イーサリアムの2026年ロードマップは、2つの軸を中心に展開します。1つはブロブを通じたロールアップのデータ容量拡大、もう1つはガス制限の変更によるベースレイヤーの実行処理能力向上です。
ガス制限の変更は、バリデータがブロックの再実行からZK実行証明の検証へ移行することに依存しています。
最初の軸は既に2025年12月3日に実装されたFusakaによって基礎が固められています。
Fusaka
ethereum.orgによると、FusakaはPeerDASとブロブパラメータのみの変更（BPO）を導入し、計画的にブロブのスループットを段階的に引き上げることが可能です。
2つ目の軸は、草案段階のEIP、クライアント実装、および分散性の制約（帯域幅、ブロック伝播、証明市場の構造など）を守らなければならないバリデータの運用に依存するため、より機械化が進んでいません。
PeerDASは、最も明確な「容量拡張」の手段と位置付けられています。これは、すべてのノードがすべてのブロブをダウンロードすることを強制せずに、ロールアップのデータ可用性を拡張するように設計されているためです。
ethereum.orgによると、ブロブの目標値は有効化直後に急増するわけではなく、開発者がネットワークの健全性を監視しながら数週間ごとに倍増させ、最大で48という目標値に達することが可能です。
optimism.ioによると、Optimismチームは上限ケースを「1ブロックあたり少なくとも48のブロブ目標値」と位置付け、それに伴いロールアップ側のスループットが約220 UOPSから約3,500 UOPSへ移行すると見込んでいます。
この見通しにおいても、2026年の実務的な課題は、需要がL1実行の入札価格を押し上げるのではなく、ブロブの使用として現れるかどうかです。
もう一つの未解決の課題は、BPOの導入が進むにつれて、P2Pの安定性とノードの帯域幅が運用者の許容範囲内に収まるかどうかです。
実行処理の面では、イーサリアムは既にハードフォークではなく、調整を通じてより高いスループットをテストしています。
GasLimit.picsは、最新のガス制限を60,000,000と報告し、表示時点での24時間平均は約59,990,755でした。
この水準が重要なのは、バリデータが実際に受け入れた内容の基準点を提供するためです。
また、レイテンシ、検証負荷、メンプールおよびMEVパイプラインの負荷が制約となる前に、「社会的スケーリング」の上限を明らかにします。
ガス制限の議論をスループットの範囲に変換する簡単な方法は、イーサリアムの12秒のスロット時間を用いた「1秒あたりのガス量」（1秒あたりガス量 = ガス制限 ÷ 12）です。
以下の数値は計算を明示し、ベースレイヤーのEVMトランザクションとロールアップのスループット主張を分けて示しています。
| シナリオ | ガス制限 | 1秒あたりガス量（≈ ガス制限/12） | 21kガス時の1秒あたりトランザクション数 | 120kガス時の1秒あたりトランザクション数 |
|---|---|---|---|---|
| 現在の調整水準 | 60,000,000 | 5,000,000 | ≈238 | ≈42 |
| ガス制限2倍ケース | 120,000,000 | 10,000,000 | ≈476 | ≈83 |
| 上限ケース（検証方式の変更が必要） | 200,000,000 | 16,666,667 | ≈793 | ≈139 |
Glamsterdam
2026年に計画されているアップグレードのブランド名「Glamsterdam」は、いくつかの実行処理指向のアイデアを包括しています。これは、提案者とビルダーの分離の固定化（ePBS、EIP-7732）、ブロックレベル・アクセスリスト（BALs、EIP-7928）、一般的な再価格設定（EIP-7904）について議論されてきた略称リストです。
EIP-7732、EIP-7928、EIP-7904の各EIPページによると、それぞれ草案段階にあります。
再価格設定は、長年続いてきたガススケジュールの不一致を対象としています。
EIP-7904によると、誤って価格設定された計算処理を修正することで、DoSリスクやガス前提をハードコードした契約の現実を認めつつ、実用的なスループットを向上させられると主張しています。
BALsは並列処理のための基盤技術として位置付けられています。
EIP-7928によると、このEIPは並列ディスク読み取り、並列トランザクション検証、並列状態ルート計算、「実行不要の状態更新」を引用し、平均約70〜72 KiBの圧縮済みBALサイズをオーバーヘッドと見積もっています。
実際には、これらの利点は、クライアントが実際のボトルネック全体で並行性を採用した場合にのみ実現します。
また、追加のデータと検証ステップが、それ自体が新たなレイテンシ負担にならないかどうかにも依存します。
EIP-7732によると、ePBSは、時間的に実行検証と合意検証を分離することを目指しているため、MEVとスループットの両方の議論の中心に位置しています。
この時間的な余裕は、新しい障害モードが現れる可能性がある場所でもあります。
ePBSの「フリー・オプション問題」に関する学術論文は、arXivによると、8秒のオプションウィンドウ下では平均して約0.82%のブロックでオプション行使が発生し、モデル化された条件下でのボラティリティの高い日には約6%に達すると推定しています。
2026年のイーサリアム
2026年の計画において、この研究は、安定状態の手数料結果だけでなく、ストレス下でのライブネスに注意を向けさせます。
「非常に高い」ガス制限の背景にある、より構造的な賭けは、バリデータによるZK証明の採用です。
イーサリアム財団の「リアルタイム証明」ロードマップは、少数のバリデータが最初にZKクライアントを本番環境で実行する段階的な道筋を説明しています。
その後、ステークの過半数が問題ないと判断した後でのみ、ガス制限を、合理的なハードウェア上での実用的な検証において証明検証が再実行に取って代わる水準まで引き上げることができると、財団の2025年7月10日のblog.ethereum.orgの投稿は述べています。
同じ投稿は、物語ではなく実現可能性に関わる重要な制約を提示しています。blog.ethereum.orgによると、これには128ビットのセキュリティを目標とすること（一時的に100ビットを受け入れる）、300 KiB未満の証明サイズ、信頼されたセットアップを伴う再帰的ラッパーへの依存を避けることが含まれます。
スケーリングの含意は証明市場に関連しています。リアルタイムの証明供給は、現在のリレー型の依存関係をスタックの別の層で再現するような狭い証明者セットに集中することなく、安価で信頼できるものでなければなりません。
Glamsterdamの後、「Hegota」は2026年後半の名前付きスロットとして位置付けられており、その範囲よりもプロセスに関するものです。
イーサリアム財団は、blog.ethereum.orgによると、1月8日から2月4日までの提案期間、続く2月5日から2月26日までの議論と最終化、その後非ヘッドライナー向けの期間を含む主要なタイムラインを公開しました。
HegotáメタEIPは草案（EIP-8081）として存在し、項目を確定ではなく検討中としてリストアップしています。EIP-8081によると、現在検討中のものとしてFOCIL（EIP-7805）が含まれます。
このスケジュールにおける短期的な報告価値は、投資家や開発者がコードネームから勝手にコミットメントを推測することなく、追跡できる日付付きの意思決定ポイントを作り出すことです。
最初のポイントは、Hegotaのヘッドライナー提案が2月4日に締め切られることです。
この投稿 Ethereum’s 2026 roadmap includes this validator risk that’s bigger than you think は最初に CryptoSlate に掲載されました。
