ブロック・アセンブリ・マーケットプレイス（BAM）

実践的な知見

• 現在、Solanaのリーダーは自身のスロット内でトランザクションの順序を決める全権限を持っており、ブロックの構築方法に関する透明性は限られています。BAMは、シーケンシングロジックを監査できる、検証可能で分散型の代替手段を導入します。
• BAMネットワークでは責任が明確に分離されています。BAMノードはSolanaトランザクションの取得、優先順位付け、フィルタリングを管理し、BAMバリデータは実行、コンセンサス、状態管理を担います。このアプローチにより、SolanaはProposer-Builder Separation（PBS）に近いアーキテクチャへと進みます。
• BAMのプラグインフレームワークにより、開発者は独自の順序付けロジックを定義し、新しいスケジューリングプリミティブを導入できます。これにより、アプリが独自のトランザクションスケジューリングルールを適用できるApplication-Controlled Execution（ACE）が実現します。
• Jitoは、最終的にBAMをオープンソース化し、透明性を中核に据えて設計することを表明しています。これは、クローズドソースで単一の信頼された主体が運用する現在のJitoブロックエンジンからの大幅な改善です。
• BAMノードは、強化されたSecure Encrypted Virtualization with Secure Nested Paging（SEV-SNP）をサポートするAMDプロセッサ上で稼働します。ハードウェアアクセラレーションにより、SEV-SNPのオーバーヘッドはわずか2〜5%で、リアルタイム処理に十分な速度です。
• BAMノード向けに最初に実装されるスケジューラは、mempool内で定期的なブロック内オークションを実行します。ブロックをN個のスロットに分割し、各オークションへCUを均等に割り当てます。
• Application-Controlled Execution（ACE）により、独自ロジックを適用するためのロールアップやネットワーク拡張の必要性が減り、より多くのアクティビティをSolanaメインネット上に維持できる可能性があります。また、プログラム可能なブロックスペースを活用する新しいアプリケーションの設計余地も大幅に広がります。
• Jitoは、Block Engineと今後のBAMシステムの両方から得られるプロトコル手数料の100%をJito DAO Treasuryへ送る予定です。現在、Jitoはチップに6%の手数料を課し、Jito LabsとDAOで均等に分配しています。2025年第2四半期には、DAOがTip Routerを通じてこれらの手数料から22,391.31 SOL（~400万ドル）を獲得しました。
• BAMはFlashbotsのBuilderNetから着想を得ており、信頼できる実行環境内でブロックを構築する同様のアプローチを採用しています。Ethereumメインネットでは、すでに約40%のブロックがTEE内で構築されています。

はじめに

JitoのBlock Assembly Marketplace（BAM）は、Solanaのブロック構築プロセスにおける、これまでで最も野心的な再設計です。8か月以上にわたり開発されてきたBAMは、次世代の高度なアプリケーションを実現するため、Solana上でプライバシー、透明性、決定論的なスロット内実行を強化したいという構想から生まれました。その成果が、現在の不透明でバリデータ主導の順序付けモデルを、プライベートかつプログラム可能で、公平性を証明できるトランザクションシーケンシングシステムへ置き換える、新たなトランザクションパイプラインです。

BAMはTrusted Execution Environment（TEE）内で動作する暗号化mempoolを導入し、すべてのトランザクションを実行時まで機密に保ちます。このプライバシー保護アーキテクチャは、搾取性の高い多くのMEVを大幅に削減し、可能であれば排除することで、ユーザーにより強固な実行保証と有利な価格を提供することを目指しています。バリデータはより高品質な実行を提供でき、開発者やサーチャーは新しいプログラム可能なブロックスペースレイヤー上で直接構築できます。

BAMは、プラグインシステムを通じてApplication-Controlled Execution（ACE）ロジックを導入します。これにより、無期限先物におけるメイカー優先マッチング、ジャストインタイムのオラクル更新、Time-in-Force注文の適用、その他の独自ルーティングおよび実行が可能になります。トランザクションの順序をきめ細かく制御することで、開発者は中央指値注文板、ダークプール、アグリゲーターレイヤーなど、より高度で信頼性の高い金融プリミティブをSolana上に構築できます。

これによりBAMは、不透明なバリデータの挙動、一貫性のない実行品質、プライベートmempoolや帯域外取引を通じたグレーマーケットの拡大など、Solanaのブロック生成モデルに対する長年の批判へ直接対応します。現在、Solanaのリーダーは自身のスロット内でトランザクションの順序を一方的に決定でき、最終的なブロックがどのように組み立てられたかを確認する手段はほとんどありません。BAMはこれを、Solanaの高性能ランタイムと円滑に統合できる、検証可能で分散型の代替手段に置き換えます。

BAMは実運用での先例を基盤とし、FlashbotsのBuilderNetから着想を得ています。信頼できる実行環境内でブロックを構築する、同様のアプローチを採用しています。Ethereumメインネットでは、すでに約40%のブロックがTEE内で構築されており、Unichain（Uniswap独自のL2）では100%に達しています。BAMはこのモデルをSolanaへ拡張し、アプリケーションレベルのプログラマビリティ、低レイテンシの実行、そして現在Jito-AgaveとJito-Firedancerを通じて総ステークの89%以上を保護しているJitoバリデータクライアントとの緊密な統合を標準でサポートします。

重要な点として、Jitoは最終的にBAMをオープンソース化し、透明性を中核に据えて設計することを表明しています。これは、クローズドソースで単一の信頼された主体が運用する現在のJitoブロックエンジンからの大幅な改善です。BAMは、実行されたコードとトランザクションの順序を正確に確認できる、暗号署名付きの証明であるオンチェーンアテステーションを生成します。これにより、あらゆる観測者が公正な実行を検証できます。

BAMの概要

BAMの中核は、トランザクションシーケンシングネットワークです。BAMノードはSolanaトランザクションの取得、優先順位付け、フィルタリングを処理し、BAMバリデータは実行、コンセンサス、状態管理に集中します。この責務の分離により、ネットワークのライブネスに不可欠な中核的責任をバリデータ側に維持しながら、BAMノード内のシーケンシングロジックに高い柔軟性と実験の余地を与えます。

BAMノード自体は、TEE内で動作するトランザクション処理ユニット（TPU）とトランザクションスケジューラで構成されます。また、接続されたバリデータとの通信を可能にするgRPCサーバーも実行します。変更されたJito-validatorクライアントには、アカウントを考慮したロックによって並行性と並列性を最適化した先入れ先出し（FIFO）エグゼキューターが搭載されています。

各BAMノードは複数のバリデータをサポートできますが、各バリデータが同時に接続できるBAMノードは1つだけです。現在、Jitoは7つのブロックエンジンを運用しています。BAMでは、分散化と冗長性を高めるため、主要なすべての地域に50〜100以上のBAMノードを配置し、ネットワークを大幅に拡張することを目指しています。BAMノードとバリデータ間の通信は双方向gRPCストリームを介して行われ、実行結果はリアルタイムのフィードバックとしてバリデータからBAMノードへストリーミングされます。

BAMノード内のすべてのトランザクションは、実行される瞬間までTrusted Execution Environment（TEE）内で暗号化され、トランザクションフローのプライバシーが実行時まで維持されます。

公正な実行を保証するため、トランザクションの順序はアテステーションを使用して検証可能な形で記録されます。アテステーションは、特定のイベントや条件が確認されたことを証明する、BAMノードによって署名およびタイムスタンプが付与された暗号学的証明です。その結果、不変の監査証跡が作成され、トランザクションが正しい順序で実行されたことを観測者が証明できます。

監査証跡には、バリデータへ転送されたトランザクションとそのシーケンシングが含まれます。たとえば、トランザクションA、B、CがこのスロットでHeliusバリデータへ送信されたことが記録されます。このシステムはリアルタイムの監視ツールと分析機能を提供し、ユーザーは送信から実行まで自身のトランザクションを追跡できます。ユーザーとアプリケーションは、BAMバリデータが指定された順序を履行したかどうかを検証し、BAMノードで実行されたコードを正確に確認できるようになります。

BAMノードは、既存のJitoリレイヤーと同様に、ネットワーク上で透過的に確認できます。バリデータがBAMへ接続すると、トランザクションを受信するエントリーポイントとなるTPUポートとTPUフォワードポートを通じて、BAMインスタンスを公開します。

ユーザーは引き続き通常のRPCクライアントからトランザクションを送信できます。ただし、セキュリティを強化するためにBAMインスタンスへ直接送信することもでき、悪意のあるバリデータによるトランザクションパケットの傍受や閲覧を防げます。

トランザクションがBAMへ入ると、重複排除、署名検証、有効な形式、blockhash、手数料支払者、nonce、Address Lookup Tablesの確認を含む標準的なサニタイズ処理が行われます。

検証後、トランザクションはBAMのmempoolへ入り、頻繁に実施される定期オークションに参加します。オークションが終了すると、トランザクションはバリデータへ送られます。トランザクションシーケンス全体はBAMソフトウェアによって署名され、データベースに記録されます。その後、バリデータはAnzaのモジュール式スケジューラが提案したAPIをモデルとする仕組みを通じて、実行結果をストリーミングで返します。

安全なスケジューリング環境とローカル手数料市場により、バリデータは、より強固なオプトイン契約の下で動作するようになります。バリデータは、指定どおり正確にスケジュールしなければならない、事前定義されたトランザクションシーケンスを受け取ります。これにより、悪意を持ってトランザクションを挿入したり並べ替えたりする余地がなくなります。

監査証跡の証拠に基づき、サンドイッチ攻撃などのバリデータによる不正行為へ対処するため、複数の執行メカニズムが検討されています。まだ確定していませんが、考えられる対応は次のとおりです。

• 違反したバリデータをBAMネットワークから除外します。
• バリデータにボンド形式の担保を求め、不正行為があった場合にスラッシュできるようにします（ただし、新規バリデータの参入障壁が高まる可能性があります）。
• ブラックリストまたはグレーリストを適用し、違反者の参加を部分的に制限します。

手数料

Jito LabsとJito Foundationは、Block Engineと今後のBAMシステムの両方から徴収されるプロトコル手数料の100%をJito DAO Treasuryへ振り向けるJito Improvement Proposal（JIP）を共同で策定しています。この提案は今後数週間以内に正式提出される見込みで、Jitoの経済モデルにおける大きな転換となります。実施にはDAOの承認が必要です。可決されれば、JitoエコシステムにおけるDAOとJTOトークン保有者の中心的な役割がさらに強化されます。

現在、Jitoプロトコルはチップに6%の手数料を課し、Jito LabsとDAOで均等に分配しています。2025年第2四半期だけで、DAOは22,391.31 SOLを獲得しました（~400万ドル）。これは、Tip Routerを通じて得た手数料です。DAOのもう1つの主要な収益源はjitoSOL手数料で、同期間の合計は13,223.73 SOL（~238万ドル）でした。

Trusted Execution Environment（TEE）

Trusted Execution Environment（TEE）は、計算とメモリの両方の機密性と完全性を確保するために設計された、ハードウェアベースのアーキテクチャです。エンクレーブとも呼ばれるTEEは、通常、ハードウェアレベルの分離によって、ホストシステムのオペレーティングシステム、カーネル、ハイパーバイザーからコード実行を隔離します。この分離によって攻撃対象領域が大幅に縮小され、エンクレーブ内の動作を観測または改ざんすることは、不可能ではないものの極めて困難になります。

TEEは2000年代から、デジタル著作権管理、コンテンツ保護、安全な決済システムなどの分野で利用されています。現在では、機密データとコードを安全に扱うため、一般消費者向けデバイスやクラウドサービスで広く採用されています。スマートフォンやノートPCでは、AppleのSecure EnclaveとAndroidのTrustZoneが生体認証データ、決済認証情報、暗号鍵を保護します。PlayStationやXboxなどのゲーム機は、AMDまたはPlutonベースのプロセッサを使用して改ざんや著作権侵害を防止しています。クラウドでは、AzureやGoogle CloudなどのプロバイダーがAMD SEV-SNP、Intel TDX、AWS Nitro Enclavesを活用してワークロードを分離し、コンフィデンシャルコンピューティングを実現しています。LedgerやTrezorなどの暗号資産ウォレットはセキュアエレメントで秘密鍵を保護し、新しいSolana Seekerスマートフォンも同じ目的でTEEを利用しています。

TEEは、プライベートデータを処理するための標準的なハードウェアベースの手法であり、完全準同型暗号（FHE）やセキュアマルチパーティ計算（MPC）など、純粋に暗号技術へ依存する手法に代わる実用的な選択肢です。FHEとMPCは理論上強力な保証を提供しますが、複雑性とパフォーマンス上のオーバーヘッドが大きく、実環境では実用的でないことが少なくありません。

BAMは、TEEが持つ2つの中核的な特性を活用します。

機密性： TEE内のコードとデータは暗号化され、システムの他の部分から隔離されます。オペレーティングシステム、ハイパーバイザー、外部ソフトウェアのいずれも、エンクレーブ内で実行される内容へアクセスしたり検査したりできません。

証明可能性： TEEは、エンクレーブの出所と現在の状態を暗号学的に証明する仕組みであるアテステーションをサポートします。これにより第三者は、侵害またはエミュレートされた環境ではなく、本物のTEEが信頼できるコードを実行して結果を生成したことを検証できます。

BAMにおけるTEEの実装

BAMは、強化されたSecure Encrypted Virtualization with Secure Nested Paging（SEV-SNP）をサポートするAMDプロセッサ上で稼働します。小規模なエンクレーブベースのアプローチとは異なり、SEV-SNPは最小限のパフォーマンスオーバーヘッドでBAMアプリケーション全体を保護します。そのため、高スループットかつ低レイテンシのトランザクションシステムに適しています。

ハードウェアアクセラレーションにより、SEV-SNPのオーバーヘッドはわずか2〜5%で、リアルタイム処理に十分な速度です。分離された計算だけでなく、複雑でステートフルなネットワークアプリケーションにも対応できます。この技術は実運用で十分に検証されており、Google Cloud、Azure、AWSなどの主要クラウドプロバイダーで導入されています。また、長年にわたるセキュリティ研究と運用経験にも裏付けられています。

BAMで使用されるSEV-SNPは、複数の重要なセキュリティ保証を提供します。各TEEインスタンスは、ハードウェアによって隔離された独自の仮想マシン内で動作し、実行時にメモリを暗号化することで、VMレベルの強力な分離を実現します。BAMはハードウェアルートのアテステーションを活用し、各TEEが真正かつ未改変のコードを実行していることを暗号学的に証明できるようにします。このアテステーションチェーンは、製造時にCPUへ物理的に組み込まれるAMDのハードウェアルートキーを基点とします。さらに、TLS鍵はプロセッサ内部のハードウェア乱数生成器を使用して生成されるため、暗号化されていないメモリに露出することはありません。

クライアントがBAMへ接続すると、標準の接続証明書、AMD SEV-SNPアテステーションレポート、TLS秘密鍵がアテステーション済みTEE内で生成されたことを示す暗号学的証明を含むTLS証明書を受け取ります。この証明書チェーンは、AMDのハードウェアベースの信頼の起点と暗号学的に結び付けられています。AMDの秘密ルートキーへアクセスしない限り偽造できないため、AMDのチップ製造プロセス以外の仲介者を信頼する必要がありません。

プラグイン

現在、Solana上のアプリケーションがトランザクションの順序へ影響を与える方法は、優先手数料または関連するチップを伴うバンドルトランザクションに限られています。AgaveやFiredancerなどのクライアント間で複数のシーケンサーが動作しているため、どの順序付けロジックが適用されるかは保証されません。その結果、アプリケーションがトランザクションの順序を制御できる範囲は限られています。

プラグインがこれを解決します。 

BAMのプラグインフレームワークを通じて、開発者は独自の順序付けロジックを実装し、新しいスケジューリングプリミティブを導入できます。プラグインは**Application-Controlled Execution（ACE）**を実現し、アプリが独自のトランザクションスケジューリングポリシーを定義できるようにします。ACEには多くの用途が考えられますが、最も広く知られ、議論されているユースケースは注文板のキャンセルを優先することです。この仕組みにより逆選択が軽減され、スプレッドを縮小できます。

注文板におけるメイカーのキャンセルを優先

現在、Solana上のオンチェーン注文板で活動するマーケットメイカーは不利な立場にあります。マーケットメイカーは公正価格が変化した際に、古くなったクオートを継続的に更新またはキャンセルすることでリスクを管理します。市場価格が動いた場合、情報を持つテイカーに機会を利用される前に、既存の注文をキャンセルする必要があります。  

トランザクションの順序をきめ細かく制御できなければ、古い価格設定を悪用する有害なフローにクオートがさらされます。マーケットメイカーが素早く行動しても、Jitoオークションでは意図より入札額が優先されるため、損失を被る可能性があります。つまり、より多く支払った当事者が先に処理されます。

この状況により、マーケットメイカーはリスク管理のためにスプレッドを広げざるを得ず、市場全体の流動性が低下し、ユーザーにとって価格条件が悪化します。テイカーが古い価格設定から利益を得て、取引相手が約定直後に後悔するような有害な取引は、ユーザー体験にはほとんど貢献せず、マーケットメイカーと流動性プロバイダーの負担を大幅に増やします。

BAMプラグインでは、「約定前にキャンセルする」ポリシーをアプリケーションレベルで適用できます。プログラムがトランザクションの順序をきめ細かく制御できるため、アプリケーションはテイカー取引より先にメイカーのキャンセルを処理できます。このシンプルなポリシー変更は、大きな効果をもたらします。

• 逆選択を軽減： 市場が動いた際に、メイカーが繰り返し不利な約定を強いられなくなります。
• 有害なフローを排除： 有害な取引が減ることで全体の取引量は低下する可能性がありますが、フローと実行の品質は向上します。
• スプレッドを縮小： リスクが低下するため、メイカーはより積極的な価格を提示できます。
• 流動性を向上： プロのメイカーと個人トレーダーの双方が、より安心してクオートを提示できるため、流動性が厚くなります。

ジャストインタイムのオラクル更新

アプリケーション固有のプラグインのもう1つの例が、Pythが実装を計画しているジャストインタイムのオラクル更新です。Solanaを代表するオラクルプロバイダーであるPythは1,700以上の個別価格フィードを管理しています。すべての価格フィードをブロックごとに更新すると、コストが非常に高く、ブロックスペースの利用効率も悪化します。

BAMを使用すると、Pythは同じブロック内でユーザーのトランザクションの直前にオラクル更新を挿入し、必要なタイミングで特定の価格フィードを正確に更新できます。これにより、非効率な清算やオラクル操作など、古いオラクルデータに伴うリスクが軽減され、DeFiアプリケーションはより高い信頼性と競争力を持って動作できます。

その他のプラグイン

最終的にBAMは、アプリケーション開発者がトランザクションシーケンシングを制御するプラグインを構築、テスト、デプロイできる、パーミッションレスなプラットフォームを目指しています。今後さらに多くのプラグインが登場し、最終的にはBAMノードが数百のカスタマイズ可能な拡張機能をサポートすると見込まれます。ほとんどのアプリケーションは引き続きデフォルトのスケジューラを使用しますが、独自のシーケンシングロジックを必要とするアプリケーションは、自らプラグインを開発して保守する責任を負います。 

さらに、アプリケーションはプラグイン機能に手数料を設定して収益化でき、その一部をガバナンストークン保有者やバリデータと共有できる可能性があります。

想定される汎用プラグイン

プラグインは単一のアプリケーションに限定されません。Jitoはすでに、BAM向けに開発できる汎用的なクロスアプリケーションプラグインの例を複数提案しています。

ブロックスペース先物： ユーザーやアプリケーションが将来の特定時点でブロックスペースを使用する権利を予約または取引できるようにし、ネットワーク需要が高い期間でも予測可能なアクセスと価格を提供します。

Time in Force（TIF）： 注文が完全に約定しなかった場合に自動キャンセルされるまでの有効期間を指します。たとえば、注文板のトランザクションを20ミリ秒だけ有効にできます。現在のSolanaでも、意図的に古いblockhashを使用し、トランザクションを直近のブロックだけで有効にすることで、簡易的な実装が可能です。

事前確認： トランザクションが実行されてネットワークへ伝播される前に、バリデータへ転送された時点でユーザーへ通知できます。これにより、一定の確度でトランザクションを早期に確認できます。

手数料無料トランザクション： ユーザーはSOLの代わりにSPLトークン（例：ステーブルコイン）でトランザクション費用を支払えます。ネイティブトークン要件を抽象化し、柔軟な手数料支払いを実現します。

低レイテンシのアグリゲーターとRequest for Quotation（RFQ）： ユーザーは取引意図をBAMへ直接送信し、ローカルで動作するアグリゲーターが最適なルートを特定します。

トランザクションのキャンセルと置換： ユーザーは、以前に送信したトランザクションをキャンセル、破棄、または置換できる特別なマーカー付きトランザクションを送信できます。

ロールアウト

ローンチフェーズでは、安定性、パフォーマンス、セキュリティを確保するため、Jito Labsが初期のBAMノード群を運用します。Helius、SOL Strategies、Triton One、Figmentを含む、許可制の初期バリデータパートナーがBAMクライアントを実行し、ローンチ直後にネットワーク総ステークの1桁台後半の割合を保護します。 

これと並行して、Drift、Pyth、DFlowなどのSolanaアプリケーションの初期グループが、第1弾プラグインの設計とテストを開始します。ローンチフェーズ終了時までに、BAMは中核機能の検証を終え、ノードオペレーターやバリデータの幅広い参加に向けた基盤を確立する見込みです。 

BAMへの参加に関心があるバリデータ、アプリケーション開発者、サーチャーは、こちらのフォームに入力してください。

Solana Foundationを含む、Solanaのバリデータおよび開発者コミュニティの主要関係者で構成されるEcosystem Advisory Committeeが、Jito Labsへ助言を提供します。この委員会は、BAMの拡大を導き、分散化を促進し、コミュニティ主導のイノベーションを支援します。

現時点でBAMのコードベースはクローズドソースですが、第三者によるプラグイン開発を可能にするため、近い将来オープンソース化する予定です。オープンソース化後、BAMは複数の主要分野でコミュニティからの貢献を受け入れます。

• プラグイン開発：BAMの機能を拡張する独自プラグインを構築します。
• スケジューリングアルゴリズム：特定のユースケースに合わせた新しいトランザクション順序付け戦略を設計し、提供します。
• 統合ライブラリ：BAMとの統合を簡素化するSDKを複数のプログラミング言語で開発します。
• 分析ツール：BAMのアテステーションデータを活用するダッシュボードと監視システムを作成します。
• 研究への貢献：MEVの軽減とシステム最適化に向けた新しいアプローチを提案し、実装します。

影響

BAMはSolanaにとって重要な転換点です。MEV搾取や効率的なブロックパッキングに関する懸念に対処し、新たなイノベーションの波を生み出す可能性があります。TEEで保護されたシーケンシングとBAMのプラグインフレームワークにより、アプリケーションチームが独自ロジックや独自方針のブロックスペースを実現するために、ネットワーク拡張、ロールアップ、またはSolanaの許可型環境を構築する動機が弱まり、より多くのアクティビティをSolanaメインネット上に維持できる可能性があります。さらに、ブロックあたりのコンピュート上限の引き上げや、使用するCUが少ない、より効率的なトークンプログラムおよびフレームワークへの需要（例：Pinocchioやp-tokenの人気上昇）によってメインネットの帯域に余裕が生まれ、開発者がカスタムソリューションを構築する動機はさらに弱まります。

BAMのプライバシー機能は、トランザクションを実行時まで秘匿することで、ボットがユーザーをフロントランする能力を制限し、サンドイッチ攻撃の発生を大幅に減らすと考えられます。その結果、DEXの効率が向上し、ユーザーにとってより競争力のある価格が実現する可能性があります。ただし、BAMがMEVを完全に排除する可能性は低いです。MEVは本質的にいたちごっこであり、サンドイッチ攻撃者は巧妙なプラグインの悪用や、暗号化パイプラインの対象外である外部オラクル（つまり、独自のプラグインを持たないオラクル）の操作などによって適応するでしょう。 

BAMによるMEVの削減は、Jitoの収益に悪影響を与える可能性があります。これは、短期的な収益を減らしたものの、最終的にはネットワークに利益をもたらした2024年のmempool停止を想起させます。BAMによって全体的なトランザクション量とプラグイン手数料が増えれば、導入率の向上を通じて長期的な収益が増加し、この影響を相殺できる可能性があります。ただし、BAMの具体的な実装、段階的な展開、経済設計には、潜在的な中央集権化リスクと未解決の問題があります。これらについては後続のセクションで検討します。それでも、こうしたリスクと未解決の問題にはさまざまな利点が対置されており、それぞれがMEVの再分配、PBS、「新しい」クライアントの開発に独自の影響を及ぼします。

MEVの再分配

BAMは、SolanaのMEV環境を、野放しの価値抽出から、より構造化された再分配モデルへと根本的に変えます。従来の構成では、フロントランやスパムによってユーザー価値がMEVに流出することが多く、バリデータやボットがサンドイッチ攻撃などの有害な手法で価値を獲得していました。しかし、BAMのTEE暗号化mempoolはトランザクションを実行時まで秘匿し、ネガティブMEVに必要な可視性を制限します。代わりに、価値はプラグインとカスタムシーケンシングを通じて内部化されます。これにより、アプリ、開発者、サーチャーは、エコシステムの効率を高めるポジティブMEV（例：DeFiのスプレッド縮小、オラクルスパムの削減）を獲得できます。

この再分配では、プラグイン手数料がBAM Nodeオペレーター、バリデータ、ステーカー、JitoのDAOの間で分配されるため、MEVの利益がステークホルダーに還元されます。これにより、持続可能な収益源を生み出せる可能性があります。たとえば、DEXは注文マッチングを最適化するプラグインを導入し、バリデータが抽出する可能性のあったMEVをアプリ由来の手数料に変換して、トークン保有者へ再分配できます。このようにトレーダーの活動を「保護」するアプローチにより、MEVはゼロサムゲームから、流動性を高めて機関投資家の資金を呼び込む仕組みへと変わる可能性があります。

ただし、再分配にはリスクが伴います。重要なのは、BAMはMEVを消し去るのではなく、移動させるという点です。この移動により、初期のプラグイン開発者、BAM Nodeオペレーター、Jitoと連携する事業体が過大な利益を得る可能性があります。暗号学的アテステーションによる制約はあるものの、TEEの脆弱性（例：サイドチャネル攻撃）が発見された場合、サーチャーへの特権アクセスが新たな巧妙な価値抽出経路を可能にし、最終的にプライバシー保証を損なうおそれがあります。また、これにより「保護された」バックランへの道も開かれます。サーチャーは戦略を公開せず、フロントランも可能にすることなく、ユーザーのトランザクション後にトランザクションを追加するコードをデプロイできます（例：価格を動かすスワップから裁定利益を得る場合）。さらに、プログラムによるスラッシングがないため、適応力のある攻撃者が、実行後に行われ、現時点ではコミュニティによる執行に依存しているアテステーションを巡って、有害な戦略を取る可能性があります。

最終的に、MEVの再分配によってBAMはSolanaの最終目標（つまり、分散型NASDAQ）を実現する触媒となり得ますが、その成功は、公平な手数料モデルの採用と堅牢なTEEセキュリティに左右されます。対応を誤れば、ネットワークが分断され、ユーザーの信頼が損なわれ、「保護」されているものの不透明なサーチャー活動に厳しい目が向けられる可能性があります。

提案者とビルダーの分離（PBS）

ほとんどのブロックチェーンは、同じ主体がブロックの提案と構築を担うように設計されており、割り当てられたスロット内でのトランザクションの順序付けと取り込みを独占的に制御できます。これは、トランザクションフローを自由に検閲または操作できるため、これらの主体にとって有利です。たとえば、高度ではあるものの有害な戦略を用いて特定の順序でトランザクションを取り込むブロックを提案・構築し、MEVを最大化できます。

提案者とビルダーの分離（PBS）は、ブロック構築とブロック提案を分離することで、この問題に対処する設計パターンです。この設計では、ブロックビルダーが順序付けされたトランザクションリストを作成し、そのブロックに対する入札を提出します。その後、通常はバリデータであるブロック提案者が最高額の入札ブロックを受け入れて確定し、自ら高度なシーケンシング戦略を運用することなく、オークションやチップを通じてMEVを再分配します。 

PBSは、2022年のThe Merge以降、Ethereum上でMEV-Boostを通じてプロトコル外に実装されています。MEV-Boostは、バリデータの実行レイヤーとコンセンサスレイヤーという2種類のクライアントソフトウェアと並行して動作する「サイドカー」です。MEV-Boostを実行するバリデータは複数のリレーに接続し、ブロックビルダーから事前構築済みのブロックを受け取れます。リレーから受け取るのはブロック報酬額とブロックヘッダーだけであるため、オンチェーンに取り込まれる前にブロックの内容を見ることはできません。この設計は現在も活発な研究段階にある点に注意が必要です。PBSはプロトコルへの完全な組み込み（ePBS）を待っており、そこには検閲をさらに緩和するための取り込みリストなどの機能が含まれる可能性があります。

BAMにより、SolanaはPBSに似た未来へ向かっています。TEEで保護されたBAM Nodeでのシーケンシングに相当するブロック構築と、引き続きバリデータが担う実行を分離する形です。これにより、プラグインを通じて、アプリやサーチャーがポジティブMEVを獲得する機会を民主化できる可能性があります。しかし、プラグインの経済設計が既存の有力事業者に有利であれば、Solanaのステーク集中を悪化させるリスクもあります。これはEthereumですでに顕在化しており、現在では3つのビルダー（Titan Builder、BuilderNet、Beaverbuild）が全ブロックの~90%超を占めています。その結果、リレーへの信頼に関する問題や、小規模参加者への参入障壁が生じています。 

MEV-BoostはEthereumにPBSを導入しましたが、ここでより適切な比較対象となるのはBuilderNetです。これは2024年11月に開始され、Flashbots、Beaverbuild、Nethermindが運営する分散型ブロック構築ネットワークです。BuilderNetはプライベートなブロック構築にTEEを使用し、複数のノードオペレーターにプロセスを分散することで、独占的なオーダーフロー契約を無力化し、中央集権化を抑えます。オーダーフローを巡る競争（例：非公開契約の奪い合い）ではなく、価値創出（つまり、ユーザー、ウォレット、アプリなどのオーダーフロー提供者とのMEV還元の共有）に重点を置いています。BuilderNetは引き続きMEV-Boostリレーを使用しますが、必須ではないため、TEE内でビルダーと提案者が直接やり取りできます。 

BAMの段階的かつ許可型の展開では、Ethereumで見られたこうした落とし穴を軽減するため、公平な手数料とオープンソースのプラグインを優先する必要があります。特に、ハードウェアへの依存（つまり、Ethereumのソフトウェアリレーに対するTEE）は、ベンダーロックインや保守コストをもたらします。Solanaはオーダーフローを巡る競争を飛び越え、価値創出に重点を置くBuilderNetのようなシステムへ一気に移行することを目指しています。 

最終的に、ブロック構築と提案におけるこの変化はバリデータの役割を縮小し、シーケンシングの複雑さを切り離しますが、手数料が広く分配されなければ、バリデータの裁量と収益を減らす可能性があります。これについては、縮小するバリデータの役割というセクションで詳しく検討します。

上：EthereumのPBSとSolanaのBAMの比較

「新しい」クライアントの登場

Jito-AgaveクライアントはAgaveのコアコードベースをほぼ踏襲しており、主な違いはMEV機能の追加です。Jitoの「AgaveプラスMEV」モデルにより、コアアーキテクチャへの変更を最小限に抑えながら、既存のSolanaバリデータエコシステムへクライアントを円滑に統合し、報酬を増やすことができました。その結果、執筆時点でJito-Agaveクライアントはバリデータ採用率79%でネットワーク首位に立っています。このため、バリデータはAgaveの基盤ロジックを利用しつつ、Jitoの追加収益源から利益を得られます。

BAMは、Agaveを緊密に踏襲してきたJitoの従来のアプローチからの転換を示しています。BAM Nodeの専用ネットワークを導入することで、新たなインフラストラクチャレイヤーが確立されます。この進化により、Jitoは単なる「強化版Agave」から、アプリケーション固有のロジックを組み込む独自のプログラマブルエコシステムを備えた、より明確に差別化されたクライアントへ移行します。

この相違は、Anzaが5月に発表したAgaveの次期スケジューラーバインディングに表れています。SolanaのMEVが成熟するにつれて、カスタムスケジューラーの実装はますます一般的になっています。カスタムスケジューラーは運営者の収益を増やす可能性がありますが、現在の実装には、別バージョンのバリデータバイナリを実行する必要があること、クローズドソースコードに依存すること、ライブネスに関する潜在的な懸念など、複数の欠点があります。 

Anzaの次期スケジューラーバインディングは、バリデータがコアのバリデータバイナリを変更せずに外部のブロック構築サービスへ接続できるようにし、カスタムスケジューラーをサポートすることでモジュール性を導入します。この設計により、透明性、安全性、DevOpsの容易さが向上します。しかし、BAMでは上流のBAM Nodeスケジューラーがシーケンシングを処理するため、Jitoユーザーはこれらのバインディングを使用する必要がありません。これはAgaveが計画するスケジューラーバインディングを迂回するため、運用を効率化できる可能性がある一方、Anzaの標準化の取り組みから乖離することで、将来的にエコシステムが分断される懸念も生じます（例：Firedancerとの統合が複雑になる可能性）。

一方、JitoはBAMを統合型バリデータクライアントの一部として位置付けています。BAMバリデータは、BAMスケジューラーを統合した更新版Agaveクライアントを実行し、BAM NodeからFIFO順で送られるトランザクションのみを受け入れます。この設計は、システムの耐障害性を高めながら、クライアントの分断を回避します。Jitoは、Anzaのモジュール型スケジューラーの展開に先駆けて、BAM対応クライアントをリリースする予定です。この動きはBAMの二面的な影響を浮き彫りにします。イノベーションを促進し、SolanaのMEVインフラストラクチャを前進させる一方で、主要バリデータクライアントとしてのJitoの地位をさらに固定化するリスクもあります。

BAMがこれらのバインディングを使用する可能性もあります。BAMがモジュール型スケジューラー内で動作すれば、Firedancerのサポートは容易になり、Jitoにバリデータクライアントが本当に必要なのかという新たな疑問が生じます。BAMのオープンソース実装と展開を待つ中で、答えを知るには時間が必要です。

未解決の問題

縮小するバリデータの役割

BAMの設計は、トランザクションのシーケンシングをTEEで保護された独立したBAM Nodeネットワークへ移すことで、Solanaのバリデータ環境を根本的に変えます。その結果、バリデータは主に実行、コンセンサス、状態管理を担当することになります。この分離は、カスタムシーケンシングやトークン保有者との収益共有を可能にするため、アプリにとって有益です。また、ネガティブMEVを減らし、より有利な価格を提供するため、ユーザーにもメリットがあります。しかし、バリデータの裁量と経済的インセンティブの縮小に関する疑問が生じます。

現在、バリデータはリーダーとしてブロックを生成する際、トランザクションの順序を完全に裁量でき、独自の判断でブロックを最適化するカスタムスケジューラーを実行できます。BAMはこの責任をバリデータから取り除きます。バリデータは事前にシーケンシングされたトランザクションを受け取り、厳密なFIFO順で実行するため、ブロック構築に関する自律性を失います。極端な場合、すべてのトランザクションがBAMを経由すれば、バリデータは単なる「追認役」となり、そもそも分散型バリデータが必要なのかという疑問が生じます。 

ただし、これを相殺する要因もあります。具体的には、プラグイン手数料がバリデータやステーカーと共有され、新たな収益源となります。BAMの統合クライアントと自動フォールバックは、自己利益とネットワークの健全性を一致させ、全体的な耐障害性を高めます。オプトイン方式の段階的な展開によって選択肢も維持され、長期的なオープンソース化により、バリデータはBAMの開発に意見を反映できます。これにより、コミュニティ主導の改善が促進され、一定の裁量が保たれます。  バリデータには、BAMに対してスケジューラーの改善を提案する可能性もあり、取引量の増加から手数料を得る道が開かれるかもしれません。さらに、バリデータはコンセンサスとフォーク選択において依然として重要な役割を担うため、単なる追認役になるという見方は誇張である可能性があります。本当の問題は、バリデータが実際にどれだけの裁量を失うのかという点です。BAMによって、バリデータがライブネスと状態の完全性により集中できる可能性はないでしょうか。

いくつかの疑問が残ります。

• BAM NodeがシーケンシングとMEV抽出を担う場合、バリデータはハードウェアと稼働時間以外の面でどのように競争するのでしょうか。 
• 導入率が高まった場合、バリデータが実行のみに注力することでSolana全体の分散性は低下するのでしょうか。低下する場合、それをどのような指標で測定できるのでしょうか。
• BAMによってバリデータが収益を求めてより悪質な手段へ向かう場合、インセンティブをさらに低下させることなく、それを防ぐためにアテステーション以外にどのような保護策を講じられるでしょうか。
• TEEの脆弱性やプラグインの悪用によって、バリデータが不当にペナルティを科される可能性はあるでしょうか。 
• EthereumのPBSの経験を踏まえ、Solanaはバリデータの裁量縮小に対してどのような対策を講じられるでしょうか。

悪意のあるノードオペレーター

BAMのアーキテクチャは、バリデータに関する新たな信頼の前提を導入します。つまり、バリデータがBAM Nodeとやり取りする際、事前にシーケンシングされたトランザクションの改ざんやデータ漏洩などの悪意ある行為をしないという前提です。ローンチ時にはTEEの制約により、BAMは許可型のオペレーター群に依存します。この許可型の参加者には、更新版Jito-Solanaクライアントを実行し、転送されたトランザクションを忠実に処理する責任が委ねられます。これらのバリデータは、BAM Nodeが入口でデータを操作しないことを信頼しなければならず、二層の信頼（つまり、TEE前のBAM NodeとTEE後のバリデータ）が生じ、許可型の構成におけるリスクが高まります。重要な疑問は、トランザクションがTEEに到達する前にBAM Nodeオペレーターが内容を覗き見ることを、何が防ぐのかという点です。その答えは、検証済みノード向けのQUIC暗号化です。QUIC証明書にアテステーションが埋め込まれます。BAM Nodeが誠実かどうかを確認するもう1つの方法は、そのハッシュをBAMのオープンソースリポジトリと照合し、特定のBAM Nodeが申告どおりのソフトウェアを実行しているか確認することです。TEEが破られていないと仮定すれば、TPU用のQUIC証明書はTEE内で生成されます。したがって、すべての送受信トラフィックが暗号化されます。

ただし、ネットワークの入口と出口におけるトランザクションパケットの検閲や選択的な操作は、重大な懸念事項です。悪意のあるオペレーターは、暗号化されたトランザクションの詳細を閲覧できなくても、依然として大きな検閲能力を持ちます。TLSシグネチャからプロトコルの種類を特定し、接続先に基づいてフィルタリングし、タイミング分析で特定のパターンを識別し、特定の特徴に一致する暗号化データをすべてブロックできます。そのため、悪意のあるオペレーターは送信中の正確なトランザクションを把握できなくても、メタデータや特定のトラフィックパターンに基づいてパケットを破棄できます。これを軽減するため、DoubleZeroのパケットフィルタリングとタイムスタンプ機能を組み込むことで、透明性を高められる可能性があります。最終的に、ネットワーク検閲攻撃を軽減することは、許可型で展開する正当な理由です。

物理アクセスに関しても、新たな信頼の前提があります。物理アクセスはほぼ常にセキュリティ障害につながり、TEEも例外ではありません。TEEは強力なセキュリティ保証を提供しますが、攻撃者がサーバーに物理的にアクセスすれば侵害される可能性があります。SOC 2準拠プロバイダーとの独占的パートナーシップは、このリスクの軽減に役立ち、データセンターレベルで堅牢な多層防御を確保します。

いくつかの疑問が残ります。

• 悪意のあるオペレーターがパケットを検閲したりデータを漏洩したりした場合、どのようにルールを執行するのでしょうか。
• 許可型の段階では、オペレーターの選定においてどのように共謀を回避し、分散化への進展をどの指標で測定するのでしょうか。 

コンポーザビリティとプラグインの相互作用

BAMに関する最も重要な未解決問題の1つは、実際にプラグイン同士がどのように連携するかです。1つのトランザクションが複数のプラグインに同時に依存する場合があります。たとえば、即時の価格更新にオラクルプラグイン、最適なスワップ経路の決定にDEXプラグイン、特定のSPLトークン動作の処理にトークンプラグインを使用する場合です。これらのコンポーネントが予測可能かつ安全に連携することを保証するのが極めて重要です。

プラグインが効果的に機能するには、外部データを取得する必要があるかもしれません。しかし、悪意のあるプラグインが外部呼び出しを悪用して機密性の高いトランザクション情報を漏洩する可能性があるため、これは潜在的な攻撃対象領域となります。システムへの信頼を維持するには、プラグインがアクセスおよび共有できる情報について厳格な境界を定めることが不可欠です。

アプリケーションレベルのプラグインロジックとSolanaの手数料メカニズムの相互作用によって、さらに複雑さが増します。複数のプラグインがブロック構築への影響力を競う場合、プラグインの実行順序、Jitoのチップ、優先手数料はどのように作用するのでしょうか。意図しない操作や悪用を防ぐには、こうした経済的ダイナミクスを明確に定義し、透明性をもって適用する必要があります。

こうしたリスクを管理するため、BAMプラグインの展開は許可型環境から開始される見込みです。これにより、段階的にパーミッションレスモデルへ移行する前に、初期段階でプラグインの挙動を実験・監査できます。

TEEへの信頼と責任

TEEへの依存は、検証可能な計算を保証するトラストレスなシステムを構築する代わりに、特殊なハードウェアエンクレーブを使用するため、新たな信頼の前提を導入します。IntelやAMDなど単一のハードウェアベンダーに依存すると、モノカルチャーのリスクが生じます。ファームウェアのリコールや脆弱性の悪用によってBAMが停止し、ネットワークでの採用状況によってはネットワーク全体のダウンタイムを引き起こす可能性があります。こうした脆弱性をファームウェア、マイクロコード、BIOSの更新で修正できない場合、ハードウェアの交換には時間がかかり、BAM Nodeオペレーターに継続的な設備投資を強いるため、潜在的なダウンタイムの影響がさらに深刻になります。 

こうした懸念は、TEEが機能不全に陥り、暗号化データが漏洩し得ることを示した過去の脆弱性に基づいています。たとえば、IntelのSoftware Guard Extensions（SGX）では、ブロックチェーンに影響を与える問題が相次いで発生しました。2022年8月、Secret NetworkはxAPICとMMIOの脆弱性の影響を受ける状態にありました。これらの脆弱性を組み合わせることで、ネットワーク上で実行される非公開トランザクションのマスター復号鍵であるコンセンサスシードを抽出できる可能性がありました。 

その他にも多数の問題があり、最終的にIntelは第11世代および第12世代Intel CoreプロセッサからSGXを非推奨にしました。AMDのSecure Encrypted Virtualization-Secure Nested Paging（SEV-SNP）にも、開示済みの脆弱性が複数あります。特に2月には、管理者アクセス権を使った悪意のあるマイクロコード注入を可能にする脆弱性、CVE-2024-56161が開示されました。 

脆弱性を軽減するための更新には後方互換性がない場合があり、物理的なアップグレードが必要になることもあります。たとえば、CVE02020-12967とCVE-2021-26311の開示により、AMD Secure Encrypted Virtualization-Encrypted State（SEV-ES）マシン上のゲスト仮想マシン内で任意のコードを実行できる可能性があることが判明しました。SEV-ESは、同社の前世代TEE実装です。AMDはこれらの脆弱性に対処する更新済みファームウェアをリリースせず、第3世代AMD EPYC（つまり「Milan」）プロセッサでのみサポートされるSEV-SNP機能で緩和策を提供しました。 

BAMのTEEインフラストラクチャは、これらの既知の攻撃を防ぐために必要なハードウェアレベルの保護を備えた、最新世代のSEV-SNPアーキテクチャ上に構築されています。また、ゼロデイ脆弱性が発見された場合でも、Jito-ValidatorはBAM Nodeから切断されると自身のTPUへ自動的にフォールバックできるため、ネットワークは稼働を継続できる点も重要です。このフェイルオーバーメカニズムにより、セキュリティパッチの適用中もバリデータは稼働を続けられます。

いくつかの疑問が残ります。

• 過去の脆弱性を踏まえると、BAMのハードウェアベンダーへの依存は長期的な信頼にどのような影響を与えるのでしょうか。ゼロトラスト実行環境（ZTEE）などの代替手段を使用して、この依存を軽減できるでしょうか。
• 侵害されたTEEから非公開トランザクションデータが漏洩した場合、金銭的損失の責任は誰が負うのでしょうか。
• TEEに障害が発生した場合、どのように信頼を回復するのでしょうか。代替手段を提供できるでしょうか。

まとめ

最終的に、バリデータは自ら選んだソフトウェアを自由に実行できます。競争の激しい市場で利益を追求する事業者として、その意思決定は、自身と委任者の双方が得られる潜在的な収益に左右されます。委任者は、利回りが最も高い場所へ自由にステークを移せます。Jito-clientが広く採用されていることは、この力学を反映しています。その成功は、運営者と委任者の双方に追加収益をもたらす能力によって大きく後押しされています。BAMの採用も、同様の力学に左右されます。BAMの運用が現状よりも一貫して高い収益性をもたらすと証明されれば、バリデータは採用するでしょう。そうでなければ、BAMが他のステークホルダーに大きなメリットをもたらすことに成功しても、切り替えには慎重になる可能性があります。

BAMは発表されたばかりであり、その設計と運用については多くの疑問が未解決のままです。この期待の高まる開発について、今後数か月のうちに、さらなる詳細やドキュメントが公開され、コミュニティで議論が進むことを楽しみにしています。

関連リソース

• BAMの紹介：Solanaにおけるブロック構築の未来 - Jito
• BAMホワイトボードシリーズ - Jito Learn
• Jito BAMとSolanaの未来 - 0xResearch