A basic concept
(1) Byzantine Fault Tolerance
Byzantine Fault Tolerance (Byzantine fault tolerance) comes from the problem with the Byzantine generals. The problem can be expressed as several generals attacking the city from multiple places. It is known that only when all of them decide to attack or not to attack at the same time can victory or no damage be guaranteed. The problem is how to reach agreement in the presence of traitors.
Simple Application Server
USD1.00 New User Coupon
* Only 3,000 coupons available.
* Each new user can only get one coupon(except users from distributors).
* The coupon is valid for 30 days from the date of receipt.
The Byzantine fault-tolerant system is a means to solve the decentralized consistency risk caused by the Byzantine Generals problem. That is, in the case of malicious behavior of individual distributed nodes, the Byzantine fault-tolerant system can still correctly complete the consistency confirmation.
The existing mainstream bottom chain frameworks that use the BFT consensus mechanism include:
Fabric: PBFT (Practical Byzantine Fault Tolerance)
EOS: PBFT (pipelined Byzantine Fault Tolerance)
BCOS: BFT (batch Byzantine Fault Tolerance)
(2) LIB
LIB: last Irreversible Block, the last block that cannot be modified will be marked as LIB.
If a block is deemed irreversible, it means that you can trust with 100% confidence that that transaction is final, fully confirmed, and immutable. If the block number of a block is lower than the Last Irreversible Block, that means it is considered final . Commonly abbreviated as LIB.
Consensus algorithm
(1) EOSIO
EOSIO uses a P (pipelines) BFT algorithm. Each block needs to go through the Propose, Pre-commit, Commit, and Finalise stages. The unmodifiable time of the transaction is about 3 minutes (the theoretical minimum is 325 block time, which is about 162.5 seconds).
But the pipelined verification process has the problem of low efficiency. After each block is generated, it will be broadcast to all other verification nodes for verification, but each node that receives the confirmation information can only express its own opinions in turn (ie block confirmation). Finally, a block can be confirmed after a round of looping.
(2) BOS
The BOS network uses the P (Practical) BFT mechanism instead of the P (Pipelined) BFT. Under this mechanism, each BP can immediately confirm the block.
Modifications to EOS at the code level:
The mechanism of circular block generation in the original consensus is retained, and the strong restrictions on clock synchronization and block generation sequence are still retained.
Deleted part of the logic of the confirmation link to avoid conflicts with the new consensus mechanism in edge cases.
Keep the communication mechanism of the P2P network to ensure that the communication cost is acceptable
The single-block mechanism is replaced by batch consensus, and multiple blocks are broadcast at once, which is close to real-time BFT effect and reduces network load.
The process of PBFT in BOS can be expressed as:
Pre-prepare
After a block is generated, it is broadcast to other block producers.
Prepare
When a block producer receives the verification request and the verification is successful, it broadcasts the received information to the entire network.
Commit
When the block producer receives enough confirmations for a request, it sends the request to the entire network
Commit-local
When the block producer receives enough Commit information for a block, it will complete the block verification process, that is, the block
View: When the block producer changes, all unauthorized information is discarded, and the consensus procedure is re-attempted until the node consensus is reached.
Checkpoint: Check the consistency of the block height, used to provide security certification. When enough block-producing nodes have the same block height, the checkpoint is considered reliable. The generation of checkpoints is divided into two categories: one is the generation of fixed blocks, and the other is special points that require special security proofs.
effect:
By observing the EOS main network, the network delay between global nodes is mostly within 1 second. Based on the existing consensus mechanism of BOS, it is estimated that the block consistency process is expected to be completed within 3 seconds, that is, the immutability of the blockchain will be realized within 3 seconds.
Confusion point
(1) pipeline vs batch
This statement is used to distinguish the method of block synchronization. In pipeline block synchronization, the block producer only applies for verification of one block at a time. In the batch form, the block producing node will issue multiple block verification applications each time.
(2) DPOS BFT vs PBFT
The development of EOS inherited the ideas of the BM bosses in previous commercial attempts, and DPOS was still used to achieve it initially. The core idea of DPOS is that there is no need to waste computing resources to compete for the right to bookkeeping, but to choose 21 people to take the role of bookkeeping based on the votes of EOS holders. Those with more EOS in the vote will have more voting power and influence.
However, DPOS does not consider the factors of network delay. For example, if the nodes that take turns out of the block are in different countries, the network delay will affect the synchronization time too much. So the BM boss designed the latest mechanism as BFT-BPOS.
The latest mechanism has three major improvements to DPOS:
In BFT-DPOS, the Byzantine fault tolerance mechanism is introduced, that is, it is only necessary to ensure that the malicious node does not exceed 1/3. Under this mechanism, as long as 2/3 of the nodes can recognize the block, the consistency of the entire network can be guaranteed;
Specify the block generation sequence of BP nodes according to geographic location: China -> Japan -> United States -> Canada, etc., to ensure that block generation roles are transferred sequentially according to geographic location;
A block producer can generate a block in 0.5 seconds, but in order to increase efficiency while considering the effect of delay, each block producer will continuously generate 6 blocks. Block generation and verification are also performed synchronously. While generating blocks, other blocks are also verified and broadcasted.
The BOSCore side chain tried another idea to increase the speed.
That is, the batch processing method based on the P (practical) BFT mechanism is used to improve the original EOS code.
PBFT (Practical Byzantine Fault Tolerance), the Practical Byzantine Fault Tolerance algorithm, was proposed by Miguel Castro and Barbara Liskov in the paper "Practical Byzantine Fault Tolerance and Proactive Recovery" published in 1999. The PBFT algorithm can work in an asynchronous environment, and solves the problem of low efficiency of the original Byzantine fault-tolerant algorithm through optimization, and reduces the algorithm complexity from exponential to polynomial, making the Byzantine fault-tolerant algorithm feasible in actual system applications. Has been widely used. The PBFT algorithm can guarantee Safety and Liveness at the same time when the number of failed nodes does not exceed 1/3 of the total.
Through the batchable BFT algorithm (that is, Batch Byzantine Fault Tolerance), BOSCore has achieved second-level block confirmation and unmodifiable.
(3) What is the LIB time of EOS?
Reference here: https://blog.csdn.net/zhuxiangzhidi/article/details/82927020
For EOS's latest BFT-DPOS consensus mechanism, each block producer has 6 seconds to produce a block, and each block takes 0.5 seconds, so each block producer generates 12 blocks continuously. Regarding the design reasons, you can refer to BM's statement:
6 seconds was chosen based upon the “maximum downtime” if a producer goes off line. This matches Steem & BitShares where a single missed block creates 6 seconds without any confirmation.
Through the discussion between BM and V God, the node confirmation of DPOS is defined as two rounds.
So the total confirmation time is:
T = 2*(2/3) *21 *12 = 336 block time, and the theoretical minimum block time also requires 325, and the minimum time required is about 162.5 seconds (close to 3 minutes).
