add bep126

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/).