Ethereum の大型アップデート「Pectra」とは？EIP-7702 とステーキング機能への変更を中心に解説

本記事の概要

Pectra は、Ethereum メインネットで 2025 年 5 月 7 日 10:05 UTC に epoch（チェーン上の時間区切り）364032 で有効化された大型アップデートです。実行レイヤー側の Prague とコンセンサスレイヤー側の Electra を合わせた呼び名で、Dencun の次に行われました。ethereum.org

主要な更新は、通常の Ethereum アカウント（EOA, Externally Owned Account）がスマートコントラクトのような処理を使えるようになる EIP-7702 です。ウォレットやアプリは、複数操作の一括実行、ガス代のスポンサー、権限を絞ったサブキーといった UX 改善を扱いやすくなりました。EIP-7702

また、ステーキング機能が大きく変わりました。EIP-7251 により 1 バリデータの最大有効残高（報酬計算に利用される残高）が 32 ETH から 2,048 ETH に引き上げられ、複数の 32 ETH バリデータをまとめる運用や、報酬を同じバリデータ内で複利的に反映する運用が可能になりました。EIP-7251

Pectra は、L2 向けのデータ可用性にも手を入れています。Dencun で導入された blob（L2 のデータを安く載せるための専用領域）は、Pectra の EIP-7691 によって目標 3 個・最大 6 個から、目標 6 個・最大 9 個へ増えました。EIP-7691

あわせて EIP-7623 が calldata（取引に添える入力データ領域）を大量に使う取引のガスコストを引き上げ、blob を使う設計への誘導を強めています。EIP-7623

Pectra アップデートの概要とタイムライン

目的と打ち手

Pectra(=Prague/Electraアップデート) のメタ EIP である EIP-7600 は本アップデートに含まれる EIP をまとめています。EIP-7600

Core EIP は 10 本です。ethereum-forks

狙いは大きく分けて、次の 4 つです。

• ウォレット UX の改善
  • EIP-7702 により、EOA が委任先コントラクトのコードを使えるようにする
  • バッチ処理、ガススポンサー、権限制限付きサブキー、リカバリーなどを、既存アカウントの延長で扱いやすくする
• ステーキング運用の柔軟化
  • EIP-7251 により、1 バリデータの最大有効残高を 2,048 ETH に引き上げ、複数バリデータの統合を可能にする
  • EIP-7002 により、ステークした ETH の引き出し先アドレスから直接バリデータの exit や partial withdrawal をトリガーできるようにする
  • EIP-6110 により、バリデータの deposit 情報を execution block に直接含め、コンセンサスレイヤーが eth1data の投票を介して間接的に取り込む必要をなくし、deposit の反映を高速化する
• L2 データ可用性とブロックサイズ制御
  • EIP-7691 により、blob の目標数・最大数を増やす
  • EIP-7623 により、calldata を大量に使う取引のガスコストを引き上げ、最大ブロックサイズを抑える
  • EIP-7840 により、fork ごとの blob 設定をクライアントに保持させる
• プロトコル効率と将来対応
  • EIP-2537 により、BLS12-381 曲線演算のプリコンパイル（データをクライアントに組み込み、ガスコストを低減）を追加する
  • EIP-2935 により、過去のブロックハッシュをシステムコントラクトから参照できるようにする
  • EIP-7549 により、attestation（バリデータの投票）の committee index（投票がどのバリデータ集団に属するかを示す ID）を署名対象の外へ移し、異なる集団の投票でも内容が同じであればまとめて集約できるようにする

Pectra は、Dencun の blob 導入で始まった L2 データ可用性の拡張を一段進めつつ、ウォレットとステーキング機能にも手を入れました。実務寄りの基盤整備が中心です。

タイムライン

Pectra は、Holešky、Sepolia、Hoodi でのテストを経て、既に mainnet で有効化されています。以下のタイムスケジュールで進行しました。EIP-7600

対象となる EIP の一覧

Pectra に含まれる EIP は次の 11 本です。EIP-7600 ethereum-forks

EIP-7600 には関連する EIP として EIP-7642（eth/69 - Drop pre-merge fields。マージ後は使われなくなった total difficulty など、p2p 通信上のフィールドを削る変更）も Networking 分類で記載されています。

目玉機能① EIP-7702：EOA がスマートコントラクトウォレットのような柔軟な処理が可能に

解決したい課題：EOA の UX 制約

Ethereum の利用者が普段使うアカウントの多くは EOA です。EOA は秘密鍵で署名して取引を送る単純なアカウントで、扱いやすい反面、スマートコントラクトウォレットのような柔軟な処理を標準では持ちません。

たとえば、DEX で ERC-20 の approve と swap を別々に送る、別のトークンでガス代相当を支払いたい、日次上限を持つサブキーだけに一部操作を任せたい、といった要望があります。

しかし EOA は署名した取引がそのまま単発の呼び出しとして実行されるだけで、複数処理をまとめたり、取引ごとに条件を持たせたりする仕組みを持ちません。スマートコントラクトウォレットはアカウント自体がコントラクトなので、こうした処理をアカウント側のロジックとして実装できますが、EOA は仕組み上それができませんでした。

EIP-7702 は、こうしたユースケースを EOA のまま扱いやすくするため、EOA が委任先コントラクトのコードを使える仕組みを追加しました。EOA が持つ秘密鍵とアドレスはそのままに、取引実行時だけ委任先コントラクトのロジックを借りて、スマートコントラクトウォレットのような処理を行えるようになります。EIP-7702

仕組み：authorization tuple と delegation indicator

EIP-7702 は、新しい取引タイプ 0x04 を追加します。この取引は、EOA が「委任先コントラクトのコードを使う」ことを承認するものです。

この取引には authorization_list と呼ばれるリストが含まれます。リストの各要素は authorization tuple と呼ばれ、[chain_id, address, nonce, y_parity, r, s] という形式で、どの委任先アドレスを使うかを示します。EIP-7702

この取引が承認されれば、対象 EOA に 0xef0100 || address という、委任先コントラクトを指し示すマーカー（delegation indicator）を書き込みます。

CALL、DELEGATECALL、STATICCALL などでその EOA が実行対象になった場合、クライアントは delegation indicator が指すアドレスのコードを読み、実行します。EIP-7702

アカウント自体を別のコントラクトへ移すのではなく、既存のアドレスに「特定のコントラクトを使う」ことができ、委任先を 0x0000000000000000000000000000000000000000 にすることでマーカーを削除できます。EIP-7702

開発者が見るべき注意点

EIP-7702 後は、「EOA は code を持たない」という判定でアカウント種別を区分することができなくなります。

authorization tuple の処理とロールバックの関係も注意しましょう。EIP-7702 では、取引実行が失敗しても、処理済みの delegation indicator はロールバックされません。ウォレットやアプリは、署名対象、nonce、委任先、失敗時の状態を利用者に誤解させない UX が必要になります。EIP-7702

目玉機能② EIP-7251 / EIP-7002：ステーキングの大規模変更

32 ETH 上限から 2,048 ETH 上限へ

Pectra 以前は、1 バリデータの有効残高は 32 ETH が上限でした。32 ETH を超える残高があっても、超過分はブロック生成の確率や報酬計算には反映されません。そのため、大規模なステーキングを行うには、多数の 32 ETH バリデータを運用する必要がありました。

EIP-7251 は、最小ステーキング残高 32 ETH は維持したまま、MAX_EFFECTIVE_BALANCE を 2,048 ETH に引き上げます。仕様上は MAX_EFFECTIVE_BALANCE_ELECTRA = 2048 ETH と定義されています。EIP-7251

この変更により、複数のバリデータを少数の大きな有効残高を持つバリデータへ統合できます。結果として、P2P メッセージ数、epoch ごとの BLS 署名集約数、BeaconState のメモリ負荷が減る見込みです。EIP-7251

統合処理は、統合元バリデータの withdrawal credentials に記録されたアドレスから、consolidation request contract（0x0000BBdDc7CE488642fb579F8B00f3a590007251）へ統合元・統合先バリデータの pubkey を含めたデータを持つトランザクションを送ることで開始できます。

統合元・統合先の両バリデータが exit 中・済みでなければ、統合元バリデータの exit が開始され、exit 後に統合先バリデータの有効残高へ統合元バリデータの残高が加算されます。

1 回のトランザクションで指定できる統合元・統合先は 1 組なので、複数のバリデータを同一の統合先にまとめる場合は統合元ごとにトランザクションを送らなければなりません。

統合は、運用移行の道具としても使えます。たとえば旧サーバー / 旧運用者のバリデータを、あらかじめ新サーバー / 新運用者側で動かす統合先バリデータに寄せる、という使い方です。

ただし統合先バリデータは、Pectra アップデートに対応した withdrawal credentials である compounding withdrawal credential を持つ active なバリデータでなければなりません。EIP-7251

また通常のバリデータの報酬計算も変わります。32 ETH を超えた報酬分も同一バリデータの有効残高に反映できるため、従来のように次の 32 ETH が溜まり、別のバリデータを建てるまでの報酬計算から外れる構造ではなくなります。ethereum-pectra

実行レイヤーからバリデータの停止・部分引出しを要求できる

EIP-7002 は、実行レイヤーの 0x01 withdrawal credentials で指定した引出先アドレスから、バリデータの exit と partial withdrawal を要求できる仕組みを追加しました。

これまではバリデータの署名鍵でexitをトリガーする必要があり、withdrawal credentials を持つ資金所有者が単独で exit を始められませんでした。EIP-7002

バリデータの署名鍵はあくまでバリデータの署名にのみ用いられ、withdrawal credentials は資金の最終的な受取・所有を担うアドレスとして扱われます。

deposit 処理の高速化

EIP-6110 は、バリデータへの deposit 処理をブロックの構造として置くことで、コンセンサスレイヤー側でのデータ取り込みを容易化し、従来必要だったコンセンサスレイヤー側の eth1data 投票を不要にします。EIP-6110

この変更によってトランザクションの送信からコンセンサスレイヤーでの処理が、既存方式の約 12 時間から、protocol 内処理では約 13 分へ短くなるとされています。EIP-6110

L2 とデータ可用性への変更：blob の数増加と calldata のコスト変更

blob は目標 6 個・最大 9 個へ

Dencun で導入された blob は、L2 が Ethereum L1 にデータを載せるための安価なデータ領域です。Pectra の EIP-7691 は、blob の target を 3 個から 6 個へ、maximum を 6 個から 9 個へ増やしました。

EIP-7691 は、rollup centric roadmap のもとで、L2 が L1 のデータ容量に依存してスケールすることを前提にしています。PeerDAS のような将来のデータ可用性拡張が入るまでの短期的な増量として、Pectra で blob throughput を引き上げました。EIP-7691

calldata のコストを増加させ blob の利用を推奨

calldata の負荷低減・コスト変更も修正され、EIP-7623 は、calldata を大量に使う取引に floor cost を設け、最大ブロックサイズとそのばらつきを抑える EIP になっています。EIP-7623

通常の ETH 送金、トークン送金、NFT、DeFi、SNS、リステーキング、ブリッジのように、calldata をデータ可用性の主手段として使わない取引は、影響を受けにくい設計です。

calldata をデータ置き場として使うようなトランザクションについては手数料が増加することとなり、「できるだけ blob を使う」設計がさらに明確になりました。

blob の増加スケジュールをクライアントが保持する

EIP-7840 は、execution client の設定ファイルに blobSchedule を追加します。

cancun では target 3・max 6・baseFeeUpdateFraction 3,338,477、prague では target 6・max 9・baseFeeUpdateFraction 5,007,716 のように、各ネットワークのフェーズごとに、目標blob数/最大blob数/Fee変動の数値を持つ形が示されています。EIP-7840

クライアント間の通信を円滑化するための修正であり、fork ごとの blob parameter を明示し、Engine API で毎ブロック複雑なやり取りをする必要を避けます。EIP-7840

その他の重要な EIP

EIP-7685：実行レイヤーからコンセンサスレイヤーへの連絡経路

Pectra のステーキング関連 EIP は、実行レイヤーからコンセンサスレイヤーへ引出/デポジット/統合のリクエストを渡します。EIP-7685 は、そのための共通基盤です。ブロックヘッダーに requests_hash を追加し、ブロック処理時に追加されたリクエスト群のハッシュを持ちます。EIP-7685

EIP-7685 自体が各種のリクエストを定義するわけではなく、各種のリクエストの EIP でリクエスト種別・データ形式などの個別具体的な仕様を定めています。

共通化することで、実行レイヤーに新しいリクエストを追加するときに同じ基盤を使いまわせます。EIP-7685

EIP-2537：BLS12-381 プリコンパイル

EIP-2537 は、BLS12-381 曲線の演算を EVM から効率よく使うためのプリコンパイル を追加します。

BLS 署名の検証等を、Solidity 実装や独自コントラクトではなくクライアントに埋め込まれたプリコンパイル情報から呼べるようになります。EIP-2537

Ethereum のコンセンサスレイヤーでは BLS 署名が使われているため、ステーキングプール、リステーキング、ブリッジ、ZK 知識証明を利用するアプリケーションがバリデータの情報や BLS 署名を扱う場面での実装コスト・ガスコストの圧縮が可能になります。ethereum-pectra

EIP-2935：過去ブロックハッシュをブロックチェーンの状態から参照可能に

EIP-2935 は、直近 8,191 ブロックのブロックハッシュをシステムコントラクトに保存し、EVM から参照できるようにします。既存の BLOCKHASH オペコードは直近 256 ブロック（約 51 分）しか参照できません。

EIP-2935 はそのオペコード自体は変更せず、別のコントラクトへの保存という形で参照できる範囲を約 27 時間分まで広げます。EIP-2935

将来的にステートレスクライアント（state を保持せず、必要なデータを witness という証明付きの形で受け取って検証するクライアント）に対応する際にも意味を持ちます。ブロックハッシュが state の一部としてコントラクトに保存されていれば、その値も witness に含めて証明できるようになるため、将来の準備という側面があります。EIP-2935

EIP-7549：BLS 署名の集約を軽量化

EIP-7549 は、attestation（バリデータの投票）に含まれる committee index（投票を提出する committee、バリデータの集団を示すインデックス）を、署名対象のデータから取り除きます。

1 epoch は 32 スロット（SLOTS_PER_EPOCH）からなり、1 スロットあたり最大 64 個の committee（MAX_COMMITTEES_PER_SLOT）に分かれて投票が行われます。

これまでは committee index も一緒に署名されていたため、同じ内容の投票でも committee が違えば別々の署名にしかなりませんでした。最悪の場合、1 epoch あたり 32 × 64 = 2,048 通りの（スロット, committee）の組み合わせごとに集約署名を検証する必要があります。EIP-7549

committee index を署名対象から外すと、同じスロット内であれば committee が違っても内容が同じ投票を 1 つの集約署名にまとめられるようになります。検証すべき単位が（スロット, committee）の組み合わせからスロット単位に変わるため、必要な集約署名の数はおおよそ committee 数（64）分の 1 まで減ります。

少なくとも 262,144 active indices がある beacon chain network では、2/3 threshold に到達するために検証する集約署名の数が ceil(32*64*2/3) = 1366 から ceil(32*2/3) = 22 へ減ると説明されています。EIP-7549

これはコンセンサスクライアントの処理・検証効率を上げるだけでなく、Ethereum の ZK 証明生成の効率化にもつながります。EIP-7549

バリデータ・ノード運用者、L2・アプリ開発者への影響とまとめ

バリデータ・ノード運用者への影響

Pectra 後のステーキング運用では、まず EIP-7251 への対応が重要です。

既存の 32 ETH バリデータをそのまま維持することもできますが、複数バリデータの統合や compounding withdrawal credentials を使う場合、鍵管理、監視、報酬計算、会計処理の単位が変わります。EIP-7251

統合は、旧運用者 / 旧サーバー構成から新しい統合先バリデータ側へ残高を寄せる移行にも使えます。

統合元・統合先の pubkey、withdrawal address、統合先の compounding credentials を取り違えると資金と運用の帰属が変わるため、手順化と事前検証が必要です。EIP-7251 Electra consensus spec

EIP-7002 により、withdrawal credentials を持つ側から exit / partial withdrawal を要求できるようになりました。active key を運用者、withdrawal credentials を資金所有者が持つような分離運用では、exit 権限や資金管理の仕様が変わることに留意する必要があります。EIP-7002

L2・rollup 開発者への影響

L2 にとって、Pectra は blob 容量の増加と calldata コスト見直しの組み合わせです。EIP-7691 で blob target / max は増えましたが、EIP-7623 によって、calldata に大容量のデータを入れる取引はコスト増が見込まれます。EIP-7691 EIP-7623

そのため、rollup は取引データをどれだけ calldata に載せるか、blob へのフォールバック戦略や手数料見積もりのロジックを、Pectra 後の blob 上限と calldata の floor cost を前提に見直す必要があります。

ウォレット・dApp 開発者への影響

EIP-7702 は、ウォレットにとって UX 改善に直結する変更です。approve と swap の一括化、ガススポンサー、権限を絞った session key、回復手段の設計など、従来はスマートコントラクトウォレット側に寄っていた機能を、既存 EOA の利用者にも届けやすくなります。EIP-7702

ただし、セキュリティ上の責任も増えます。署名画面は「どのアドレスに、どのコードを委任するのか」を利用者が理解できる形にしなければなりません。アプリ側は、EOA に code がないという前提、tx.origin 周辺の前提、アカウント種別ごとのアクセス制御を見直す必要があります。EIP-7702

まとめ

EIP-7702 は EOA を AA（Account Abstraction、アカウント抽象化）のように利用可能にし、EIP-7251 と EIP-7002 はバリデータの残高単位と exit 権限を変えました。EIP-7691 は blob を目標 6 個・最大 9 個へ増やし、EIP-7623 は calldata に多くのデータを持たせる取引へのコストを増加させました。

Pectra は、利用者・運用者・開発者の既存ワークフローに影響が多いアップデートです。ウォレットはアクションへの認可処理の考え方を見直す必要があります。ステーキング運用者は統合の手順と exit 権限の所在を、L2 は blob と calldata のコスト前提を、それぞれ確認することになります。

Omakase は Ethereum ステーキングの運用代行事業者（SSP, Staking Service Provider）として、Pectra 後のバリデータ統合、withdrawal credentials、クライアント運用要件を継続的に確認しています。