イーサリアムは単発のアップグレードで完成する技術ではありません。Vitalik Buterinが示すロードマップには「Merge」「Surge」「Scourge」「Verge」「Purge」「Splurge」という6つのフェーズが描かれており、各アップグレードはこのビジョンに沿った段階的な実装として位置付けられています。
2025年のPectraはこのロードマップのうち主に「Surge（スケーリング）」と「Splurge（細かな改善の集積）」に対応するアップグレードでした。Pectraの次にはFusakaとOsakaが控えており、それぞれPeerDAS・EOFコード改革・Verkleツリーの導入という重要な技術変更が予定されています。
本記事では、Pectra以降のイーサリアム開発ロードマップを整理するとともに、EIPの採択を支えるガバナンス構造（All Core Devs）についても詳しく解説します。
1. Pectraのロードマップ上の位置付け
1-1. Vitalikのロードマップとの対応
Vitalik Buterinが定期的に更新するイーサリアムロードマップは6つのフェーズで構成されています。
- The Merge：PoS移行（2022年完了）
- The Surge：スケーリング（ブロブ・L2・シャーディング）
- The Scourge：MEV・分散化問題への対処
- The Verge：Verkleツリーによるステートレスクライアント実現
- The Purge：ヒストリカルデータの削減・プロトコルシンプル化
- The Splurge：その他の細かな改善の集積
PectraはSurgeの一部（EIP-7691によるブロブ増量）、Splurgeの一部（EIP-7702・EIP-7251など）に対応しています。完全なSurge（Danksharding）の実現はPeerDASを経てさらに先のステップとなります。
1-2. Pectraが残した課題
Pectraで候補に挙がりながらも見送られた提案の中には、EOF（EVM Object Format：EVMコードの構造改善）がありました。EOFはEVMのバイトコード形式を刷新する大規模変更で、技術的な準備に時間が必要と判断され次のFusakaまたはOsakaに繰り越しとなっています。
2. 次のアップグレード「Fusaka」
2-1. PeerDASの本格導入
Fusakaで最も注目される変更はEIP-7594（PeerDAS）の本格導入です。PeerDAS（Peer Data Availability Sampling）はブロブデータをネットワーク全体でサンプリング方式で保持することで、各ノードの負担を増やさずにブロブ容量を大幅拡大できる技術です。
Fusakaでは1ブロックあたりのブロブ数をPectraの最大9から数十単位へと増やすことが視野に入っています。これはL2のデータコストをさらに引き下げ、より多くのユーザーとアプリケーションがイーサリアムエコシステムに参加できる環境を整えます。
2-2. FusakaのEOF採用可否
EOF（EVM Object Format）はEVMバイトコードの形式を刷新し、コードの検証・分析・最適化を容易にする提案です。具体的にはEIP-7692（EVM Object Formatメタパッケージ）として複数のサブEIPをまとめて提案されています。
EOFの採用はEVMの根本的な変更を伴うため、クライアントチームの工数が大きく、テスト・仕様策定のコストも高いとされています。FusakaへのEOF採用についてはAll Core Devsで継続的に議論が行われており、採用・見送りの判断は2025年中のACDミーティングで決定される見込みです。
3. さらに先の「Osaka」とVerkleツリー
3-1. Verkleツリーとは何か
Verkleツリー（EIP-6800等）はイーサリアムのステートデータ構造を現在のMerkleパトリシアツリーから置き換える技術です。Verkleツリーの特長は「ベクトルコミットメント」を使うことで、ステートの一部を証明するためのサイズが非常に小さなウィットネス（witness）で済む点です。
これによりフルノードと同等の検証能力を持ちながら全ステートを保存しない「ステートレスクライアント」の実現が近づきます。ステートレスクライアントが普及すると、イーサリアムのフルノードを動かすための必要ストレージが劇的に削減されます。
3-2. ステートレスクライアントの意義
現在のイーサリアムフルノードを運用するには数百GBから数TBのSSDストレージが必要です。Verkleツリーベースのステートレスクライアントでは、ブロックを検証するために必要なウィットネスをブロックとともに受信するだけで済み、全ステートの保存が不要になります。これはノード参加の敷居を下げ、ネットワークの分散化に貢献します。
3-3. Merkle→Verkle移行の技術的難易度
Verkleツリーへの移行は既存ステート（数億件以上）を変換する大規模なプロセスを伴います。この変換を安全に・ダウンタイムなしに実施するための仕組みの設計が鍵であり、Osaka以降のアップグレードに組み込む際の最大の技術課題とされています。
4. The PurgeとPurgeに含まれる提案
4-1. ヒストリー期限切れ（EIP-4444）
The Purgeの中心にあるのがEIP-4444（ヒストリー期限切れ）です。イーサリアムノードが保持するブロックヒストリーに期限を設け、古いデータをP2Pネットワーク上から削除することでノードの容量要件を削減する提案です。
EIP-4444の実現にはPortal Networkなどの分散型ヒストリーアーカイブが前提として必要であり、段階的な移行が計画されています。Pectraに含まれるEIP-2935（過去ブロックハッシュのステート保存）もこのPurgeへの準備の一つです。
4-2. プロトコルのシンプル化
The Purgeではヒストリーデータの削減だけでなく、使われなくなったオペコードの廃止・レガシー機能のクリーンアップなども含まれます。プロトコルをシンプルに保つことで、新しいクライアントの実装コストを下げ・バグリスクを低減し・オーディットを容易にする効果があります。
5. All Core Devsによるガバナンス
5-1. ACDミーティングの仕組み
イーサリアムのプロトコルアップグレードはAll Core Devs（ACD）と呼ばれる非公式な会議体が主要な意思決定の場となっています。ACDは隔週でビデオ会議を開催し、クライアントチームの代表者・EIP提案者・研究者が参加します。会議はYouTubeでライブ配信され、議事録はGitHubに公開されます。
EIPが採用されるまでには「提案→議論→ラフコンセンサス→クライアント実装→テストネット検証→メインネット採択」という流れを経ます。明示的な投票はなく「ラフコンセンサス（大まかな合意）」を基に判断が進みます。
5-2. ガバナンスの課題と批判
ACDによるガバナンスは柔軟で迅速な意思決定を可能にする一方、参加者が限られることへの批判もあります。「一部のクライアントチームや研究者に権力が集中している」という指摘は古くからあり、コミュニティからの透明性向上要求に応えるための取り組みも続けられています。EIPプロセスはオープンソースであり、誰でも提案・コメントが可能ですが、実質的な影響力を持つには技術的な知見と継続的な関与が必要です。
6. EIP提案者とコミュニティの役割
6-1. EIPを提案できるのは誰か
EIPはGitHubリポジトリ（ethereum/EIPs）にプルリクエストを送ることで誰でも提案できます。ただし採用されるためには、技術仕様の詳細さ・実装の実現可能性・既存プロトコルへの影響分析が求められます。Vitalik Buterinをはじめとするコアコントリビューターが提案することが多いですが、コミュニティメンバー発のEIPが採用された事例も多数あります。
6-2. エコシステム参加者の声の反映
L2プロトコル・ウォレットプロバイダー・ステーキングサービスなどのエコシステム参加者もACDや専門の作業グループ（Execution Layer Specs・Beacon Chain APIなど）を通じてフィードバックを送ることができます。また「Ethereum Magicians」フォーラムはEIPに関する非公式議論の場として機能しており、ここでの議論がACDの方向性に影響することもあります。
7. ETH保有者・投資家視点でのロードマップ評価
7-1. 長期的なETH価値との関係
イーサリアムのロードマップが着実に進展することは、ネットワークの利用価値向上・開発者コミュニティの信頼維持・機関投資家からの評価に影響します。スケーリング改善はL2の利用増加を促し、ガス需要を通じたETHのバーンとユーティリティに貢献します。一方で競合するブロックチェーンの動向・規制環境・マクロ経済なども価格に大きく影響するため、ロードマップ単独で価格を評価することは適切ではありません。
7-2. 開発の遅延リスク
大型アップグレードは想定外のバグや仕様変更により遅延することがあります。実際にPectra自体もHoodiテストネット段階で問題が発見され、スケジュールが調整されました。FusakaやOsakaについても同様の遅延リスクは常に存在します。ロードマップはあくまで開発の方向性を示すものであり、確定したスケジュールではないという点は理解しておく必要があります。
まとめ
Pectra以降のイーサリアムロードマップはFusaka（PeerDAS）→Osaka（Verkleツリー）→さらなるPurge/Splurgeへと続きます。各アップグレードはVitalikのロードマップの「Surge・Verge・Purge」に沿った段階的な実装であり、スケーラビリティ・分散化・プロトコルシンプル化という三つの目標を追求しています。
イーサリアムの技術進化はACDという合意形成の場を通じて着実に進んでいます。今後の動向を追う際はACDミーティングのアジェンダやEIPリポジトリの更新を定期的に確認することをお勧めします。
よくある質問
Q. Fusakaはいつメインネットでアクティベートされますか？
A. 2025年時点では具体的な日程は未定です。テストネットでの検証を経てACDでの合意が形成された後に決定されます。
Q. Verkleツリーへの移行はイーサリアムの利用者に影響しますか？
A. 一般ユーザーへの直接的な影響はほぼありません。主にノード運営者・クライアント開発者・コントラクト開発者に関係する変更です。
Q. ACDの会議内容を確認するにはどうすればよいですか？
A. YouTubeの「Ethereum Foundation」チャンネルでライブ・アーカイブが公開されています。またGitHubの「ethereum/pm」リポジトリに議事録が掲載されています。
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
