BidBlock Enhances Block Production Efficiency on BNB Smart Chain

BNB Smart Chain (BSC) has implemented BidBlock, a block-production mechanism introduced under BEP-675, to address inefficiencies in the traditional block production process. BidBlock eliminates redundant transaction execution by validators before sealing blocks, creating potential for higher gas limits and improved scalability.

How BidBlock Changes Block Production

Under the legacy SendBid process, builders and validators both execute transactions before a block is sealed, consuming valuable time within the block interval. BidBlock modifies this workflow by allowing builders to submit blocks with execution results already attached. Validators then seal the block and re-execute transactions after broadcast to verify correctness. This adjustment reduces the number of execution passes from three to two, as modeled in BEP-675.

The new process does not automatically raise the network's gas limit but provides builders with more time to construct blocks, enabling higher gas limits if configured. Validators maintain the option to revoke a builder's SendBidBlock permissions in cases of invalid submissions, with fallback to the legacy SendBid process.

Key Features of BidBlock

A BidBlock submission includes:

• A header with execution results, such as the state root and receipts root.
• Signed user transactions and unsigned system transactions.
• Optional blob sidecars for additional data.

Validators verify deterministic header fields against the parent block and consensus rules before sealing. After broadcast, they re-execute the block locally to confirm the submitted results. Normal block validity rules remain unchanged, ensuring network integrity.

reth-bsc v0.1.3 Enhancements

The reth-bsc v0.1.3 release supports BidBlock by improving transport and reliability. It uses RLP-encoded binary payloads over gRPC, reducing serialization overhead compared to JSON parsing. Additional features include:

• Rejection of BidBlocks with a zero state root.
• Preservation of revocations across node restarts.
• Metrics for monitoring bad BidBlocks and revocation activity.

Validators can also use evidence from peers to revoke local SendBidBlock permissions, enhancing the protocol's robustness.

Performance Implications

BEP-675 estimates that BidBlock could enable a 50% higher gas-limit ceiling under modeled conditions, though this figure reflects capacity headroom rather than a guaranteed increase in live transaction throughput. Observations from the post-Pasteur upgrade period indicated a 28% average increase in gas per block for BidBlock V2 compared to V1, demonstrating its potential to handle more complex workloads.

Builders, validators, and sentry operators are encouraged to validate BidBlock transport and permission handling as part of their deployment processes. For further details, refer to BEP-675 and the reth-bsc v0.1.3 release notes.