Skip to content

BEP-590.md

Latest commit

 

History

History
94 lines (60 loc) · 4.38 KB

BEP-590.md

File metadata and controls

94 lines (60 loc) · 4.38 KB
  BEP: 590
  Title: Extended Voting Rules for Fast Finality Stability
  Status: Draft
  Type: Standards
  Created: 2025-06-25
  Description: Enhance the robustness of Fast Finality by extending aggregate vote inclusion rules.

BEP-590: Extended Voting Rules for Fast Finality Stability

1. Summary

This BEP proposes an extension to the aggregate vote inclusion rules in the Fast Finality (FF) protocol of the BNB Smart Chain. The change aims to improve the stability and liveness of Fast Finality under adverse network conditions and support further reductions in block interval.

2. Abstract

BEP-126 introduced Fast Finality as a mechanism for deterministic block finalization in BNB Smart Chain. Under the original design:

  • Proposers (miners) may only aggregate votes for their direct parent block.

Formally, if KAncestorGenerationDepth defines the inclusion scope, then in the original design:

KAncestorGenerationDepth = 1

This BEP extends the scope by allowing KAncestorGenerationDepth > 1:

  • Aggregate Vote Inclusion Extension — Proposers may include votes for up to KAncestorGenerationDepth recent ancestor blocks, improving tolerance to vote propagation latency.

This adjustment enhances the resilience of Fast Finality during periods of network congestion, without modifying the core consensus model or cryptographic assumptions.

3. Motivation

Validators can experience latency in receiving, verifying, and casting votes for blocks. Such delays may lead to missing justifications, which in turn hinders finalization.

Additionally, as block intervals shorten, inter-region network latency becomes a more prominent bottleneck in vote propagation.

This BEP addresses these issues by introducing:

  • More flexible vote aggregation — to increase the chances of including valid votes despite network delays.

4. Specification

This BEP introduces modifications to the Aggregate Vote Inclusion Rules.

4.1 Aggregate Vote Rule Changes

To improve vote inclusion under delayed network conditions, proposers are allowed to aggregate votes for recent ancestor blocks. The process follows this priority sequence:

  1. Attempt to aggregate votes for the immediate parent block.
  2. If unavailable, try the grandparent block.
  3. Continue iteratively up to KAncestorGenerationDepth recent ancestors.

The process terminates immediately once any valid vote is included. At most one ancestor block’s votes may be aggregated in a single proposal.

This rule gives validators up to KAncestorGenerationDepth block intervals to propagate their votes, improving the success rate of vote inclusion and reducing justification gaps during periods of network latency.

With the block interval reduced to 0.45s, the parameter KAncestorGenerationDepth is set to 3.

  KAncestorGenerationDepth = 3

5. Security

This BEP does not alter the core safety assumptions or mechanisms of Fast Finality defined in BEP-126. Specifically, it does not change:

  • Validator Vote Rules — which govern when and how validators may issue votes.
  • Finality Rules — including thresholds for justification and finalization.
  • Longest Chain Rule — the fork-choice rule determining canonical chain selection.

This proposal only modifies the vote aggregation scope to improve vote inclusion flexibility. All original safety guarantees, including one-block finality under an honest super majority, remain intact.

6. Backward Compatibility

This BEP is not backward compatible with older clients, as it changes vote aggregation behavior. However, it introduces no changes to protocol-level message formats or user-facing APIs.

A full client upgrade across validators and block producers is required to activate the changes and maintain consensus.

7. License

The content is licensed under Creative Commons CC0 1.0 Universal License.