add bep126

BEP126.md

@@ -0,0 +1,132 @@
+# 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 for finality from validators.
+5. Set the block's finality information into the finality field of the header while proposing a child block.
+6. Validators and full nodes who received the child block with the block's finality information can finalize the block.
+
+The finality of a block can be achieved within one or 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. According to the whitepaper, with 21 validators, full nodes and validators can
+wait ⅔*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 assume that validators set are fixed and more than ½ validators are honest, the honest validators won’t violate
+these two rules:
+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)
+
+Once a full node sees ¾+ validators signed on one block, the block will be treated as finalized and never reverted.
+Otherwise, all the full nodes and validators can still wait until enough blocks have been produced to ensure the
+probabilistic finality. For BSC, with 21 validators, full nodes and validators can wait ⅔*21+1=15 blocks to ensure a
+relatively secure finality, in this case, the predefined n can be set to 15.
+
+### 5.2 Theory Proof
+#### 5.2.1 Validators Set is Fixed
+
+**Proposition:  A block is said to be in “finalized status” if it gets voted by more than ¾ validators. If more than
+½ validators are honest and behave under the above Rule 1 and Rule 2, honest validators can only vote one chain into a
+finalized status if they vote within n block time, where n is the same predefined number in Rule2 above.**
+
+We can prove the above proposition by proving the assumption is impossible to happen:
+
+**Assumption: Honest validators under Rule 1 and Rule 2 can vote two blocks on two different chain forks into finalized
+within n block periods.**
+
+⇒ The worst case: out of total 2f+1 validators, f+1 are honest validators, while f are malicious validators.
+
+⇒ Both Block A and B gets at least V=3*(2f+1)/4 + votes.
+
+⇒ At least  K= V-f honest validators vote for Block A, so does block B, where K = V-f > 3*(2f+1)/4 -f = f/2 + ¾  > f/2.
+
+⇒ As K > f/2, and 2K > f, At least one honest validator voted for both Block A and Block B, and the distance between
+block A and B is smaller than n.
+
+⇒ If block A and block B on the same height, above conclusion break Rule 1, if not,  above conclusion break Rule 2.
+
+Once the n blocks finality can be ensured by consensus protocol, then we have the conclusion: **Honest validators always
+get the same finalized block.**
+
+#### 5.2.2 Validators Set is Changed
+
+Above mechanism needs a precondition that the validators set is fixed, this can be satisfied within an epoch, but
+validators will be reelected when epoch is over, so we should deal with the validators set change between different epochs.
+
+As the Rule 2 can’t prohibit new validators’ vote on the first block of the epoch, we take the following rules to deal
+with this scene:
+* New validators’ votes for the first n blocks of each epoch won’t be involved as valid finality votes, this will be ensured by consensus protocol.
+* If the new validators number is less than ¼ validators, the fast finality works as normal, the first n blocks also
+have chance to get ¾+ votes.
+* If the new validators number is more than ¼ validators, then the first block of the epoch has to wait until n blocks
+have been produced, this block has no chance to get fast finality, and the remaining first n-1 blocks may get finalized
+when the n+1 block gets ¾+ votes.
+
+### 5.3 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 ‘finalized’, it should be considered as
+the longest chain even though there are other chain forks with higher difficulty sum. This can be implemented by
+validators to drop any new chain forks that have non-finalized blocks at the same height.
+
+This is expected to reduce the chance of chain re-organization and stabilize the block producing further.
+
+### 5.4 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.4.1 Reward Rules
+* Validators whose vote is wrapped into the vote attestation can get reward
+* The block get finalized 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.5 Slash
+#### 5.5.1 Slash Rules
+* The validator who violates the two 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/).