TLDR: Try out the networking layer at https://web.fledg.re !
Bring back the fun - remember when bitcoin was there to change the world?
Do you remember building your first webpage? Sending your first email? Installing your first webserver?
Well, this project is for you: build something without having to install a lot of infrastructure. Learn how blockchains work, and what you can do with them.
Easy setup - no need to configure your node or your own network - just start the docker
Fledger only asks you one of two things thing:
- connect to https://web.fledg.re and start mining
- Run the following on your server:
wget https://github.com/ineiti/fledger/raw/main/docker-compose.yaml docker-compose up -d
Either will connect to the library chain, get the latest block within seconds, then participate in finding mining transactions to earn Mana. It will also offer some of your docker power as a service to other participants. Of course, if they use your node, you get more Mana. No port-opening needed, no TLS setup, no downloading a lot of data - just start it.
Fast rewards - once your node is running, get direct (small) rewards within minutes
The goal of Fledger is to make participation easy. If you run your own node, you are guaranteed that within 3 minutes you will get your first Mana to spend on transactions.
Actually useful - offer and use memory, HD, CPU, network bandwidth
Other blockchain projects, like filecoin, set up a huge environment to serve files. But there are other assets, too. The goal of Fledger is to allow each node to easily share
- CPU/GPU power - what Ethereum is already doing
- Memory (RAM and harddisk/SSD) - like filecoin
- Bandwidth - used for example when hosting webpages
- Trust - using DARCs
And to earn Mana in doing so, which can be used in turn to buy necessary resources.
From a technological point of view, use the following goodies described by the Chainiac, Byzcoin, and OmniLedger papers:
Every block is final - by using a fast BFT algorithm, no forks can happen
If the acceptance of a new leader is also included in this signature round, then there is no need to wait for a certain number of blocks before considering its transactions to be final.
The big downside of this method is the need to know the set of nodes that should sign, and how to securely sign the new blocks in a byzantine fault tolerant way. PBFT signing is very expensive, this is why ByzCoinX has been proposed in OmniLedger as a fast and secure way to sign new blocks.
Multi-level ForwardLinks - small proofs: no need to look at all block headers to confirm a transaction
- downloading all headers takes time
- calculating the hash of all the headers takes time
Chainiac introduced forward-links that go from block n-1 to block n, but also every multiple of _k^i_th block to the block n+k^i. With k = 2, the links would be:
- block-# -> forward-links
- 0 → 1, 2, 4, 8, 16
- 1 → 2
- 2 → 3, 4
- 3 → 4
- 4 → 5, 6, 8
If the latest block is #17, instead of having to download and verify 17 hashes, it is enough to have the hash of block 0, the forward-link #0 → #16, and the forward-link #16 → #17. This is implemented in the current version of ByzCoin by the DEDIS-lab and allows to reduce the proof of the latest block in a chain with 100'000 blocks to a mere 24 forward-links.
Sharding - cut the processing power of the nodes in little units so that more nodes means more speed
- An attacker might concentrate his attack on one shard, which is easier than the whole set of nodes
- Inter-shard communication is difficult to get right
The OmniLedger paper proposes how to overcome these problems. It gives the probability of an attacker being able to create a faulty shard, given the shard size and the total number of nodes.
The following elements are purely engineering stuff, and hopefully not too bad of a choice. If you're a PhD student and want to work on these ideas, feel free to get in contact with me ;)
Adaptable difficulty - let slow nodes participate in the network
To accomodate all of these different types of nodes, Fledger uses a hierarchical structure with the fastest nodes on top. Nodes are incentivized to join the top by getting more reward than if they would split themselves up and participate as multiple nodes. To avoid attacks on the lower groups they are vetted by their parents, and misbehaving nodes or groups will be banned - or at least their Mana will be removed.
Proof of Useful Work - prove you're a useful node by validating other transactions
The idea is that at the start of each epoch (1 minute), all nodes must race to verify as many transactions as possible from other shards. The transactions each node must work on are only known at the start of an epoch. Also, every node has another set of transactions it needs to process. The amount of transactions each node managed to verify defines the amount of work this node is able to do. Faster nodes rise up, while slower nodes go down in the pyramid.
Of course there are a lot of problems with this approach:
- Nodes might use more power just for this PouW round
- This is why all nodes need to do it at the same time, to avoid some collusion
- Making the batch of transactions only available at the latest moment
- Probably some BLS signature magic where the threshold signature is not known in advance and where the signing nodes cannot predict or influence the signature
- It's still somewhat wasteful
- The verification of other transactions helps to stabilize the system by disincentivizing nodes to cheat, as they will be found out
- Verifying the verification
- Nodes might just say: "Hey, I verified all these transactions, and they are OK".
How to make sure the verifications are really OK?
- Inserting wrong transactions and verifying that the wrong transactions are caught
- Binding the transactions somewhat to the node and the nonce used for the PouW round
- Inserting random transactions where the result is not known in advance, and where the verifying node does not know it's a random transaction
- Nodes might just say: "Hey, I verified all these transactions, and they are OK". How to make sure the verifications are really OK?
Heavy Transaction / Small Global State - instead of having a huge global state, the client needs to keep track of its own memory
Instead of holding the full state of every account or UTXO in the ledger, this information is kept by the client. If a client wants to send in a transaction, she needs to send the following:
- The account-#
- A proof of the block of the latest transaction of the account
- The inclusion-proof of the account in this block
- The full memory of the account - state, smart-contract - to match the current merkle-tree root hash
- The transaction to send to the smart contract (including the signature)
All the nodes will reach consensus on the correctness of the state sent by the client and the new state, which will not be stored anywhere. The block will only have the merkle-tree root of all accounts. The inclusion-proofs of the new state can be stored in a temporary memory that can be deleted later, as they can be re-created when needed from the information in the block.
Forgetting stuff over time
Current blockchains keep the state of everything around, for all time. Even though there are some checkpoint features that allow to prune old UTXOs. Fledger proposes to allow forgetting of accounts / UTXOs in multiple steps, by requiring mana for holding the information. The following parts can be chosen by the user:
- Duration of a UTXO - for every new block / every epoch, the UTXOs value decreases, unless it's been integrated in an account. Once the UTXOs value goes to 0, the nodes of the shard can split up the UTXO in their accounts, and the UTXO disappears
- Account - which needs to pay for being hold on the chain. Every block / epoch, some of the accounts mana is distributed to the nodes, depending on how much storage the account uses:
- Low storage: if the account is fully off-chain, the chain still needs to store the merkle-tree root and the version in the global state. But this is very little memory.
- High storage:
DeFi related - the goal of Fledger is not to allow financial transactions fast and securely
an investment product - Mana will be sold at a stable price for those wanting to profit from the resources of the network
- The author of Fledger dreams of working only on this project - so he allows himself to influence the Mana economy by selling them at a fixed price to pay the development of Fledger
- The standard distribution of Fledger always includes at least one node of the main developer in the top shard
If you wish to participate, here some more information:
In its current state, Fledger is for you if you:
- love trying out new stuff
- know some rust / typescript
- want to bring out the anarchist in you - but still want consensus on some issues
- have a running server connected 24/7 on the internet or are ready to let your browser do some work
The minimum viable product allows nodes to publish a static webpage and let it run on the network. The roadmap to do this is the following:
- Network using WebRTC - 70% done - first version runs in Chrome, Safari, Firefox and node
- Onboarding of new nodes - Specs are done
- Nodes can offer disk space
- CLI to put a static page on Fledger and a viewer
- Add a plugin to Hugo to put the site on Fledger
ETA - End of 2021? Very ambitious. Please join ;)
Go to https://github.com/ineiti/fledger and participate in an issue, or create a PR.