トップ > Pectra Upgrade解説（Ethereum）

Pectra Upgrade解説（Ethereum）

 

はじめに

みなさん、こんにちはこんばんは！

コインチェックのクリプト入出金開発 Gでエンジニアをしているよーたです。

EthereumのPectra Upgradeが着々と近づいているので、今回はPectra Upgradeに含まれるEIPによる仕様変更について解説します。

この記事はコインチェック株式会社（以下、コインチェック）のアドベントカレンダー12日目（シリーズ1）の記事です。  

コインチェック Advent Calendar 2024

概要

2025年~2026年にかけてEthereumにて実施予定のPectra Upgradeについて、個人的に注目しているEIPを解説します。

Pectra Upgradeは二段階に分けて実施される予定で、第1弾は2025年のQ1に予定されています。

大きな変更点としては、長らく待ち望まれていたAA（Account Abstraction）をはじめ、バリデータの運用改善やPeerDASによるデータ領域活用の効率化等があります。

解説するEIPはEIP-7600 Hardfork Meta - Pectraをもとに選出しています。

用語

  • EL: Execution Layer

  • CL: Consensus Layer

解説するPectra UpgradeのEIP一覧

  1. EIP-6110: ELのブロックにバリデータのデポジットリストを提供する

  2. EIP-7002: ELからバリデータのexitとpartial withdrawalを可能にする

  3. EIP-7251: バリデータのステーキング上限の増加

  4. EIP-7594: ゴシップ配信とピアリクエストによるシンプルなDASの導入

  5. EIP-7685: ELトリガーのリクエストをCLと共有するための汎用バスの追加

  6. EIP-7702: 一時的なEOAアカウント用の新しいtx typeの追加

EIP-6110

ELのブロック構造にバリデータのdepositを追加します。
これにより、ブロックに含まれるdeposit contractのログイベントを解析することで、バリデータのdepositとバリデーションをELの責務として移行することができ、CLからdeposit（またはeth1data）に対する投票が不要になります。

　現状ステーキングを始めるためにバリデータのETHをデポジットした後、CL側でバリデータが認識されるようになるためには、下記の理由から14時間ほどかかります。

  1. CL側でdeposit トランザクションがreorgにより覆らないことを確認する（6.82 hours）

  2. 1のあと、depositに対してバリデータが投票を完了する（6.82 hours）

EIP-6110により上記の工程が不要になり、バリデータがCLに認識されるための時間が13分ほどに短縮されます。

その他にも下記のメリットが挙げられます。

  • proposerの投票から、プロトコル内のメカニズムになることで、2/3以上のバリデータが悪意を持っていたとしても偽のdepositを組み込むことがなくなる

  • EIP-4881のDepositのコントラクトのスナップショットを維持するための要件を排除することで、CLのクライアントソフトウェアの設計とエンジニアリングの複雑さを軽減する

  • そのほかにもvalidator depositに関するセキュリティの向上

本EIPのリクエストは後述するEIP-7685を利用して行われます。

EIP-7002

バリデータのexitやpartial withdrawalをEL側で発火することができるようになります。
exitするためのメッセージがELのブロックに追加され、そのブロックをCLで処理します。

現在のバリデータはactive key（validator key）とwithdrawal credentialの二つのキーを持っており、バリデータをexitすることができるのはactive keyのみで、バリデータがステーキング用にdepositしたETHを最終的に受け取るのはwithdrawal credentialになっています。バリデータはactive keyを用いて署名等の操作を行うためホットな情報として、withdrawal credentialは資金を受け取るだけなのでコールドな情報と区別ができます。

これらが分離していることで、active keyの所有者とwithdrawal credentialの所有者が異なるということがありえます。その場合にwithdrawal credentialの所有者が下記のような不利益を被る可能性が考えられます。

  1. active keyの所有者がバリデータを正常に稼働させないといった脅しができてしまうこと

  2. active keyの所有者が事前に署名しておき、バリデータが十分に稼働する前にexitすること

このような危険があるため、コールドな情報であるwithdrawal credentialに引き出しの権限を持たせられるようにします。そうすることで、2が起こることを防ぎ、1が起こった場合もwithdrawal credentialの所有者の任意のタイミングでステーキングしている資産を引き出して退避することが可能になります。

また、active keyを紛失した場合もexitは可能なため、資産の回収ができる状態を維持できます。

あらゆるものを分散させるのではなく、セキュリティリスクを鑑みて適切に権限はまとめておこうといった感じですね。

EIP-7251

バリデータがステーキングをする際の上限額（MAX_EFFECTIVE_BALANCE）を 32 ETHから2048 ETHに引き上げます。
最低ステーキング額は32 ETHのまま変更はありません。

これによりバリデータ数を減らすことができ、peer-to-peerレイヤーのメッセージの減少や集約するBLS署名数の減少、BeaconStateのメモリ容量の減少、さらにステーキングによる複利報酬の獲得が見込めます。

現在の実態としては複数のバリデータを同一環境、同一ビーコンノードで制御し、別々のBLS署名を持っているだけの場合もあり、バリデータ数が冗長に増えてしまうことの要因にもなっています。
その結果、2024年12月現在でEthereum上のアクティブなバリデータは107万を超えています。
Ethereum Foundationのエンジニアはバリデータ数が140万を超えるとpeer-to-peerレイヤーが大量のメッセージにより肥大化し、Ethereumのプロトコルが深刻なネットワークの問題に直面するとシミュレーションしました。

Dencunアップグレードにおいて、一時的な対応としてEIP-7514により、1epochあたりにバリデータを有効化できる数を12→8に減少させて凌いだうえでの今回の恒久対応へと至ります。

また、現状はステーキングの上限額が32 ETHであるため、複利報酬を得るためには一度引き出してから再度新しいバリデータを立ち上げる必要がありますが、本変更によりステーキングによって得た報酬で複利報酬を得られるようになります。

ちなみに、32 ETHの制限が存在していた理由は、初期のEthereumのシャーディングの設計に則った制限の名残で、設計が変更された現在では技術的な負債として残っており、上限の引き上げによる悪影響は少ないと見られています。

ノードの管理オペレーションも簡略化できるため、ステーキング事業を営む事業者にとっては良い効果となりそうです。

EIP-7594

本EIPはPeerDAS（Peer Data Availability Sampling）と呼ばれるものです。

PeerDASの前提としてまず、Data Availability（DA: データ可用性）があります。
ブロックチェーンのモットーとして「Don't trust, verify（信用するな、検証せよ）」がありますが、DAはブロックの検証に必要なデータがすべてのネットワーク利用者が利用可能な確実性のことを指しており、まさにこれを体現しています。

実際の検証を実施するにあたって、全てのデータを保持するフルノードを建ててしまえば検証は可能ですが、そのような状況が続くと、スケーリングやロールアップの障壁となってしまいます。これをデータ可用性問題と呼んでいます。
また、すべてのデータを保持するのにはハードウェア要件的にも高い水準を要求されるため、ネットワークの分散化を妨げることも考えられます。

データ可用性問題の解決策として、DASがあげられます。
DASでは各ノードがすべてのデータからランダムに選択されたサブセットをダウンロードします。ダウンロードが成功したことを以て、すべてのデータが取得可能であることの信頼性としています。

そして、PeerDASではEIP-4844で導入されたblobデータを対象として、サンプリングを行います。
PeerDASはビーコンノードがデータ可用性サンプリングを実行し、データのサブセットのみをダウンロードしながら、blobデータが利用可能になったことを確認するネットワーキングプロトコルです。
このプロトコルではデータの伝播にゴシップと呼ばれるEthereumのpeer-to-peerの通信メカニズムを利用します。

これによりレイヤー1のデータ可用性がボトルネックとなっている、ロールアップと呼ばれるレイヤー2のシステムのスケーリングが恩恵を得られます。

今後Ethereumをスケールするための手段として予定のDankshardingにDASは不可欠なため、着々とDankshardingの実現に近づいていますね。

EIP-7685

ELからトリガーされたCL向けのリクエストを共有するための汎用的なバスになります。

コントラクトが発行したリクエストを格納するための汎用フレームワークを定義します。実行ヘッダーを拡張し、リクエスト情報を格納するためのフィールドを1つ追加します。
リクエストは後にCLに公開され、CLで各リクエストを処理します。

スマートコントラクトで制御されるバリデータが普及したことで、ELをトリガーとした動作を求められることが増えてきました。これらの操作をスマートコントラクトに移譲することで、確実な動作をさせるために仲介する必要がなくなり、より安全になります。

EIP-7702

Account Abstraction（AA）を実現するためのEIPです。

新しいトランザクションタイプ（SET_CODE_TX_TYPE）の導入により、AAを実現します。

具体的には[chain_id, address, nonce, y_parity, r, s]からなる認証タプルのリスト（authorization_list）をトランザクションのペイロードに追加します。

トランザクションの実行開始時にnonceをインクリメントした後、それぞれの認証タプルに対して下記の処理を行います。

  1. chain_idが現在のチェーンのIDまたは0であることの確認

  2. nonceが2**64-1未満であることの確認

  3. 認証タプルをRPLシリアライズした結果 or パラメータとして渡されたMAGICをハッシュ化したものをauthorityとして保持する

  4. トランザクション実行時に指定されたaccessed_addressにauthorityを追加する

  5. authorityに関するコードが空でなく、すでに移譲されていることを確認する

  6. authorityが持つnonceが認証タプルのnonceと同じであることを確認する

    1. authorityがtrie上に存在しない場合はnonceが0であることを確認する

  7. authorityがtrieに存在する場合、一部のgasをグローバルなrefund counterに追加する

  8. authorityのコードを0xef0100 || addressにセットします。これをdelegation designatorといい、特定のauthorityがアドレスに付与されます。

    1. この時のaddressが0x0000000000000000000000000000000000000000の場合はauthorityは付与されず、アカウントに設定されているコードが空にアップデートされ、authority設定がリセットされます。

  9. authorityのnonceを1増やす

上記処理のどこかで失敗した場合は、次の認証タプルの処理に移ります。
また、複数の認証タプルで同一アドレスに対してコードの設定が行われた場合は、最後の処理の内容が設定されます。

AAでは今までのEOAでは実現できない、下記のような機能の実装が可能になります。

バッチ処理：1つのトランザクション内で同一ユーザーによる複数の操作が可能になります。
例として、ERC20を出金する際に、出金可能額を承認するトランザクションと、承認した資金を移動させるトランザクションの二つが必要になりますが、これらを一つのトランザクションで実現できるようになります。

スポンサーシップ：アカウントXはアカウントYに代わってトランザクション用の支払いをすることができる。アプリケーションの運営者がユーザーの代わりにトランザクションに係る支払いをすることでユーザーは無料で利用できるようになる等の活用方法があります。

権限の縮小：ユーザーはsub-keyに署名することで、アカウントへのグローバルアクセスよりも弱い特定の権限を与えることができます。例としては、ERC-20トークンの送金は可能だが、ETHの送金はできないようにするといった制限や、1日に総残高のうちの1%までしか使えないようにする、特定のアプリケーションのみとやり取りできるようにする、などが想定されます。

2016年ごろからAAの議論はされていましたが、それがついに今回実装される形となりました。
待ち望んでいた人も多かったのではないでしょうか。

おわりに

多くの方が長年待ち望んでいたであろうAccount Abstractionがついに入り、Ethereumを基盤としたアプリケーション開発が今まで以上に捗りそうです。

また、Dankshardingに向けた基盤が少しづつ整っている感じがしてワクワクしますね。

今後もEthereumのUpgrade情報の収集と発信をしていきたいと思います。

本ブログが皆様の情報収集の手助けになれば幸いです。