メインコンテンツまでスキップ

Glamsterdam の遅延：ePBS の遅れにより、イーサリアムの MEV 改革がエンジニアリングの現実に直面

· 約 17 分
Dora Noda
Dora Noda
Software Engineer

イーサリアムの 2026 年から 2027 年にかけての加速されたフォーク・ケイデンスにおいて、初めてロードマップに停滞の兆しが現れた。2026 年 4 月中旬、コア開発者たちは、クライアントチームが数週間前から囁いていたことを公式に認めた。Glamsterdam（グラムステルダム）ハードフォークにおいて最も野心的な要素である「Enshrined Proposer-Builder Separation（ePBS）」は「予想以上に困難」であり、当初予定していた 5 月から 6 月のメインネット稼働はほぼ間違いなく達成不可能である。この遅延により、Glamsterdam は 2026 年第 3 四半期または第 4 四半期へとずれ込み、すでに予定されている Hegota フォークとの間隔が狭まる。そして、イーサリアムが解決済みと考えていた問いが再び浮上することになった。それは、「5 つのクライアントを持つベースレイヤーは、ポスト Pectra の L2 経済が求めるスピードで依然としてアップグレード可能なのか？」という問いである。

この答えの影響は、イーサリアム自身のエコシステムをはるかに超える。ePBS がデブネットに留まる期間が 1 週間延びるごとに、現在の Flashbots リレーの寡占状態が年間数百億ドルの MEV フローを仲介し続け、L2 はフォークによって緩和されるはずだった供給曲線に対して Blob の価格設定を続け、そして 2025 年 9 月に Alpenglow コンセンサス刷新で 98.27% のバリデーター承認を得た Solana が、明らかに速いモノリシックなアップグレードのペースでリードを広げることになる。Glamsterdam は単なる一つのハードフォークではなかった。それは「高速 L1」という命題に対するイーサリアムの回答だった。その回答は今、遅れている。

Glamsterdam を定義する 2 つの EIP​

Glamsterdam（Gloas：コンセンサスレイヤーのコードネームと、Devcon 開催都市の伝統に従った Amsterdam：実行レイヤーのコードネームを組み合わせた造語）は、イーサリアムのブロック生成プロセスを刷新する 2 つの主要な EIP を軸としている。

EIP-7732 (ePBS) は、プロトコルレベルでコンセンサスブロックを実行ブロックから分離する。現在、MEV-Boost を実行しているバリデーターは、中央集権的なリレーを介して、プロトコル外のビルダー市場にブロック構築を委託している。Flashbots 自身が 2024 年 12 月にすべてのビルダーとオーダーフローを BuilderNet に移行したことは、リレー・アーキテクチャが集中リスクを生み出していることを認めた形となった。ePBS はこの分離をプロトコルに組み込む。プロポーザーとビルダーは、リレーを介さずに直接やり取りする第一級のプロトコル参加者となる。

EIP-7928 (ブロックレベル・アクセスリスト) は、ブロックが接触するアカウントやストレージスロットといった読み取り / 書き込みのフットプリントを事前に宣言するようにする。これにより、クライアントは実行と検証を並列化でき、ブロックが伝播に要する時間を短縮できる。ePBS と組み合わせることで、実効ブロックレイテンシを約 50% 削減することを目指している。

理論上、これらは互いに補完し合う。しかし実装においては、Pectra ですでに導入された EIP-7251（MaxEB バリデーター統合）を含む、ポスト Pectra スタックのあらゆる要素と、当初の仕様では完全に予見されていなかった形で干渉し合っている。

実際に何が遅延したのか​

2026 年 4 月 16 日の全コア開発者コンセンサス会議（ACDC #177）で、エンジニアリングの現実が浮き彫りになった。今月まで、テストは 2 つの別々のネットワークに分かれていた。プロポーザーとビルダーの分離のための epbs-devnet と、アクセスリストのための bals-devnet である。これらを統合し、Glamsterdam のすべてのコンポーネントが共存する初の環境である「汎用デブネット」は、Lighthouse と他のいくつかのコンセンサスクライアントが 4 月の相互運用性（interop）期間中に安定したビルドを作成した後に、ようやくゴーサインが出た。

「ePBS Devnet Zero はパフォーマンスよりも相互運用性が重要である」と、あるクライアントエンジニアは会議のサマリーで指摘した。これは、「5 つのコンセンサスクライアントと 5 つの実行クライアントがそれぞれ独自に仕様を解釈した場合に何が壊れるかを、まだ探っている段階である」ということを意味する。初期の稼働ではほとんどが空のブロックであり、これは構造的な欠陥ではないものの、ハッピーパス（正常系）がようやく整いつつある段階であり、アドバーサリアル（敵対的）なシナリオの検証はまだ先であることを示唆している。

タイムラインへの影響は連鎖する：

  • Devnet Zero は、コンセンサス側の Lighthouse, Prysm, Teku, Nimbus, Lodestar、および実行側の Geth, Nethermind, Besu, Erigon, Reth のすべてで安定させる必要がある。
  • Devnet One および Two では、ePBS、BAL、ガス価格の再設定、および検討中の 25 以上の主要ではない EIP 間の干渉バグを洗い出す必要がある。
  • パブリックテストネット（Holesky の後継、Sepolia）では、メインネットの目標日を確実にする前に、少なくとも 6 〜 8 週間のシャドーフォーク活動が必要である。
  • クライアントリリースは、メインネットでのフォーク選択の問題がライブネス（活性）のインシデントにならないよう、十分なリードタイムを持って監査され、ステーカーに配布されなければならない。

各ステップは日単位ではなく週単位で測定される。5 月から 6 月のローンチには、2 月に Devnet Zero が安定している必要があったが、そうではなかった。6 月から 7 月のローンチには 3 月の安定が必要だったが、それも叶わなかった。4 月の時点で、もはや計算が合わない。そのため、主要なフォークが 2026 年後半にずれ込むことが静かに認められたのである。

クライアント多様性のパラドックス​

イーサリアムの 5 つの実行クライアントによる多様性は、間違いなくその最も価値のある信頼できる中立的（credibly-neutral）な特性である。単一クライアントのバグでネットワークがダウンすることはないからだ。しかし、その多様性こそが Glamsterdam を困難にしている理由でもある。

すべての実装チームは、ePBS を個別に構築、テスト、安定化させなければならない。それぞれが異なるエッジケースを表面化させる。4 月の ACDC の議事録では、複数のクライアントにわたる「保留中のプルリクエスト」について説明されており、コンセンサス仕様の変更が解決されるまで、ePBS Devnet Two が完全にブロックされる可能性があると記されている。これはまさに、単一の実装を持つチェーンが支払う必要のない調整コストである。

Solana のペースと比較してみよう。100 〜 150ms の確定的ファイナリティを目指す Solana のコンセンサス置換である Alpenglow は、2025 年 9 月に 98.27% の支持（ネットワーク史上最も強力な信任の一つ）を得てバリデーターの投票を通過した。展開計画はシンプルだ。Anza の Agave クライアントが 2026 年第 3 四半期にアップグレードをリリースし、Jump Crypto による 2 つ目の実装である Firedancer がそれに続く。Solana は今年初めに Firedancer がメインネットのステークの 20% を超えるまで、実質的に 1 つのプロダクションクライアントしか持っていなかったため、その調整範囲はイーサリアムのわずか数分の一である。

これは中立的な観察ではない。モノリシックなチェーンはより速く出荷し、マルチクライアントのチェーンはより安全に出荷する。Glamsterdam の遅延は、イーサリアムのアーキテクチャ上の選択による代償である。そしてマージ以来初めて、市場はその代償が依然として支払う価値があるものかどうかを測り始めている。

L2 と MEV にとっての遅延の意味​

Pectra フォークは 2025 年に予定通りリリースされました。その後すぐに Fusaka が PeerDAS を追加し、ブロブ容量を拡張しました。L2 チームは、第 2 四半期に Glamsterdam が実施されることを前提に 2026 年の容量計画を立て、急増するロールアップ需要に対応するためのさらなるブロブ拡張と MEV 再分配を見込んでいました。

それらの計画は現在、描き直す必要があります。

ブロブの価格設定。Glamsterdam はブロックあたりのブロブ数をさらに増やし（潜在的には 72 以上）、オプティミスティックおよび ZK ロールアップに、より安価なデータ可用性を大幅に提供することが期待されていました。第 3 〜 第 4 四半期への遅延は、ブロブ供給が逼迫する期間がさらに 2 〜 4 ヶ月続くことを意味し、これはすでに手数料レーンが飽和しているロールアップにとって最も重要です。

MEV の再分配。現在の MEV-boost アーキテクチャは、大規模なビルダーに対して不釣り合いな報酬を与えています。オーダーフロー集約における超線形的なリターンは、一旦ビルダーがリードを確保すると、経済原理が独占へと向かうことを意味します。ePBS は MEV を排除するものではありませんが、調整のチョークポイントとしてのリレーを取り除きます。これにより、理論的には、現在の抽出分の一部がプロポーザーへ、そして下流のステイカーへと再分配されるはずです。遅延が発生する毎月は、既存の MEV ダイナミクスが持続する月となります。

L2 間の競争。Base はすでに 2 秒のブロック時間を達成しています。Arbitrum と Optimism は、独自の間隔でシーケンサーと DA の改善をリリースしています。L1 のボトルネックが長く続くほど、L2 のロードマップは統一された L1 アップグレードから乖離し、「ロールアップ中心のロードマップ」は、たまたま同じベースレイヤーで決済を行う N 個の個別のロールアップロードマップへと変化していきます。

FOCIL の問題と Hegota の圧迫​

4 月の ACDC における最も重要な決定の一つは、Fork-Choice Inclusion Lists（FOCIL）を Glamsterdam から外し、2026 年後半のコンセンサス層の目玉として正式に選定された Hegota へと移動させたことでした。

FOCIL はイーサリアムの検閲耐性に対する回答です。これは、プロポーザーの委員会が共同でトランザクションの包含を強制できるようにするメカニズムであり、単一のビルダーが（例えば OFAC 制裁対象アドレスなどの）ペイロードを体系的に除外できないようにします。Base エンジニアリングチーム は、FOCIL を ePBS とバンドルすると Glamsterdam が 2026 年を完全に過ぎてしまうと公に警告していました。FOCIL を切り離すことで Glamsterdam のスケジュールは緩和されますが、その代償として、Glamsterdam の最終的なメインネット稼働と Hegota の稼働までの期間が圧縮されることになります。

もし Glamsterdam が 2026 年第 4 四半期にリリースされ、Hegota が第 4 四半期後半を目指すなら、その差はわずか 6 〜 8 週間になる可能性があります。これは、バリデーター、ブロックビルダー、ステーキングプロバイダー、そして L2 チームにとって、一つのプロトコル変更を吸収してから次の変更が到来するまでの非常に短い準備期間です。Hegota のロードマップ には、大幅なステート肥大化への対策も含まれています。初期の議論では Verkle Trees に焦点が当てられており、これはノードのハードウェア要件を削減しますが、それ自体に広範なテストが必要となります。

イーサリアムが現在密かに計画しているシナリオは、Solana が一つの統合されたリリースで提供するようなテストマトリックスを、一つの四半期内に二つの主要なフォークとして着地させることです。

なぜこれがまだ「危機」ではないのか​

Glamsterdam の遅延を存亡の危機と捉えるのは誤りです。イーサリアムのフォークプロセスは、まさに設計通りに機能しています。ePBS が遅れているのは、調整が失敗したからではなく、メインネットに到達する前に仕様の曖昧さや実装のエッジケースという問題を調整プロセスで発見できたからです。代替案として、予定通りにリリースし、4,000 億ドル以上の決済資産が懸かっている中で稼働中のフォーク選択バグに対処することは、計り知れないほど悪い事態です。

より深い問いは、各フォークの複雑さが増す中で、イーサリアムの現在の開発ペースが持続可能かどうかです。Glamsterdam は単なる 2 つの EIP ではありません。2 つの主要機能に加えて 25 以上の小さな変更が含まれており、それぞれが、すでに maxEB 統合、PeerDAS 有効化ブロブ、成熟した L2 エコシステムを備えた Pectra 後のバリデーターセットと相互作用します。新しいフォークごとにテストマトリックスは広がります。

Glamsterdam 自体を分割し、2026 年第 3 四半期に BALs を、2027 年第 1 四半期に ePBS をリリースするという提案も浮上しましたが、これまでのところ否決されています。反論は説得力があります。ePBS なしの BALs は、並列実行の利得が現在のビルダーアーキテクチャによってボトルネックになるため、わずかな価値しか提供しません。これらの機能は真に補完的であり、それらを切り離すことは、アップグレードの一貫性を犠牲にしてスケジュールを確保することになります。

今後 90 日間の注目ポイント​

2026 年後半に向けて L2 ブロック空間の価格設定を行っている開発者、ステイカー、およびすべての人にとって、3 つのシグナルが重要です。

  1. Devnet Zero の安定性。もし汎用デブネットが 6 月初旬までに重大な障害なく 30 日以上稼働すれば、2026 年第 3 四半期の目標が現実味を帯びてきます。そうでなければ、第 4 四半期が最低ラインとなります。
  2. 公開テストネットの有効化。Holesky の後継と Sepolia は、メインネットの少なくとも 8 週間前にフォークする必要があります。テストネットのフォーク日が決まらなければ、メインネットのフォーク日も決まりません。
  3. Hegota EIP の選定。2026 年 2 月時点での Hegota のコンセンサス層の目玉は FOCIL でしたが、実行層の目玉についてはまだ議論が続いています。何が選ばれるにせよ、2 つのフォークをどれだけ密接にシーケンスできるかがさらに制限されることになります。

イーサリアムの 2026 〜 2027 年のロードマップは常に野心的でした。Glamsterdam の遅延は、野心的であることが予定通りであることを意味しないという最初の具体的な教訓です。困難なことを慎重に行うことで信頼を築いているネットワークにとって、慎重な検討による遅延は失敗ではありません。それは一つの「機能」なのです。

BlockEden.xyz は、Pectra、Fusaka、および Glamsterdam のフォークルールをステージングするすべてのテストネットにわたって、エンタープライズグレードのイーサリアムインフラを運営しています。アップグレード目標が変動する中で開発を行っており、メインネット、テストネット、デブネットを並行して追跡するノードが必要な場合は、当社の イーサリアム API サービス をご覧ください。仕様変更の際に誤った側のフォーク状態に陥ることを許容できないチームのために設計されたインフラです。

情報源​

Share on Twitter