PBSの完全実施後のBSCのパフォーマンスはどうですか?

PBSの完全実施後のBSCのパフォーマンスはどうですか?

BNB Smart Chain は 2024 年初頭に BEP 322(Proposer-Builder Separation、PBS)を実装し、BSC ビルダー市場を創出し、新たなエコシステムダイナミクスをもたらしました。セキュリティ企業として、私たちは BSC の発展に継続的に注目し、PBS メカニズムとその派生エコシステムを研究することで潜在的な派生リスクを分析し、対応するリスク軽減策を推奨しています。

BSC バリデーターは BSC エコシステム内で大きな影響力を持っています。 BSC バリデーターのエントリーしきい値は高く、バリデーターの数は常に 40〜50 名程度に維持されています。イーサリアムの数百万のバリデーターノードと比較して、BSC バリデーターはオンチェーンエコシステムに対してより強い影響力を行使しています。

数ヶ月にわたる激しい競争を経て、ビルダー市場は安定した構造を形成しました。 Blockrazor や 48Club-pussaint のようなビルダー市場の主要プレーヤーは、ブロック構築の約 80% に貢献しており、Bloxroute、Blocksmith、Nodereal は collectively で約 19% を占めています。後続のプレーヤーはブロック構築に散発的にしか貢献していません。さらに、BSC チェーンにおけるバリデーターとビルダー間の垂直統合の現象が、中央集権化のリスクをさらに悪化させる可能性があることを議論しました。

新しいメカニズムはオンチェーントランザクションリスクも導入し、リスク防止製品の出現につながりました。 BSC のユニークな 0 Gwei トランザクションメカニズムはトランザクションコストを削減しますが、オンチェーンでの頻繁なフィッシング活動につながっています。PBS メカニズムの下では、ビルダーがトランザクションバンドルを受信するプロセスにより、サンドイッチ攻撃のコストが削減され、トランザクションがそのような攻撃に対してより脆弱になっています。これは、MEV(Maximum Extractable Value)を軽減することを目的としたプライバシー RPC 製品の開発を推進しています。

BSC とイーサリアムの PBS メカニズムの違い

BSC の PBS メカニズムと比較するのに適しているのはイーサリアムです。BSC はイーサリアムの実装原則のほとんどを採用していますが、コンセンサスメカニズムやバリデーターネットワークトポロジーなど、いくつかの詳細な違いがあります。

① リレーメカニズムの廃止:

BSC のバリデーター数は比較的少ないため、ビルダーとバリデーター間の通信の複雑さを軽減するための集中型リレーは必要ありません。さらに、BSC のブロック間隔が短いため、リレーを使用してトランザクションを転送すると、ビルダーとバリデーター間の通信リンクが増加し、相互作用時間が長くなります。

リレーの補足として、BSC は mev-sentry サービスを導入しており、各バリデーターは独自のセントリーを運用しています。セントリーサービスはビルダーと直接やり取りし、このセントリー・バリデーター分離メカニズムはバリデーターをより良く保護します。リレーとは異なり、バリデーターはセントリーからビルダーの入札からブロックコンテンツを直接取得できるため、ビルダーの入札の有効性を独立して検証できます。これにより、バリデーターの利益がさらに保護されます。各ブロック間隔で、ビルダーはセントリーに 3 つ以下の入札を送信できます。この制限により、BSC ビルダーとイーサリアムビルダーの入札戦略に大きな違いが生じます。

② Coinbase Transfer 設定の違い:

イーサリアムの PBS メカニズムでは、ビルダーは coinbase アドレスを自分のものに変更することができ、これによりイーサリアムの優先手数料が実行され、ビルダーによって再分配されます。しかし、BSC の PBS メカニズムにはこの機能がなく、ビルダーの入札と割り当ての柔軟性がいくらか制限されています。

③ 0 Gwei トランザクションのサポート:

BEP-322 アップグレードの前に、0 Gwei メカニズムは 48Club によってメンバーシップ機能として最初に導入されました。48Club のトークン KOGE を一定量保有するメンバーは、この機能を使用でき、これはバリデーターによって特別なサービスとして提供されていました。

BEP-322 アップグレード後、すべての BSC バリデーターは 0 Gwei トランザクションを含むブロックを受け入れることが許可されました。イーサリアムの動的な Base Fee メカニズムとは異なり、BSC のトランザクション Base Fee はデフォルトで 0 に設定されており、Gas Price が 0 のトランザクションが許可されることを意味します。これを最小 Gas Fee のセーフガードとして補完するために、BSC はブロックの Effective Gas Price が 1 未満にならないという制限を設定しています。このユニークなメカニズムにより、ビルダーはブロック構築時に 0 Gwei トランザクションを含めることができ、ブロック空間のより効率的な利用が可能になります。

ビルダー市場の発展

イーサリアムと同様に、PBS の実装後、BSC 上にビルダー市場が出現し、開発期間を経て、最終的に安定した構造を形成しました。

Dune が提供する統計によると、合計 8 名のビルダープレイヤーが BSC ビルダー市場に参加しています。PBS 実装の初期段階では、NoderealBlocksmithBlockrazor が一時的に市場全体を支配しました。しかし、6 月末に 48ClubBloxroute が競争に参加したことで、市場は綱引きの段階に入りました。

現時点では、Blockrazor48Club が BSC 上のブロック構築の 80% 以上を占め、ビルダー市場の主要プレーヤーとしての地位を確立しています。一方、BloxrouteBlocksmithNodereal は「ティア 2」プレーヤーになり、JetbldrBlockbusDarwin はブロック生成に散発的にしか貢献していません。

バリデーターの発展

イーサリアムとは異なり、エントリーしきい値の違いにより、BSC のバリデーター数は安定した範囲内に収まっています。イーサリアムでは、誰でも 32 ETH をステークすることでバリデーターになることができるため、バリデーターの数は 100 万を超えています。イーサリアムバリデーターはリレーと統合してビルダーと接続し、ブロック提案を受信し、ブロック生成を完了します。

しかし、BSC では、バリデーターになるには多額の BNB をステークする必要があり、エントリーバリアが大幅に上昇します。現在、BSC には 45 名のバリデーターしかおらず、そのうち 21 名が Cabinet、残りの 24 名が Candidate と分類されています。BSCScan の統計によると、これらの 45 名のバリデーターは collectively で 29,244,219 BNB をステークしています(2024 年 12 月 18 日現在)。最も少ないステーク量でも 73,446 BNB をステークしています。

バリデーターの集中度のこの違いは、ある程度、BSC とイーサリアムの生態系に違いをもたらしています。例えば、BSC では、ビルダーとバリデーターをリンクするコストが低いため、リレーサービス市場の余地がなくなります。同時に、バリデーターの影響力が大きいため、オンチェーンエコシステムの開発はバリデーターの利益を優先する必要があります。これは、バリデーターグループ以外のパブリックチェーンの協力エコシステム内の他のプロジェクトチームの競争力と熱意に影響を与える可能性があります。

オンチェーンの潜在的リスク

ビルダー・バリデーター間の垂直統合

BSC では、ビルダー・バリデーター間の垂直統合が顕著です。2024 年 12 月 1 日 00:00:00 (UTC) から 12 月 18 日 00:00:00 (UTC) までの期間、すべてのバリデーターにおけるビルダー生成ブロックの分布を分析しました。データは、一部のバリデーターノードのブロック生成統計が市場平均から大きく逸脱していることを示しており、ビルダーとバリデーター間の垂直統合の存在を示唆しています。

例:

  • NoderealTWStaking との 100% のシェアを持っています。
  • BloxrouteFigment との 100% のシェアを持っています。
  • 48ClubTuringThe48ClubShannonListaFeynmanAvengers との 90% 以上のシェアを保持しています。

この垂直統合から生じる潜在的リスクは、イーサリアムで見られるより一般的な Searcher-Builder 統合とは異なります。具体的には、ビルダー・バリデーター統合メカニズムは、トランザクションフローを制御するために悪用される可能性があり、トランザクションを特定のバリデーターにのみ送信します。これにより、ユーザーの利益が損失し、中央集権化のリスクが増悪する可能性があります。

0 Gwei トランザクションメカニズムのリスク

0 Gwei トランザクションメカニズムは、フィッシングコントラクトによる悪用の機会を生み出します。0 Gwei トランザクションでは、フィッシングコントラクトは費用なしで資金を転送でき、フィッシング攻撃の蔓延を悪化させます。

BSC では、0 Gwei トランザクションを利用する複数のフィッシングコントラクトをすでに検出しています。当初、これらのコントラクトは Koge を保有することで 48Club の 0 Gwei トランザクションサービスを利用していました。48Club はいくつかの制限を実装していますが、執筆時点でも、48Club の 0 Gwei トランザクションサービスを通じたフィッシング活動が複数確認されています。

MEV 攻撃がより蔓延し、特にサンドイッチ攻撃

現在の PBS メカニズムは MEV 攻撃市場を再編成しており、ユーザーがこの新しい構造の下で MEV 保護戦略を把握することが不可欠です。さまざまな MEV 攻撃の中で、サンドイッチ攻撃はブロックチェーン上で最も悪名高いものです。

サンドイッチ攻撃の仕組み:

  1. ターゲットトランザクションの監視:

    攻撃者は、ブロックチェーンのトランザクションプール(mempool)を監視して、ターゲットトランザクションを特定します。これらのターゲットは通常、大規模なトークンスワップトランザクション(例:DEX で ETH を USDT にスワップする)です。

  2. ターゲットトランザクションのフロントランニング:

    攻撃者は、ターゲットトランザクションが実行される前に市場価格に影響を与えるために、ターゲットトランザクションの前にトランザクションを送信します(フロントランニング)。たとえば、攻撃者はターゲットトークンを購入し、その価格を押し上げます。

  3. ターゲットトランザクションのバックランニング:

    ターゲットトランザクションが実行された後、攻撃者はバックランニングのために、フロントランニングステップで取得したトークンを販売するために、その後に別のトランザクションを送信します。これにより、攻撃者はターゲットトランザクションによって引き起こされた価格変動から利益を得ることができます。

MEV に関する詳細情報: https://blocksec.com/blog/harvesting-mev-bots-by-exploiting-vulnerabilities-in-flashbots-relay

PBS の実装前は、トランザクションは公開トランザクションプールに完全に公開されており、攻撃者に見えるようになっていました。攻撃者は、収益性の高いすべてのトランザクションを分析し、ガス価格を制御することでトランザクションの順序を操作し、攻撃を実行できるようにしていました。

PBS メカニズムはトランザクションのためのプライバシーチャネルを導入しており、ユーザーはビルダーのみに表示されるプライベートトランザクションプールにトランザクションを送信できます。これにより、トランザクションは攻撃者から隠されたままになります(ビルダーが意図的に漏洩しない限り)、ユーザーのトランザクションが保護されます。

以前はガス価格を制御してサンドイッチ攻撃を実行していた主要なサンドイッチボット(0x00000000004e660d7929B04626BbF28CBECCe534)が、100 日以上前に完全に運用を停止したことを確認しました。これは、BSC 上の PBS メカニズムが MEV 攻撃の状況を再編成したことを示しています。

しかし、オンチェーンの行動を観察し、統計データを分析すること(https://dune.com/hildobby/sandwiches?Blockchain_e8f77a=bnb)で、PBS(2024 年 5 月)実装後、BSC チェーンでのサンドイッチ攻撃トランザクションの数が大幅に増加していることがわかりました。

サンドイッチ攻撃の増加の主な理由は、ほとんどのトレーダーやプロジェクトチームが PBS によって提供されるプライバシーチャネルを効果的に活用していないことです。代わりに、公開トランザクションプールにトランザクションを送信し続けています。攻撃者にとって、攻撃機会を得るためのコストは大幅に増加していません。

それどころかに、攻撃者はビルダーがバンドルを受け入れる能力を悪用し、ターゲットトランザクションと攻撃トランザクションの両方を単一のバンドルにパッケージ化してビルダーに提出します。バンドルがオンチェーンに正常に含まれた場合、サンドイッチ攻撃は成功します。失敗した場合、Searcher は損失を被りません。これにより、サンドイッチ攻撃はよりコスト効率が高く効率的になります。

MEV 攻撃と戦うための新しいアプローチ

BSC のポスト PBS 環境では、MEV 攻撃がますます蔓延し多様化しているため、これらの課題に対処するには新しい対策が必要です。

Blocksec は、ユーザーにオンチェーンアクティビティの強化された保護を提供することにコミットしています。BSC の主要なビルダーサービスプロバイダーである BlockRazor との協力により、MEV 保護 RPC を開発しました。

複数回のテストの結果、この RPC は以下のことを実証しました。

  • サンドイッチ攻撃とフロントランニング攻撃を防止する 100% の効果。
  • トランザクション速度の保証、98% のトランザクションが次のブロックに含まれています。

これにより、ユーザーは攻撃による損失を防ぎ、より安全な取引環境を構築できます。

今後も BlockRazor と協力して、より多くのトランザクションサービスツールを導入し、より安全で優れたオンチェーン取引体験の創造に努めていきます。

安全なトランザクション保護のための RPC の使用方法を学ぶ → https://docs.blocksec.com/blocksec-anti-mev-rpc

Sign up for the latest updates
Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

Weekly Web3 Security Incident Roundup | Feb 9 – Feb 15, 2026

During the week of February 9 to February 15, 2026, three blockchain security incidents were reported with total losses of ~$657K. All incidents occurred on the BNB Smart Chain and involved flawed business logic in DeFi token contracts. The primary causes included an unchecked balance withdrawal from an intermediary contract that allowed donation-based inflation of a liquidity addition targeted by a sandwich attack, a post-swap deflationary clawback that returned sold tokens to the caller while draining pool reserves to create a repeatable price-manipulation primitive, and a token transfer override that burned tokens directly from a Uniswap V2 pair's balance and force-synced reserves within the same transaction to artificially inflate the token price.

Top 10 "Awesome" Security Incidents in 2025

Top 10 "Awesome" Security Incidents in 2025

To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

#10 Panoptic Incident: XOR Linearity Breaks the Position Fingerprint Scheme

On August 29, 2025, Panoptic disclosed a Cantina bounty finding and confirmed that, with support from Cantina and Seal911, it executed a rescue operation on August 25 to secure roughly $400K in funds. The issue stemmed from a flaw in Panoptic’s position fingerprint calculation algorithm, which could have enabled incorrect position identification and downstream fund risk.