How is the performance of BSC after full implementation of PBS？

BNB Smart Chain (BSC) implemented BEP-322, the Proposer-Builder Separation (PBS) mechanism, in early 2024. This pivotal upgrade gave rise to the BSC Builder market and introduced new ecosystem dynamics. As a leading blockchain security company, BlockSec continuously monitors the development of BSC, analyzing potential derivative risks by studying the PBS mechanism and its evolving ecosystem. Our goal is to provide robust risk mitigation recommendations to enhance BSC security.

The Evolving Landscape of BSC Validators and Builders

BSC validators have significant influence within the BSC ecosystem. The entry threshold for BSC validators is notably high, with their number consistently maintained at around 40-50. Compared to Ethereum's millions of validator nodes, BSC validators exert a stronger influence on the on-chain ecosystem due to their concentrated power.

After months of intense competition, the BSC Builder market has formed a stable structure. Leading players like Blockrazor and 48Club-pussaint now contribute nearly 80% of block construction, while Bloxroute, Blocksmith, and Nodereal collectively account for approximately 19%. Tail-end players contribute only sporadically. BlockSec's analysis has also highlighted the phenomenon of vertical integration between Validators and Builders on the BSC chain, which may further exacerbate centralization risks and impact overall BNB Smart Chain security.

The new mechanism has also introduced on-chain transaction risks, leading to the emergence of risk prevention products. BSC's unique 0 Gwei transaction mechanism reduces transaction costs but has unfortunately resulted in frequent phishing activities. Under the PBS mechanism, the Builder's process of receiving transaction bundles has lowered the cost of sandwich attacks, making transactions more susceptible to such attacks. This, in turn, has driven the development of privacy RPC products aimed at mitigating Maximum Extractable Value (MEV) and bolstering BSC security.

Key Differences Between BSC and Ethereum PBS Implementations

A good point of comparison for the BSC PBS mechanism is Ethereum. While BSC has adopted most of Ethereum's implementation principles, there are still detailed differences, particularly in consensus mechanisms and validator network topology. Understanding these distinctions is crucial for grasping the unique performance characteristics of BNB Smart Chain after PBS.

Elimination of the Relay Mechanism

Given the relatively small number of validators on BSC, there is no need for a centralized Relay to reduce communication complexity between Builders and Validators. Additionally, BSC's shorter block intervals mean that using a Relay to forward transactions would actually increase communication links and extend interaction time.

As a supplement to the Relay, BSC introduced the mev-sentry service, where each validator operates its own sentry. This sentry service interacts directly with Builders, and its separation from the Validator provides enhanced protection. Unlike a Relay, Validators can directly obtain block content from Builder bids through the sentry, enabling them to independently verify the validity of Builder bids. This further safeguards the interests of Validators. During each block interval, Builders are allowed to send no more than three bids to the sentry, leading to significant differences in bidding strategies between BSC Builders and Ethereum Builders.

Differences in Coinbase Transfer Settings

In Ethereum's PBS mechanism, Builders are allowed to change the coinbase address to their own, enabling Ethereum's priority fees to be executed and redistributed by Builders. However, BSC's PBS mechanism does not have this capability, which somewhat limits the bidding and allocation flexibility of Builders.

Support for 0 Gwei Transactions

Before the BEP-322 upgrade, the 0 Gwei transaction mechanism was initially introduced by 48Club as a membership feature, offered as a special service by Validators to KOGE token holders.

After the BEP-322 upgrade, all BSC Validators were permitted to accept blocks containing 0 Gwei transactions. Unlike Ethereum's dynamic Base Fee mechanism, BSC's transaction Base Fee is set to 0 by default, meaning transactions with a Gas Price of 0 are allowed. To supplement this as a minimum Gas Fee safeguard, BSC has set a restriction that the Effective Gas Price of a block cannot fall below 1. This unique mechanism allows Builders to include 0 Gwei transactions when constructing blocks, enabling more efficient utilization of block space and impacting BSC security.

Development of the BSC Builder Market

Similar to Ethereum, after the implementation of PBS, the BSC Builder market emerged and underwent a period of rapid development, eventually forming a stable structure.

According to statistics provided by Dune, a total of 8 Builder players have participated in the BSC Builder market. In the early stages of PBS implementation, Nodereal, Blocksmith, and Blockrazor briefly dominated the entire market. However, with 48Club and Bloxroute joining the competition in late June, the market entered a tug-of-war phase.

As of now, Blockrazor and 48Club account for over 80% of block construction on BSC, establishing themselves as the leading players in the Builder market. Meanwhile, Bloxroute, Blocksmith, and Nodereal have become 'tier 2' players, while Jetbldr, Blockbus, and Darwin contribute only sporadically to block production. This consolidation significantly influences the performance of BSC after PBS.

Development of BSC Validators

Unlike Ethereum, the number of validators on BSC remains within a stable range due to differences in entry thresholds. On Ethereum, anyone can become a validator by staking 32 ETH, resulting in the number of validators surpassing 1 million. Ethereum validators integrate with Relays to connect with Builders, receive block proposals, and complete block production.

On BSC, however, becoming a validator requires staking a large amount of BNB, significantly raising the entry barrier. Currently, there are only 45 validators on BSC, with 21 classified as Cabinet and the remaining 24 as Candidates. According to statistics from BSCScan, these 45 validators collectively staked 29,244,219 BNB (as of December 18, 2024), with the validator staking the least amount still holding 73,446 BNB.

This difference in validator concentration has, to some extent, led to ecological differences between BSC and Ethereum. For instance, on BSC, the lower cost of linking Builders and Validators eliminates the market space for Relay services. At the same time, the high influence of validators means that the development of the on-chain ecosystem must prioritize validator interests. This could affect the competitiveness and enthusiasm of other project teams within the public chain's collaborative ecosystem, apart from the validator groups, posing a challenge to long-term BNB Smart Chain security.

Potential On-Chain Risks Post-PBS Implementation

The full implementation of PBS on BSC, while bringing architectural improvements, has also surfaced several potential risks that demand attention, particularly concerning BSC security.

Builder-Validator Vertical Integration

There is a significant phenomenon of Builder-Validator vertical integration on BSC. BlockSec analyzed the distribution of Builder-produced blocks across all Validators from December 1, 00:00:00 (UTC) to December 18, 00:00:00 (UTC). The data shows that some validator nodes have block production statistics that deviate significantly from the market average, indicating the existence of vertical integration.

For example:

• Nodereal has a 100% share with TWStaking.
• Bloxroute has a 100% share with Figment.
• 48Club holds over 90% shares with Turing, The48Club, Shannon, Lista, Feynman, and Avengers.

The potential risks arising from this vertical integration differ from the more common Searcher-Builder integration seen on Ethereum. Specifically, the Builder-Validator integration mechanism may be exploited to control transaction flow, transmitting transactions only to specific Validators. This could result in losses to user interests and exacerbate centralization risks, directly impacting BNB Smart Chain security.

Risks of the 0 Gwei Transaction Mechanism

The 0 Gwei transaction mechanism, while reducing costs, creates opportunities for exploitation by phishing contracts. With 0 Gwei transactions, phishing contracts can transfer funds at no cost, exacerbating the prevalence of phishing attacks.

On BSC, BlockSec has already detected multiple phishing contracts utilizing 0 Gwei transactions. Initially, these contracts leveraged 48Club's 0 Gwei transaction service by holding Koge. Although 48Club has implemented certain restrictions, as of the time of writing, we still observe several phishing activities being carried out through 48Club's 0 Gwei transaction service, posing a significant threat to BSC security.

MEV Attacks are Becoming More Rampant, Especially Sandwich Attacks

The current BSC PBS mechanism has reshuffled the MEV attack market, making it essential for users to grasp MEV protection strategies under this new structure. Among the various MEV attacks, the sandwich attack is one of the most notorious on the blockchain.

How a Sandwich Attack Works:

1. Monitoring the Target Transaction: The attacker monitors the blockchain's transaction pool (mempool) to identify target transactions. These targets are typically large token swap transactions (e.g., swapping ETH for USDT on a DEX).
2. Front-Running the Target Transaction: The attacker sends a transaction before the target transaction (front-running) to influence the market price. For example, the attacker buys the target token, driving its price up.
3. Back-Running the Target Transaction: After the target transaction is executed, the attacker sends another transaction after it (back-running) to sell the tokens acquired in the front-running step. This allows the attacker to profit from the price fluctuations caused by the target transaction.

For more information on MEV, read our detailed analysis: Harvesting MEV Bots by Exploiting Vulnerabilities in Flashbots Relay.

Before the implementation of PBS, transactions were fully exposed in the public transaction pool, making them visible to attackers. Attackers could analyze all profitable transactions and manipulate the transaction order by controlling the gas price, enabling them to carry out attacks.

The BSC PBS mechanism introduces a privacy channel for transactions, allowing users to send their transactions to a private transaction pool that is only visible to Builders. This ensures that transactions remain hidden from attackers (unless a Builder deliberately leaks them), providing a layer of MEV protection for user transactions.

We observed that a leading sandwich bot (0x00000000004e660d7929B04626BbF28CBECCe534), which previously conducted sandwich attacks by controlling gas prices, completely ceased operations over 100 days ago. This indicates that the PBS mechanism on BSC has reshuffled the MEV attack landscape.

However, by observing on-chain behavior and analyzing statistical data (e.g., Dune Analytics), we found that after the implementation of PBS (May 2024), the number of sandwich attack transactions on the BSC chain has significantly increased. This paradox highlights a critical gap in current MEV protection strategies on BSC.

The primary reason for the rise in sandwich attacks is that most traders and project teams have not effectively utilized the privacy channels provided by PBS. Instead, they continue to send transactions to the public transaction pool. For attackers, the cost of obtaining attack opportunities has not significantly increased.

On the contrary, attackers exploit the Builder's ability to accept bundles by packaging both the target transaction and the attack transaction into a single bundle submitted to the Builder. If the bundle is successfully included on-chain, the sandwich attack succeeds. If it fails, the Searcher incurs no loss. This makes sandwich attacks more cost-effective and efficient, further emphasizing the need for robust MEV protection.