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

BSC's adoption of PBS (BEP-322) has reshaped its ecosystem, driving Builder market growth while increasing centralization risks and MEV attacks, such as sandwich attacks, spurring the creation of privacy RPC solutions for better transaction security.

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

BNB Smart Chain implemented BEP 322 (the Proposer-Builder Separation mechanism, or PBS) in the early 2024, which has given rise to the BSC Builder market and introduced new ecosystem dynamics. As a security company, we continuously pay attention to the development of BSC, analyze potential derivative risks by studying the PBS mechanism and its derived ecosystem, and provide corresponding risk mitigation recommendations.

BSC validators have significant influence within the BSC ecosystem. The entry threshold for BSC validators is high, with the number of validators 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.

After months of intense competition, the Builder market has formed a stable structure. Leading players in the Builder market, such as Blockrazor and 48Club-pussaint, contribute nearly 80% of block construction, while Bloxroute, Blocksmith, and Nodereal collectively account for approximately 19%. Tail-end players contribute only sporadically to block construction. Additionally, we discussed that the phenomenon of vertical integration between Validators and Builders on the BSC chain may further exacerbate centralization risks.

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 resulted in frequent phishing activities on-chain. 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 MEV (Maximum Extractable Value).

Differences Between BSC and Ethereum PBS Mechanisms

A good point of comparison for the BSC PBS mechanism is Ethereum. BSC has adopted most of Ethereum's implementation principles but still there are some detailed differences such as consensus mechanisms and validator network topology:

① Elimination of the Relay Mechanism:

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

As a supplement to the Relay, BSC introduced the mev-sentry service, where each validator operates its own sentry. The sentry service interacts directly with Builders, and this sentry-Validator separation mechanism provides better protection for validators. Unlike the 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. This limitation results in 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 which enables 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 mechanism was first introduced by 48Club as a membership feature. Members who held a certain amount of 48Club's token, KOGE, could use this feature, which was offered as a special service by Validators.

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.

Development of the Builder Market

Similar to Ethereum, after the implementation of PBS, the Builder market on BSC emerged and underwent a period of 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.

Development of Validators

Unlike Ethereum, the number of validators on BSC remains within a stable range due to the 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 of them classified as Cabinet and the remaining 24 as Candidates. According to statistics from BSCScan, these 45 validators collectively stake 29,244,219 BNB(As of December 18, 2024), with the validator staking the least amount still staking 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.

On-Chain Potential Risks

Builder-Validator vertical integration

There is a significant phenomenon of Builder-Validator vertical integration on BSC. We analyzed the distribution of Builder-produced blocks across all Validators during the period 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 between Builders and Validators.

For example:

  • Nodereal has a 100% share with TWStaking.
  • Bloxroute has a 100% share with Figment.
  • 48Club holds over 90% shares with TuringThe48ClubShannonListaFeynman, 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.

Risks of the 0 Gwei Transaction Mechanism

The 0 Gwei transaction mechanism 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, we have 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.

MEV attacks are becoming more rampant especially Sandwich

The current 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 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 before the target transaction is executed. 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.

More info. for MEV:https://blocksec.com/blog/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 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 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 (https://dune.com/hildobby/sandwiches?Blockchain_e8f77a=bnb), we found that after the implementation of PBS (May 2024), the number of sandwich attack transactions on the BSC chain has significantly increased.

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.

A New Approach to Combat MEV Attacks

In the post-PBS environment on BSC, where MEV attacks are becoming increasingly rampant and diverse, new measures are required to address these challenges.

Blocksec is committed to providing users with enhanced protection for on-chain activities. In collaboration with BlockRazor, a leading Builder service provider on BSC, we have developed an MEV-protected RPC.

Through multiple rounds of testing, this RPC has demonstrated:

  • 100% effectiveness in preventing sandwich and front-running attacks.
  • Guaranteed transaction speed, with 98% of transactions being included in the next block.

This creates a safer trading environment for users, preventing losses caused by attacks.

Moving forward, we will continue working with BlockRazor to introduce more transaction service tools, striving to create a safer and better on-chain trading experience.

Learn how to use RPC for secure transaction protection → https://docs.blocksec.com/blocksec-anti-mev-rpc

Sign up for the latest updates