From 8660f7f66b7fb779bcf3a7569effeecc6d50e287 Mon Sep 17 00:00:00 2001 From: Keefe Date: Fri, 17 Dec 2021 18:09:24 +0800 Subject: [PATCH] add bep126 --- BEP126.md | 169 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 BEP126.md diff --git a/BEP126.md b/BEP126.md new file mode 100644 index 00000000..2228df14 --- /dev/null +++ b/BEP126.md @@ -0,0 +1,169 @@ +# 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 a block has gotten enough votes from validators as an attestation. +5. Set the vote attestation into the extra field of the header while proposing a child block. +6. Validators and full nodes who received the child block with the block's attestation can justify the block. +7. The previous latest justified block then get 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 wait until enough blocks have been produced +to ensure a probabilistic finality. For BSC, with 21 validators, full nodes and validators can wait 1/2*21+1=11 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. Validators always vote once and only once on one height (Rule 1) +2. Validators always vote for the child of its previous vote within a predefined n blocks. (Rule 2) + +For BSC, validator number v is 21, the predefined n is ½*v+1 = 11, we have the consensus that the longest fork in BSC +should be no longer than n. + +#### 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 one **unfinalized nearest ancestor** block gathered ¾*v+ votes from valid +validators, they should aggregate these votes as an attestation for the ancestor block. We call this ancestor block as +the attested block. +2. The distance height between the attested block and mining block should no longer than ¼*v when aggregating the votes. +3. The distance height between the attested block and finalized block should no longer than ¼*v when aggregating the votes. + +#### 5.1.3 Finality Rules +A block either finalized by default n blocks finality or fast finalized by fast finality rules. +There are two steps to fast finalize a block, the first step we call justify, the second step we call finalize. + +1. Once a block has an attestation in its header, the attested block is justified. +2. Then the last justified block by the current attested block is finalized. +3. The attestation can be inherited, if the block has no new attestation, it will inherit its parent block’s attestation. + +#### 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. + +As the block voted by more than ¾ validators within n blocks is considered as “justified”, it should be considered as the +longest chain even though there are other chain forks with higher difficulty sum. + +Under the validators vote rules, we can be sure no more than one fork will include attestation at the same time. So our +longest chain rule can be described as follows. + +1. The fork that includes the higher attested block is considered as the longest chain. +2. When the attested block is the same, fall back to compare the sum of the “Difficulty” field. + +### 5.2 Theory Proof +If more than ½ validators are honest and behave under the above rules, we have several conclusions: + +1. Fast finality should happen within n-1 blocks. +2. Two blocks in different forks can’t be finalized at the same time. + +The block can’t be finalized by fast finality, it will be finalized by n blocks finality in default, from above, we have +the conclusion: + +**Honest validators always get the same finalized block.** + +In the next prove parts, we assume that blockX is the common parent of two forks and has been finalized, the first fork's +block we name them from blockA to blockE, etc. the second fork's block we name them from blockA1 to blockE1, etc. + +For the fist fork, blockC has the attestation for blockA, blockE has the attestation for blockC, there is no attestation +on the second fork. + +#### 5.2.1 Fast finality should happen within n-1 blocks +From the **Aggregate Votes Rules**, we have that the distance between blockX and blockC should no longer than ¼* v, and +the distance between blockX and blockE should no longer than ¼* v either, so we know the distance between blockX and blockE +should no longer than ½*v = n-1. + +#### 5.2.2 Two blocks in different forks can’t be finalized at the same time +We have the precondition that the longest fork in BSC wouldn’t longer than ½*v, then we assume two blocks (blockA and blockA1) +in different forks have been finalized at the same time, we analyze two scenarios to prove this should not happen. + +**a. Both finalized by fast finality** + +⇒ The worst case: out of total 2f+1 validators, f+1 are honest validators, while f are malicious validators + +⇒ Both blockA and blockA1 gets at least V=3*(2f+1)/4 + votes. + +⇒ At least K= V-f honest validators vote for blockA, so does blockA1, where K = V-f > 3*(2f+1)/4 -f = f/2 + ¾ + +⇒ as K > f/2 + 3/4, and 2K > f + 1, At least one honest validator voted for both blockA and blockA1, and the distance +between blockA and blockA1 is smaller than n. + +⇒ If blockA and blockA1 are on the same height, above conclusion breaks Rule 1, if not, above conclusion breaks Rule 2. + +**b. One finalized by fast finality, the other finalized by n blocks finality** + +We assume blockA and blockA1 are the same height, and blockA is finalized by fast finality, blockA1 is finalized by n blocks finality. + +=> BlockA has been finalized when received blockE, blockE justify blockC, and blockC finalize blockA. + +=> From blockE’s attestation, we know there are ¾*v+ validators have received blockC. + +=> From the longest chain rules, because blockC justify blockA, so there are ¾*v+ validators should mine based on blockA +after they have received blockC. + +=> That means no more than ¼* v will ming bases on blockA1, as we know the distance between blockC and blockX should no +longer than ¼* v, we know that blockA1’s fork wouldn’t longer than ½* v, that means blockA1 can’t get finalized by +n = ½*v+1 blocks finality. + +### 5.3 Reward +In order to make the block get finalized faster, once the validators see the votes for the block are more than ¾ 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 attestation wrapped within one block, within two blocks and others, their reward weight would be 8:4:1 +* The reward will be paid by our system reward contract + +### 5.4 Slash +#### 5.4.1 Slash Rules +* The validator who violates the 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 remaining 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/).