導入
ブロックチェーンの歴史がビットコインの拡大の歴史であるならば、イーサリアムの周期的なアップグレードは拡大の方向性を示す中核的な指標です。
1～2年ごとに行われるイーサリアムのメジャーハードフォークアップグレードは、それ自体から徐々に各イーサリアムシリーズのL2に広がり、その後複数のL1の開発に拡大します。各ハードフォークに含まれるEipは、イーサリアムコアコミュニティの本質を表し、利益とコストのバランスの結果です。
それでは、Shisijun がPrague-Electra のアップグレードの 11 の Eipを技術的な観点から説明します。それらは何であり、何に使用されるのでしょうか。そして、なぜそれが彼なのでしょうか。
背景
アップグレードの現在の正確な時間は、Sepolia テスト ネットワークでは 3.5、Ethereum メイン ネットワークでは 4.8 にリリースされる予定です。イーサリアム公式コードベースが4日前（2025.2.26）にリリースしたバージョンの最初の文章は、「ああ、またホットフィックスがリリースされた！」です。はい、問題があります。現在Holeskyテストネットワークで有効化されているバージョンコードにより、テストネットワークでフォークが発生しました（大規模なダウンタイムと理解できます）。フォークされたコードのバグに注意する必要はありませんが、今回はコンテンツの複雑さがわかります。そして、私の個人的な観点から言えば、このアップグレードは、イーサリアムにおけるPowとPosの統合以降、最も影響力のあるアップグレードでもあります。チェーン上の動作モードを完全に変更し、まったく新しい体験をもたらすでしょう。 eips の完全なリストは次のとおりです。
[出典: https://ethroadmap.com/#pectra スティッキー]
提案の導入は若干変更されましたが、 Okx、Metamask、WalletConnect、Biconomy、BaseWallet、Uniswap、Rhinestone、ZeroDev、TrustWallet、Safeなどのウォレットチームの注目を集めています。基本的に、すべてはメインネットワークが切り替わった瞬間に適応できるようにするために行われます。ユーザーとして、ウォレットの助けを借りてそれを体験することもできます。
しかし、本当の核心的な疑問は、開発者の技術的な実装に加えて、このアップグレードは本当に Ethereum のエコロジカル構造を活用できるのか、ということです。
この変更は十分に深いものなのでしょうか、それとも L2 時代の Ethereum Foundation による単なる定期的なパッチなのでしょうか?
パノラマスキャン
全体のリズムを感じるために表を使ってみましょう。
明らかに、3 つの主要な特徴が見られます。
イーサリアムの開発が深海ゾーンに入ったため、基本的に、含まれる可能性のある新しい提案提案者はすべてイーサリアム財団自体の出身者でした。その中で、ヴィタリックは重要な変更を最初に提案した人物でした。他の役割の創造性が公式のアップグレードに取り入れられることはほとんど不可能です。これは、イーサリアムがますます「独自の道を歩み」、次第に中央集権的な意思決定システムになりつつあることの証拠でもあるかもしれません。
イーサリアムの市場ペースは加速している。昨年11月、今回のアップグレードは8項目で基本的な合意が成立し、現在、実際の実装には11項目が含まれている（追加はvitalikが推進するL2レベルの最適化3つ）。これまでのメジャーバージョンは基本的に1つのコアからいくつかの最適化を行うだけだったが、現在ではほぼ複数の関係者が同時に実施しており、長年合意形成が難しかったAA（ハードフォークバージョン）も含まれるようになった。このことから、現在複数のチェーンが爆発的に増加している中で、EVM システムは、急成長を遂げている SVM システム (Solana など)、Move システム (Aptos など)、さらには BTC システム (さまざまな BTC L2) と対峙する過激な状態にあることがわかります。
Ethereum は環境上の利点を活用し、ユーザー エクスペリエンスを最適化する傾向が強まっています。ユーザー エクスペリエンスの最適化は行うべきことだとお考えでしょうか?いいえ、実際のところ、Ethereum のメジャー バージョンのマージの多くは、一般的なユーザー エクスペリエンスとはまったく関係がありません。ブロック サイズが最後に調整されたのは 2018 年でした (容量の拡張によりユーザー コストが削減され、価格変動の低減はユーザー エクスペリエンスの最適化と見なされます)。前回は、blobの導入により、L2のユーザー料金コストが大幅に削減されました。そして今回は、3つの時点から、ユーザーコストの最適化に重点が置かれていることがわかります。
しかし、問題は、イーサリアムは本当に「ユーザーエクスペリエンスを最優先」しているのかということです。それとも、ユーザーエクスペリエンスを最適化するために強制されているだけでしょうか?詳細を一つずつ議論し、彼が何を変更したかを理解しましょう。
エクスペリエンスの最適化
まず、最も重要な変更は7702で、チェーン層のアップデートからアカウント抽象化メカニズムが導入されます。この点については、以前に体系的な記事の解釈がありましたので、今回は繰り返しません。 「4337から7702まで：イーサリアムアカウント抽象化トラックの過去と未来の詳細な解釈」
解釈
客観的に言えば、7702 は複数のチェーン上の不可能な暗黙のルールを破り、ほとんどの Dapps のアプリケーション ロジックも破ります。
ユーザーにとっては、依然として EOA アドレスであり、CA ロジックは必要なときにのみ駆動され使用されるため、保持コストは低くなります。
操作を実行する前にオンチェーン CA ID を変換する必要がないため、ユーザーは登録する必要がありません。
ユーザーは EOA を使用することで、承認された控除と実行された控除を 1 つにまとめるなど、複数のトランザクションを並行して簡単に実行できるため、ユーザーのトランザクション コストが削減されます。
Dapp、特に取引所など、オンチェーンの企業レベルの管理が必要なプロジェクトにとって、これは破壊的な最適化です。元のエコシステムでバッチ収集が実現されると、基本的な交換コストが一瞬で半分以上削減され、最終的にユーザーに利益をもたらすことができます。
したがって、大きく変化したにもかかわらず、コストの次元はすべての Dapps による研究と適応に値します。なぜなら、今回は、ユーザーは間違いなく EIP 7702 の側に立つからです。
しかし、ここには隠れたリスクがあります。アカウントの抽象化によってインタラクションのコストは削減されますが、ユーザー権限管理の複雑さも増します。
ウォレットメーカーが適切に適応できない場合、予期せぬセキュリティ上の脆弱性につながる可能性があります。以前は、調査中に失われるのはせいぜい 1 つのチェーン資産だけでしたが、現在ではチェーン全体が失われる可能性があり、予定された時間に爆発することさえあります。
どうやら、これはフィッシングハッカーが好むアップグレードであり、ユーザーはオンチェーン取引についてより注意する必要があります。
アプリケーション側の最適化
EIP-2537 (BLS 12-381 曲線演算のプリコンパイル)
効果
BLS 12-381 楕円曲線のプリコンパイルを導入しました。これにより、BLS 署名検証などの複雑な暗号化操作が最適化され、より高いセキュリティ (120 ビット以上のセキュリティ) と計算効率 (ガス最適化) が実現します。
実際の機能としては、BLS署名検証、公開鍵集約、マルチ署名検証などが追加されました。
さまざまな BLS 操作に対して特定のプリコンパイル済みアドレスが指定されており、BLS 12-381 に関連する複雑な数学的操作を実行するための追加コードを展開することなく、これらのプリコンパイル済みアドレスを呼び出すことで契約を直接実行できます。
解釈
マルチ署名スマートコントラクトウォレットを低コストで使用できるため、一般ユーザーにとってますます便利になっています。署名検証計算の複雑さとガスコストを大幅に削減できるほか、ゼロ知識証明 (zk-SNARK など) や準同型暗号化などの機能をより効率的に実装およびサポートすることもできます。これは、プライバシーと相互運用性（特に ZCash などの他の BLS 対応ブロックチェーンと）の面で役立ちます。
EIP-2935 (状態から履歴ブロックハッシュを提供する)
効果
最後の 8192 個のブロック ハッシュをシステム コントラクトのストレージに保存し、ステートレス クライアントに最新のブロック ハッシュ データを提供します。
この設計により、クライアントはチェーン全体の履歴データ自体を保存しなくても、実行中に履歴ブロックハッシュにアクセスできるようになります。これは、Verkle ツリーなどの将来の最適化ソリューションにとって特に重要です。
これらのハッシュ データはリング バッファーの形式で保存され、ローリング更新をサポートします。つまり、常に最新の 8192 ブロック ハッシュ値を保持します。
Set および Get 操作を提供します。SET はトランザクションの書き込みに使用できるシステム アドレスであり、ユーザーは Get を使用してブロック番号でブロック ハッシュを照会できます。
解釈
クライアントは追加のストレージを必要とせずに簡単なクエリを通じて履歴ブロックハッシュにアクセスできるため、一般ユーザーに直接的な影響はありませんが、一部のストレージフリークライアントの出現を促進し、検証を必要とするオンチェーンサービスアプリケーションにとって最適化の価値を持ちます。
また、ほとんどの L2 はオンチェーン データの一貫性と履歴情報を検証するために過去の期間の L1 ブロック ハッシュにアクセスする必要があるため、Rollup L2 のコストも削減されます。
また、データエラーがオフチェーンで報告されるのを防ぐために、履歴ブロックの検証とデータ追跡を必要とするオラクルなどのオンチェーン検証サービスもあります。
ステーキングシナリオの複数の最適化
イーサリアムのステーキングは大きな話題ではありますが、一般ユーザーへの影響は小さいです（ただし、ステーキングに参加する場合は、ここで経済的なロジックについて深く検討して考える必要があります）。各提案を一文でまとめてから、まとめてコメントします。
EIP-6110 (サプライバリデーターがチェーン上にデポジット)
ステーキング操作はチェーン内プロトコルメカニズムを通じて処理され、コンセンサス層の投票メカニズムが排除され、ステーキングフローのセキュリティと効率が最適化されます。バリデータ誓約操作のリストを実行層ブロックに追加することで、誓約操作の記録と検証が実行層ブロック構造に直接配置されるため、コンセンサス層は誓約データ (eth 1 データ) の投票メカニズムに依存する必要がなくなります。
EIP-7002 (実行レイヤーのトリガー可能な引き出し)
この提案により、Ethereum の実行レイヤーはバリデーターの終了と部分的な引き出しをトリガーするメカニズムを提供できるようになり、「0x 01」引き出しバウチャーを使用するバリデーターは実行レイヤーからステークした ETH を独立して制御できるようになります。
EIP-7251 (MAX_EFFECTIVE_BALANCE を増やす)
最小ステーキング制限は 32 ETH のままですが、単一のバリデーターの有効ステーキング制限を (2048 ETH に) 増加します。
EIP-7549 委員会インデックスを認証外に移動する
検証を簡素化し、効率を向上させるために、コンセンサス レイヤーの「証明」メッセージの委員会インデックス フィールドをメッセージの外側に移動します。その結果、特に ZK 回路で実行する場合、Casper FFG クライアントのパフォーマンスが向上します。
解釈
一度にたくさんのことを見ると混乱するかもしれませんが、実際には、自分自身をコントロールして、核心的なニーズに戻るだけでよいのです。
マクロ的な文脈では、イーサリアムのバリデータークラスターは急速に成長しており、2023年10月時点でバリデーターは830,000を超えています。 MAX_EFFECTIVE_BALANCE は 32 ETH に制限されているため、ノードオペレーターは、より大きなステーク資産を管理するために複数のバリデーターアカウントを作成する必要があり、その結果、多数の「冗長バリデーター」が存在することになります。
したがって、EIP-7251を通じて上限を引き上げることにより、lidoなどの集約型ステーキングプロトコルでは管理アカウントの数とシステムの複雑さを軽減できますが、これにより分散化の問題が悪化し、ETHステーキング市場がより集中化される可能性があります。
常に最低 32 のステークを維持するということは、大規模な世帯が参加する必要があることを意味し、これは集約プロトコルとの環境上の妥協であり、また、小規模な世帯がコンセンサス レイヤーの安定性に影響を与える高頻度の操作を行うことを防止します。
EIP-7549 により、引き出し操作の柔軟性が向上し、ステーカーやノード オペレーターが資金の管理を改善しやすくなります。ここでの技術的な背景は、元の設計にいくつかの欠陥があったことです。委員会インデックスが署名情報に含まれているため、同じ投票であっても、委員会が異なると異なる署名ルートが生成され、各投票を個別に検証する必要が生じます。したがって、EIP-7549 の目的は、署名内の委員会インデックスを削除することで検証に必要なペアリング操作の数を減らし、それによって同一投票の集約を実現することです。
したがって、イーサリアムはステーキング体験を常に最適化しており、その本質はステーキングとノードオペレーターのグループを統合することであることに注意することが重要です。これは、合併後のイーサリアムの生命線です。大量の資金がイーサリアムの周囲になくなると、そのセキュリティ自体が揺らぐことになります。
複数の EIP が追加されることで、大規模なノード オペレーターは複数のバリデーター アカウントを統合できるようになり、同時に、複利の蓄積による収入の増加や、より柔軟なステーキングの増加など、小規模なバリデーターにも柔軟性が提供されます。
これは非常に重要です。元の 32 ETH に達した後、新しい収入で 10 ETH を生成すると、新しいアカウントを開設するためにまだ 32 ETH を取得する必要があるため、ステーキングに ETH を使用し続けることはありません。
しかし、このアップデート後は、42 eth を直接ステークできるようになります。そうすれば、当然、複利は ETH に戻ることができます。
したがって、私の意見では、 ETH市場でのDeFiプロジェクトの収益が弱い現在の状況では、吸い上げが続き、ETHの流動性は低下するでしょう。これが財団がこのシリーズを推進する動機かもしれません。
L2エコロジーの最適化
EIP-7623: コールデータコストの増加
これは evm レイヤーに影響を与えるもので、トランザクション内の calldata のガス料金を 1 バイトあたり 4/16 ガスから 10/40 ガスに直接増加させます。ここでの 2 つの値は、0 バイトと非 0 バイトの料金を区別するために使用され、どちらも 2.5 倍高くなります。
実際、ブロック圧力を軽減することはバナーであり、 L2 に calldata を使用させず、より多くの Blob を使用するように強制します。
EIP-7691: BLOB スループットの増加
ブロック内の BLOB のサイズを増やし、より大きな L2 ストレージ スペースをサポートします。以前の Cancun アップグレードでは、BLOB を表すコア パラメーターが 2 つありました。target と max で、ブロックあたりの BLOB のターゲット数とブロックあたりの BLOB の最大数を示すために使用されていました。カンクンではパラメータが3と6でしたが、プラハ以降はパラメータが6と9になりました。つまり、容量が拡大されたのです。
実際、イーサリアムはL2に「高速道路」を追加しているだけですが、「トラフィック管理」と「異なる高速道路の課金基準」をどのように解決するかが最も根本的な問題です。
EIP-7840: EL 構成ファイルに BLOB スケジュールを追加する
クライアントが EIP-7691 の BLOB 量設定を動的に調整できるように、構成ファイルが追加されました。
また、BLOB のガス価格の応答性を調整できるパラメーター baseFeeUpdateFraction もあります。
解釈
結局のところ、これは EIP 提案なので、非常に技術的に聞こえますが、コアとなる概念は理解しやすいです。
イーサリアムのコアセールスポイントは、Defi Summerの契約システムからL2エコシステムコミュニティに変わりました。他のチェーンシステム、たとえ24年間で最もホットなBTC L2システムであっても（その本質は依然としてL2への期待によるものです）、イーサリアムのL2と完全に競争できる立場にはありません。
BTC と同様に、チェーンの制限により、データフォールバックやセキュリティ共有の実際の意味での L2 を実現することは困難です。
他の svm および move チェーンは、本質的に独自の L1 を開発中で、その上の L2 を浅く探索しています。もちろん、これらのチェーンの高パフォーマンスは、L2 への依存度が比較的低いです。
そのため、イーサリアムはL2のtpsを通じて自らを改善します。もちろん、流動性の分散やクロスチェーンの複雑さなど、多くの問題があります。しかし、これが彼が行ける唯一の方法だった。結局、Web3が高頻度アプリケーションチェーンの段階まで発展すると、チェーンを頻繁に横断することはなくなります。また、流動性と普遍性の問題を解決するために、チェーンの抽象化などのトラックが試行されています。その後、パーティクルネットワークなどの分析を解釈します。
L2 のトランザクション コストは Ethereum の Blob の容量に大きく依存するため、calldata ガス料金を変更する目的は、L2 がより多くの BLOB を使用し、 L2 状態データを保存するために Ethereum の永続的な calldata を使用しないようにすることです。
さらに、BLOB の容量は、その後の L2 の増加も考慮する必要があり、動的に構成可能である必要があります。
したがって、この開発方向を通じて、L2 の方向の確実性をさらに決定することができ、それはまた、L2 の欠点を解決するための市場の需要の確実性を意味します。
最後に
プラハ アップグレードは、イーサリアムの継続的な進化の道のりにおける重要な節目ですが、私としては、このアップグレードは、絶え間ない妥協と調整を必要とする妥協案のようなものです。
イーサリアムは、ステーキングと L2 に関するイーサリアム固有の最適化とは別に、他の BLS、AA などが実際に他の L1 によって広く試験運用されているため、主導権を握るというよりは、市場に押されています。
しかし、全体的な重要性という点では、このアップグレードは「ロンドン」や「合併」のような広範な市場の議論を引き起こしたわけではないものの、イーサリアムネットワークのより高いスケーラビリティと分散化の基盤を静かに築き上げています。
アカウントの抽象化が進むと、ユーザーが暗号アプリケーションを使用するハードルが下がります。ステーキング メカニズムの改善により、Ethereum PoS ネットワークのセキュリティと安定性がさらに強化されます。データの可用性とスループットの向上により、ますます繁栄する第 2 層エコシステムに広いスペースが提供されます。
Prague/Electra アップグレードの完了により、 Ethereum はより効率的で、より使いやすく、より柔軟になることが予測できます。さらに重要なのは、Prague アップグレードによってもたらされた概念とテクノロジーの一部が、将来の改善への道を示していることです。
次に計画されているハードフォーク「Osaka」アップグレードでは、コミュニティは待望のVerkleツリー状態ソリューションやシングルスロット最終確認メカニズムなど、さらに革新的な改善を導入する可能性があります。
長期的には、イーサリアムの開発ロードマップは明確かつ確固たるもので（少し頑固ではあるが）、これらのアップグレードの累積的な効果により、イーサリアムは「1秒あたり数百万件のトランザクション」（The Surge）と検閲防止、中央集権化リスクの低さ（The Scourge）という壮大なビジョンを達成することになるだろう。
2025年末の大阪ハードフォーク（例年通り26年延期と予想）と2026年のアムステルダムハードフォークでは、各アップグレードによりイーサリアムがより成熟し、堅牢になり、機能が豊富になると予想されます。
