著者: 0xNatalie 出典: chainfeeds
イーサネットの次のアップグレードである Pectraは、プラハとエレクトラの組み合わせからその名前を取っています。
プラハは実行層のアップグレードを意味し、イーサ・デブコン4を主催した都市であるプラハにちなんで名付けられ、エレクトラはコンセンサス層のアップグレードを象徴しています。これらはアルファベット順に星の名前にちなんでいる。この場合、星の名前Electraはアルファベットの "E "に相当する。
ペクトラのアップグレードは、イーサの歴史の中でおそらく最も多くのイーサリアム改善提案(EIP)を伴うハードフォークであり、検証機の操作とメインネットのパフォーマンスを改善する一連の提案を含むだけでなく、L2レイヤーの最適化も導入しています。Pectra Devnet 4のテストネットは稼働したばかりで、Pectraのアップグレードに含まれることが確認されているEIPはすでに8つあります。
含めるEIPの特定と影響
これら8つのEIPがユーザーに与える影響は、次のように示されます。一方、バリデータのプロセスを最適化することで、セキュリティと効率が向上し、イーサのスピードとスループットが向上します。
EIP-2537(BLS署名サポート):BLS署名検証を可能にし、複数の検証者を可能にする一連のプリコンパイルを導入することで、イーサにBLS12-381曲線演算のサポートを追加します。BLS署名は、より小さな署名を生成し、署名の集約をサポートする暗号アルゴリズムです。これは、多くの署名検証とデータ検証操作を必要とするL2の実行を支援します。
EIP-2935 (Storing Historical Block Hash in State): システムコントラクトに最後の8192ブロックハッシュを格納することで、ステートレスクライアントをサポートします。モデルをサポートし、過去のブロック ハッシュのより柔軟なクエリを提供します。これらのハッシュは、コントラクトを通じて直接照会することができ、ステートレス・クライアントが証明(証人)のバンドルとして利用できるようになります。完全なブロックチェーンの履歴を維持したり、大量のデータを独自に保存したりする代わりに、クライアントは、ステートを通じて保存されたブロックハッシュと関連する証明だけに頼ることで、ブロックとトランザクションの正当性を検証することができます。
EIP-6110(プロビジョニング・バリデーター・デポジット・オン・チェーン):バリデーター・デポジットの処理をコンセンサスレイヤーから実行レイヤーに移行し、デポジット情報を検証するためにコンセンサスレイヤーの追加の投票メカニズムに依存することなく、オンチェーンで処理・検証する。コンセンサスレイヤーとクライアントの設計を簡素化しながら、デポジットプロセスのセキュリティを強化し、処理の待ち時間を短縮します。
EIP-7002 (Execution Layer Triggerable Withdrawal): 出金認証情報を保持するオーナーが、バリデータのアクティブキー(BLSキー)に依存することなく、独自に出金を開始できるようにします。strong>、ユーザーの自主性を高める。現在、バリデータのアクティブキーだけが引き出しをトリガーできるため、アクティブキーを紛失した場合や、バリデータが第三者(例えば質権設定サービスプロバイダー)に検証タスクを委任した場合、引き出し証憑の所有者(すなわち資金の実際の所有者)は、質権設定されたETHを自律的にコントロールできない。本提案では、実行レイヤーを通じてETHの引き出しと引き出し操作をトリガーし、これにより所有者はアクティブキーに依存することなく、引き出し証憑を通じて引き出しを開始できる。アクティブキーに依存する必要はありません。
EIP-7251(誓約限度額の増加):各バリデータが32ETHを超える誓約を保持できるように、バリデータの最大有効残高を増加させますが、最低誓約基準額は32ETHのままです。 その意図は、大規模なノード運営者が複数のバリデータを統合することで、ネットワーク内のETH量を削減できるようにすることです。ネットワーク内のバリデータの数を減らすことで、P2Pメッセージ、署名集約、ストレージの負担を減らすことができます。
EIP-7549(認証から委員会インデックスを移動):認証メッセージから委員会インデックスフィールドを移動することで、より効率的なコンセンサス投票集約を可能にします。現在イーサネットコンセンサスメカニズムでは、各ベリファイアはLMD GHOSTポーリング(ポーリングのブロックルートとタイムスロットが含まれる)、Casper-FFGポーリング(ソースとターゲット情報が含まれる)、およびコミッティインデックス(ベリファイアが所属するコミッティ番号)を含むポーリングに投票する。委員会インデックスが署名メッセージに含まれているため、複数の検証者が同じブロックに投票する場合、たとえ投票数が同じであっても、生成される署名ルートは異なり、その結果、これらの投票を簡単に集約することができません。委員会インデックスフィールドを署名メッセージ自体から移動することで、より効率的な投票集約が可能になり、検証コストとネットワーク負荷が軽減されます。
EIP-7685 (Generic Execution Layer Requests): スマートコントラクトによってトリガーされたリクエストを保存し処理するための、実行レイヤー(EL)の汎用フレームワークを定義します。このフレームワークはより幅広い実行レイヤーのトリガー動作をサポートし、異なるタイプのリクエストを統一された方法で処理することを可能にし、実行ブロック構造を変更することなく、新しいリクエストタイプを追加するプロセスを簡素化します。
EIP-7702(EOAへのコード実行機能の追加):外部所有口座(EOA)にコード実行機能を追加し、口座の柔軟性とプログラマビリティを強化する.EOAは、承認された署名によって、以下のことを行います。バッチ取引や許可制御など、特定の操作を代理で実行するスマートコントラクトを割り当てます。EOAは、スマートコントラクトのアカウントに変換することなく、スマートコントラクトの一部の機能を提供します。
優先的に検討すべきEIP
以下は、主にブロブの最適化、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性、L2データパブリッシングのコスト安定性L2データ・パブリッシングのコスト安定性の向上、L2のトランザクション処理能力の強化、L2のコストの効果的な削減。さらに、calldataのコストを増加させる調整は、ETHの破壊に影響を与え、ETHのインフレ圧力を高める可能性があります。
EIP-7742(コンセンサスレイヤーと実行レイヤー間のブロブカウント依存性の切り離し):コンセンサスレイヤーと実行レイヤー間のブロブカウントを切り離し、ブロブ検証プロセスを簡素化し、不必要な複雑さを減らし、プロトコルのスケーラビリティと柔軟性を向上させます。現在のプロトコルでは、実行レイヤーとコンセンサス・レイヤーの両方がブロブの最大値をハードコードしており、冗長な検証が行われている。本提案では、実行層によるブロブの最大値の検証をキャンセルし、代わりにコンセンサス層がブロブ目標値を動的に実行層に提供する。このようにして、ブロブ・ターゲット・パラメータは、将来の拡張ニーズに対応するために、より柔軟に調整することができる。EIP-7742は、アップグレードに含めるかどうか検討されているEIPのリストの中で、最も議論の余地の少ない提案です。 最新のコンセンサス層会議によると、開発者はEIP7742を pectra-devnet 5 で実装し始めることに合意していますが、正式に含めるかどうかは、ACDE(All Core Developers Executive)会議での実装層からのフィードバックを待つ必要があります。ミーティング)で実装層からのフィードバックを待つ必要があります。
EIP 7762 (最小ブロブ基本コスト): ブロブ価格が妥当なレベルに調整されるまでの時間を短縮するために、MIN_BASE_FEE_PER_BLOB_GASを増やします。strong>。現在、最低ブロブ基本料金は1ウェイに設定されており、ブロブ需要が供給を上回った場合、価格発見プロセス(すなわち、妥当なブロブガス価格を決定すること)が遅すぎて、適切な料金レベルに達するまでに長い時間がかかります。ブロブ基本料金の下限を引き上げることで、価格調整にかかる時間を短縮し、市場の均衡をより早く達成することができる。
EIP-7623(calldataコストの増加):トランザクションのcalldataコストを増加させ、最大ブロックサイズとその変動幅を縮小し、ネットワークがトランザクションをよりスムーズに処理できるようにします。現在の最大ブロックサイズは約1.79MBであるが、ロールアップなどのアプリケーションによって投稿されるデータ量が多いため、平均ブロックサイズは増加している。主にデータ・アベイラビリティ(DA)トランザクションに使用されるcalldataのコストを引き上げることで、最大ブロック・サイズは約0.72MBに縮小され、将来的にブロック・ガス制限を追加したり、ブロブを増やしたりする余地が残されている。一般ユーザーの取引コストは変わらず、この変更は主に大規模なデータ保存にイーサに依存する取引タイプに影響します。しかし、calldataコストの増加は、データストレージにおけるイーサの競争力を低下させるかもしれません。加えて、calldataコストの増加はトランザクションの減少をもたらし、EIP-1559メカニズムを通じて破壊されるETHの量を減らし、ひいてはETHに大きなインフレ圧力を生み出すかもしれません。
EIP7782(スロット時間の短縮):イーサネットのスロット時間を12秒から8秒に短縮し、より多くのトランザクションを処理するためにブロブをより頻繁に生成します。しかし、12秒のスロットタイムをハードコードしている特定のスマートコントラクトを壊し、イーサの状態肥大化問題を加速させ、ストレージと計算負荷を増加させる可能性があります。
EIP-7783(ブロックのガス料金制限の段階的増加):EIP-7782より穏やかな代替案として、ブロックのガス制限を動的に調整することで、各ブロックに収容できるトランザクション数を徐々に増加させ、ネットワークの処理能力を高めます。ガスリミットを徐々に調整することで、スロットタイムを直接短縮するよりもスムーズにネットワークを拡張できる。この提案はハードフォークを必要としませんが、ステートデータに影響を与える可能性があります。
ペクトラのアップグレードには多数のEIPが含まれるため、1回のアップグレードの複雑さを軽減し、一部のEIPの稼働を早めるために、5月にイーサネット財団のエンジニアチーム EthPandaOps が、ペクトラを2つに分割することを提案しました。9月、EtherFoundationの研究者である Alex Stokes は再び分割を提案し、今度は開発者たちに受け入れられました。text-align: left;">パート1:Pectra Devnetテストネットワーク上ですでに稼働しているEIP(つまり、すでに特定されている8つのEIP)を含み、実装が比較的簡単で、すでに広範なテストに合格しています。
パート2:より複雑なEIP(例: PeerDAS、EOF関連の提案)や、フェーズ2でテストに時間を要するその他の提案を配置します。これらのプロポーザルは、特にコンセンサス層と実施層の間の調整を含む、さらなる開発、監査、テストを必要とする。