This BEP introduces a fast finality mechanism on the BNB Smart Chain.
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:
- A block is proposed by a validator and propagated to other validators.
- Validators use their BLS private key to sign for the block as a vote message.
- Gather the votes from validators into a pool.
- Aggregate the BLS signature if a block has gotten enough votes for finality from validators.
- Set the block’s finality information into the finality field of the header while proposing a child block.
- 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.
This BEP is working in progress.
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.
We assume that validators set are fixed and more than ½ validators are honest, the honest validators won’t violate these two rules:
- Validators always vote once and only once on one height (Rule 1)
- 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.
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.
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.
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.
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.
- 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
- 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.
The content is licensed under CC0.