EOS.IO is a Blockchain system following BFT-DPOS (Byzantine Fault Tolerance - Delegated Proof of Stake) consensus. In this article, I will explain the workflow of EOS and compare it with Ethereum that is a PoW (Proof of Work) Blockchain. In the following, you can know
- Footprint of transactions in EOS.IO
- BFT-DPOS consensus algorithm in EOS.IO
- Comparison between EOS and Ethereum
Footprint of transactions in EOS.IO
To understand a Blockchain system, tracing how transactions flow in system is an effective method. The trip of a transaction starts from “created by wallet” and ends at “recorded in block / discarded”. Let’s see which components are passed by transactions and what mechanisms are used.
1. Create transaction
The transaction is created by user’s wallet. Wallet helps users to interact with Blockchain system. In EOS, a transaction looks like:
1 | { |
From line 2 to 8, they claim some metadata about this transaction. Line 12 shows that this is a “transfer” action. From line 20 to 23, they claim that account “jkigcd4uli3s” transfers “5346.0014 EOS” to account “yjo3cd2keflz”. Line 25, “hex_data” shows the hash of transaction. This hash value is used to confirm that this transaction is generated by account’s owner.
2. Broadcast transaction
After wallet generates the transaction, transaction is located at EOSIO consumers layer. So far, this transaction is not admitted by entire network until it is sealed in one of valid block.
The figure above illustrates the EOSIO network architecture. In this architecture, network consists of 3 layers: consumers network, access network, and core network. Transactions are generated in consumers network firstly. Then, access network will check their validation, like signature, account balance. Only valid transactions will be sent to core network. Core network consists of 21 block producing (BP) nodes that will check the validation of transactions and seal transactions in blocks.
More details about EOSIO full scale network are introduced in here.
3. Seal transactions in block
So far, a default maximum size of block is 5MB. It’s wasteful if we only put one transaction in a block. In general, BP will put a bunch of transactions into one block and publish block to entire network. After this step, transaction is transmitted as a part of the block. A block structure looks like:
1 | { |
Line 2-11 and 60-63 are some metadata about this block, such as timestamp, previous block id, producer id, producer signature, block number. In lines 27-57, we only show one of transactions in “transaction”. Line 27-53 is the data generated by wallet. The other information are generated by producer, like CPU usage and network usage for this transaction.
4. Admitted by entire network
So far, block and transactions in it are only admitted by its producer. To ensure that this transaction is irreversible, people still need to wait for the responses from more than 2/3 (14) BPs. If more than 2/3 BPs admit/reject this block, transactions in this block is irreversible.
Above figure presents the life cycle of publishing a new block to network. (cited from blog)
- Propose block: Broadcast block to the other BPs
- All the BPs acknowledge block (pre-commitment): Check validation and sign block
- All the BPs ackowledge when >2/3 have sent them pre-commitments (commitment)
- A block is final once a node has received >2/3 commitments
- Unanimous agreement on finality is guaranteed unless >1/3 are bad and evidence of bad behavior is available to all.
Now, user can confirm that his/her transaction is recorded in Blockchain irreversibly.
BFT-DPOS consensus algorithm in EOS.IO
Consensus algorithm is the soul of Blockchain system. As a distributed system, Blockchain system depends on consensus algorithm to realize the cooperation between different machines. EOS.IO utilizes BFT-DPOS consensus algorithm. This algorithm is an integration of Byzantine Fault Tolerance and traditional DPOS.
BFT (Byzantine Fault Tolerance) is the characteristic which defines a system that tolerates the class of failures that belong to the Byzantine Fault [1]. In EOS Blockchain system, Byzantine Fault [2] comes when one or more BPs (Block Producers) have abnormal behaviors, such as sealing invalid transactions in block. BFT mechanisms will protect system if less than 1/3 BPs behave abnormally/maliciously. Actually, this mechanism has been introduced in previous section.
DPOS (Delegated Proof of Stake) is a specific version of PoS (Proof of Stake). In PoS consensus, the producer of the next block is chosen via various combinations of random selection and wealth or age. If the producer tries to cheat system, producer will lose stake. Meanwhile, these stake will reward honest producers. This economic incentive encourages producers to check the validation of blocks and transactions. As a consequence, PoS protects the security of Blockchain system.
In contrast to general PoS, DPOS does not depend on a random method to choose next block producer. Blocks can only be created by a group of elected nodes. So, the DPOS algorithm is divided into two parts: electing a group of block producers and scheduling production [3].
In the election part, every user (account) can vote for 30 producer candidates and the weight of their vote depends on stake in their account (stake means tokens will be locked up for 3 days after being un-staked). Voting is an ongoing process, with votes being recalculated approximately every 2 minutes. After calculating votes, system will choose the top 21 candidates to be BPs in this turn.
In the production part, I cite description in EOS white paper [4].
The EOS.IO software enables blocks to be produced exactly every 0.5 second and exactly one producer is authorized to produce a block at any given point in time. If the block is not produced at the scheduled time, then the block for that time slot is skipped. When one or more blocks are skipped, there is a 0.5 or more second gap in the blockchain.
Using the EOS.IO software, blocks are produced in rounds of 126 (6 blocks each, times 21 producers). At the start of each round 21 unique block producers are chosen by preference of votes cast by token holders. The selected producers are scheduled in an order agreed upon by 15 or more producers.
There is something that should be noticed. So far, a BP produces 12 blocks consecutively but not 5 blocks [5]. I think that this difference may come from carelessness of developer.
In EOS, production schedule is consulted by 21 BPs (“The selected producers are scheduled in an order agreed upon by 15 or more producers.”). Definitely, this design increases the centralization of EOS. Meanwhile, it is easy for BPs to collude with each other. However, you pays and you takes. This design reduces confirmation time of new block from 45 seconds to 3 seconds. In most cases, block can be confirmed within 1 second.
Top 21 BPs will earn a 0.25% per block reward on a pro-rata basis to the number of blocks each one produces. All BPs (active + standby) will also earn a .75% per vote reward on a pro-rata basis to the total number of votes they receive. Planned EOS annual inflation allocation are presented below [6].
Although DPOS seems more centralized than PoS, this centralization does not mean that system is controlled by this 21 BPs. Vote mechanism can also protect system from malicious BP.
A block producer caught doing this will likely be voted out. Cryptographic evidence of such double-production may also be used to automatically remove abusers.
Comparison between EOS and Ethereum
EOS | Ethereum | |
---|---|---|
Consensus | DPOS | PoW |
Block interval | 0.5s | 10-19s |
Contract? | True | True |
Decentralization | Low | High |
Conrimation time | ~1s | ~3min |
Transaction fee | 0 | 0.00071 ETH (avg) |
TPS | ~15 | ~60 (max ~4000) |
The table above presents the difference between EOS and Ethereum.Different consensus algorithms make two systems perform different features. Compared with PoW, DPOS sacrifices decentralization to achieve a higher performance, such as low block interval, zero transaction fee. The voting mechanism protects part of decentralization. Publics can still control this system by vote, even if it depends on the coins they own.
In PoW system, system will waste massive resources on computing a valid hash value brutally. The only redundant calculation in DPOS system is from BPs who process the same transactions.
Although EOS claims that its performance can achieve millions transactions per second. So far, it sits far from this value. The performance may be limited by BPs’ infrastructure or the number of new transactions.
Thanks for voting mechanism, to attract more votes, most of BPs have their website introduce themselves. One of BP’s infrastructure is shown below [7].
Intuitively, if this is the average status of top 21 BPs infrastructure, I don’t think they are ready for handling millions of transactions per second.
Conclusion
Although EOS.IO is a more centralized Blockchain system, I’m interested to observe the development of this community. Especially, there may be some interesting Dapps in the future when they are released from TPS restriction. Moreover, we may observe this project not only from computer science but also from sociology, thinking how would a commodity grows up if its vote weight depends on its wealth.
During the journey of exploring EOS.IO, I find some blogs that may help you to build a private EOS.IO network.
If you find any error in this article, feel free to contact me by email.
[1] Understanding Blockchain Fundamentals, Part 1: Byzantine Fault Tolerance
[2] Byzantine fault (From Wikipedia)
[3] DPOS Consensus Algorithm - The Missing White Paper
[4] EOS.IO Technical White Paper v2