Ethereum Pectraの解釈：次の主要なアップグレード

ペクトラのアップグレードは、Ethereum Networkの次の重要なマイルストーンであり、2025年の第1四半期に実装される予定です。このアップグレードには、プラハの実行レイヤーアップグレードとエレクトラプロトコルレイヤーアップグレードの2つの主要な部分が含まれています。

以前の主要なアップグレードとは異なり、Pectraには顕著な主な目標はありませんが、複数の技術的改善と最適化に焦点を当てています。これは、Dencunのアップグレード（L2料金の大幅な削減）またはShapellaのアップグレード（ETH引き出しをステーキングするために利用可能であり、イーサリアムの株式証明（POS）への移行の最終ステップを完了することとは対照的です。

最新の進歩

最近、Ethereum Core Developers（ACD、すべてのコア開発者）は、電話会議でペクトラのアップグレードを2つのフェーズに分割する可能性について議論しました。この提案によると：

1. ペクトラのアップグレードには、Pectra-Devnet-3のEIPが含まれます（詳細については以下を参照）。

2. 元の計画されたEOF（EVMオブジェクト形式）とPeerdas（ピアデータの可用性サンプリング）コンテンツは、暫定的にFusaka（Fulu + Osaka）という名前の次のアップグレードに延期されます。

3. 元々大阪（大阪）で実装される予定のVerkle Trees関連コンテンツは、さらに延期され、その後のアムステルダム（アムステルダム）のアップグレードで実装される場合があります。

この段階的なアプローチは、各アップグレードのスケールと複雑さが制御可能な範囲内に残っていることを保証することを目的としており、さまざまなテクノロジーの完全なテストと改善に十分な時間を残しています。

ペクトラアップグレード関連EIP

eIPが含まれていることを確認しました

1. EIP-2537^[1]：BLS12-381曲線操作の事前コンパイル

2. EIP-2935^[2]：州内の歴史的なブロックハッシュを保存します

3. EIP-6110^[3]：チェーンに検証剤堆積物を提供します

4. EIP-7002^[4]：トリガー可能な実行レイヤー終了

5. EIP-7251^[5]：最大有効バランスを増やします

6. EIP-7549^[6]：委員会指数を証明から移動します

7. EIP-7685^[7]：一般的な実行レイヤーリクエスト

8. EIP-7702^[8]：トランザクションのEOAアカウントコードを設定する

検討中のEIP

• EIP-7212：SECP256R1曲線の事前縮合をサポートします

• EIP-7547^[9]：リストを含めます

• EIP-7623^[10]：CallDataコストを増やします

• EIP-7742^[11]：コンセンサスレイヤーと実行レイヤーの間のBLOBカウントの関係を減圧します

キーEIPはじめに

EIP-2537：BLS12-381曲線操作の事前補償

この提案では、BLS12-381曲線に事前コンパイル操作を導入し、BLSの署名検証などの運用の効率を大幅に改善します。既存のBN254のプレキングコンパイルと比較して、BLS12-381はより大きなセキュリティを提供します（BN254の80ビットと比較して120ビット以上）。この改善には、基本的な曲線操作が含まれるだけでなく、複数の指数操作も統合され、パブリックキーと署名の効率的な集約の基礎を築きます。

EIP-2935：状態で履歴ブロックハッシュを保存します

この提案は、システム契約に最後の8192ブロックのハッシュを保存することを提案しています。これは、主にStatelessクライアントの実行をサポートするための変更です。このようにして、Statelessのクライアントは、既存のBlockhashオペコードとの互換性を維持しながら、必要な履歴情報をより簡単に取得できます。これにより、ブロックハッシュ履歴のストレージメカニズムが簡素化されるだけでなく、履歴データにアクセスする新しい方法も提供します。

EIP-6110：チェーンに検証剤堆積物を提供します

この提案は、バリデーター堆積物のプロセスを、イーサリアム実行層のブロック構造に直接統合します。この変更により、預金の包含と検証の責任がコンセンサス層から実行層にシフトし、コンセンサス層が預金（またはETH1DATA）に投票する必要性を排除します。デポジットトランザクションの契約ログイベントを分析することにより、預金リストを生成するこのアプローチは、預金処理のセキュリティと効率を改善するだけでなく、ユーザーエクスペリエンスを改善します。さらに、クライアントソフトウェアの設計を簡素化し、システム全体の複雑さを軽減します。

EIP-7002：トリガー可能な実行レイヤーの出口

この提案は、バリエーターが資格情報の撤回（0x01）を介して撤回をトリガーし、操作を終了できるようにする新しいメカニズムを導入します。特定の実装は、撤回メッセージを実行レイヤーブロックに追加し、コンセンサスレイヤーで処理することです。このアプローチは、システムのセキュリティと一貫性を維持しながら、より柔軟な出口オプションをバリエーターに提供します。

EIP-7251：最大有効バランスを増やします

この提案は、32 ETHの最小ステークバランスを維持しながら、Ethereum Validators（MAX_EFFECTIECT_BALANCE）の最大有効バランスを増やすことを目的としています。この変更には複数の利点があります。

1. 大規模なノードオペレーターがより少ないバリデーターに合併できるようにし、運用効率を向上させます。

2. 複利の利益を受け取り、誓約の魅力を高める機会を小さな誓約を提供します。

3. より多くの参加者を引き付けるために、より柔軟なステーキングオプションを提供します。

4. ネットワーク内の冗長なバリデーターを削減し、P2Pメッセージの数を減らします。

5. ビーコンステートのメモリの使用量を削減し、システムの効率を向上させます。

6. 実行層の部分的な引き出しメカニズムの強化と併せて、イーサリアムネットワーク全体の流動性をさらに最適化します。

EIP-7549：委員会指数を証明から移動します

提案は、同じコンセンサス投票の集約を達成するために、署名された証明メッセージから委員会のインデックスフィールドを削除することを推奨しています。この変更の主な目標は、コンセンサスルールの検証に必要なペアの平均数を減らすことにより、キャスパーFFGクライアントの効率を高めることです。あらゆるタイプのクライアントがこの改善から恩恵を受けることができますが、この変更は、キャスパーFFGのコンセンサスを証明する必要があるZKサーキットの最も重要なパフォーマンス改善につながる可能性があります。

EIP-7685：一般的な実行レイヤーリクエスト

この提案は、スマートコントラクトによってトリガーされるリクエストを保存および処理するための共通のフレームワークを定義します。具体的な実装は、各実行ヘッダーとボディにフィールドを追加してリクエスト情報を保存することで、これらの要求をコンセンサスレイヤーに公開し、各要求を処理できるようにします。このメカニズムは、主にスマート契約制御のバリデーターの需要の増加に対処し、将来より複雑なオンチェーン相互作用の基盤を提供するために設計されています。

EIP-7702：トランザクションのEOAアカウントコードを設定します

Vitalik Buterin et alが提案したEIP-7702この提案では、外部所有のアカウント（EOA）が認証メカニズムを介してアカウントコードを設定できるようにする新しいタイプのトランザクションを導入します。この改善は、いくつかの新機能をサポートしています。

1. バッチ操作：EOAが同じトランザクションで複数の操作を実行して、効率を向上させることができます。

2. 支払い取引：第三者が取引手数料を支払うための利便性を提供します。

3. 許可ダウングレード：アカウントのセキュリティと柔軟性を高めます。

新しいトランザクション構造を採用することにより、この提案はEOAの機能と可用性を向上させるだけでなく、将来のアカウント抽象化テクノロジーに適した互換性とスケーラビリティを提供します。

結論

ペクトラのアップグレードには顕著な主な目標はありませんが、一連の技術的改善と最適化を通じて、イーサリアムネットワークの機能、セキュリティ、効率性がさらに向上します。アップグレード計画が進むにつれて、より多くのEIPが組み込まれたり調整されたりすることがあります。