Call for Feedbacks: BSC Short Block Interval, Validator Dedicated Network ,and Direct Mempool

[BNBChainCore]

Call for Feedbacks: BSC Short Block Interval, Validator Dedicated Network ,and Direct Mempool

TDLR:

1. Aligned with the BNB Chain 2025 roadmap, BNB Chain aims to optimize trader experience by reducing block time from 3 seconds to 0.75 seconds in 2 phases.
2. Validator Dedicated Network(VDN) will increase the efficiency of validator communication, which is crucial for shorter block time.
3. Directed mempool means transactions would be forwarded to a subset of validators that are most likely to produce the next block. It will avoid exposing users’ transactions directly to a public mempool, so validators will take more responsibility for reducing malicious MEV attacks.

1. Reduce block time from 3s to 0.75s

Target is to achieve the 0.75 seconds block interval goal in H1 or early Q3 2025 in 2 phases.

1.1 Phase 1: BEP-520: Short Block Interval Phase One: 1.5 seconds

This upgrade cuts the block interval from 3 seconds to 1.5 seconds. It revises key parameters (such as lowering the gas limit, extending the epoch length, and increasing consecutive block production) and introduces technical updates:

• Timestamp Precision: Block timestamps, which were previously recorded in seconds, will now include millisecond precision.
• Penalty Mechanism: Validators who intentionally delay block production, often to wait for more transactions or to try to maximize fee revenue, will face penalties. Such delays can give an unfair advantage by extending the time to include transactions, so the system reallocates fee rewards from delayed blocks to discourage this behavior.

Key Parameters:

Note:

• Consecutive TurnLength: it is the consecutive block generation number, which is introduced in BEP-341

1.2 Phase 2: BEP-524: Short Block Interval Phase Two: 0.75 seconds

This phase further reduces the interval from 1.5 seconds to 0.75 seconds while keeping the block production mechanism unchanged to phase one. The parameters are adjusted to maintain stability and network security with the faster pace.

Key Parameters

2.BEP-525: Validator Dedicated Network & Directed TxPool(WIP)

2.1 Validator Dedicated Network (VDN)

Short block intervals would bring challenges to the network layer, and current P2P gossip based network is good at broadcasting blocks/transactions to the whole network, but it is not efficient enough, i.e. it would take lots of network bandwidth and also cost non-negligible latency.

As block/transaction/vote would be processed in a shorter time, Validator Dedicated Network (VDN) is introduced here. The general network layout is described in the below diagram, basically validators would be able to be connected directly, so the latency will be reduced.

2.2 Directional Transactions Broadcast

There is another key aspect of VDN, transactions that are broadcast in VDN will no longer be gossip based, on the contrary, they will only be multicasted to next N validators (default could be 3), which have the right to propose the next block. It could also avoid exposing users transactions directly to public txpool, so validators will take more responsibility to reduce malicious MEV attacks.

The existing PBS infrastructure is still valid in this Direct TxPool, however, it will depend on the collaboration between validators and PBS players, i.e., validators can decide how to open their own txpool to their collaborated searchers or builders.

3.Backwards Compatibility

3.1.MEV

As the public txpool would be gradually replaced by validator directed txpool, which means transactions would be forwarded to validators directly.

• MEV searchers would have to get the transactions from validators, which would be more difficult.
• MEV builders can still act as a bridge between searchers and validators, but the impact to searchers would impact builders indirectly.

3.2.Layer-2

BSC’s blob-handling capacity is enhanced by roughly 33% under these upgrades. This extra capacity is useful for Layer‑2 solutions that depend on blob transactions, ensuring they have the necessary network resources to operate efficiently.

3.3.CEX

For Centralized exchanges (CEXs), the new block timing and production mechanisms require recalibration of their systems to align with the updated network timings to ensure the correct finality.

3.4.DApp Developers And Users

Timing Based on Block Numbers

The reduction in block intervals affects logic that relies on block numbers for timing, whether in independent services or within smart contracts. A simple solution is to adjust the corresponding block count or avoid using block numbers for timing altogether.

Indexing Based on block.timestamp

With the block interval reduced to 0.75 seconds, block.timestamp, which has second-level precision, may be the same for consecutive blocks. Therefore, using block.timestamp as an index key or for similar purposes requires adjustment. A common solution is to use the block hash instead.

3.5.Other Network Infrastructure Providers

Infrastructure providers such as RPC nodes, data indexing services (like The Graph), and analytics platforms (like Dune) must adjust their systems to account for the faster block intervals. This includes updating data polling, synchronization strategies, and performance monitoring to ensure accurate, real-time data processing.

4. Practical Benefits

4.1.For dApps

Imagine sending a transaction on a decentralized application (DApp). Under the current 3-second interval, confirmation might take a few extra seconds. With the upgrade:

• Phase One (1.5s): Transactions are confirmed nearly twice as fast, greatly enhancing the user experience in time-sensitive applications like decentralized finance (DeFi).
• Phase Two (0.75s): Confirmation times drop even further, enabling high-frequency trading or real-time gaming applications to operate more effectively on the blockchain.

4.2.For Validators

• Predictable Production Windows:

With extended consecutive turn lengths (16 blocks in phase one and 32 blocks in phase two), validators know exactly when their block production window will occur. This window will be longer and uninterrupted. This predictability allows them to better plan system maintenance, resource allocation, and network connectivity. In addition, faster block times help reduce overall network congestion.

• Operational Advantages:

While the primary benefit for users is faster transactions, validators gain from a more efficient network that minimizes the risk of delays and penalties. A stable, low-latency network can lead to lower operational costs and a fairer reward system since the penalty mechanism rewards prompt block production.

4.3.For Network Infrastructure

With the introduction of VDN:

• Reduced Latency: Direct validator-to-validator communication significantly cuts down the propagation time for blocks and transactions. This means a validator’s block reaches its peers more quickly, lowering the risk of delays or conflicts that could lead to penalties.
• Optimized Transaction Flow: Directional broadcasting ensures that transactions are sent only to validators who need them next, streamlining network operations.

5.FAQ

5.1.Why 0.75s and Why Two Phases

Basically, for block intervals, the faster the better. But shorter block intervals would have challenges on the whole network, especially on a P2P based network. 0.75s could be a desired value considering both the network challenges and user experience.

And the two phase strategy is to avoid one big step to reduce it to 0.75s directly, which could be too risky, as the overall infrastructure may not be fully ready for this change. Phase two(0.75s) would be carried out after phase one(1.5s) has been verified.

5.2.What Is The State Of Other Chains On Block Interval

Here is the latest status of some chains:

• BTC: ~10 minutes
• Ethereum: ~12 seconds
• Polygon: ~2 seconds
• Solana: ~ 400ms
• Sui: ~400ms
• Aptos: ~200ms

[48ClubIan]

My opinions:

1. BNB Chain is neither a company nor a project team, so there is no need for the community to adhere to a roadmap that was not determined by community voting. Imposing such a plan contradicts the principles of decentralized governance.

2. This entire proposal is based on the premise that “MEV is evil.” However, as a fundamental public blockchain infrastructure, it should not make emotionally charged value judgments about a neutral technical characteristic. In fact, given this biased standpoint, I have reasons to question the necessity and neutrality of these proposals.

3. Regarding the reduction of block time: since this change comes with a reduction in the gas limit, it does not increase the overall TPS capacity of BSC. Instead, it introduces additional block propagation overhead and stricter block time constraints, reducing the network’s robustness. Does this adjustment truly align with BSC’s long-term development goals?

4. Next, about the Validator Dedicated Network (VDN). I want to remind everyone that BSC already has a fast finality network, and now another VDN network is being introduced. This means that each validator node must maintain three separate application-layer networks. Is such complexity really necessary for a blockchain infrastructure? More importantly, does this approach expose the roles of different nodes more clearly, making validators easier to be identified, and consequently, more vulnerable to attacks, potentially compromising the security of the chain?
   Back to the original intent of this change—reducing the exposure of user transactions in the public mempool while allowing validators to decide how to disclose transactions to searchers and builders—what is the actual purpose of this? Are we really considering embedding a definition of “malicious” MEV into the consensus layer? This is simply absurd.

5. The third section clearly anticipates the challenges that the MEV ecosystem will face under this new mechanism. Given this, should we reconsider last year’s PBS upgrade? The fact that both MEV-enabling and MEV-eliminating mechanisms are coexisting on BSC is utterly confusing. At this point, I’m genuinely concerned about the mental well-being of the core team developers because this decision-making process is enough to drive anyone insane.

[Quixotic_bnb]

• MEV extraction & distribution: The proposal aims to limit MEV extraction by reducing order flow exposure, which could otherwise allow other actors to conduct fair and open auctions (OFAs). The directed mempool could gradually eliminate “private transactions” and “conditional order flow,” which some solutions depend on to extract healthy MEV and are built on a profit-sharing model that increases validator yields and secures proceeds for the originator. Also let’s not forget that many actors (both MEV originators and validators) are already aligned with profit-sharing through secondary wallets that receive direct payments from builders.

• UX: While searchers will appreciate near-instant confirmations, bringing BSC closer to the feel of centralized exchanges, their strategies and infrastructure may still face challenges. A 0.75-second block time means searchers have a much smaller window to submit bundles for inclusion in the next block. This could lead to missed opportunities if bundles aren’t relayed in time, especially for latency-sensitive strategies like arbitrage. Searchers may need to optimize their relay infrastructure or rely on faster submission protocols to keep up. Similarly, users might benefit from safer trades without predatory attacks (like sandwiching or front-running), but how will fair and transparent ordering be enforced on the validators’ side?

• Network Stability: Are there any plans to do some stress testing to ensure the network can handle this?

• Implementation Details: How will the VDN be structured? Is this a private overlay network, or are you leveraging existing solutions like libp2p with custom optimizations?

• Validator Collusion Risk: If a small subset of validators consistently receives transactions, what’s stopping them from colluding to extract value in other ways? Strong monitoring and penalty mechanisms will be crucial. Not all private mempools are safe!

[Rudy-InfStones]

• Shorter Block Time Improves User Experience:
  As a BNB Chain validator, we support the reduction of block time, as faster transaction confirmation is particularly important for time-sensitive transactions including meme trading. Shorter block intervals, while maintaining a TPS of approximately 2,000, make BNB Chain more attractive for users seeking quick execution, ultimately driving more trading activity to the network.

• Technical Challenges of Shorter Block Interval:
  A reduced block time introduces synchronization challenges for validators, requiring more efficient transaction propagation to prevent delays. VDN is positioned as a critical solution to address this. We would like to better understand its technical implementation if more technical docs can be shared. Additionally, extensive testing and validation on testnet will be essential to ensure that VDN effectively mitigates these challenges under real-world conditions.

• New Validator-Builder Collaboration Model:
  The directed mempool shifts transaction flow control to validators, introducing new responsibilities for both validators and builders. While this model enhances privacy by limiting public transaction exposure, it also requires strong collaboration to maintain fair transaction inclusion. Validator and builder collaboration is essential in establishing mechanisms to identify and mitigate malicious MEV strategies, such as sandwich attacks, ensuring a secure trading environment.

• Expectations & Next Steps:
  a) We look forward to actively participating in the testnet phase to evaluate the impact of these changes on validator operations.
  b) We also hope to receive detailed technical documentation on VDN for further technical assessment.
  c) Further discussions on optimizing validator-builder collaboration will be valuable to ensure the new transaction flow structure remains fair and competitive.