Welcome to the BNB Smart Chain (BSC)! As an experienced Solana developer, you are accustomed to an environment with the QUIC protocol, Stake-Weighted QoS (SWQoS), Leader rotation, and a lack of a public Mempool. BSC, an EVM-compatible chain, has a dramatically different propagation mechanism for how a transaction goes from initiation to being included in a block.

This section will focus on the Transaction Propagation Mechanism. By drawing comparisons with Solana, we will break down in detail how a BSC transaction is received, disseminated across the network, and finally included in a block.

1. BSC Transaction Propagation Deep Dive: Mempool and Gossip Protocol

BSC’s transaction dissemination mechanism is similar to Ethereum's, relying heavily on a decentralized Public Memory Pool (Mempool) and the P2P Gossip Protocol. Unlike Solana, where a transaction is "pushed" directly to the Leader, this is a process of "diffusion" and "pulling" across the network.

1.1 Step 1: Node Discovery and Connection Establishment (P2P Network)

In Solana, your RPC node knows the Leader's address via the Leader Schedule. In BSC, a node (including the RPC node) must first "find" other nodes (Peers) in the network.

• Bootstrapping: A new node contacts the hardcoded bootnodes upon startup.
• Discovery: The node sends a PING request to the Bootnode. The Bootnode replies with a PONG, providing a list of nearby peers it knows of.
• Connection: The node uses the RLPx protocol to establish an encrypted and authenticated TCP channel with these Peers, exchanging Node IDs, ports, and other information, formally becoming a Peer Node.

This establishes a decentralized P2P network, laying the groundwork for transaction propagation.

1.2 Step 2: Transaction Enters Local Mempool

• User Submission: You (or your application) send the signed transaction to a connected RPC node (a full node).
• Local Validation: The RPC node immediately performs a series of checks (similar to Solana RPC's pre-flight check):
  • Is the signature valid?
  • Is the Nonce correct (is it the account's next Nonce)?
  • Is the Gas Limit within the block limit?
  • Is the account balance sufficient to pay for Gas Limit * Gas Price?
• Entry into Local Mempool: Upon passing validation, the transaction is placed into this RPC node's own Local Mempool (pending transaction pool).

1.3 Step 3: Gossip Dissemination (“Hash Broadcast-Pull” Model)

This is where the mechanism differs most from Solana. A Solana RPC bundles transactions (PacketBatch) and "pushes" them to the Leader's TPU. In BSC:

• Broadcast Hash: When a node's Mempool receives a new transaction, it does not immediately broadcast the full transaction. Instead, it uses the Wire Protocol to broadcast a NewPooledTransactionHashes message (a list of hashes) to a randomly selected $\sqrt{N}$ of its Peers.
• Peers Pull: The receiving Peers check their own Mempool. If they find a hash they don't have, they send a GetPooledTransactions message back to the sender, actively pulling the complete transaction data.
• “Flooding” Diffusion: The Peer that receives the full transaction performs local validation (same as Step 1.2), adds it to its Mempool, and repeats the process—broadcasting the transaction's hash to its own Peers.

Transactions are diffused like a "flood" (flooding) across the network using this "hash broadcast-pull" method, ultimately ensuring all nodes in the network (including validators) see the transaction in their Mempool.

2. BSC Transaction Ordering Rules (Native Mechanism)

In Solana, transaction ordering is primarily based on CU Price and account lock contention. In BSC, when a Validator selects transactions from the Mempool to build a block (before the introduction of PBS or without Builder intervention), its native ordering rules strictly follow the EVM specification:

• Nonce: Transactions from the same account must be executed strictly in ascending Nonce order. This is an EVM-enforced data consistency rule.
• Gas Price: Based on Nonce ordering, transactions across different accounts are prioritized by descending Gas Price. Similar to Solana's CU Price, transactions with a higher Gas Price are prioritized for inclusion to maximize validator revenue.
• Arrival Time: If two transactions from different accounts have the same Gas Price, the one that arrived in the Validator's Mempool first takes priority.

3. Comparison with the Solana Transaction Propagation Mechanism

To help you visualize this, let's recap Solana's propagation mechanism:

• Non-SWQoS Mechanism: Transactions are pushed to the Leader's tpu port. This has about 500 open connections, no stake-weighting, and is first-come, first-served, making packet loss common.
• SWQoS Mechanism (Stake-Weighted QoS): Transactions are forwarded through a Staked Validator, entering the Leader's tpu port (about 2000 stake-weighted connections). High-staked nodes receive more bandwidth, leading to higher on-chain certainty.

Now, let's summarize the core differences between BSC and Solana:

4. New Insights for Solana Developers

For developers accustomed to Solana's deterministic forwarding (SWQoS), understanding the BSC propagation mechanism leads to the core takeaways:

• No Longer "Leader Direct-Send": Your transaction is no longer sent directly to the Leader. It must be broadcast across the P2P network, waiting to be "discovered" and "pulled" by all Validators.
• High Uncertainty: The time it takes for your transaction to go from submission to being included by a Validator heavily depends on the P2P network topology and propagation speed, leading to higher on-chain uncertainty and latency.
• Third-Party Solutions Are Crucial: Just as Solana's SWQoS mechanism can significantly improve on-chain speed, on BSC, third-party services like BlockRazor establish a low-latency direct-connect channel (bridging directly to Validator nodes), similar to SWQoS, to solve the latency and packet loss issues caused by native P2P broadcasting. If you seek the ultimate transaction speed and success rate, you should consider using these services.

Now that you have a preliminary understanding of the BSC transaction propagation mechanism, the next article will further introduce the differences between BSC's MEV link (PBS mechanism) and Solana's Jito. Furthermore, we sincerely welcome all users to join our Discord channel to discuss related topics.