PectraアップグレードにはどのEIPが含まれることが確定していますか？ETHのインフレをさらに悪化させる可能性はありますか？

確定されたEIPはアカウントのプログラマビリティ、Ethereumのバリデータ効率およびステーキング最適化などを向上させ、未確定のEIPはL2のスケーラビリティ向上に焦点を当てています。

執筆：0XNATALIE

Ethereumの次回アップグレード「Pectra」は、PragueとElectraの組み合わせに由来しています。

Pragueは実行レイヤーのアップグレードを表し、Ethereum開発者カンファレンス（Devcon 4）が開催された都市プラハにちなんでいます。一方、Electraはコンセンサスレイヤーのアップグレードを象徴し、アルファベット順に星の名前が付けられています。今回選ばれた星名Electraはアルファベット「E」に対応しています。

Pectraアップグレードは、Ethereum史上最も多くのEthereum Improvement Proposals（EIP）が含まれる可能性のあるハードフォークであり、バリデータの操作やメインネットのパフォーマンス向上に関する一連の提案だけでなく、L2最適化の提案も導入されます。Pectra Devnet 4テストネットが立ち上がったばかりで、現在8つのEIPがPectraアップグレードに含まれることが確定しています。

確定しているEIPおよびその影響

これら8つのEIPがユーザーに与える影響は、EOAにコード実行能力を追加することでアカウントの柔軟性を高め、より複雑な操作が可能になること、ステーキング上限の引き上げによりETH需要が増加する可能性があること、またバリデータのプロセス最適化によりセキュリティと効率が向上し、Ethereumの速度とスループットが高まることです。

1. EIP-2537（BLS署名のサポート）：一連のプリコンパイルコントラクト（precompiles）を導入することで、EthereumにBLS12-381曲線演算のサポートを追加し、BLS署名検証を実現、複数の署名を1つの署名に集約できるようになり、検証時の複雑さを軽減します。BLS署名は小さな署名を生成し、署名集約をサポートする暗号アルゴリズムです。大量の署名検証やデータ検証操作が必要なL2の運用に役立ちます。
2. EIP-2935（状態における過去ブロックハッシュの保存）：直近8192個のブロックハッシュをシステムコントラクトに保存し、Stateless Clientsモデルをサポート、より柔軟な過去ブロックハッシュのクエリ機能を提供します。これらのハッシュ値はコントラクトから直接クエリでき、証明（witness）としてStateless Clientsに提供されます。クライアントは完全なブロックチェーン履歴や大量データを自分で保持する必要がなく、状態に保存されたブロックハッシュと関連証明に依存するだけでブロックやトランザクションの正当性を検証できます。
3. EIP-6110（オンチェーンでのバリデータデポジット提供）：バリデータデポジットの処理をコンセンサスレイヤーから実行レイヤーに移し、オンチェーンで処理・検証を行うことで、コンセンサスレイヤーの追加投票メカニズムに依存せずデポジット情報の有効性を確認します。これによりデポジットプロセスのセキュリティが強化され、処理遅延が減少し、コンセンサスレイヤーとクライアント設計が簡素化されます。
4. EIP-7002（実行レイヤーによる退出トリガー）：引き出し証明書の所有者が独立して退出を開始できるようになり、バリデータのアクティブキー（BLSキー）に依存する必要がなくなります。現在はバリデータのアクティブキーのみが退出をトリガーできますが、アクティブキーを紛失した場合や、バリデータが検証作業を第三者（ステーキングサービスプロバイダーなど）に委託した場合、引き出し証明書の所有者（資金の実際の所有者）はステーキングしたETHを自律的にコントロールできません。この提案により、実行レイヤーでETHの退出と引き出し操作をトリガーでき、所有者は引き出し証明書で退出を開始できるようになります。
5. EIP-7251（ステーキング上限の引き上げ）：バリデータの最大有効残高を増やし、各バリデータが32ETHを超えるステーキングを保持できるようにします（最低ステーキング基準は32ETHのまま）。これにより大規模ノード運営者が複数のバリデータを統合し、ネットワーク内のバリデータ数を減らし、P2Pメッセージ、署名集約、ストレージ負担を軽減します。
6. EIP-7549（コミッティインデックスをアテステーションから分離）：コミッティインデックスフィールドをAttestation（証明）メッセージから分離し、より効率的なコンセンサス投票集約を実現します。現在のEthereumコンセンサスメカニズムでは、各バリデータの投票にはLMD GHOST投票（ブロックルートとスロットを含む）、Casper-FFG投票（ソースとターゲット情報を含む）、コミッティインデックス（バリデータが属するコミッティ番号）が含まれます。コミッティインデックスが署名メッセージに含まれているため、複数のバリデータが同じブロックに投票しても、投票内容が同じでも生成される署名ルートが異なり、投票の集約が困難です。コミッティインデックスフィールドを署名メッセージ本体から分離することで、より効率的な投票集約が可能となり、検証コストとネットワーク負荷が削減されます。
7. EIP-7685（汎用実行レイヤーリクエスト）：実行レイヤー（EL）向けに、スマートコントラクトによってトリガーされるリクエストの保存と処理のための汎用フレームワークを定義します。このフレームワークは、より多くの実行レイヤートリガー動作をサポートし、異なるタイプのリクエストを統一的に処理できるようにし、新しいリクエストタイプの追加を簡素化します（実行ブロック構造の変更不要）。
8. EIP-7702（EOAにコード実行能力を追加）：外部所有アカウント（EOA）にコード実行機能を追加し、アカウントの柔軟性とプログラマビリティを強化します。EOAは署名による認可方式で、特定のスマートコントラクトに一部操作（バッチトランザクションや権限管理など）の代理実行を指定できます。スマートコントラクトアカウントに変換することなく、一定のスマートコントラクト機能を持つことができます。

重点的に検討されているEIP

以下は現在積極的に検討されているEIPであり、主にblobの最適化を通じてL2データ公開の手数料安定性を高め、L2のトランザクション処理能力を強化し、L2コストを効果的に削減します。また、calldataコストの増加調整はETHのバーン量に影響し、ETHのインフレ圧力を高める可能性があります。

• EIP-7742（コンセンサスレイヤーと実行レイヤー間のblobカウント依存解除）：コンセンサスレイヤーと実行レイヤー間のblob数の結合を解消し、blob検証プロセスを簡素化し、不要な複雑さを減らし、プロトコルの拡張性と柔軟性を高めます。現行プロトコルでは、実行レイヤーとコンセンサスレイヤーの両方でblobの最大値がハードコードされており、冗長な検証が発生しています。本提案では、実行レイヤーによるblob最大値の検証を廃止し、コンセンサスレイヤーが動的にblobターゲット値を実行レイヤーに提供します。これにより、blobターゲットパラメータを柔軟に調整でき、将来のスケーリングニーズに対応可能となります。EIP-7742はアップグレードに含めるEIPリストの中で最も議論が少ない提案であり、最新のコンセンサスレイヤーミーティングでは、開発者がpectra-devnet 5でEIP-7742の実装を開始することに同意しましたが、正式に含まれるかどうかはACDE（All Core Developers Execution Layer Meeting）での実行レイヤーのフィードバックを待つ必要があります。
• EIP 7762（最低blob基礎手数料）：MIN_BASE_FEE_PER_BLOB_GASを引き上げ、blob価格が適正水準に調整されるまでの時間を短縮することを目的としています。現在、最低blob基礎手数料は1weiに設定されており、blob需要が供給を上回る場合、価格発見プロセス（適正なblob Gas価格の決定）が非常に遅く、適正な手数料水準に達するまでに長い時間がかかります。最低blob基礎手数料を引き上げることで、価格調整の時間を短縮し、市場均衡をより早く実現し、需要ピーク時にもネットワークの安定性を維持できます。
• EIP-7623（calldataコストの増加）：トランザクション内のcalldataコストを引き上げ、ブロックの最大サイズとその変動範囲を縮小し、ネットワークがより安定してトランザクションを処理できるようにします。現状、ブロック最大サイズは約1.79MBですが、rollupsなどのアプリケーションによる大量データ公開により、平均ブロックサイズが増加し続けています。主にデータ可用性（DA）トランザクションに使用されるcalldataコストを引き上げることで、ブロック最大サイズを約0.72MBに削減し、将来的なブロックGasリミット増加やより多くのblob追加の余地を確保します。一般ユーザーのトランザクションコストは変わらず、この変更は主にEthereumを大規模データストレージに利用するトランザクションタイプに影響します。ただし、calldataコストの増加はEthereumのデータストレージ競争力を低下させる可能性があります。また、calldataコスト増加によりトランザクション数が減少し、EIP-1559メカニズムによるETHのバーン量も減少し、ETHのインフレ圧力が高まる可能性があります。
• EIP 7782（slot時間の短縮）：Ethereumのslot時間を12秒から8秒に短縮し、より頻繁にブロックを生成して多くのトランザクションを処理できるようにし、blob数増加の代替案とします。これによりトランザクションスループットが向上しますが、12秒slot時間をハードコードしている一部のスマートコントラクトに影響を与え、Ethereumの状態膨張問題を加速させ、ストレージや計算負担を増加させる可能性があります。
• EIP-7783（段階的なブロックGasリミット増加）：EIP-7782のより穏やかな代替案として、ブロックのgasリミットを動的に調整し、各ブロックに含められるトランザクション数を段階的に増やすことで、ネットワークの処理能力を高めます。slot時間を直接短縮するよりも、gasリミットを段階的に調整することでネットワークの拡張がよりスムーズになります。この提案はハードフォークを必要としませんが、状態データに影響を与える可能性があります。

Pectraアップグレードは多数のEIPを含むため、単一アップグレードの複雑さを軽減し、一部EIPのリリースを加速するために、5月にEthereum FoundationのエンジニアチームEthPandaOpsがPectraを2つの部分に分割することを提案しましたが、当時はアップグレードの遅延が懸念され、真剣に検討されませんでした。9月にEthereumリサーチャーのAlex Stokesが再度分割提案を行い、今回は開発者の賛同を得ました。この分割により、6か月以内にアップグレードの第1部を完了できる見込みです：

• 第1部：すでにPectra Devnetテストネットで稼働しているEIP（すなわち確定した8つのEIP）を含み、これらは比較的実装が容易で、多くのテストを通過しています。
• 第2部：より複雑なEIP（PeerDAS、EOF関連の提案など）や、さらなる開発・監査・テストが必要な提案を第2段階に分けます。特にコンセンサスレイヤーと実行レイヤーの協調が必要な提案が含まれます。