イーサリアム・ペクトラ・ハードフォーク入門

By NIC Lin, Medium

Pectraハードフォークは2025年3月にメインネット展開を開始する予定です。Pectraアップグレードには11の技術プロトコル(EIP)が含まれており、以下の通りです:

• EIP-2537: BLS12-381カーブ操作の事前コンパイル

• EIP-2935: 過去のブロックハッシュ値を状態に保存

• EIP-6110: オンチェーン バリデータ預金を提供

• EIP-7002: Execution layer triggered exit

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE 

• EIP-7549: ；committee インデックスを検証から外す

• EIP-7623:calldataコストを増やす 

• EIP-7685:Generic Execution Layer Request

• EIP-7691.

• EIP-7702:EOAアカウント コードの設定

• EIP-7840: EL 構成ファイルへのブロブ プランの追加

誓約関連技術プロトコル

EIP-6110: BLS12-381 カーブ操作のプリコンパイル

ユーザーの誓約への参加処理を簡素化し、待ち時間の大幅な短縮を可能にします。

誓約へのユーザーの参加は、実行レイヤーに32のETHを保存し、イベントログに記録することで達成されます。その後、コンセンサスレイヤーの実行がイベントログを解析して、誰かが誓約に参加したかどうかを判断し、誓約に参加したユーザーが検証者になります。

しかし、コンセンサスレイヤーの検証者は、まず、どの時点でどの入金を行うかについて合意する必要がある。そうしないと、ある検証者は5つの新しい入金を見るが、他の検証者は3つしか見ないことに気づくだろう。そのため、コンセンサスレイヤーの検証者は、どのeth1dataブロックを参照するかについて投票し、全員が同じeth1dataブロックを見るようにする。

しかし、最初のうちは、チェーンフォークにつながるような実行レイヤーの大きなエラーを避けるために、参照する実行レイヤーのブロック（eth1data）は、約10時間以上前の実行レイヤーのブロックとします。これは、大きなエラーが発生した場合、コンセンサスレイヤーの開発者がそれに対応し、対処するのに十分な時間があることを確認するためです。有効になる

CLブロックの10900000 eth1dataのCLブロックには、10時間前に出現した実行レベルブロック21683339のブロックハッシュが含まれています。

EIP-6110の実装後は、コントラクト上のユーザーの誓約情報がそのまま実行レイヤの一部となり、コンセンサスレイヤブロック自体が実行レイヤブロックを含む（eth1dataは含まない）ので、コンセンサスレイヤメモリブロックがコンセンサスレイヤメモリブロックの3分の2以上を受け取る限り、コンセンサスレイヤベリファイアは「参照された実行レイヤメモリブロックが同じであることを確認する」という問題を考慮する必要がなくなる。コンセンサス・レイヤ・ブロックがベリファイアの3分の2以上によって確認される限り、同じ実行レイヤ・ブロックが参照されているというコンセンサスが得られる。その結果、ユーザーの誓約は、実行レイヤーのブロックが処理された後、わずか13分で検証することができ、コンセンサスレイヤークライアントは、誓約データを処理するために使用される複雑なロジックを削除することができます。

EIP-7002:  Stateに過去のブロックハッシュを保存する

検証者が誓約を撤回したり、お金や収益を引き出したりするプロセスを改善し、検証者のリスクを減らすために使用できます。

プレッジに参加するには、「Validator Key」と「Withdrawal Credential」の 2 つの鍵が必要である。

「Validator Key」は、バリデータの作業内容に使用され、「Withdrawal Credential」は、バリデータがプレッジを抜ける際の預託金や収益の出金先アドレスに使用される。加えて、バリデータ・キーは現在、誓約を撤回するために必要である。

Validator Key を紛失した場合、Validator タスクを実行できなくなり、プレッジから引き出すことができなくなる。

Withdrawal Credential を紛失した場合、すべての預託金と収益を失うことになる。さらに、一部の利用者は Lido などのサードパーティのプレッジサービスを利用しており、これらのプラット フォームを利用する場合、利用者自身で出金クレデンシャルを保管する必要がある。一方、Validator Key はサービスプロバイダが保管し、利用者に代わって Validator タスクを実行する。

EIP-7002技術プロトコルを実装することで、利用者は出金クレデンシャルを使用して出金契約（0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAAに配備）を呼び出し、プレッジを終了するか、デポジットと収益を回収することができる（部分出金契約）。部分的引出しは、第三者の質権サービスを利用することに伴うリスクを軽減する。これは、ユーザーが自分自身で誓約し、バリデーターキーを紛失した場合に誓約を終了するためにも使用できます。

• リクエストはvalidator_pubkeyとvalidator_pubkeyのパラメータで開始されます。validator_pubkeyはバリデータのバリデータ（公開）キーで、validator_pubkeyは請求する金額です。

• 要求を開始するWithdrawal Credentialは、validator_pubkeyのWithdrawal Credentialでなければならない。

• Withdrawコントラクトを呼び出して要求を開始するには、ガス料金(ETH)がかかる。

• 利用者の Withdrawal Credential がコントラクトの場合、利用者はまず Withdraw コントラクトにアクセスして手動更新料の現在の金額を取得し、その後リクエストを開始して手動更新料を添付することができる。ただし、Withdrawal Credential が EOA アカウントの場合、セル更新の正確な金額を取得する方法はなく、 リクエスト開始が正常に実行されることを保証するために、超過セル更新料（払い戻し不可）を事前にシミュレートして支払うことしかできない。

注意：退会クレデンシャルがBLS公開鍵形式のままになっている場合は、ELアドレス形式に変更する必要があります。

EIP-7251:MAX_EFFECTIVE_BALANCE 

誓約可能な最大金額を大幅に増やすことで検証者の数を減らすことができ、最大金額に達しない検証者には自動的に誓約の収益を受け取る権利が与えられます。

検証者になることを誓約するユーザーは、MAX_EFFECTIVE_BALANCEの金額のETHを提供する必要があり、これは少なくても多くてもかまいません（現在のMAX_EFFECTIVE_BALANCEは32ETHです）。ユーザーが1024ETHを誓約する場合、32回誓約し、32のバリデータを有効にし、32のバリデータノードを実行することができる。コンセンサスレイヤーの状態データがずっとずっと大きくなることに加えて、何万もの検証者の署名が毎スロット（12秒ごと）にp2pネットワークレイヤーを通過して集約されるため、コンセンサスレイヤーのp2pネットワークレイヤーの負荷はさらに大きくなります。

EIP-7251の実装後、誓約の下限（MIN_ACTIVATION_BALANCE）は32ETHのままですが、誓約の上限（MAX_EFFECTIVE_BALANCE）は2048ETHに大幅に引き上げられるため、32～2048の間で任意のETHを誓約することができ、誓約収益を得ることができます。32ETHから2048ETHの間で任意の量のETHを誓約することができ、誓約による収益を得ることができます。 定期的に収益を取り出す必要がなくなり、32ETHを蓄積した後に再び誓約を続けることができます。

現時点では、既存の検証者は特に誓約を終了し、それらをマージして再追加する必要はありません。代わりに、実行可能レベルで新しい「誓約をマージするための契約」（0x00431F263cE400f4455c2dCf564e53007Ca4bbbBbに配置）を使用して、検証者のWithdrawalによって契約を開始するだけです。Crendentialでコントラクトを呼び出し、預金をマージするリクエストを開始します。

• 入金マージリクエストのパラメータには、source_pubkeyとtarget_pubkeyが含まれる: 両方のキーはバリデータのバリデータキーであり、ソースバリデータはターゲットバリデータにマージされる。

• 要求を開始する引出クレデンシャルは、送信元バリデータの引出クレデンシャルでなければならない。

• 要求を開始するための統合デポジットコントラクトの呼び出しには、現在の要求数に基づいて計算される処理手数料（ETH）が伴う。手数料は現在のリクエスト数に基づいて計算され、リクエストが多い場合は高くなります。

• 利用者の Withdrawal Credential がコントラクトの場合、リクエストを開始して手動更新に添付する前に、Consolidated Deposit Contract を呼び出して手動更新の現在の金額を取得することが可能である。ただし、Withdrawal Credential が EOA アカウントの場合、手動更新料の正確な金額を取得する方法はなく、 リクエスト開始が正常に実行されるように、超過分の手動更新料（払い戻し不可）を事前にシミュレートし、支払うことのみが可能である。

注意: 退会クレデンシャルが BLS 公開鍵形式の場合、EL アドレス形式に変更するための切り替えが必要です。

EIP-7685: Generic Execution Layer Request

正式なEL -> CLメッセージパイプラインを確立し、ユーザーと誓約サービスがコンセンサスレイヤーに直接リクエストを送信できるようにします。

ユーザーが実行レイヤーからコンセンサスレイヤーに直接リクエストを送れるようにすることで、Lidoのようなプレッジサービスはより分散化された方法で運営できるようになります。例としては、前述のEIP-7002による誓約を終了するリクエストや、EIP-7251による預金を統合するリクエストなどがあります。このプロトコルがなければ、リドのユーザーはリド・ノード・サービス・プロバイダーがコンセンサス・レベルと同じように誓約の撤回や預金の統合を実行することを信頼しなければならない。このプロトコルがあれば、リドのユーザーは実行レベルのガバナンス契約を通じて直接リクエストを送ることができる。

これらのリクエストはリクエストタイプによって区別され、異なるコントラクトを通じて開始され、実行レイヤーのメモリブロックに書き込まれます。これにより、コンセンサスレイヤーは個々の解析ロジックを記述することなく、実行レイヤーのメモリブロックから直接この情報を取得することができます。

EIP-6110、EIP-7002、およびEIP-7251はすべて、EIP-7685で定義された基準に基づいてリクエストを策定しています:

• EIP-6110 は、誓約リクエストを追加します。預金契約

  (0x000000219ab540356cbb839cbe05303d7705fa)を通じて、要求を開始する。

• EIP-7002 Exit Pledge Request: Request Type=1で、Withdrawコントラクト

  (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA)を通して要求が開始されます。

• EIP-7251おまとめ入金要求：要求タイプ=2、おまとめ契約を通じて開始

  (0x00431F263cE400f4455c2dCf564e53007Ca4bbb)。

エクスペリエンスを向上させる技術的なプロトコル

EIP-7702:  EOAアカウントコードの設定

EOAアカウントを任意で契約アカウントに変換できるようにし、エクスペリエンスを大幅に向上させます。

EOAアカウントには、以下のような欠点があります:

• 秘密鍵またはニーモニックを記録して保存する必要があり、新規ユーザーとしてサインアップする際の高い障壁となっています。

• EOAアカウントで実行できる取引は1回のみです。 例えば、UniswapでUSDTをETHに交換するには、まずUSDTを承認 するトランザクションを開始し、次に別のトランザクションを送信して交換を実行する必要があります。

• アカウントの特定の操作を第三者に与えるなど、権限を制御する方法がないため、ユーザーはすべての雑用に個人的に対処し、すべての操作に一度署名しなければなりません。

• リカバリーの仕組みがなく、秘密鍵やニーモニックを自分で保管しなければならず、紛失するとアカウントの資産を取り戻すことはできない。

スマートコントラクトのアカウント（例：Safe）であれば、上記の問題は解決できます：

• ユーザーは、携帯電話（またはコンピュータ）のセキュリティチップにある秘密鍵を使って認証に署名することができ、秘密鍵やニーモニックを覚えておく必要はありません。また、電子メールやその他のさまざまな認証方法で認証に署名することもできます。

• 複数の操作をまとめてパッチし、1つのトランザクションで実行することができるため、以前は複雑だったDAppの操作を、1回の署名と認証、1回のトランザクションで完了させることができます。

• 非常にきめ細かな権限の制御が可能です。 ユーザーは自分のアカウントを制御するために第三者に権限を与えることができますが、同時に「どのような契約とやり取りできるか」「どのような操作を実行できないか」「資産移転に使用できる資産の最大数」「1週間に実行できる操作の最大数」などの制限を指定することができます。

• 自分のニーモニックや携帯電話、Eメールを紛失した場合に、自分のアカウントから新しいアカウントに資産を移せるよう、「リカバリー」メカニズムを追加することができる。

EIP-7702の提案は、EOAアカウントに契約アカウントに変換する力を与えることです。

• チェーンID：これは、Aチェーンの署名がBチェーンでリプレイされるのを防ぐために使用されます。ただし、チェーンIDに0が記入されている場合は、すべてのチェーンで変身する意思があることを示す。

• 変更先の契約アドレス：安全な契約アドレスを記入した場合、EOAアカウントは安全な契約に変更されます。NULLアドレス（address(0)）を記入した場合、変更をキャンセルしてシンプルなEOAアカウントに戻ることを意味します。

• EOAのNonce値：これは署名がリプレイされないようにするために使用されます。Nonce値が増加した場合、元の署名は無効になります。

しかし、注意すべき点がいくつかあります：

1.EOAの秘密鍵はまだ使える

ユーザーのEOAアカウントが契約に変わっても、元のEOAアカウントと同じように使い続けることができます。例えば、EOAアカウントがSafeコントラクトになった場合、Safeインターフェースを使用し、Safe取引プロセスを経て、元のEOAウォレットで取引を継続することができます。しかし、これはまた、アカウントのセキュリティが依然として秘密鍵に限定されていることを意味します。

2.依然としてEOAキーのセキュリティ

ユーザーのEOAがマルチシグネチャーになったとしても、EOAキーを失わない限り、彼のアカウントのセキュリティは常にEOAキーのセキュリティです。

3.EOAアカウントのストレージがフォーマットされない

EOAアカウントがコントラクトにモーフィングし、そのストレージにデータを書き込むとき、そのデータは、データを削除するアクションが明示的に実行されない限り、EOAアカウントが別のコントラクトにモーフィングしたり、モーフィングをキャンセルしたりしてもフォーマットされないため、開発者は次のことに注意する必要があります。したがって、開発者は、ERC-7201で説明されているように、ストレージが以前にモーフィングされたコントラクトによって残されたデータを読み取らないように注意する必要があります。

4.EIP-7702プロセスは初期化を含まない

通常、コントラクトティルは初期化ステップを必要とし、ティルの所有者に関する情報（公開鍵やアドレスなど）がティルの展開中に同期して書き込まれ、ティルの損失を招く可能性のある先取り展開ステップ（Frontrun）を回避します。デプロイメントステップ（Frontrun）が実行されると、アカウントの所有権が失われます。これは通常、コントラクトされたアカウントをデプロイするファクトリーのコントラクトによって実行されるが、EIP-7702はファクトリーがコントラクトをEOAにデプロイするのではなく、直接的な変更であるため、攻撃者はユーザーの変換署名をコピーし、ユーザーのためにアカウントを変換するトランザクションをチェーン上に先取りして送信することができるが、アカウントは攻撃者が制御できるものに初期化されるため、開発者はEIP-7702に注意する必要がある。開発者はEIP-7702を意識する必要があります。可能な予防策としては、初期化関数内でEOAアカウントの署名をチェックし、たとえそれが先取りされたとしても、攻撃者が初期化を完了させるためにEOAアカウントの署名を作成する方法がないようにすることなどが挙げられます。

5.ウォレットは変更要求をゲートする必要がある

ウォレットはユーザーのためにこれを行う必要があり、悪意のあるDAppサイトがユーザーに変更トランザクションに署名するよう求めたときに、ブロックして警告します。

• Modified Safe Ithaca Account

• Ithaca Account

DAppテクノロジープロトコル

EIP-2537: BLS12-381 Curve Manipulation Pre-compilation

BLS カーブに基づくゼロ知識証明アプリケーションをより低コストで手頃なものにします。

EIP-2537は、安価なBLS曲線操作を提供するいくつかのプリコンパイル契約を追加し、BLS曲線に基づくゼロ知識証明のアプリケーションの開発をより現実的なものにします。

EIP-2935: 過去のブロックハッシュをステートに保存

開発者やノードがシステムコントラクトのストレージから過去のブロックハッシュを直接読み取れるようにします。

開発者が特定の過去のメモリブロックの内容を証明する必要がある場合、たとえば、1000個の過去のメモリブロックにおける特定のトランザクションの存在を証明するための仮想的なOptimismtic Rollup不正チャレンジでは、チャレンジャーがただそう言うしか方法がありません。

「このトランザクションが本当に1000メモリブロック前に存在したと信じてください」と、彼はそれを証明しなければなりませんが、「1000個前のメモリブロックにこのコンテンツが含まれている」という直接的な証明はありません。トランザクションがそのメモリブロックに存在することを証明しなければならない。

△ 各ブロックは親ブロックを指すので、次のブロックまで進むことができる。
△ 各ブロックは親ブロックを指すので、次のブロックまで遡ることができる。

現在ブロック10000にいるとして、ブロック9000にトランザクションXが存在することを証明することが不正チャレンジだとすると、チャレンジャーはブロック10000のハッシュから始め、ブロック 10000が接続されている親ブロック9999のハッシュを証明し、ブロック9998...メモリブロック 9999がブロック9999に接続されるまで...メモリブロック9998がブロック9999に接続されるまで...メモリブロック9999がブロック9999に接続されるまで...メモリブロック9998がブロック9999に接続されるまで...メモリブロック9999がブロック9999に接続されるまで...メモリブロック9999が証明されるまで。

EIP-2935の後、システムコントラクト（0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCCCに配置される）が存在し、そのシステムコントラクトは最大8192個まで格納される。ストレージには、以前のメモリ・ブロックのハッシュが最大8192個格納される。新しいメモリブロックが作成されるたびに、このシステムコントラクトは自動的に更新され、前のブロックのハッシュがシステムコントラクトに書き込まれます（8192個の前のブロックのハッシュが上書きされます）。

このようにして、Optimismtic Rollup Fraud Challengeの場合、挑戦者はメモリブロックごとにメモリブロックを証明する必要はありませんが、その代わりに、メモリブロック10000のチェーンの現在の状態において、システムコントラクトのストアの1つ（メモリブロック9000に対応する）の値がメモリブロック9000のハッシュであることを証明することができます。範囲が8192以上、たとえばメモリブロック1000の場合、メモリブロック1808（= 10000 - 8192）のハッシュを証明し、メモリブロック1808の下のチェーンの状態のシステムコントラクトでメモリブロック1000のハッシュを証明するのは、せいぜいもう1ステップです。

これはまた、将来のステートレスクライアントへの道を開くものでもあります。履歴内のすべてのメモリブロックのブロックヘッダーを保存する代わりに、将来のライトノードは、履歴内のメモリブロックのハッシュ値またはメモリブロックの内容を使用する代わりに、前の詐欺チャレンジの例と同じ証明方法を使用して、他の人に証明を提供するよう求めることができます。前の詐欺チャレンジの例の証明方法を使用して証明を提供するために。

EIP-7623: : calldataのコストを増やす 

calldataを使用してデータを公開するコストを増やし、Block Gas LimitとBlobの数を増やすのに十分な安全領域を作ります。

Rollupのデータ配信のニーズが高まり、EIP-4844でBlobを導入してRollupのデータ配信を非常に安価にした後、Blobの数を増やすことは待望のアップグレードであり、あるいは最近のBlock Gas Limitの増加の推進の場合のように、より堅牢な方法でリソースを増やす必要性への対応でした。

△ブロックガスの上限を増やすことへの支持が高まっている。

しかし、ブロックガスの上限であれ、引き上げられるBlobsの数であれ、取引されるデータ量が大きくなればなるほどイーサリアムのp2pネットワークに負担がかかるため、データの配布コストも引き上げられない限り、攻撃者にとって攻撃効率が高くなります。

EIP-7623プロトコルのリリースにより、calldataのコストは「ゼロバイト：4ガス、非ゼロバイト：16ガス」から「ゼロバイト：10ガス、非ゼロバイト：40ガス」へと2.5倍に引き上げられます。

もともと、攻撃者がスパムのためにブロックガス制限（30M）全体を使用した場合、ブロックサイズは約1.79MB（30M÷16）となり、平均ブロックサイズの約100KBと比較されます。一方、ブロックガス制限が40Mに引き上げられた場合、攻撃者は約2.38MBのブロックを作成できます。ブロックガスの上限が40Mに引き上げられた場合、攻撃者は約2.38MBのメモリブロックを作成できる。calldataコストが2.5倍になると、攻撃者の効率は30Mで最大0.72MB、40Mで最大0.95MBまで低下するため、Block Gas LimitとBlobの数をより慎重に増やすことができる。

1. トランザクションのガス使用量を計算するオリジナルの方法。calldataコスト：つまり、calldataは「ゼロバイト：4ガス、非ゼロバイト：16ガス」として計算され、さらにトランザクションの実行で消費されるガスとコントラクトの展開で消費されるガスが加算されます。

2. calldataガス使用量の計算は単純ですが、計算は新しいコストで行われます。calldataは「ゼロバイト：10ガス、非ゼロバイト：40ガス」として計算されますが、トランザクションを実行するために消費されるガスや、コントラクトを展開するために消費されるガスは考慮されていません。 したがって、「データを公開するためにcalldataを取らない」平均的なユーザー（例えば、Uniswapにデータを交換しに行く人）にとっては、ガスの主なコストはトランザクションのコストとなります。したがって、「データを公開」していないユーザー（Uniswapにデータを交換しに行く人など）にとっては、ガスの主な消費量は実行時であり、仮にcalldataが新しいコストで計算されたとしても、実行時に消費されるガスの量を超えることはないので、一般的なユーザーには影響はありません。

実際に影響を受けるのは、小規模なロールアップです。Blobは固定サイズ、固定コストのソリューションであるため、小規模なロールアップはBlobでは非効率的であり、calldataの方がコスト効率が高いのですが、EIP-7623では、これらのロールアップのコストは2.5倍に増加します。

EIP-7691:Blobのスループットを向上させる 

Blobの数を強調表示することで、Rollupsがデータを公開するために利用できるスペースの量を増やします。

EIP-7691は、データを公開するために使用できるBlobの数を増やします。

注釈: Blobハンドリニューアルマーケットには、ハンドリニューアルの調整速度が不十分であったり、ハンドリニューアルの床が低すぎるなど、微調整が必要な設計面もありますが、これはBlobハンドリニューアルマーケットの設計の一部ではありません。しかし、これはこの技術協定が扱う問題ではありません。

その他のプロトコル

EIP-7549: 委員会インデックスを認証の外に移動する

認証者の投票内容を調整することで、投票の集約を容易にし、p2pネットワークの力を弱めることができます。

検証者はエポックごとにランダムに委員会のグループに割り当てられ、

メモリのブロックに投票します。各委員会に所属する検証者の投票はまとめて集計できるため、p2pネットワークを通過する投票数を減らすことができますが、検証者の投票には「この検証者がどの委員会に所属しているか」という情報が含まれるため、委員会ごとに投票内容が異なることになります。

この結果、異なる委員会からの投票は、たとえそれらがすべて同じメモリ ブロックに投票したとしても、一緒に集計されません。

EIP-7549では、投票内容から「このバリデーターはどの委員会に所属しているか」という情報を削除し、投票内容が同じであれば、異なる委員会のバリデーターをまとめて集計できるようにしています。これにより、p2pネットワークを通過する投票数がさらに減り、p2pネットワークのパワーが低下します。

EIP-7840:EL設定ファイルにBlobスキームを追加する  

実行レイヤーでBlobパラメーター用のプロファイルを作成することで、実行レイヤーのノードがコンセンサスレイヤーのノードにBlob関連のパラメーターを問い合わせる手間を省くことができます。

現在、Blobパラメーターはコンセンサスレイヤーノードに保存されていますが、実行レイヤーノードは特定の状況（たとえば、RPC eth_feeHistory）でそれらを必要とするため、コンセンサスレイヤーノードにそれらを求める必要があります。

EIP-7840は、実行層でBlobパラメータのプロファイルを作成し、実行層ノードは、コンセンサス層ノードに問い合わせることなく、このプロファイルからBlobパラメータを直接読み取ることができます。