[WIP] BEP-126: Introduce Fast Finality Mechanism (#126)

---------

Co-authored-by: NathanBSC <[email protected]>

BEP126.md

@@ -0,0 +1,186 @@
+# 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=14 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=14, 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 ⅓*v or more 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. 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 2/3 or more 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.
+
+### 5.5 Stopping Attacks
+There are two well-known attacks against proof-of stake system: *long range revisions* and *catastrophic crashes*, these
+attacks are also existed after implementing this BEP.
+
+## 6. License
+
+The content is licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).