イーサリアムの Glamsterdam アップグレード:Block Access Lists と ePBS が 2026 年のネットワークをどのように変革するか
イーサリアムのバリデータは現在、食料品店のレジが 1 つのレーンで機能するのと同じようにトランザクションを処理しています。つまり、列がどれほど長く伸びていても、1 つずつ順番に、前のものが終わるまで処理されません。2026 年半ばに予定されている Glamsterdam(グラムステルダム)アップグレードは、このアーキテクチャを根本から変えます。Block Access Lists(BAL)と enshrined Proposer-Builder Separation(ePBS)を導入することで、イーサリアムは現在の約 21 TPS(秒間トランザクション数)から 10,000 TPS へとスケールする準備を整えています。これは 476 倍の向上であり、DeFi 、 NFT 、およびオンチェーンアプリケーションのあり方を再構築する可能性があります。
ボトルネックの問題:なぜイーサリアムには並列実行が必要なのか
2022 年の The Merge(ザ・マージ)以来、イーサリアムはプルーフ・オブ・ステーク(PoS)コンセンサスで稼働していますが、その実行レイヤーは根本的に逐次的(シーケンシャル)なままです。すべてのトランザクションは前のトランザクションの完了を待たなければならず、需要が高い時期には計算処理の渋滞が発生します。この設計上の選択は、イーサリアムがまだ初期段階にあった頃には、逐次実行の方が実装や推論が容易であったため理にかなっていました。しかし、現在ではネットワークにおける最も重大なスケーリングの制限となっています。
数字がその状況を明確に物語っています。イーサリアムのベースレイヤーは現在、6,000 万のガスリミットで約 21 TPS を処理しています。一方、競合する Solana は 1,100 TPS 以上を処理し、Visa のような中央集権的な決済ネットワークは 65,000 TPS 以上を処理します。イーサリアムがグローバル金融の決済レイヤー(ブラックロックの BUIDL ファンド、JP モルガンのトークン化されたマネーマーケットファンド、成長を続ける機関投資家向け DeFi エコシステムなど)として機能するためには、劇的に高いスループットが必要です。
Arbitrum 、 Optimism 、 Base といったレイヤー 2 ソリューションは、この需要の多 くを吸収しており、合計で 390 億ドル以上の TVL を保持しています。しかし、L1 の混雑は依然として問題を引き起こしています。高額なロールアップのデータ投稿コスト、ファイナリティの遅延、そして L2 がより多くの価値を獲得する中で、イーサリアムが依然として重要であり続けられるかという絶え間ない問いです。
Block Access Lists: 1 車線から多車線の高速道路へ
Glamsterdam アップグレードの目玉は EIP-7928 で、これにより Block Access Lists が導入されます。お役所仕事のような名前に聞こえるかもしれませんが、BAL は革新的な何かを可能にします。それは、ブロック内のトランザクションが互いにどのように関連し、ネットワークのどの部分のステート(状態)を修正するかを示す「マップ」を作成することです。
これがなぜ重要なのかを説明します。2 つのトランザクションが完全に異なるアカウントやストレージスロットにアクセスする場合(例えば、あるユーザーが Uniswap で ETH を USDC に交換し、別のユーザーが NFT をミントする場合)、それらを同時に実行できない論理的な理由はありません。現在のアーキテクチャでは、イーサリアム仮想マシン(EVM)がそれらが競合するかどうかを事前に判断できないため、どちらにせよ列に並んで待つことを強制されます。
Block Access Lists は、各トランザクションがどのアカウントとストレージの場所に触れるかを事前に宣言することで、この問題を解決します。過去のデータ分析によると、一般的なブロック内のトランザクションの 60 ~ 80% は、完全に分離されたストレージスロットにアクセスしています。これらのトランザクションは、即座に並列実行が可能です。残りの 20 ~ 40% の依存関係がある可能性のあるものは、中間的な変更を追跡するトランザクション後のステート差分(state diffs)を使用して並列化できます。
Consensys のシニアブロックチェーンエンジニアである Gabriel Trintinalia 氏は、この改善を端的に説明しています。このシステムは、「ディスクから逐次読み取るのではなく、必要なデータをあらかじめメモリにロードしておくこと」で、イーサリアム最大のボトルネックを解消します。各トランザクションが何を必要としているかを発見するのを待つ代わりに、バリデータはブロックのアクセスリストを見た瞬間に、必要なすべてのステートデータを準備できます。
実用的な結果として、Glamsterdam はブロックあたりのガスリミットを 6,000 万から 2 億へと引き上げる(233% の増加)ことを目標としており、並列処理と組み合わせることでスループットを 10,000 TPS 以上に押し上げることができます。ユーザーにとっては、これは手数料の低下と確認の高速化を意味します。開発者にとっては、ネットワーク容量の制約を心配することなくアプリケーションを構築できることを意味します。
Enshrined Proposer-Builder Separation: プロト コルレベルの MEV 管理
Glamsterdam の 2 番目の主要コンポーネントは EIP-7732 で、これにより Proposer-Builder Separation(プロポーザー・ビルダー分離)がイーサリアムのコンセンサスルールに直接組み込まれます。これがなぜ重要かを理解するには、現在のブロックがどのように構築されているかを知る必要があります。
現在、バリデータは自分でブロックを構築するか、Flashbots が開発したオフチェーンシステムである MEV-Boost を介して、専門の「ビルダー」にこの作業を委託するかのどちらかを選択できます。ビルダーは、トランザクションの順序付け、サンドイッチ攻撃、裁定取引などから得られる利益である最大抽出可能価値(MEV)を抽出するために競い合い、ブロックへの包含権と引き換えに、その価値の一部をバリデータと共有します。
問題は、このシステムが「リレー」と呼ばれる信頼できる仲介者に依存しており、中央集権化のリスクを生み出し、イーサリアムのプロトコルルールの完全に外部で運用されていることです。少数の洗練されたビルダーが市場を支配しており、本来であればバリデータセット全体に流れるはずの価値を独占しています。
Enshrined PBS(ePBS)は、このプロセス全体をオンチェーンに移行し、信頼できるリレーをプロトコルによって強制されるコミットメントに置き換えます。ePBS の下では、ビルダーは 封印された入札とブロックヘッダーのコミットメントをネットワークに直接提出します。バリデータ(専用の MEV インフラを持たない家庭用ハードウェアで稼働している場合もあります)は、単に最も高い入札額を選択するだけです。落札したビルダーは、その後、指定された時間枠内にブロックの全内容を開示しなければならず、これは新しい Payload Timeliness Committee(ペイロード・タイムリネス委員会)によって検証されます。
このアーキテクチャにはいくつかの利点があります。ソロステーカーは、複雑なビルダーソフトウェアを実行することなく MEV 報酬を得ることができます。プロトコル自体がビルダーのコミットメントを強制するため、信頼の必要性が減少します。また、標準化されたルールにより、単一の主体がブロック生成を独占することがより困難になります。
しかし、課題も残っています。学術研究によると、ビルダーは通常時で約 0.82% のブロック、ボラティリティが高い時期には最大 6% のブロックで、戦略的にブロックの開示を遅らせる可能性があると推定されています。これは「フリー・オプション問題」と呼ばれます。開示期間中に市場状況が大きく変化した場合、ビルダーはブロックを差し控えることで利益を得る可能性があります。現在の ePBS 仕様は、これらのエッジケースに完全には対応していませんが、開発者は設計の改良を続けています。