[BSC] BEP-126: Fast Finality Mechanism

[redragonvn]

[WIP] Preliminary Security review

BEP-126: Introduce Fast Finality Mechanism

July, 2022
Author: Verichains - https://verichains.io

Summary

This is a preliminary review of Verichains on bnb-chain/BEPs#126, which introduces a fast finality mechanism on the BNB Smart Chain. BEP-126 is still working in progress so we will go back for a more in-depth review when the implementation at a more complete stage.

Our Understanding

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.

Key change in this proposal is that a validator will also vote for a path to future blocks instead of only the next block as in the usual chain. A block will be finalized (consensus-stable) when the chain ending on it has a super majority voted weight of more than ⅔ for any block. In order to ensure accountable safety (no double spending at block level) the proposal added some constraints to the voting process, in which the key one is that a single validator cannot vote for 2 different blocks at the same height. This voting process also works just like the old branching algorithm in that new blocks can still be always appended to the chain without violating any rules (the "Plausible Liveness" in the proposal).

Another new point in this proposal is to ensure faster validation is that only first ⅔ of the validators will share the validation reward so validators must always be racing.

Main Concerns for Security Review

The security review shall focus to find any potential attacks related to the following concerns

• Someone can steal tokens from others, system accounts, or nowhere.
• The newly added function breaks the Cross-Chain communication.
• DOS attack, someone can send a particular transaction and cause the chain panic.
• The chain can revert even after finality.
• The chain halted because of the newly introduced mechanism.

Findings

As from the previous section, the proposal is well-defined and each rule is logically added for a purpose:

1. Upper bound of the number of not-finalized blocks voted by a single validator is the number of blocks in its longest chain only, so no DOS attack is possible on validation structures storage or network transfer.
2. Bad validators without majority power will waste their votes because at a single height a validator can vote only one block.

Potential Issues / Concerns

The reward rule seems problematic, as validators can cooperate together by joining a group to become a big validator with higher voting weight, to increase their rewards (saying another way, steal other's rewards), thus letting their votes take precedence over network votes. Another exploitation is to wait in the block until their own votes can be added up with the rest to reach the required ⅔ votes for block finalizing.

These problems can be mitigated but it depends on the implementation. For now, the proposal is still unclear on how the race will be implemented. We have also reviewed the current code implementation of BEP-126 (bnb-chain/bnc-cosmos-sdk#289) but it is still working in progress so we will go back to review this when the implementation is at a more complete stage.