イーサリアムの開発は「The Merge（マージ）」「The Surge（サージ）」「The Scourge（スコージ）」「The Verge（ヴァージ）」「The Purge（パージ）」「The Splurge（スプラージ）」という六段階のフェーズで構成されるロードマップに沿って進められています。Pectraはこのロードマップの中でSurgeとVergeにまたがる重要な変更を含むアップグレードです。本記事では、Pectraがイーサリアムの長期ロードマップにおいてどのような位置を占めるのかを整理し、次のアップグレード「Fusaka」以降で計画されているVerkleTrie、EOF（Ethereum Object Format）、シングルスロットファイナリティ（SSF）などの技術的方向性を詳しく解説します。
イーサリアムロードマップ全体像の再整理
ヴィタリック・ブテリンが描く六段階
イーサリアムの創設者ヴィタリック・ブテリンは、イーサリアムの進化を六つのフェーズとして体系化しています。The Mergeはプルーフ・オブ・ステークへの移行（2022年9月完了）、The SurgeはDankshardingによるスループット拡大（進行中）、The ScourgeはMEV（最大抽出可能価値）問題への対処、The VergeはVerkleTrie導入によるステートレスクライアントの実現、The Purgeは古いデータと複雑性の削減、The SplurgeはEIP-1559以降の細かな改善の積み重ねです。Pectraはこの中でSurge（ブロブ拡張）とVerge（ステート構造の準備）に関連する変更を含んでいます。
Pectraの位置づけ
PectraはDencunの後継アップグレードとして、SurgeとVergeへの移行を加速させる役割を担います。EIP-7691（ブロブ拡張）はSurge、EIP-2935（履歴ブロックハッシュのアクセス効率化）はVergeへの準備、EIP-7702（アカウント抽象化）はSplurgeに対応します。このように、Pectraは複数のロードマップフェーズにまたがる変更をバランスよく束ねたアップグレードとして設計されています。
次のアップグレード「Fusaka」の概要
FusakaはFujiとOsakaの合成名
Pectraの次に来るアップグレードは「Fusaka」と呼ばれています。これは実行レイヤー側の「Fuji（富士）」とコンセンサスレイヤー側の「Osaka（大阪）」を合わせた命名です。Fusakaでは、EOFバイトコード（EIP-7692）やVerkle Trie移行（EIP-6800）、PeerDAS（EIP-7594）の完全実装などが検討されています。ただし、各EIPの実装スケジュールはテストネットでの検証結果によって変動します。
FusakaのスコープとPectraとの違い
PectraがUX改善とバリデータ効率化を中心としたアップグレードであるのに対し、Fusakaはより根本的なEVMの書き換えとステート構造の変更を含む、より大規模な技術的変革を伴うアップグレードになる見込みです。EOFとVerkle Trieはいずれも既存との後方互換性を保ちながら移行を行う必要があるため、実装と検証に長い時間を要します。
Verkle Trie：ステートレスイーサリアムへの道
現行のMerkle Patricia Trieの課題
イーサリアムのステート（全アカウントの残高・コントラクトコード・ストレージ）は現在Merkle Patricia Trie（MPT）というデータ構造で管理されています。MPTは安全で検証可能なデータ構造ですが、ステートが大きくなるにつれてノードが保持するデータ量が増大し、初期同期時間の長期化やディスク使用量の増加というスケーラビリティの課題が生じています。これは新規ノードの参加障壁を高め、イーサリアムの分散化に悪影響を与えます。
Verkle Trieが解決する問題
Verkle Trieは、Merkle Patricia Trieの代替として設計された新しいデータ構造です。Verkle Trieの最大の特長は、ベクトルコミットメント（Vector Commitment）という暗号技術を用いることで、MPTより大幅に小さいサイズのウィットネス（証明データ）を生成できる点です。これにより「ステートレスクライアント」が実現可能になります。ステートレスクライアントはステート全体をローカルに保持せず、各トランザクションの実行に必要なステートのみをウィットネスとして受け取り検証するため、ディスク容量とメモリの要件が大幅に下がります。
MPTからVerkle Trieへの移行プロセス
MPTからVerkle Trieへの移行は、イーサリアムの歴史上最も大規模なステート変換の一つです。現在のイーサリアムメインネットには膨大な量のステートデータが蓄積されており、すべてを一度に変換することは現実的ではありません。開発チームはオーバーレイツリー方式を採用し、新しいステートの書き込みはVerkle Trieで行い、古いMPTのデータは段階的にVerkle Trieに変換していく移行計画を立てています。
EOF：EVMの根本的な改善
現行EVMバイトコードの問題点
イーサリアム仮想マシン（EVM）のバイトコードは歴史的な経緯から様々な非効率性を抱えています。最大の問題の一つは、コントラクトのコードとデータの区別がバイトコードレベルでは明確でないことです。これにより、静的解析やフォーマル検証が難しく、セキュリティツールの開発コストが高くなっています。また、従来のJUMP命令は動的ジャンプを許容するため、コントラクトの実行フロー解析が困難です。
EOF（Ethereum Object Format）の設計
EOFは、EVMバイトコードに明確な構造（ヘッダー、コードセクション、データセクション）を導入することで、上記の問題を解決する提案です。EOFバイトコードでは、コードとデータが明確に分離され、動的ジャンプが廃止されてJUMPFとCALLFという新しい関数呼び出し命令が導入されます。これにより、コントラクトのデプロイ時に静的解析が可能になり、実行時のガス消費の予測可能性が向上します。また、将来的なEVMの拡張（新しいオペコードの追加など）がより安全かつ段階的に行えるようになります。
シングルスロットファイナリティ（SSF）への道
現行のファイナリティメカニズムの限界
現在のイーサリアムでは、Casper FFG（Friendly Finality Gadget）によってブロックのファイナリティが決定されますが、完全にファイナルになるまでに通常2〜3エポック（約12〜19分）かかります。この長いファイナリティ時間は、ユーザーが支払いを確認する際の待機時間やブリッジプロトコルが確認を行うまでの遅延に直結しています。
SSFが実現する世界
シングルスロットファイナリティ（SSF）は、ブロックが提案されてから1スロット（12秒）以内にファイナリティが達成される仕組みです。これはユーザーの待機時間を劇的に短縮し、ブリッジやクロスチェーン通信の効率を飛躍的に向上させます。ただしSSFの実装にはすべてのバリデータが各スロットで署名を行う必要があり、現行のバリデータ数（90万超）ではネットワーク帯域幅が限界に達します。EIP-7251によるバリデータ統合はSSF実現のための前提条件の一つであり、Pectraはここでも長期ロードマップへの布石を打っています。
MEV問題とePBS：The Scourgeの進展
MEVがイーサリアムにもたらす問題
MEV（最大抽出可能価値）はブロックビルダーやバリデータがトランザクションの順序を操作することで得られる利益です。フロントランニングやサンドウィッチ攻撃などのMEV戦略はユーザーに不利益をもたらし、また大規模なMEV抽出業者へのインセンティブ集中はネットワークの中央集権化リスクを高めます。
ePBS（Enshrined Proposer Builder Separation）の概要
ePBSは、ブロック提案者（バリデータ）とブロック構築者（ビルダー）の分離をプロトコルレベルで組み込む提案です。現在はMev-Boostという外部のミドルウェアでProposer-Builder Separationが実現されていますが、これはプロトコル外の仕組みであるため信頼の前提が必要です。ePBSが実装されるとこの分離がプロトコルレベルで保証され、MEVに関連するリスクとセキュリティ前提が大幅に改善されます。PectraにはePBSは含まれていませんが、The Scourgeフェーズの研究・議論は継続されています。
EIP-2935：履歴ブロックハッシュへのアクセス改善
現行の256ブロック制限
現在のEVMでは、BLOCKHASH命令で参照できるブロックハッシュは直近256ブロックに限定されています。この制限はVerkle Trie移行後のステートレスクライアントでブロックハッシュを効率的に提供する際の障壁となります。EIP-2935はシステムコントラクトを通じて過去8,192ブロック（約27時間分）のブロックハッシュをスマートコントラクトからアクセス可能にすることで、この制限を緩和します。
ステートレスクライアントとの関係
EIP-2935はステートレスクライアントがブロックハッシュを検証するための仕組みを提供します。Verkle Trieのウィットネスにブロックハッシュ履歴のコミットメントが含まれるようになると、ステートレスクライアントは過去のブロックハッシュを外部に依存せずに検証できるようになります。この変更はVerge（Verkle Trie移行）の準備として機能します。
まとめ：Pectraからその先へ
Pectraはイーサリアムのロードマップにおける重要な通過点です。EIP-7702によるUX改善、EIP-7251によるバリデータ効率化、EIP-7691によるブロブ拡張、そしてEIP-2935によるVerge準備と、多岐にわたる改善が一度に実施されます。この先にはFusakaでのEOFとVerkle Trie移行、そして長期的にはSSFとePBSというさらに大きな変革が控えています。イーサリアムがスケーラブルで安全かつ分散化されたプラットフォームへと進化し続ける道のりは長いですが、Pectraはその確実な一歩となるでしょう。
よくある質問
Q1. Verkle Trieへの移行はいつ完了しますか？
Verkle Trieへの移行はFusakaアップグレードでの開始が検討されていますが、完全な移行にはさらに複数のアップグレードサイクルを経る見込みです。テストネットでの検証と開発者コミュニティの合意形成を経て、正式なスケジュールが確定します。
Q2. EOFはSolidityやVyperで書かれたコントラクトに影響しますか？
EOFはオプトイン方式での導入が検討されており、既存の非EOFバイトコードは引き続き実行できます。SolidityやVyperなどのコンパイラがEOFバイトコードを出力するようになれば、新しくデプロイされるコントラクトの効率が向上します。既存のデプロイ済みコントラクトへの影響は最小限に抑えられる設計です。
Q3. ステートレスクライアントが普及するとETHの価格に影響しますか？
ステートレスクライアントはノード運用コストを下げ、イーサリアムの分散化を促進します。これはネットワークのセキュリティと検閲耐性の向上につながりますが、ETH価格への直接的な影響は市場参加者の評価に委ねられます。技術的改善が長期的なネットワーク価値に貢献するという考え方はあるものの、価格予測を行うことは適切ではありません。
免責事項
※本記事は情報提供を目的としており、投資を推奨するものではありません。暗号資産への投資は元本割れのリスクがあります。投資判断はご自身の責任で行ってください。
