ペクトラのアップグレードはイーサネット・ネットワークの次の大きなマイルストーンであり、2025年の第1四半期に実施される予定です。このアップグレードは2つの主要コンポーネントで構成されており、プラハ実装層のアップグレードとエレクトラ・プロトコル層のアップグレードです。
これまでのメジャーアップグレードとは異なり、ペクトラには1つの際立った主要目標があるわけではなく、むしろ複数の技術的な改善や最適化に焦点が当てられています。これは、L2手数料を劇的に削減したDencunのアップグレードや、誓約されたETHの引き出しを可能にし、EtherのProof of Stake (PoS)への移行の最終段階を完了したShapellaのアップグレードとは対照的です。
最新情報
最近、イーサネットコア開発者(ACD、All Core Developers)は電話会議で、ペクトラのアップグレードを2段階に分ける可能性について議論しました。この提案によると、以下のようになります。この提案によると:
ペクトラ・アップグレードには、pectra-devnet-3のEIPが含まれます(詳細は以下を参照)。
当初予定されていたEOF (EVM Object Format)とPeerDAS (Peer Data Availability Sampling)の内容は、次のアップグレードに延期されます。.
当初大阪で予定されていたVerkle Trees関連のコンテンツはさらに延期され、その後のアムステルダムのアップグレードで実装されるかもしれません。
この段階的なアプローチは、各アップグレードの規模と複雑さが管理可能なままであることを保証する一方で、技術が完全にテストされ洗練されるまでの時間を確保するために設計されています。
ペクトラのアップグレードに関連するEIP
EIPs identified for inclusion
- EIP-2537[1]: BLS12-381曲線操作のプリコンパイル
EIP-2935[2]: 過去のブロックハッシュを保存するために状態にして履歴ブロックハッシュを保存する
EIP-6110[3]: チェーン上にベリファイア預金を提供する
EIP-7002[4]: トリガー可能な実行レイヤーの終了
EIP-7251[5]: 検証済み残高の上限を増やす
EIP-7549[6]: 委員会インデックスの証明外移動
EIP-7685[7]: 汎用実行レイヤ要求
EIP-7702[8]: トランザクションのEOAアカウントコードの設定
検討中のEIP
EIP-7212:secp256r1曲線のプリコンパイルのサポート
EIP-7547[9]: インクルード・リスト
EIP-7623[10]: カルデータ・コストを追加
EIP-7623[10]: カルデータ・コストを追加。EIP-7742[11]: コンセンサス層と実行層の間でブロブ計数をデカップリングする
主要なEIPの紹介
EIP-は、次のようなものです。2537: BLS12-381曲線操作のためのプリコンパイル
この提案は、BLS12-381曲線にプリコンパイル操作を導入し、BLS署名検証などの操作の効率を大幅に改善します。既存のBN254プリコンパイルと比較して、BLS12-381ははるかに高いセキュリティレベル(BN254の80ビットに対して120ビット以上)を提供する。この改良には、基本的な曲線演算だけでなく、複数の指数演算も統合されており、公開鍵と署名の効率的な集約の基盤となっています。
EIP-2935:ステート内に過去のブロックハッシュを保存する
この提案は、システムコントラクト内に最後の8192ブロックのハッシュを保存することを提案しています。これは主にステートレス・クライアントの実行をサポートするための変更である。これは主にステートレス・クライアントの実行をサポートするための変更である。こうすることで、ステートレス・クライアントは、既存のBLOCKHASHオペコードとの互換性を維持しながら、必要な履歴情報により簡単にアクセスできるようになる。これはブロックハッシュの履歴を保存するメカニズムを単純化するだけでなく、履歴データにアクセスする新しい方法を提供します。
EIP-6110: Validator Deposits on Chainの提供
この提案は、バリデータのデポジット処理をイーサネット実行層のブロック構造に直接統合します。この変更により、デポジットの包含と検証の責任がコンセンサスレイヤーから実行レイヤーに移り、コンセンサスレイヤーがデポジット(またはeth1data)に投票する必要がなくなります。デポジットトランザクションのコントラクトログイベントを分析してデポジットのリストを生成することで、このアプローチはデポジット処理のセキュリティと効率を向上させるだけでなく、ユーザーエクスペリエンスも向上させる。さらに、クライアント・ソフトウェアの設計を簡素化し、システム全体の複雑さを軽減します。
EIP-7002: Triggerable Execution-Level Withdrawal
この提案は、ベリファイアが実行レイヤ(0x01)を介してクレデンシャルを引き出すことにより、引き出しと終了操作をトリガーできるようにする新しいメカニズムを導入します。これは実行レイヤーのブロックに取り下げメッセージを追加することで実装され、その後コンセンサスレイヤーによって処理される。このアプローチは、システムのセキュリティと一貫性を維持しながら、検証者により柔軟な終了オプションを提供する。
EIP-7251:最大有効残高の増加
この提案は、イーサバリデータの最大有効残高(MAX_EFFECTIVE_BALANCE)を増加させようとするものです。この変更には複数の利点があります:
大規模なノード運用者がより少ない検証者に統合することを可能にし、運用効率を向上させます。
小規模の誓約者に複利報酬を得る機会を提供し、誓約の魅力を高めます。
より多くの参加者を惹きつけるために、より柔軟な誓約オプションを提供する。
ネットワーク内の冗長なバリデータの数を減らし、P2Pメッセージの数を減らします。
BeaconStateのメモリフットプリントを減らし、システム効率を向上させます。
イーサネット・ネットワーク全体の資金の流動性をさらに最適化するために、実行レイヤーの部分引き出しメカニズムの強化と組み合わせます。
EIP-7549:証明から委員会インデックスを移動する
この提案は、署名された証明メッセージから委員会のインデックス・フィールドを削除して、同一のコンセンサス票の集約を可能にすることを提案します。集計することを提案します。この変更の主な目的は、コンセンサスルールの検証に必要なペアの平均数を減らすことによって、Casper FFGクライアントの効率を改善することです。すべてのタイプのクライアントがこの改善の恩恵を受けることができますが、この変更はおそらく、Casper FFGのコンセンサスを証明する必要があるZK回路に最も大きなパフォーマンス向上をもたらすでしょう。
EIP-7685: Generic Execution Layer Requests
この提案は、スマートコントラクトによってトリガーされたリクエストを保存し、処理するための汎用フレームワークを定義します。これは、実行ヘッダーにフィールドを追加し、ボディにリクエスト情報を格納するフィールドを追加することで実装され、コンセンサスレイヤーにこれらのリクエストを公開し、各リクエストを処理できるようにする。このメカニズムは、主にスマートコントラクトが制御するバリデータのニーズの高まりに対応するために設計されており、将来的にはより複雑なオンチェーンインタラクションの基盤を提供する。
EIP-7702:トランザクションにEOAアカウントコードを設定する
ヴィタリック・ブテリンらによって提案されたEIP-7702は、イーサネットのアカウント抽象化(account abstraction)を最適化することを目的としている。この提案は、外部所有アカウント(EOA)が認証メカニズムを通じてアカウントコードを設定できるようにする新しいトランザクションタイプを導入する。
バッチ操作:EOAが同じトランザクションで複数の操作を実行できるようにし、効率を向上させます。
ペイ・オン・デマンド取引:第三者による取引手数料の支払いを容易にします。
特権の低下:アカウントのセキュリティと柔軟性を強化します。
新しいトランザクション構造を採用することで、この提案はEOAの機能と使いやすさを強化するだけでなく、将来のアカウント抽象化技術に対して優れた互換性と拡張性を提供します。
結論
ペクトラのアップグレードは、目立った主目的はないものの、一連の技術的な改善と最適化を通じて、イーサネットネットワークの機能性、セキュリティ、効率性をさらに強化するものです。アップグレードプログラムが進むにつれて、より多くのEIPが組み込まれたり、適応されたりすることになるでしょう。