-
Notifications
You must be signed in to change notification settings - Fork 554
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
182 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,182 @@ | ||
| # BEP-126: Introduce Fast Finality Mechanism | ||
|
|
||
| - [BEP-126: Introduce Fast Finality Mechanism](#bep-97-introduce-fast-finality-mechanism) | ||
| - [1. Summary](#1-summary) | ||
| - [2. Abstract](#2-abstract) | ||
| - [3. Status](#3-status) | ||
| - [4. Motivation](#4-motivation) | ||
| - [5. Specification](#5-specification) | ||
| - [6. License](#6-license) | ||
|
|
||
| ## 1. Summary | ||
|
|
||
| This BEP introduces a fast finality mechanism on the BNB Smart Chain. | ||
|
|
||
| ## 2. Abstract | ||
|
|
||
| BEP-126 Proposal describes a fast finality mechanism to finalize a block, once the block has been finalized, it won't be | ||
| reverted forever. | ||
|
|
||
| It takes several steps to finalize a block: | ||
| 1. A block is proposed by a validator and propagated to other validators. | ||
| 2. Validators use their BLS private key to sign for the block as a vote message. | ||
| 3. Gather the votes from validators into a pool. | ||
| 4. Aggregate the BLS signature if its direct parent block has gotten enough votes when proposing a new block. | ||
| 5. Set the aggregated vote attestation into the extra field of the new block's header. | ||
| 6. Validators and full nodes who received the new block with the direct parent block's attestation can justify the direct parent block. | ||
| 7. If there are two continuous blocks have been justified, then the previous one is finalized. | ||
|
|
||
| The finality of a block can be achieved within two blocks in most cases, this is expected to reduce the chance | ||
| of chain re-organization and stabilize the block producing further. | ||
|
|
||
| ## 3. Status | ||
|
|
||
| This BEP is working in progress. | ||
|
|
||
| ## 4. Motivation | ||
|
|
||
| Finality is critical for blockchain security, once the block is finalized, it would not be reverted anymore. The fast | ||
| finality feature is very useful, users can make sure they get the accurate information from the latest finalized block, | ||
| then they can decide what to do next instantly. | ||
|
|
||
| Currently, on BNB Smart chain, all the full nodes and validators need to wait until enough blocks have been produced | ||
| to ensure a probabilistic finality. For BSC, with 21 validators, full nodes and validators can wait 2/3*21+1=15 blocks | ||
| to ensure a relatively secure finality, it would be quite long time for some critical applications. | ||
|
|
||
| ## 5. Specification | ||
| ### 5.1 Fast Finality Mechanism | ||
| We introduce a vote mechanism to reach fast finality, the whole mechanism includes several rules in vote and consensus. | ||
|
|
||
| #### 5.1.1 Validator Vote Rules | ||
| Validators can vote for blocks if they think that block should be in the canonical chain, and once their votes have been | ||
| wrapped into the header, they will get rewards. At the same time, they should obey the vote rules, the vote rules can be | ||
| described as follows. | ||
|
|
||
| 1. A validator must not publish two distinct votes for the same height. (Rule 1) | ||
| 2. A validator must not vote within the span of its other votes . (Rule 2) | ||
| 3. Validators always vote for their canonical chain’s latest block. (Rule 3) | ||
|
|
||
| Define the following notation: | ||
| * _s_ : the block hash of the latest justified block in the longest chain(the “source”) | ||
| * _t_ : the expected longest chain head block hash that is a descendent of s (the “target”) | ||
| * h(_s_): the height of block _s_ | ||
| * h(_t_): the height of block _t_ | ||
| * <_v_, _s_, _t_, h(_s_), h(_t_)> : validator _v_’s vote message | ||
| * _a_ -> _b_ : super majority link that ⅔*v+ validators have voted with source _a_ and target _b_ | ||
|
|
||
| The Rule 1 and Rule 2 can be described as for any two votes: | ||
| 1. h(*t*1) == h(*t*2) is not allowed. (Rule 1) | ||
| 2. h(*s*1) < h(*s*2) < h(*t*2) < h(*t*1) is not allowed. (Rule 2) | ||
|
|
||
| #### 5.1.2 Aggregate Votes Rules | ||
| The valid vote messages should be saved to the block header, before that the miner should first aggregate these votes, | ||
| the rules for aggregating votes can be described as follows: | ||
|
|
||
| 1. When validators mining blocks, if they see its direct parent block has gathered ⅔*v+ votes from valid validators, they | ||
| should aggregate these votes as an attestation for the parent block. We call this direct parent block as the attested | ||
| block. We assume 1 block time is totally enough for validators to receive a block, vote for the block and propagate the | ||
| vote to other validators. | ||
|
|
||
| #### 5.1.3 Finality Rules | ||
| There are two steps to finalize a block, the first step we call justify, the second step we call finalize. | ||
|
|
||
| 1. A block is called justified if | ||
| * (1) it is the root, or | ||
| * (2) there exists attestation for this block in its direct child’s header, we call this block **vote justified**, or | ||
| * (3) the height distance between this block and the current header is longer than ⅔*v, and there is no block vote justified, | ||
| we call this block **naturally justified**. | ||
| 2. A block is called finalized if | ||
| * (1) it is the root, or | ||
| * (2) it is vote justified and its direct child is vote justified. | ||
|
|
||
| #### 5.1.4 Longest Chain | ||
| In the Parlia and Clique consensus, the validators will rely on the sum of the “Difficulty” field to compare and confirm | ||
| which chain is the longest to pick as the ancestor. | ||
|
|
||
| While introducing this finality mechanism, the chain should grow based on the finalized block, so the fork including the | ||
| highest finalized block should be considered as the longest chain even though there are other chain forks with higher | ||
| difficulty sum. If there is no new block that can be finalized during some time, the chain can grow with the previous | ||
| longest chain rule, which can make the chain remain original probabilistic finality. | ||
|
|
||
| The new longest chain rule can be described as follows. | ||
|
|
||
| 1. The fork that includes the higher finalized block is considered as the longest chain. | ||
| 2. When the finalized block is the same, fall back to compare the sum of the “Difficulty” field. | ||
|
|
||
| #### 5.1.5 Validator Liveness | ||
| In the current Parlia consensus, the validator liveness is ½*v+1=11, which means when there are more than 11 validators | ||
| online, the chain can get increased continuously. | ||
|
|
||
| In this design, we should change the liveness from ½*v+1=11 to ⅔*v+1=15, this can protect the chain from getting increased | ||
| in a malicious fork. | ||
|
|
||
| ### 5.2 Theory Proof | ||
| Assume the malicious validators are less than ⅓*v, honest validators are more than ⅔*v, honest validators always behave | ||
| under the above rules, the vote can be propagated to all validators within one block time, then we can prove this fast | ||
| finality mechanism has accountable safety and plausible liveness. | ||
|
|
||
| Accountable safety means that two blocks in different forks cannot both be finalized unless more than ⅓*v validators | ||
| violate the voting rules. | ||
|
|
||
| Plausible liveness means that, regardless of any previous events, if ⅔*v+ validators follow the mechanism, then it’s | ||
| always possible to finalize a new block without any validator violating the vote rules. | ||
|
|
||
| Under the assumption that less than ⅓*v validators violate the vote rules, we have the following properties: | ||
|
|
||
| 1. If *s*1 -> *t*1 and *s*2 -> *t*2 are distinct super majority links, then h(*t*1) != h(*t*2). | ||
| 2. If *s*1 -> *t*1 and *s*2 -> *t*2 are distinct super majority links, then the inequality h(*s*1) < h(*s*2) < h(*t*2) < h(*t*1) cannot hold. | ||
|
|
||
| From these two properties, we can immediately see that, for any height n: | ||
|
|
||
| 3. there exists at most one super majority link _s_ -> _t_ with h(_t_) == n. | ||
| 4. there exists at most one vote justified block with height n. | ||
|
|
||
| With these four properties in hand, we move to the main theorems. | ||
|
|
||
| #### 5.2.1 Accountable Safety | ||
| **Theorem 1 (Accountable Safety).** Two blocks in different forks cannot both be finalized. | ||
|
|
||
| Let Am (with vote justified Am+1, meaning h(Am) + 1 == h(Am+1)) and Bn (with vote justified direct child Bn+1, meaning | ||
| h(Bn) + 1 == h(Bn+1)) be distinct finalized blocks as following figure. Now suppose Am and Bn are on different forks, | ||
| and without loss of generality h(Am) < h(Bn) (If h(Am) == h(Bn) it is clear that at least one honest validator violated | ||
| Rule 1). | ||
|
|
||
| Bn is finalized, so there must exist a super majority link R -> B1, …, Bi - > Bi+1, …, Bn -> Bn+1. We know no super majority | ||
| link’s target h(Bi) equals either h(Am) or h(Am+1), because that violates property 4. | ||
|
|
||
| Let j be the lowest integer such that the super majority link’s target h(Bj) > h(Am+1). If the super majority link’s | ||
| source is vote justified , we have h(Bj-1) < h(Am+1), and h(Am) = h(Am+1)-1, so h(Bj-1) < h(Am); this implies that the | ||
| existence of a super majority link Am -> Am+1 within the span of Bj-1 -> Bj, this violates the vote Rule 2. If the super | ||
| majority link’s source h(Bj-1) is naturally justified, and if h(Bj-1) >= h(Am), because of the probabilistic finality, | ||
| we won’t let the Am+1 block insert to the chain, so this won’t happen; if h(Bj-1) < h(Am), this violates the vote Rule 2. | ||
|
|
||
| #### 5.2.2 Plausible Liveness | ||
| **Theorem 2 (Plausible Liveness)**. Super majority links can always be added to produce new finalized blocks, provided there exist children extending the finalized chain. | ||
|
|
||
| We have two kinds of justified block: vote justified and naturally justified block, with the justified block grow, the | ||
| validators can always start new round voting without violating any vote rules, then we know there always will be new | ||
| vote justified blocks, and once one of its direct child block has been vote justified, this block can be finalized without | ||
| violating any vote rules. | ||
|
|
||
| ### 5.3 Reward | ||
| In order to make the block get finalized faster, once the validators see the votes for the block are more than 2/3 validators, | ||
| these votes will be wrapped and the reward will be distributed to these wrapped voted validators, the remained validators | ||
| who didn’t vote for the block or vote later won’t get reward. | ||
|
|
||
| #### 5.3.1 Reward Rules | ||
| * Validators whose vote is wrapped into the vote attestation can get reward | ||
| * The reward will be paid by our system reward contract and distributed at the end of the epoch | ||
|
|
||
| ### 5.4 Slash | ||
| #### 5.4.1 Slash Rules | ||
| * The validator who violates the first two vote rules will be slashed | ||
| * The evidence can be submitted by anyone, whenever someone sees the malicious behavior, he can submit the evidence to a | ||
| designed system contract | ||
| * Once the evidence has been proved valid, the malicious validator will be put into jail, | ||
| the submitter can get part of the rewards from our system reward contract. | ||
| * Once the malicious validator has been put into jail, the later submitters that submit malicious evidence of the | ||
| validators won’t get any reward. | ||
|
|
||
| ## 6. License | ||
|
|
||
| The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |