BAL（EIP-7928）とは何でしょうか。また、なぜ並列実行の前提条件とされているのでしょうか

BAL（EIP-7928）は、Glamsterdamの議論で「並列実行の前提条件」として頻繁に言及されています。この用語は、すべてのトランザクションが即座に並列実行されることを意味するのではなく、状態アクセスの関係性が暗黙の前提から検証可能で明示的な制約へと移行することを示します。これらの制約が明確に定義されて初めて、安定したスケジューリングが実現できます。

この制約レイヤーは、Glamsterdamアップグレード概要で説明されているアップグレード目標と密接に関連しており、ePBS（EIP-7732）メカニズムを補完します。ePBSはブロック生成協調の境界を、BALは実行制約の境界を定義します。GlamsterdamがDAppに与える影響では、制約レイヤーの変化がアプリケーションのパフォーマンス期待値やリリース頻度にどのように影響するかがさらに説明されています。

BAL（EIP-7928）とは

BALはBlock-Level Access Lists（ブロックレベルアクセスリスト）の略で、ブロック実行時にアクセスされたアカウントおよびストレージスロットを記録し、実行後の状態結果も含まれる場合があります。目的は実行エンジンの代替ではなく、より早期かつ明確な競合検出とデータ準備のための入力を提供することです。

従来の直列実行は一貫性維持が容易ですが、高負荷時には効率面で限界に直面します。並列実行を実現するには、「どのトランザクションが互いに競合するか？」という問いへの解答が不可欠です。BALの価値は、競合検出を実行時から計画可能な事前段階へ移行させる点にあります。Ethereum.orgのロードマップやEIP-7928によれば、BALはGlamsterdamアップグレードの重要な提案です。

なぜEthereumにブロックレベルアクセスリストが必要か

ブロックが複雑化する中、状態の読み書き関係が実行時に動的にしか判明しない場合、クライアントは事前に実行経路を計画できません。ハードウェアリソースが十分でも、ロールバック競合や再スケジューリングにより効率が低下します。

ブロックレベルアクセスリストにより「実行時に競合が初めて判明する」リスクが減少します。明確な制約が事前に存在することで、クライアントはデータ準備・タスク分割・競合分離を行い、パフォーマンスのランダムな変動を抑制できます。インデックスサービスやアーカイブノードなど大量の状態読み取りを行う役割にとっても、事前のアクセス関係把握はI/O計画の最適化に貢献します。

この表は、BALが「情報の可用性」を変えるものであり、単に最終スループットだけを決定するものではないことを示しています。

BALはどのようにクライアントの競合特定やスケジューリング最適化に寄与するか

クライアントはアクセスリストを活用し、「並列化可能な集合」と「直列化必須の経路」を分割するという2つの主要な判断を行えます。完全な並列化が困難でも、競合の少ない部分から優先的に最適化し、徐々に並列化範囲を拡大できます。

エンジニアリング観点では、BALは一時的な性能向上をもたらすものではなく、実行挙動の予測可能性を高めます。ノード運用チームにとっては、短期的なピークよりも予測可能性の方がSLAや障害対応に直結するため重要です。テストネット上での競合・ロールバック率の変動は、BALの有効性を評価する主要指標となります。

図1. BALメカニズムのイメージ：ブロックレベルアクセスリストが競合検出と並列実行スケジューリングを支援する仕組み

BALと並列実行の関係

BALは並列実行の「代替」ではなく「前提レイヤー」です。並列実行の実現には、クライアント実装・スケジューリング戦略・状態管理の連携も不可欠です。基礎的な制約がなければ、強制的な並列化はかえって不確実性を高めます。

要するに、BALは並列実行を理論上の概念からエンジニアが実現可能な目標へと転換します。「前提条件が整っているか？」に答えるものであり、「最大性能が出ているか？」に答えるものではありません。より積極的な並列戦略が導入されても、BALのアクセス制約は競合管理に不可欠です。

BALが開発者・アプリケーションチームにもたらす意味

開発者は状態アクセスパターンに一層注意を払う必要があります。同一状態への高頻度書き込みや複雑なコントラクト間依存、バッチトランザクションの結合といった設計は、新たな制約下で異なる実行挙動を示す可能性があります。アプリケーションは機能テストだけでなく、実行経路のテストもローンチ前に実施すべきです。

プロダクトチームもパフォーマンス説明の再調整が必要です。アップグレード後のユーザー体験向上は直線的ではなく、エコシステム適応に応じて変動します。安定性・失敗率・レイテンシパーセンタイルといった段階的指標で確認し、平均値だけで判断しないことが賢明です。指標リセットや段階的リリースは、アプリケーション適応フレームワークと連動させるべきです。

BALの実装範囲と潜在的課題

最初の課題はクライアント間の一貫性確保です。異なる実行クライアントがアクセスリストやスケジューリング戦略を異なる解釈で実装する可能性があり、テストネット比較やクロスクライアント回帰、タイムスタンプ付きメトリクススナップショットを通じた収束が求められます。

2つ目の課題はエコシステムの学習コストです。開発チームが状態アクセス構造を見落とすと、アップグレード後にパフォーマンス逸脱が生じる場合があります。レガシーコントラクトはアクセスフレンドリーなパターンで書かれていないことも多く、移行にはツールと時間が必要です。

3つ目の課題はモニタリングシステムの更新です。運用チームはアクセス制約に関する新たな指標を導入し、問題がデータ準備・スケジューリング競合・実行エンジンのボトルネックのどこに起因するかを特定する必要があります。モニタリングが未対応のままでは、メカニズムの価値を十分に発揮できません。ノードアップグレード準備チェックリストでは、BAL関連のログや競合ロールバック率を受け入れ基準に含めるべきです。Glamsterdam対Dencun/Fusaka比較の文脈では、これらの課題は構造的変更に特有のリスクであり、単なるキャパシティアップグレード経験だけでは対処できません。

まとめ

BAL（EIP-7928）は、状態アクセス関係を明示化し、競合検出を構造化し、スケジューリングをリアクティブから検証可能な計画へと移行させることで、実行順序の課題に対応します。アップグレードの成否を単独で決定するものではありませんが、安定した並列実行には不可欠であり、Glamsterdam実行レイヤーの中核となる制約メカニズムです。

よくある質問

BAL（EIP-7928）は並列実行そのものですか？

いいえ。BALは並列実行の前提制約レイヤーであり、競合検出の基盤を提供します。並列実行はクライアント実装やスケジューリング戦略にも依存します。

なぜBALは実際のパフォーマンスに影響するのですか？

状態アクセス関係を事前に明示することで、クライアントは早期にデータ準備やタスクグループ化が可能となり、実行時の競合ロールバックを減らし、実行の安定性が向上します。

BALとePBS（EIP-7732）の役割分担は？

ePBSはブロック生成協調の境界を、BALは実行制約の境界を扱います。それぞれ異なるレイヤーで機能し、Glamsterdamにおいては補完的な関係です。

DAppチームはBAL導入にどう対応すべきですか？

状態アクセスパターンや高頻度トランザクション経路を見直し、アップグレード前後での実行挙動テストを補完し、パフォーマンスモニタリングやアラート閾値を更新して、従来の実行前提に依存しないようにしてください。

BALで全トランザクションの並列処理が保証されますか？

いいえ。BALは競合検出とスケジューリングの入力を提供しますが、競合の多いトランザクションは直列処理が必要です。並列化の範囲はアクセスパターン、クライアント実装、ネットワーク負荷特性に依存します。