一文で理解するイーサリアム Pectra アップグレード：各 EIP の詳細解析

原文：Pectra: Ethereumの次の大規模アップグレード

著者 ： Tanay Ved, Coin Metrics

翻訳 ：GaryMa, 吴说区块链

原文の翻訳に加えて、この記事では原文で言及されていないPectraの他のEIPについても補足して紹介します。

重要なポイント

PectraはEthereumの次の大規模アップグレードであり、実行層（Prague）とコンセンサス層（Electra）の変更を含みます。テストネットPectraのアップグレードは波乱がありましたが、最終的に5月7日10:05 UTC頃にPectraメインネットのアップグレードが有効化されることが決定しました。

このアップグレードは、ステーキング、Layer 2のスケーラビリティ、ユーザーエクスペリエンス（UX）において重要な改善をもたらし、将来の変革の基盤を築きます。

主な変更点には、バリデーターのステーキング上限の引き上げ、柔軟なステーキングの引き出し、アカウント抽象化の強化、blobのスループットの増加が含まれ、ネットワークの効率と安全性を向上させます。

序論

「合併」（The Merge）から31ヶ月、「Shapella」アップグレードから24ヶ月、「Dencun」アップグレードから13ヶ月が経過し、Ethereumは次の大規模アップグレードであるPectraハードフォークを迎えようとしています。

Pectraメインネットのアップグレード前のテストネットのアップグレードは波乱に満ちていました。

HoleskyテストネットのPectraアップグレードは2月24日21:55 UTCに有効化されましたが、クライアントソフトウェアの設定ミス（Geth、Nethermind、Besuのデポジットコントラクトアドレスの誤り）により中断され、チェーンがフォークしました。開発者は、大規模なペナルティイベントを通じてネットワークを回復する計画を議論し、誤ったバリデーターの退出を加速し、ネットワークの最終確定を実現することを目指しましたが、最終化には3月11日までかかりました。

SepoliaテストネットのPectraアップグレードは3月5日に予定通り実施されましたが、カスタムデポジットコントラクトの設定問題により、一部の実行層（EL）クライアントがブロック内でトランザクションを含める際に異常が発生しました。しかし、問題はすぐに修正され、ネットワークは最終化されました。

3月19日、バリデーターの退出をテストするために新しいテストネットHoodiが導入され、3月26日にPectraネットワークのアップグレードが成功裏に有効化されました。

Ethereum Pectraテストネットのアップグレードは2ヶ月の波乱を経て、メインネットの展開への道を開き、最終的に5月7日10:05 UTC頃にPectraメインネットのアップグレードが有効化されることが決定されました。

従来のEthereumのアップグレードと同様に、Pectraは実行層（EL）とコンセンサス層（CL）の両方に関わります。その名称はこの二重の焦点を反映しています：Prague（プラハ）は実行層のアップグレードを表し、Devcon 4の開催地を記念しています；Electra（エレクトラ星）はコンセンサス層のアップグレードを象徴しています。

PectraはEthereumの歴史の中で最も多くのEIP（Ethereum Improvement Proposals、Ethereum改善提案）を含むハードフォークの一つであり、昨年のDencunアップグレードを基にさらなる最適化が行われ、ユーザーエクスペリエンス（UX）の改善、バリデーターの操作の最適化、Layer 2の拡張を推進することを目指しています。これによりEthereumエコシステムに深遠な影響を与えることが期待されています。

この記事では、各EIPの所属分野に基づいて分類し、各EIPを深く分析します。

バリデーターとステーキングメカニズムの改善

Pectraは3つの主要なEIPを通じてEthereumのPoSシステムにおけるバリデーターの操作体験を最適化します：

EIP-7251：最大有効残高（MaxEB）の引き上げ

現在、Ethereumのステーキングメカニズムは、単一のバリデーターの有効ステーキング上限を32 ETHに制限しています。これは、独立したステーキング者が32 ETH単位でステーキングを行わなければならず、その限度を超えた報酬は有効ステーキングにカウントされないことを意味します。

EIP-7251は最大有効残高（MaxEB）を2048 ETHに引き上げ、単一のバリデーターのステーキング範囲を32から2048 ETHに拡大することを提案しています。これにより以下の影響があります：

· ステーキングの柔軟性の向上：ステーキング者は、32 ETHの倍数に制限されることなく、すべての収益を有効ステーキング残高に再投資できます。例えば、33 ETHを保有するバリデーターは、現在すべての33 ETHでステーキング報酬を得ることができ、資金の効率と柔軟性が向上します。

· バリデーターの数の削減：現在、Ethereumには105万のアクティブなバリデーターがいます。このEIPにより、大規模なオペレーターがバリデーターを統合できるため、総数が減少し、ネットワークの負担が軽減されます。

· ネットワーク負荷の軽減：多くのバリデーターは分散化に寄与しますが、帯域幅と計算負担を増加させることにもなります。MaxEBの引き上げは、バリデーターの集まりを最適化し、ピアツーピア通信のオーバーヘッドを削減します。

EIP-7002：実行層による引き出しのトリガー

EIP-7002はバリデーターの機能をさらに強化し、実行層（0x01）を通じて引き出しの証明書を直接トリガーすることを許可します。

現在、バリデーターには2つのキーがあります：

1. アクティブキー：バリデーションの責任を実行するために使用されます；

2. 引き出しキー：ステーキング資金にアクセスし、管理するために使用されます。

以前は、アクティブキーのみが退出をトリガーでき、引き出しキーは自律的に操作できませんでした。EIP-7002は引き出しキーも引き出しをトリガーできるようにし、以下の利点をもたらします：

· 資金の管理権の拡大：バリデーターは、ノードオペレーターに依存せずに資金を直接管理できます。

· 完全に信頼のないステーキングプールをサポートし、安全性と分散化の程度を向上させます。

EIP-6110：チェーン上のバリデーターのデポジットの保存

現在、新しいバリデーターが実行層にデポジットした後、コンセンサス層がそれを認識し処理するのを待つ必要があり、アクティベーションに遅延が生じます。

EIP-6110は、実行層が直接コンセンサス層にデポジット情報を伝達できるようにし、追加の検証ステップを減少させ、バリデーターのアクティベーション時間を約9時間から約13分に短縮します。

Layer 2の拡張能力の向上：Blobのスループットの引き上げ

EIP-7691：Blobのスループットの増加

昨年のDencunアップグレードでは、Blobが導入され、Layer 2のロールアップがデータを効率的に保存する方法として機能しています。現在、毎日約2.1万のBlobがEthereumに提出されていますが、容量が限界に近づいており、手数料の上昇とスループットの制限を引き起こしています。

現在、Ethereumの各ブロックの目標Blob数は3個で、最大6個です。EIP-7691はその目標値を6に引き上げ、最大値を9に引き上げることを提案し、データ保存容量を増加させ、スループットとスケーラビリティを向上させます。これによりデータ保存コストが削減され、L2の取引手数料が減少します。

EIP-7623：calldataコストの引き上げ

Blobメカニズムが導入される前、L2は主にcalldataを使用してデータを保存しており、特定の状況では引き続き使用されています。これは、コスト効率が高い場合があるためです。

EIP-7623はcalldataの費用を引き上げ、L2が主にBlobを使用してデータを保存するように促し、ロールアップ取引の効率を向上させます。

ユーザーエクスペリエンス（UX）の向上

EIP-7702：EOAアカウントコードの設定

核心思想：EOAに一時的にスマートコントラクト機能を付与する

EIP-7702は新しい取引タイプ（0x04として識別される）を導入し、外部所有アカウント（EOA）が取引を実行している間に一時的にスマートコントラクトの機能を得ることを許可します。つまり、従来のEOAはコードを持たず、取引に署名するためだけに使用されていましたが、この提案により、EOAは取引の中でコードを「ロード」し、スマートコントラクトウォレットのように複雑な操作を実行できるようになります。

主な利点

1. バッチ操作：ユーザーは一つの取引内で複数の操作（例：approve + depositの組み合わせ）を完了でき、複数の取引が必要な非効率的な問題を回避できます。

· ガススポンサーシップ：このメカニズムは、第三者が取引手数料をスポンサーすることをサポートし、ユーザーエクスペリエンスを改善し、ユーザーが事前にETHを保有することなく操作できるようにします。

· セキュリティと柔軟性の向上：ユーザーは取引に対して細かい権限管理を行うことができ、例えば、子アカウントが特定の条件下でのみ操作できるようにすることで、アカウントの安全性が向上します。

直面する可能性のある課題

· エコシステムの互換性の問題：EOAは従来、コードを持たないと見なされていたため、既存のスマートコントラクトやセキュリティチェック（例：require(tx.origin == msg.sender)）は、この一時的にコードを付与するメカニズムに適応するために調整が必要になる可能性があります。

· 取引構造の複雑性の増加：新しい取引タイプの導入により、ウォレットやクライアントは、新しい権限のタプルや一時的なコード設定を処理する際に安全性の脆弱性や追加の高コストが発生しないように大きな変更を行う必要があります。

EIP-7702は、一般的なEOAが単一の取引内で一時的にスマートコントラクト機能を得ることを許可し、バッチ取引、取引スポンサーシップ、より柔軟な権限管理をサポートします。このメカニズムはユーザーエクスペリエンスを大幅に改善し、dApp機能を拡張することができますが、いくつかの従来の仮定を打破することになり、エコシステムの各方面が適応して更新する必要があります。全体として、これはアカウント抽象化への道を開く重要な提案であり、将来のEthereumアカウントが安全でありながらも柔軟であることを目指しています。

その他のEIP

EIP-7685：汎用実行層リクエスト

背景と目的

現在、Eth1（実行層）と信号チェーン（コンセンサス層）の間で処理する必要がある主要なリクエストは3種類です：

1. デポジット：ユーザーが発起するデポジットイベントは最初にEth1ブロックに現れますが、最終的には信号チェーンで処理される必要があります。

2. 引き出し：信号チェーンから発信される引き出しリクエスト（通常はコマンドラインツールを通じて）はEth1で処理される必要があります。

3. バリデーターのマージ：同様に、このリクエストもEth1と信号チェーンの間で伝達される必要があります。

この提案が必要な理由

現在、異なるタイプの操作が2つの層の間で行き来しており、混乱を引き起こす可能性があります。EIP-7685が提案する統一処理フレームワークは、以下を目指しています：

·すべてのリクエストを標準的な方法で処理し、プロセスを明確にし、効率を向上させること；

·これらの操作をEth1のみに依存してトリガーすることで、バリデーターの実行環境とステーキング管理を分離し、安全性を向上させること。

主な内容

1. リクエストタイプの識別：各操作に特定の識別子を定義します。例えば、既存のデポジットと引き出しリクエストタイプに加えて、マージリクエストタイプを追加します。

2. 完全性の保証：リクエストデータの完全性と安全性を確保するために、ハッシュ検証やマークル化データなどのメカニズムを採用します。

3. 処理キューと制限：処理待ちのリクエストに対して、同時に待機しているデポジット、引き出し、またはマージリクエストの数に制限を設定し、システムの過負荷を防ぎます。

最終的な意義

一般のユーザーや開発者にとって、今後はデポジット、引き出し、またはバリデーターのマージ操作を行う際に、統一された標準化されたプロセスを通じてより迅速かつ安全に完了できることを意味します。これにより、システムの効率が向上し、全体的なリスクが低減されます。

EIP-2537：BLS12--381曲線操作のプレコンパイル

核心目的

この提案は、Ethereumに内蔵機能（プレコンパイルコントラクト）を追加し、BLS12--381曲線上の数学演算を処理するためのものです。

なぜこのプレコンパイルが必要か

·効率の向上：スマートコントラクト内で複雑な楕円曲線演算（署名検証や集約など）を直接実装すると、大量のガスを消費します。プレコンパイルコントラクトは、これらの演算コストを大幅に削減できます。

·より高い安全性：現在使用されているBN254曲線（約80ビットの安全性）に比べ、BLS12--381曲線は約120ビットの安全性を提供し、暗号操作がより安全になります。

主な用途

·BLS署名検証：BLS署名は、複数の署名を1つに集約することを許可し、検証時の計算量を大幅に削減します。

·zkSNARK証明の検証：いくつかのプライバシー保護およびスケーラビリティソリューションでは、zkSNARK証明を検証する必要があり、これらの操作も複雑な楕円曲線計算に依存しています。

実際の意義

このEIPにより、開発者はスマートコントラクト内でBLS12--381曲線に関連する暗号演算をより効率的かつ低コストで使用できるようになり、より多くの革新的なアプリケーションをサポートできます。例えば、より効率的なコンセンサスメカニズム、クロスチェーンインタラクション、さまざまな分散型アプリケーションなどです。

要するに、EIP-2537は、チェーン上で高い安全性の暗号演算を行う際に過剰なガスを消費する問題を解決するために、プレコンパイルコントラクトを通じてこれらの複雑な演算をより効率的かつ実用的にすることを目的としています。

EIP-2935：状態に歴史的ブロックハッシュを保存

現在の問題

Ethereum仮想マシン（EVM）では、BLOCKHASHオペコードを通じて最近の256ブロックのハッシュ（約50分間のもの）しか取得できず、これは一部のアプリケーションにとっては不十分です。例えば、より古いブロックデータの証明が必要なクロスチェーンアプリケーションや無状態クライアント（ロールアップなど）です。

提案の核心

EIP-2935は、ブロックチェーンの状態に8192ブロックのハッシュ（約27.3時間分）を追加で保存することを提案しており、これによりクエリ可能な歴史的ブロックデータの範囲が大幅に拡大されます。

実現方法

現在のBLOCKHASHオペコードが最近の256ブロックにのみアクセスできることを維持しつつ、提案は新しいシステムコントラクトを導入します：

·set()メソッド：各ブロックが処理される際に、新しいコントラクトが自動的に現在のブロックハッシュをリングバッファに保存します。

·get()メソッド：誰でもこのメソッドを通じてリングバッファに保存された歴史的ブロックハッシュをクエリできます。

実際の利点

これにより、クロスチェーンアプリケーション、ロールアップ、または他の古いブロックデータにアクセスする必要があるシステムは、外部データに依存せずに直接チェーン上で必要な歴史情報を取得できるようになり、設計がよりシンプルで安全かつ信頼性の高いものになります。

EIP-7840：blobスケジューリングをEL設定ファイルに追加

核心目的

この提案は、blobスケジューリングに関する重要なパラメータ（例えば、各ブロックで許可されるblobの数や基本手数料の更新比率）を実行層（EL）の設定ファイルに書き込むことを目的としています。

具体的な方法

·設定ファイルに「目標blob数」と「最大blob数」の設定を追加します。

·同時に、基本手数料の更新速度を調整するためのbaseFeeUpdateFractionというパラメータを追加します。

·クライアントはノードAPIを通じてこれらのパラメータをクエリでき、現在のネットワークのblobに関する具体的な設定を知ることができます。

なぜ有用か

これらの情報は、開発者やノードオペレーターがblobのガス費用をより正確に見積もるのに役立ち、ネットワークがブロック内の大データのスケジューリングと処理をより良く管理するのに役立ちます。

全体として、EIP-7840はEthereum実行層に一連の構成可能なblobスケジューリングパラメータを追加し、ネットワークが大データ（blob）を処理する際により効率的かつ透明性を持たせることを可能にします。

EIP-7549：委員会インデックスを証明から移動

核心アイデア

現在、バリデーション投票（Attestation）メッセージには3つの部分が含まれています：

·LMD GHOST投票（ブロックルートとタイムスロットを含む）

·Casper-FFG投票（ソースとターゲットを含む）

·委員会インデックス（index）

問題は、委員会インデックスも署名されているため、投票内容が同じでもインデックスが異なると生成される署名ルートも異なります。これにより、同じ内容の投票が一緒に集約できなくなります。

EIP-7549が提案する解決策は、委員会インデックスを署名された投票メッセージから削除することです。これにより、投票の核心内容（LMD GHOSTとCasper-FFG投票）のみが署名計算に参加し、同じ投票の複数のバリデーターが同じ署名ルートを生成できるようになり、集約が可能になります。

主な利点

·バリデーション作業量の大幅な削減：現在の状況では、2/3のコンセンサスを達成するために1366件の投票を検証する必要があります。委員会インデックスを削除すると、約22件の投票を検証するだけで済み（計算量が約62倍節約されます）、これは大量のペアリング計算を必要とするバリデーションプロセスにとって、特にゼロ知識証明に基づくCasper FFGクライアントにとって効率の向上が非常に顕著です。

·チェーン上のデータストレージ効率の向上：投票情報がより効率的に集約できるため、各ブロックにより多くの投票をパッケージ化できます。現在、1つのブロックには2つのタイムスロットの投票しか含められませんが、改善後は最大8つのタイムスロットの投票を含めることができ、たとえ提案者の1/8しかオンラインでなくても、すべての投票をブロックに含めることができます。

委員会インデックスをAttestationメッセージから削除することで、バリデーション投票時に処理する必要があるペアリング計算の数を大幅に削減できるだけでなく、投票データをより効率的にパッケージ化し、全体のコンセンサスバリデーションプロセスの性能とチェーン上のストレージ利用率を向上させることができます。この改善は、Casper FFGコンセンサスメカニズムおよびその関連のゼロ知識証明検証にとって特に重要です。

結論

Pectraは、記録的な数のEIPを含むアップグレードとして、Ethereumのアカウント抽象化、バリデーター機構の最適化、ネットワーク効率の向上、Layer 2の拡張などの重要な方向性を推進します。また、Vitalik Buterinが最近強調したように、EthereumはRollup中心の拡張ルートを採用していますが、Layer 1の最適化も継続して行っており、最近ではガス制限を3600万に引き上げ、将来的にはさらなる検閲耐性、スループット、スケーラビリティの向上が期待されています。

参考リンク：

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md