イーサリアムの近づくハードフォークを解析：Pectraアップグレード
TechFlow厳選深潮セレクト
イーサリアムの近づくハードフォークを解析：Pectraアップグレード
プラハ /Electra（Pectra）アップグレードは2025年3月に予定されています。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Sergey Boogerwooger、Dmitry Zakharov、MixBytes
翻訳：AI 翻訳官、登録チェーンコミュニティ
はじめに
以前の記事では、イーサリアム検証者のライフサイクルについて詳細に振り返り、迫り来るElectraハードフォークに関連するいくつかの側面について議論しました。現在は、間近に迫ったElectraおよびPragueアップグレードにおける変更点に注目し、それらを詳しく説明する時期です。
イーサリアム2.0「プルーフ・オブ・ステーク（PoS）」への移行というハードフォークの歴史は複雑です。それは既存の実行レイヤーにビーコンレイヤーを追加することから始まり、実行レイヤーが依然としてプルーフ・オブ・ワーク（PoW）を維持している一方で、ビーコンレイヤー上でプルーフ・オブ・ステーク合意が開始されました（Phase0およびAltairハードフォーク）。次に、BellatrixハードフォークでPoSが完全にアクティブ化されましたが（引き出し機能はまだ有効になっていませんでした）。その後、Capellaハードフォークにより引き出しが可能になり、検証者ライフサイクルが完結しました。最近のDenebハードフォーク（Dencun（Deneb/Cancun）アップグレードの一部）では、証明のタイムウィンドウ、自発的退会処理、検証者交換制限など、ビーコンチェーンパラメータに対して小幅な修正が行われました。Dencunでの主な変更は実行レイヤーで発生し、blobトランザクション、blobガス、blob用のKZGコミットメントの導入、およびSELFDESTRUCT操作の廃止が含まれます。
現在、Prague/Electra（すなわちPectra）ハードフォークは、実行レイヤーとコンセンサスレイヤーに重要なアップグレードをもたらします。Lidoプロジェクトの監査担当者として、我々はこのハードフォークにおけるコンセンサスおよびステーキング関連の変更に特に注目しています。しかし、Pragueの実行レイヤーにおける変更も無視することはできず、これらにはイーサリアムネットワークおよび検証者に影響を与える重要な機能が含まれています。これらの変更の詳細を見てみましょう。
Pectraのハイレベル概要
Electraはビーコンレイヤーに多数の新機能を導入します。主な更新内容は以下の通りです。
-
検証者の有効残高を32～2048 ETHの範囲で変動可能にする（従来の固定32ETHではなく）。
-
検証者が第2の「引き出し」資格情報を使って退会を開始できるようにする（アクティブ検証者キーは不要）。
-
ビーコンレイヤーがEth1預入を処理する方法を変更する（預入コントラクトからのイベント解析をやめる）。
-
通常のEth1コントラクトからのリクエストをビーコンレイヤー上で処理するための新しい汎用フレームワークを追加する（Electra以前の預入管理方式と類似）。
一方、Pragueは実行レイヤーに以下の変更をもたらします。
-
zkSNARK証明の検証をサポートするためにBLS12-381曲線を使用する新しいプリコンパイルコントラクト（一般的なBN254曲線に加えて）。
-
最大8192個の履歴ブロックハッシュを保存・アクセスできる新しいシステムコントラクト（ステートレスクライアントにとって非常に有用）。
-
calldataのガスコストを増加させ、ブロックサイズを削減し、rollupなどのcalldata集中型操作をDencunで導入されたblobsへ移行するよう促進する。
-
Eth1ブロックあたりのblob数を増加させ、その数を読み取るAPIを提供する。
-
EOA（外部所有アカウント）が独自のアカウントコードを持つことを許可し、multicallの実行や他のアドレスへの実行委任など、EOAが実行可能な操作を大幅に拡張する。
さらに議論するために、関連するイーサリアム改善提案（EIP）を参照しましょう。
-
EIP-7251: MAX_EFFECTIVE_BALANCEの増加
-
EIP-7002: 実行レイヤーによるトリガー可能な退会
-
EIP-6110: チェーン上での検証者預入提供
-
EIP-7549: 証明からの委員会インデックスの移動
-
EIP-7685: 汎用実行レイヤーリクエスト
-
EIP-2537: BLS12-381曲線演算のプリコンパイル
-
EIP-2935: ステート内での履歴ブロックハッシュの保存
-
EIP-7623: calldataコストの増加
-
EIP-7691: blobスループットの増加
-
EIP-7840: ELプロファイルへのblobスケジューリングの追加
-
EIP-7702: EOAアカウントコードの設定
これらのEIPのうち、一部は主にコンセンサス（ビーコン）レイヤーに関係し、他は実行レイヤーに関係しています。また、預入や引き出しのような操作はコンセンサスレイヤーと実行レイヤーの両方で同期的に変更が必要となるため、二つのレイヤーを跨ぐものもあります。このような相互依存性があるため、ElectraとPragueを分けることは非現実的であり、それぞれのEIPを順番に見ていき、各ケースで影響を受けるイーサリアムコンポーネントを特定します。
EIP-7251: MAX_EFFECTIVE_BALANCEの増加
参考: EIP-7251
最初のPhase0ハードフォーク以来、イーサリアムのプルーフ・オブ・ステーク準備のため、Electra以前まで検証者の最大有効残高は固定で32ETHでした。検証者をアクティブ化するには、最低でもspec.min_activation_balance（32ETH）が必要です。アクティブ化後、検証者はこの最大有効残高からスタートしますが、spec.ejection_balance（16ETH）まで有効残高を減らすことができ、そのしきい値に達すると追い出されます。この「最小」ロジックはElectraでも変わりませんが、現在spec.max_effective_balanceは2048ETHまで引き上げられています。したがって、検証者は32～2048ETHの範囲で預入してアクティブ化でき、すべての金額が有効残高に寄与します。この変化は、「32ETH-プルーフ・オブ・ステーク」から真の「プルーフ・オブ・ステーク」への移行を象徴しています :)
この変動可能な有効残高は今後以下に使用されます。
-
有効残高に比例して、ブロック作成者になる確率を増加させる
-
有効残高に比例して、同期委員会メンバーになる確率を増加させる
-
相対的なスラッシングおよび非アクティブ罰則の計算基準として使用される
前2つの活動は検証者にとって最も報酬の高い操作です。したがって、Electra以降、大規模ステーキングを行う検証者は、有効残高に比例してより頻繁にブロック提案および同期委員会に参加します。
もう一つの影響はスラッシングに関係しています。すべてのスラッシングペナルティは検証者の有効残高に比例します。
-
「即時」と「遅延」のスラッシングペナルティは、大規模ステーキング検証者にとってより大きくなる。
-
大規模ステーキングをしているスラッシング対象検証者と一緒にいる場合の「遅延」スラッシングペナルティも大きくなる。なぜなら、総ステーク中の「スラッシング」部分がより大きくなるため。
-
有効残高が高い検証者を報告した通報者は、スラッシングされたステークのより大きな割合を得る。
Electraはまた、スラッシング比率の変更も提案しており、これはスラッシングされた検証者の残高の一部を定義し、通報者が受け取ることになります。
次に無効性への影響があります。検証者がアクティブ中に（証明または提案時に）オフラインになると、無効性スコアが蓄積され、各エポックで無効性ペナルティが課されます。これらのペナルティも検証者の有効残高に比例しています。
有効残高の増加に伴い、検証者の「交換制限」も変化しています。「Electra以前」のイーサリアムでは、検証者は通常同じ有効残高を持っており、退会交換制限は「1エポック内で、総ステークの1/65536（spec.churn_limit_quotient）を超えて退会できない」と定義されていました。これにより、同じステークを持つ検証者の「固定」退出数が生まれていました。しかし、「Electra以降」では、少数の「ホエール」だけが退出する可能性があり、彼らが総ステークの重要な部分を占めるためです。
もう一つの考慮事項は、単一の検証者インスタンス上で多数の検証者キーをローテーションすることです。大規模検証者は現在、大規模ステークに対応するために数千の検証者キーを1つのインスタンス上で実行せざるを得ず、それを32ETHごとの部分に分割しています。Electra以降、この行為は強制的ではなくなります。財務的にはこの変更の影響は大きくありません。なぜなら報酬と確率はステーク額に線形にスケーリングするため、32ETHずつ100人の検証者を持つことは3200ETHの1人の検証者と同等だからです。さらに、複数のアクティブ検証者キーは同じEth1引き出し資格情報を持て、すべての報酬を1つのETHアドレスに引き出すことが可能になり、報酬統合に関連するガスコストを回避できます。ただし、多数のキーを管理することで追加の管理コストが発生します。
検証者残高を集約する能力の向上は、新たなタイプの実行レイヤーリクエストを追加します。以前は預入と引き出しがありました。今後はもう一つのタイプが加わります：集約リクエストです。これは2つの検証者を1つに結合します。この操作リクエストにはソース検証者の公開鍵とターゲット公開鍵が含まれ、預入や引き出しと同様に処理されます。集約にも保留中のリクエストと残高交換制限があり、預入や引き出しと同様です。
まとめると以下の通りです。
-
小規模な独立検証者にとって、Electraは有効残高（および報酬）を自動増加させる能力を提供します。以前は32ETHを超える余剰は引き出すしかありませんでしたが、Electra以降はこの余剰が最終的に有効残高に貢献します。ただし、有効残高はspec.effective_balance_increment（1ETH）の倍数でのみ増加するため、次の「1ETHの境界」に到達して初めて増加が発生します。
-
大規模な独立検証者にとって、Electraは複数のアクティブ検証者キーを1つに統合できるため、大幅な管理簡素化を提供します。ゲームチェンジャーではありませんが、1x2048のステークを運営することは64x32のステークを管理するよりもはるかに簡単です。
-
流動性ステーキングプロバイダーにとっては、ユーザーから小規模なステークを集め検証者間で分配するため、Electraはステーク分配スキームに柔軟性をもたらしますが、同時に固定32ETH有効残高に基づく検証者会計の根本的な再構築が必要です。
もう一つ重要な話題は、検証者の履歴データと利益推定であり、リスクとリターンを評価しようとする新規参加者にとって特に重要です。Electra以前（本稿執筆時点）、32ETH上限（最小でも最大でも事実上）は履歴データに均一性をもたらしていました。すべての検証者の有効残高、報酬、個別のスラッシングペナルティ、ブロック提案頻度、その他の指標が同一でした。この均一性により、イーサリアムは統計的異常値なしにコンセンサスメカニズムをテストし、貴重なネットワーク行動データを収集できました。
Electra以降、ステーク分布は大きく変化します。大規模検証者はブロック提案および同期委員会への参加がより頻繁になり、スラッシング時にはより大きなペナルティを受け、遅延スラッシング、アクティベーションキュー、退出キューに大きな影響を与えます。これはデータ集計において課題をもたらす可能性がありますが、イーサリアムのコンセンサスは非線形計算が最小限であることを保証しています。唯一の非線形コンポーネントはsqrt(total_effective_balance)を使用して基本報酬を計算するものであり、これはすべての検証者に適用されます。つまり、検証者の報酬とスラッシングは依然として「1ETHあたり」（あるいはより正確にはspec.effective_balance_incrementに従って、将来変更される可能性あり）で推定可能です。
詳細については、以前の検証者行動に関する記事をご覧ください。
EIP-7002：実行レイヤーによるトリガー可能な退会
参考：EIP-7002
イーサリアムの各検証者には2つの鍵ペアがあります：アクティブ鍵と引き出し鍵です。アクティブな公開BLS鍵は、検証者がビーコンチェーンにおける主要なアイデンティティとして使用され、この鍵ペアはブロック署名、証明、スラッシング、同期委員会集約、および（このEIP以前）自発的退会（遅延後に検証者のコンセンサス退会を開始する）に使用されます。第2の鍵ペア（「引き出し資格情報」）は、別のBLS鍵ペアまたは通常のEth1アカウント（秘密鍵とアドレス）のいずれかです。現在、ETHアドレスへの引き出しにはアクティブBLS秘密鍵による引き出しメッセージの署名が必要です。このEIPはこの点を変更します。
実際には、この2つの（アクティブおよび引き出し）鍵ペアの所有者は異なる場合があります。検証者のアクティブ鍵は検証責任（サーバーの実行、稼働の維持など）を担いますが、引き出し資格情報は通常、報酬を受け取り資金を管理するステーク所有者が制御しています。現在、引き出し資格情報を制御するステーク所有者は検証者の退会を開始できません。報酬の引き出しのみ可能です。この状況により、検証者のアクティブ鍵所有者は検証者の残高を「人質」のように保持することが可能になります。検証者は退会メッセージを「事前署名」してステーク所有者に渡すことができますが、この回避策は理想的ではありません。また、現在のところ引き出しと退会の両方には専用のAPIを通じてビーコンレイヤー検証者と対話する必要があります。
最良の解決策は、ステーク所有者が標準のスマートコントラクト呼び出しを通じて引き出しと退会の両方を同時に行えるようにすることです。これには標準的なEth1署名チェックが含まれ、操作が大幅に簡素化されます。
このEIPにより、ステーク所有者はETHアドレスから専用のスマートコントラクトに標準トランザクションを送信することで、引き出しと退会をトリガーできます（既存の「預入」コントラクトを使った預入手続きを類似）。引き出し（または十分なステークが除去された場合の退会）プロセスは以下の通りです。
-
ステーカーがシステムの「引き出し」コントラクトに引き出しリクエスト（「in」リクエスト）を送信する。
-
コントラクトは潜在的な悪意ある攻撃を軽減するために特定の料金（ETH）を徴収し、EIP-1559と同様にリクエストキューが混雑している場合は料金が増加する。
-
コントラクトは「in」引き出し／退会リクエストを自身のストレージに保存する。
-
ビーコンレイヤーにブロックが提案されたとき、キュー内の「in」引き出し／退会リクエストがストレージから取得される。
-
ビーコンレイヤーが「in」リクエストを処理し、アクティブ検証者の残高とやりとり、検証者の退会を手配し、「out」引き出しリクエストを作成する。
-
「out」引き出しリクエストが実行レイヤーで処理され、ステーカーがETHを受け取る。
預入はEth1ブロック内でトリガーされ、その後「保留中」預入キューを通じて「移動」してビーコンレイヤーに到達するのに対し、引き出しは異なる仕組みを採用しています。引き出しはビーコンレイヤー（CLI経由）でトリガーされ、その後Eth1ブロックに「移動」します。現在、両方の仕組みは以下で説明する同じ汎用フレームワークで動作します：Eth1レイヤーでリクエストを作成し、「保留中」預入／引き出し／統合キューを処理し、ビーコンレイヤーで処理します。引き出しのような「出力」操作の場合、出力キューも処理され、結果はEth1ブロック内で「決済」されます。
このEIPにより、ステーカーは検証者のCLIや検証者インフラに直接アクセスせずとも、通常のETHトランザクションで引き出しと退会を行えるようになります。これは特に大規模ステーキングプロバイダーにとって、ステーキング操作を大幅に簡素化します。検証者インフラはほぼ完全に隔離可能になり、アクティブ検証者鍵の維持のみが必要となり、すべてのステーキング操作は別途処理できます。これにより、独立ステーカーがアクティブ検証者の行動を待つ必要がなくなり、Community Staking ModuleのようなLidoサービスのオンチェーン外部分も大幅に簡素化されます。
したがって、このEIPはステーキング操作を「完了」し、完全にEth1レイヤーに移行することで、インフラのセキュリティリスクを大幅に低下させ、独立ステーキングの分散化を強化します。
EIP-6110：チェーン上での検証者預入供給
参考：EIP-6110
現在、預入はシステム「預入」コントラクト内のイベントによって実現されています（以前の記事で詳細に説明）。コントラクトはETHと検証者資格情報を受け取り、「Deposit()」イベントを発行し、これが後で解析されビーコンレイヤー上の預入リクエストに変換されます。このシステムには多くの欠点があります：ビーコンチェーンレイヤーのeth1dataに対する投票が必要であり、これにより顕著な遅延が発生します。さらに、ビーコンレイヤーは実行レイヤーを照会する必要があり、複雑さがさらに増します。これらの問題はEIPで詳細に議論されています。こうした多くの問題を処理せずに済むよりシンプルな方法は、指定された場所に直接Eth1ブロック内に預入リクエストを含めることです。このメカニズムは前述のEIPで説明された引き出し処理プロセスと類似しています。
このEIPで提案されている変更は有望です。eth1data処理は完全に削除され、Eth1側のイベントとビーコンレイヤー上の預入包含の間に投票や長時間の遅延（現在約12時間）が不要になります。また、預入コントラクトのスナップショットロジックも削除されます。このEIPは預入手続きを簡素化し、上述の引き出し処理スキームと整合させます。
ステーカーや検証者にとって、これらの変更により預入から検証者アクティブ化までの遅延が大幅に短縮されます。検証者がスラッシングされた場合、必要な補充もより迅速になります。
このEIPに関しては、時代遅れのロジックを削除し、プロセスを簡素化し、関係者全員にとってより良い結果をもたらす以外に言うことはありません。
EIP-7685：汎用実行レイヤーリクエスト
参考：EIP-7685
このEIPは、預入／引き出し／統合に関連する前の3つのEIPより前に提示されるべきでしたが、基礎を築いているためです。しかし、ここでは紹介することで、Eth1（実行）およびビーコン（コンセンサス）チェーンブロック（レイヤー）間で専用データを一貫して移動させる必要性の高まりを強調します。このEIPは2つのレイヤーに影響を与え、通常のETHトランザクションでトリガーされるリクエスト処理をより効率化します。現在、以下の点が観察されています。
-
Eth1ブロック内の預入イベントが「移動」され、ビーコンブロックで処理される。
-
ビーコンブロック内の引き出しリクエスト（CLI使用）が「移動」され、Eth1ブロックで処理される。
-
検証者統合の処理も必要であり、これはEth1→ビーコンリクエストである。
この3つの操作は、実行レイヤーとビーコンレイヤー間を変換する際に、さまざまなタイプのリクエストを一貫して処理する必要性を示しています。さらに、これらの操作をEth1レイヤーだけでトリガーできる能力が必要です。これにより、検証者インフラとステーキング管理インフラを分離でき、セキュリティが向上します。したがって、このようなリクエストを管理する汎用的な解決策は実用的かつ必要不可欠です。
このEIPは少なくとも3つの主要なケース（預入、引き出し、統合）のための枠組みを確立します。そのため、早期のEIPではWITHDRAWAL_REQUEST_TYPEやDEPOSIT_REQUEST_TYPEといったフィールドが導入され、現在統合は別のフィールドCONSOLIDATION_REQUEST_TYPEを追加します。さらに、このEIPはリクエスト処理の制限に関する汎用メカニズム（定数例：PENDING_DEPOSITS_LIMIT、PENDING_PARTIAL_WITHDRAWALS_LIMIT、PENDING_CONSOLIDATIONS_LIMIT）を含む可能性があります。
このフレームワークの詳細な実装の詳細はまだ利用できませんが、重要なリクエストタイプ、完全性メカニズム（例えばハッシュとマークル化リクエスト）、保留中キュー処理、レート制限などを含むでしょう。
このEIPはアーキテクチャ上の意義を持ち、Eth1が統一されたフレームワークを通じてビーコンレイヤーの重要な操作をトリガーできるようにします。エンドユーザーおよびプロジェクトにとって、これはEth1レイヤーでトリガーされたすべてのリクエストがビーコンレイヤーでより効率的に伝達・処理されることを意味します。
EIP-2537：BLS12-381曲線操作のプリコンパイル
参考：EIP-2537
深く入りたくない人は、BLS12-381のプリコンパイルを、スマートコントラクトで使えるようになった複雑な暗号「ハッシュ」操作と考えてください。興味のある方はさらに掘り下げましょう。
BLS12-381（および対応するBN-254）のような楕円曲線に対する数学的演算は現在、主に2つの目的に使われています。
-
BLS署名。ここで「ペアリング」と呼ばれる特殊な操作が署名検証に使用されます。BLS署名は検証者に広く使われており、複数の署名を1つに集約できるためです。検証者はBLS12-381曲線ベースのBLS署名に依存しています（ただし、BN254などペアリングをサポートする任意の曲線でも実装可能です）。
-
zkSNARK証明の検証。ここでペアリングは証明検証に使用されます。さらに、Dencunハードフォークで導入された大容量データのKZGコミットメントも、ブロックコミットメントを検証するためにペアリングを使用しています。
スマートコントラクト内でBLS署名やzkSNARK証明を検証したい場合、これらの「ペアリング」を計算する必要がありますが、これは計算量的に非常に高価です。イーサリアムにはすでにBN254曲線操作用のプリコンパイルコントラクト（EIP-196およびEIP-197）があります。しかし、現在はより安全で広く使われているBLS12-381曲線は、プリコンパイルとして実装されていません。このようなプリコンパイルがない場合、スマートコントラクト内でペアリングや他の曲線操作を実装するには大量の計算（ ここ を参照）が必要になり、巨大なガスを消費します（約~10^5〜10^6 gas）。
このEIPは、BLS12-381曲線ベースの安価なBLS署名検証を可能にする多くの潜在的用途の扉を開きます。これにより、さまざまな目的のためのしきい値スキームの実装が可能になります。前述の通り、イーサリアム検証者はすでにBLS12-381ベースの署名を使用しています。このEIPにより、標準スマートコントラクトは今後、集約された検証者署名を効率的に検証できます。これにより、コンセンサス証明やクロスネットワーク資産ブリッジが簡素化され、BLS署名はブロックチェーンで広く使用されているためです。しきい値BLS署名自体は、投票、分散型乱数生成、マルチシグなどに多くの効率的なしきい値スキームの構築を可能にします。
より安価なzkSNARK証明検証は、逆に大量のアプリケーションを解放します。多くのzkSNARKベースのソリューションは現在、高い証明検証コストのために妨げられており、特定のプロジェクトが事実上非現実的になっています。このEIPはこれを変える可能性を持っています。
EIP-2935：ステート内での履歴ブロックハッシュの保存
参考：EIP-2935
このEIPは、8192個（約27.3時間）の履歴ブロックハッシュをブロックチェーンステートに保存し、ステートレスクライアント（rollupなど）およびスマートコントラクトに拡張された履歴を提供することを提案しています。BLOCKHASHオペコードの現在の動作を維持し、256ブロックまでの制限を維持しつつ、履歴ハッシュの保存・取得に特化した新しいシステムコントラクトを導入することを提案しています。このコントラクトは実行レイヤーでブロックを処理するときにset()操作を実行します。get()メソッドは誰でもアクセスでき、リングバッファから必要なブロックハッシュを取得できます。
現在、EVM内で履歴ブロックハッシュを参照することは可能ですが、アクセスは直近256ブロック（約50分）に制限されています。しかし、古いブロックデータにアクセスすることが極めて重要な場合があります。特にクロスチェーンアプリケーション（以前のブロックデータを証明する必要がある）や、定期的に過去のブロックハッシュにアクセスする必要があるステートレスクライアントにとって重要です。
このEIPは、rollupおよびクロスチェーンアプリケーションが利用可能な時間範囲を拡張し、EVM内で直接履歴データにアクセスできるようにすることで、外部での収集を不要にします。これにより、これらのソリューションはより堅牢で持続可能になります。
EIP-7623：calldataコストの増加
参考：EIP-7623
calldataのコストはトランザクションペイロードの利用可能なサイズを調整し、場合によっては非常に大きくなることがあります（たとえば、大きな配列やバイナリバッファを引数として渡す場合）。大きなcalldata使用は主にrollupに起因しており、rollupは現在のrollup状態を含むcalldataでペイロードを送信します。
大規模で証明可能なバイナリデータをブロックチェーンに導入することは、rollupにとって極めて重要です。Dencun（Deneb-Cancun）アップグレードは、このようなユースケースに重要な革新を導入しました――blobトランザクション（EIP-4844）。blobトランザクションは専用の「blob」ガス料金を持ち、本体は一時的に保存されますが、その暗号証明（KZGコミットメント）はそのハッシュとともにコンセンサスレイヤーに統合されます。したがって、calldataにデータを保存するよりも、blobはrollupにとって優れたソリューションを提供します。
rollupがデータをblobに移行するよう促すには、「ニンジンとムチ」アプローチが有効です。低下したblobガス料金が「ニンジン」であり、このEIPはcalldataコストを増加させることで「ムチ」として機能し、トランザクション内の過剰なデータ保存を抑制します。このEIPは次のEIP-7691（blobスループットの増加）を補完します。EIP-7691は1ブロックあたりのblob最大数を引き上げます。
EIP-7691：blobスループットの増加
参考：EIP-7691
以前のDencunハードフォークでblobが導入され、当初の「1ブロックあたり」のblobの最大値と目標値は控えめな見積もりでした。これは、p2pネットワークが検証者ノード間で大型バイナリオブジェクトをどのように扱うかを予測するのが難しいためです。以前の構成は良好に機能しており、新しい値をテストする適切なタイミングです。以前、1ブロックあたりの目標／最大blob数は3／6に設定されていました。これらの制限は現在、それぞれ6／9に引き上げられます。
以前のEIP-7623（calldataコストの増加）と組み合わせることで、この調整はさらにrollupがデータをcalldataからblobsに移行するよう促進します。最適なblobパラメータの探索は続いています。
EIP-7840：ELプロファイルへのblobスケジューリングの追加
参考：EIP-7840
このEIPは、前述の1ブロックあたりの目標および最大blob数、およびbaseFeeUpdateFraction値をイーサリアム実行レイヤー（EL）プロファイルに追加することを提案しています。また、クライアントがノードAPIを通じてこれらの値を取得できるようにします。この機能は、blobガス料金の見積もりなどのタスクに特に有用です。
EIP-7702：EOAアカウントコードの設定
参考：EIP-7702
これは非常に重要なEIPであり、イーサリアムユーザーに大きな変化をもたらします。ご存知の通り、EOA（外部所有アカウント）はコードを持てず、トランザクション署名（tx.origin）を提供できます。一方、スマートコントラクトはバイトコードを持ちますが、「それ自身」の直接署名を主動的に提出できません。現在、追加的・自動的・検証可能なロジックを必要とするユーザーインタラクションは、必要な操作を実行する外部コントラクトを呼び出すことでしか実現できません。しかし、この場合、外部コントラクトが後続コントラクトのmsg.senderになり、「ユーザーではなくコントラクトからの呼び出し」となります。
このEIPは新しいSET_CODE_TX_TYPE=0x04トランザクションタイプを導入します（以前は旧式の0x1トランザクション、ベルリンおよびEIP-1559アップグレードで導入された新しい0x02トランザクション、Dencunで導入された0x03 blobトランザクションがありました）。この新しいトランザクションタイプにより、EOAアカウントにコードを設定できます。実際には、EOAが「自身のEOAアカウントの文脈内で」外部コードを実行できるようにします。外側から見ると、トランザクション中、EOAはあたかも外部コントラクトのコードを「借用」して実行しているように見えます。技術的には、EOAアドレスの「コード」ストレージに特別な認可データタプルを追加することで実現します（このEIP以前、この「コード」ストレージはEOAに対して常に空でした）。
現在、このEIPが提案する新しい0x04トランザクションタイプは以下の配列を含みます。
authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
各要素は、指定されたアドレスのコード（最後の有効な認可項目から）を使用することをアカウントに許可します。このようなトランザクションを処理する際、指定されたEOAのコードは特別な0xef0100 || アドレス値（23バイト）に設定されます。ここでアドレスは必要なコードを持つコントラクトを指し、||は連結を表し、0xef0100は通常のスマートコントラクトが含めることができない特別なマジック値（EIP-3541に従う）です。このマジック値により、このEOAが通常のコントラクトと見なされたり、通常のコントラクトのように呼び出されたりしないことが保証されます。
このEOAがトランザクションを開始するとき、指定されたアドレスがこのEOAの文脈内で対応するコードを呼び出すために使用されます。このEIPの完全な実装の詳細はまだ明らかではありませんが、重大な変化をもたらすことは確かです。
主な影響の一つは、EOAから直接マルチコール（multicall）ができることです。マルチコールはDeFiにおける継続的なトレンドであり、多くのプロトコルが強力なツールとしてこの機能を提供しています（例：Uniswap V4、Balancer V3、Euler V2）。このEIPにより、今後EOAから直接マルチコールが可能になります。
たとえば、この新機能はDeFiにおけるよくある問題——approve() + anything()に2つの独立したトランザクションが必要な非効率性——を解決します。このEIPにより、approve(X) + deposit(X)を単一のトランザクションで完了できる汎用的な「事前承認」ロジックが可能になります。
EOAを代表してトランザクション実行を委任できるもう一つの利点はスポンサーシップの概念です。スポンサーシップは新規ユーザーがイーサリアムに入るために頻繁に議論され、強く望まれる機能です。
EOAに関連付けられたプログラマブルロジックは、セキュリティ制限の実施、支出上限の設定、KYC要件の強制など、多くの可能性を解き放ちます。
もちろん、この変化は多くの設計上の問題も提起します。1つの問題はchain_idの使用です。これは、署名に含めるかどうかに応じて、同じ署名が複数のネットワーク間で有効かどうかを決定します。もう一つの複雑な問題は、ターゲットコードのアドレスを使用するか、実際のバイトコードを埋め込むかの選択です。どちらの方法にも独特な特徴と制限があります。さらに、nonceの使用は、権限が「多目的」か「単一目的」かを定義する上で重要な役割を果たします。これらの要素は、バッチ無効化署名や使いやすさなど、機能とセキュリティの問題に影響を与えます。Vitalikはあるディスカッションで（ ここ ）これらの問題を提起しており、さらに探求する価値があります。
注目に値するのは、この変化がイーサリアムのセキュリティメカニズムの1つ、tx.originに影響を与えることです。このEIPの実装に関する詳細はまだ必要ですが、require(tx.origin == msg.sender)の挙動が変わるようです。このチェックは、msg.senderがEOAであってコントラクトではないことを保証する最も信頼できる方法でした。他の方法、例えばEXTCODESIZEをチェックする方法（それがコントラクトかどうかを確認する）は、しばしば失敗し、回避可能です（たとえば、コンストラクタを呼び出す、またはトランザクション後に事前定義されたアドレスにコードをデプロイするなど）。これらのチェックは再入攻撃やフラッシュローン攻撃を防ぐために使われますが、理想からは程遠く、外部プロトコルとの統合も妨げます。このEIP以降、信頼できるrequire(tx.origin == msg.sender)チェックさえも時代遅れになるようです。プロトコルはこれらのチェックを削除して適応しなければなりません。なぜなら、「EOA」と「コントラクト」の区別がもはや適用できなくなるためです――今後はすべてのアドレスが関連コードを持つ可能性があるのです。
従来のEOAとスマートコントラクトの分離は曖昧になり続けています。このEIPにより、イーサリアムはTONのような設計に近づき、すべてのアカウントが本質的に実行可能なコードを持つようになります。プロトコルとのインタラクションがますます複雑になるにつれ、ユーザーエクスペリエンスを改善するためのプログラマブルロジックの使用は、この進化の自然な過程です。
結論
プラハ／Electra（Pectra）アップグレードは2025年3月に予定されています。計画されている最も顕著な変更には以下が含まれます。
-
最大2048ETHまでの変動検証者有効ステーク。これにより、ステーク分布、検証者スケジュールが大きく変化し、小規模ステークの統合により大規模ステーキングプロバイダーの管理が簡素化される
-
実行レイヤーとコンセンサスレイヤー間の相互作用の改善。Eth1実行ブロックとビーコンチェーンブロック間のデータ交換を簡素化。これにより預入、アクティベーション、引き出し、退会が大幅に簡素化され、これらのプロセスが高速化され、コンセンサスレイヤーと実行レイヤー間のさらなる相互作用の基盤が築かれる
-
新しい「ペアリングフレンドリー」BLS12-381プリコンパイルにより、スマートコントラクト内でより安価なBLS署名およびzkSNARK検証を直接サポート
-
blobトランザクションのしきい値を増加させ、calldataコストを引き上げることで、rollupがblobトランザクションを採用するよう促進
-
EOAをプログラマブルアカウントとして機能させ、マルチコール、スポンサーシップ、その他の高度な機能を付与
ご覧の通り、Pectraはステーキングおよびコンセンサスレイヤー、そして実行レイヤーのエンドユーザー体験に大きな影響を与えます。開発は進行中であるため、現段階でコードレベルでこれらすべての変更を詳細に分析することはできませんが、今後の記事でこれらの更新を取り上げます。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@MixBytes
