Pectraアップグレードに含まれることが決定したEIPはどれですか？ETHのインフレを悪化させますか？
TechFlow厳選深潮セレクト
Pectraアップグレードに含まれることが決定したEIPはどれですか？ETHのインフレを悪化させますか？
確定済みのEIPは、アカウントのプログラマビリティ、イーサリアムの検証効率、ステーキングの最適化などを向上させる。未確定のEIPは、L2スケーラビリティの向上方法に焦点を当てている。
Web3業界の深掘り報道に専念し潮流を洞察執筆：0XNATALIE
イーサリアムの次回アップグレード「Pectra」は、Prague（プラハ）とElectra（エレクトラ）を組み合わせた名称に由来する。
「Prague」は実行層（Execution Layer）のアップグレードを意味し、Devcon 4が開催された都市プラハにちなんで名付けられた。一方、「Electra」はコンセンサス層（Consensus Layer）のアップグレードを象徴し、星の名前をアルファベット順に採用するという慣例に従い、「E」に対応する星の名前であるElectraが選ばれた。
Pectraアップグレードは、イーサリアム史上最多のEthereum Improvement Proposals（EIP）を含むハードフォークの一つとなる可能性がある。これはバリデーター操作やメインネット性能向上のための複数の提案に加え、L2最適化のための提案も導入するものだ。現在、Pectra Devnet 4テストネットが立ち上がった段階で、すでに8つのEIPがPectraアップグレードに正式に含まれることが確定している。
確定したEIPおよびその影響
これらの8つのEIPは、ユーザーに対して以下のような影響を持つ。EOAにコード実行能力を追加することでアカウントの柔軟性を高め、より複雑な操作を可能にする。また、ステーキング上限の引き上げによりETH需要が増加する可能性がある。さらに、バリデータープロセスの最適化によって安全性と効率性が向上し、イーサリアムの速度とスループットが改善される。
-
EIP-2537（BLS署名のサポート）：一連のプリコンパイル契約（precompiles）を導入し、BLS12-381曲線演算をイーサリアム上でサポートする。これによりBLS署名の検証が可能となり、複数の署名を1つに集約できるようになるため、検証時の計算量を削減できる。BLS署名は暗号学的手法であり、小さな署名サイズと署名集約機能を提供する。これは多数の署名検証やデータ検証を行うL2の運用をより効率化するのに貢献する。
-
EIP-2935（状態内での履歴ブロックハッシュ保存）：最近8192個のブロックハッシュをシステムコントラクト内に保存することで、ステートレスクライアント（Stateless Clients）モデルを支援し、履歴ブロックハッシュの柔軟な照会機能を提供する。これらのハッシュ値はコントラクトから直接照会でき、証明（witness）としてバンドルされ、ステートレスクライアントに提供される。クライアントは完全なブロックチェーン履歴を保持したり大量のデータを保存したりする必要がなくなり、状態に保存されたブロックハッシュと関連証明に依存して、ブロックやトランザクションの正当性を検証できる。
-
EIP-6110（オンチェーンでのバリデーター預け入れ処理）：バリデーターの預け入れ処理をコンセンサス層から実行層に移行し、オンチェーンで処理・検証を行う。これにより、コンセンサス層における追加の投票メカニズムによる預け入れ情報の有効性確認が不要になり、預け入れプロセスの安全性が強化され、遅延が減少するとともに、コンセンサス層およびクライアント設計の簡素化が図られる。
-
EIP-7002（実行層からの退出トリガー）：引き出し資格を持つ所有者が、バリデーターのアクティブキー（BLSキー）に依存せず、独自に退出を開始できるようにする。現在はバリデーターのアクティブキーのみが退出をトリガーできるため、アクティブキーを紛失した場合や、第三者（ステーキングサービスプロバイダーなど）に検証作業を委託している場合は、実際の資金所有者（引き出し資格所有者）がステークされたETHを自主的に制御できない。このEIPでは、実行層を通じてETHの退出および引き出し操作をトリガー可能にし、所有者は引き出し資格を使ってアクティブキーに依存せずに退出を開始できる。
-
EIP-7251（ステーキング上限の引き上げ）：バリデーターの最大有効残高を引き上げることで、各バリデーターが32 ETHを超えるETHをステーキングできるようにする（最低ステーキング要件は引き続き32 ETH）。大規模ノード運営者が複数のバリデーターを統合することで、ネットワーク内のバリデーター総数を削減し、P2Pメッセージ数、署名集約量、ストレージ負荷を低減することを目指す。
-
EIP-7549（証明から委員会インデックスを削除）：Attestation（証明）メッセージから委員会インデックスフィールドを除外することで、より効率的なコンセンサス投票集約を実現する。現在のイーサリアムコンセンサスメカニズムでは、各バリデーターの投票にはLMD GHOST投票（ブロックルートとスロットを含む）、Casper-FFG投票（ソースとターゲット情報を含む）、委員会インデックス（バリデーターが所属する委員会番号）が含まれる。署名メッセージに委員会インデックスが含まれるため、同じ内容の投票であっても生成される署名ルートが異なり、これらを簡単に集約できない。委員会インデックスを署名対象外にすることで、より効率的な投票集約が可能となり、検証コストとネットワークロードの両方を削減できる。
-
EIP-7685（汎用実行層リクエスト）：スマートコントラクトによってトリガーされるリクエストを保存・処理するための、実行層（EL）向け汎用フレームワークを定義する。このフレームワークにより、実行層でトリガー可能な動作の種類が増え、異なるタイプのリクエストを統一的に処理できるようになり、新しいリクエストタイプの追加が容易になる。実行ブロック構造の変更を伴わない。
-
EIP-7702（EOAへのコード実行機能付与）：外部所有アカウント（EOA）にコード実行機能を追加し、アカウントの柔軟性とプログラマビリティを高める。EOAは署名によって特定のスマートコントラクトに代理操作（例えば一括取引や権限管理）を委任できる。これにより、EOA自身をスマートコントラクトアカウントに変換することなく、ある程度のスマートコントラクト機能を利用できるようになる。
検討中の主要EIP
以下は現在積極的に検討されているEIP群であり、主にblobの最適化を通じて、L2のデータ公開における料金安定性を向上させ、L2の取引処理能力を強化し、L2コストを効果的に削減するものである。また、calldataコストの調整により、ETHのバーン量に影響を与え、ETHのインフレ圧力を高める可能性もある。
-
EIP-7742（コンセンサス層と実行層間のblob数依存の解除）：コンセンサス層と実行層間のblob数の結合を解除し、blob検証プロセスを簡素化することで、不要な複雑性を排除し、プロトコルの拡張性と柔軟性を向上させる。現在のプロトコルでは、実行層とコンセンサス層の両方にblobの最大値がハードコードされており、冗長な検証が発生している。この提案では、実行層によるblob最大値の検証を取りやめ、代わりにコンセンサス層が動的に実行層にblob目標値を提供する方式に変更する。これにより、将来のスケーリングニーズに応じてblob目標パラメータを柔軟に調整できるようになる。EIP-7742は、アップグレードに含める検討対象の中で最も議論の少ない提案であり、最新のコンセンサス層会議では、開発者たちがPectra-devnet 5での実装を開始することで合意した。ただし、正式に採用されるかどうかは、実行層の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だが、rollupなどのアプリケーションによる大量のデータ公開により、平均ブロックサイズが継続的に増加している。データ可用性（DA）取引で主に使用されるcalldataのコストを引き上げることで、ブロックの最大サイズを約0.72MBまで削減し、今後のブロックGas制限の拡大やより多くのblob導入の余地を確保する。一般ユーザーの取引コストは変わらないが、この変更はイーサリアムを大規模データストレージに利用する取引タイプに主に影響を与える。一方で、calldataコストの引き上げにより、イーサリアムのデータストレージ分野での競争力が低下する可能性がある。また、calldataコストの上昇により取引数が減少し、EIP-1559メカニズムによるETHバーン量も減少するため、ETHに対するインフレ圧力が高まる。
-
EIP-7782（slot時間の短縮）：イーサリアムのslot時間を12秒から8秒に短縮し、より頻繁にブロックを生成することでより多くの取引を処理できるようにする。これはblob数の増加に代わるスループット向上策として提案されている。しかし、12秒のslot時間をハードコードしているスマートコントラクトが破壊される可能性があり、また、ステートの肥大化問題を加速させ、ストレージおよび計算負荷を増加させる恐れがある。
-
EIP-7783（ブロックGas制限の段階的増加）：EIP-7782のより穏やかな代替案として、ブロックのgas制限を動的に調整しながら段階的に増加させ、各ブロックが収容できる取引数を徐々に増やすことで、ネットワークの処理能力を高める。直接slot時間を短縮するよりも、gas制限の段階的調整はネットワークのスケーリングをよりスムーズに行える。この提案はハードフォークを必要としないが、ステートデータに影響を与える可能性がある。
Pectraアップグレードには多数のEIPが含まれるため、単一アップグレードの複雑性を低減し、一部EIPの早期導入を促進するため、5月にイーサリアム財団のエンジニアチームEthPandaOpsがPectraを2分割する案を提案した。しかし当時はアップグレードの遅延を懸念し、真剣に検討されなかった。9月になり、イーサリアム研究者のAlex Stokesが再び分割案を提唱し、今度は開発者の支持を得た。この分割により、6ヶ月以内に第1段階のアップグレードを完了できる可能性がある：
-
第1段階：Pectra Devnetテストネットですでに稼働しているEIP（つまり、すでに確定した8つのEIP）を含む。これらは比較的実装が容易であり、既に十分なテストを経ている。
-
第2段階：PeerDASやEOF関連の提案など、より複雑なEIPや、さらなるテスト期間を要する他の提案を後回しにする。これらの提案はさらなる開発、監査、テストが必要であり、特にコンセンサス層と実行層の協調を要するものは慎重に扱われる必要がある。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@ChainFeedsxyz
