著者名 NIC Lin, MediumPectraのハードフォークは2025年3月にメインネット展開を予定しています。Pectraのアップグレードには11の技術提案（EIP）が含まれており、それらは次のとおりです：* EIP-2537:BLS12-381カーブ操作プリコンパイル* EIP-2935: State に過去のブロックのハッシュ値を保存* EIP-6110: チェーン上のバリデーター預金を提供します* EIP-7002: 実行レイヤーでの終了トリガー* EIP-7251: MAX\_EFFECTIVE\_BALANCE* EIP-7549: コミットティーインデックスを検証の外に移動する* EIP-7623:通話データコストの増加* EIP-7685: 共通実行層リクエスト* EIP-7691: Blobのスループットを増やす* EIP-7702: EOAアカウントのコードを設定する* EIP-7840: EL構成ファイルにBlobスケジュールを追加## **ステーキングに関する技術協定****EIP-6110: BLS12-381 曲線演算プリコンパイル**ユーザーがステーキングに参加するための処理プロセスを簡素化し、待ち時間を大幅に短縮します。ユーザーのステーキング方法は、32 ETHを実行レイヤーに預けてイベントログに記録し、その後、コンセンサスレイヤーがイベントログを解析してステーキングに参加したかどうかを判断し、ステーキングに参加したユーザーが検証者になります。ただし、共識層の検証者は最初にどの時間点に合意に達したかを指定する必要があります。さもないと、一部の検証者が5つの新しいエントリを見る一方、他の検証者は3つしか見ないことに気付くかもしれません。そのため、共識層の検証者は、どの実行層ブロック（eth1data）を参照するか投票し、皆が同じ実行層ブロックを見ていることを確認します。しかし、最初の設計では、実行レイヤーで重大なエラーが発生してチェーンが分岐することを避けるために、参照される実行レイヤーブロック（eth1data）は約10時間前のものになります。これにより、重大なエラーが発生した場合、コンセンサスレイヤーの開発者が適切に対応するための十分な時間が確保されますが、これはステーキングに参加するためにも10時間以上待たなければならないことを意味します。! [](https://img.gateio.im/social/moments-bbadb1f667d3cee0098bf70caff78be0)△CLブロック内の10900000eth1data、そこに記録されているブロックハッシュは、10時間前に登場した実行層ブロックの21683339です。EIP-6110の技術プロトコルを実行した後、ユーザーの契約に関する担保データは直接実行レイヤーの一部になります。共識レイヤーブロック自体が実行レイヤーブロックを含むため（eth1dataではない）、共識レイヤーの検証者はもはや「参照する実行レイヤーブロックが同じであることを確認する」必要がありません。共識レイヤーブロックが3分の2以上の検証者の投票によって確認されると、参加者は同じ実行レイヤーブロックを見ているという共識に達します。したがって、担保に参加したユーザーは、最短で約13分後に実行レイヤーブロックが処理されると有効になります。同様に、共識レイヤークライアントは担保データを処理するために元々使用していた複雑なロジックを削除できます。**EIP-7002: 履歴ブロック ハッシュを状態に保存**これは、バリデーターが預金や収益をアンステークまたは引き出しするためのプロセスを改善し、バリデーターのリスクを軽減するために使用できます。ステーキングに参加するには、バリデーターキーと出金認証情報の2つのキーが必要です。Validator Keyは、バリデーターの作業内容を検証するために使用され、Withdrawal Credentialは、バリデーターがステーキングから退出する際に担保金と収益が送金されるアドレスを検証するために使用されます。また、現在、ステーキングからの退出にはValidator Keyが必要です。Validator Keyを失くすと、バリデータの作業を実行できなくなり、ステーキングも取り消せなくなります。Withdrawal Credentialを失くすと、全てのステークと収益が失われます。また、一部のユーザーはLidoなどのサードパーティのステーキングサービスを利用しており、これらのプラットフォームを使用する際には、ユーザー自身でWithdrawal Credentialを保管する必要があり、その際にはValidator Keyはサービスプロバイダーによって保管され、バリデータの作業を代行されます。EIP-7002テクノロジーを実行すると、ユーザは「Withdraw コンテラクト」を呼ぶことができます（ありとは0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAAにデプロイされている）。このここで、プレスチェクトウィジェンをイヵアウディングしようとしています（イエクスト）。ウィジェンドーのキーを失望した場合も、このここを使用してプレスチェクトを退出することができます。* リクエストを開始するためのパラメータには、validator\_pubkey と amount: validator\_pubkey はバリデータの Validator(Public) Key、amount は出金する金額です。* リクエストを開始した Withdrawal Credential は、バリデーター\_pubkey バリデータの Withdrawal Credential である必要があります。※出金コントラクトを呼び出してリクエストを開始する場合、ガス料金(ETH)は現在の出金リクエスト数に応じて計算され、リクエスト数が多い場合はガス料金が増加します。*ユーザーの引き出し資格情報が契約の場合、引き出し契約に移動して現在の料金額を取得し、リクエストを開始して料金を添付できます。 ただし、出金認証情報がEOAアカウントの場合、正確な手数料を取得する方法がないため、事前にオフチェーンをシミュレートし、超過手数料(返金されません)を支払うことで、リクエストが正常に実行されるようにすることができます。*注意：あなたの出金証明書がまだBLS公開鍵形式である場合は、まずELアドレス形式に変更する必要があります。***EIP-7251: MAX\_EFFECTIVE\_BALANCE** ステーキング枠上限を大幅に引き上げることで、検証者の数を減らし、上限に達していない検証者は自動的にステーキング報酬を受け取ることができます。ユーザーは、検証者として登録するために最大 MAX\_EFFECTIVE\_BALANCE の量のETHを提供する必要があり、それ以上でもそれ以下でもない（現在のMAX\_EFFECTIVE\_BALANCEは32ETHです）。1024ETHを保有しているユーザーがステーキングを行う場合、32回に分けてステーキングを行い、32の検証者を有効にし、32の検証者ノードを実行できます。そして、積極的にステーキングに参加することで、現在約100万の検証者が存在し続け、共識レイヤーの状態データがより多くなり、共識レイヤーのp2pネットワーク層の負荷がより大きくなることにつながっています。なぜなら、各スロット（12秒ごと）で数万の検証者の署名がp2pネットワーク層で継続的に伝播および集約される必要があるからです。EIP-7251テクニカルプロトコルの実装後、最小ステーキング制限(MIN\_ACTIVATION\_BALANCE)は32ETHのままですが、上限(MAX\_EFFECTIVE\_BALANCE)は2048ETHに大幅に引き上げられ、32~2048の間で任意の量のETHをステーキングでき、ステーキング報酬を得ることができ、定期的に収入を引き出す必要がなくなり、32ETHを蓄積した後も新しいETHをステーキングし続けることができます。現時点では、既存の検証者は特にステークを解除してから再度統合する必要はありません。代わりに、新しく実行レイヤーに追加された「マージデポジット用の契約」（0x00431F263cE400f4455c2dCf564e53007Ca4bbBbにデプロイされています）を直接利用できます。検証者の引き出し資格情報を使用して、契約を呼び出してデポジットの統合リクエストを開始できます。* マージデポジットリクエストのパラメータには、source\_pubkeyとtarget\_pubkeyが含まれます: 両方のキーはバリデータのバリデーターキーであり、ソースバリデーターはターゲットバリデーターにマージされます。* リクエストを開始する Withdrawal Credential は、ソース検証者の Withdrawal Credential である必要があります。* 合併デポジット契約を呼び出すときに手数料（ETH）を添付する必要があります。手数料は現在のリクエスト数に応じて計算され、リクエスト数が多い場合は手数料が上昇します。* もしユーザーのWithdrawal Credentialが契約である場合、現在の手数料額を取得するためにデポジット契約を呼び出してからリクエストを行い、手数料を添付することができますが、Withdrawal CredentialがEOAアカウントである場合、正確な手数料を取得する方法はありません。その場合、事前にチェーンでシミュレーションを行い、余分な手数料を支払って（返金されない）リクエストが成功することを保証する必要があります。注:引き出し資格情報がBLS公開鍵形式の場合は、最初にELアドレス形式に切り替える必要があります。**EIP-7685: 共通実行レイヤー要求**正式なEL-> CL情報パイプラインを確立し、ユーザーとステーキングサービスがコンセンサスレイヤーに直接リクエストを送信できるようにします。ユーザーは実行レイヤーからコンセンサスレイヤーに直接リクエストを送信でき、ステーキングサービス(Lidoなど)はより分散化された方法で運用できます。 例としては、EIP-7002 のステーク解除要求や EIP-7251 の預金統合要求などがあります。 この技術プロトコルがなければ、LidoユーザーはLidoノードサービスプロバイダーを信頼して、コンセンサスレイヤーでステーキング解除またはマージデポジットを実行する必要があります。 この技術プロトコルにより、Lido のユーザーは、実行レイヤーのガバナンス コントラクトを通じて直接要求を送信できます。これらのリクエストには、異なるタイプのリクエストを区別するためのリクエストタイプがあり、リクエストは異なるコントラクトを介して開始され、最終的にこれらのリクエストは実行レイヤーのメモリブロックに書き込まれるため、コンセンサスレイヤーは、個々の解析ロジックを記述することなく、実行レイヤーのメモリブロックを介してこの情報を直接取得できます。EIP-6110、EIP-7002 および EIP-7251 はすべて EIP-7685 によって定義された標準に基づいてリクエストを作成します：* EIP-6110 ステーキングリクエスト：Request Type=0、Depositコントラクトを介して(0x00000000219ab540356cbb839cbe05303d7705fa) 要求の開始。* EIP-7002 デポジット解除リクエスト：Request Type=1、Withdrawコントラクトを介して(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) 要求の開始。* EIP-7251 デポジット統合リクエスト：リクエストタイプ=2、Consolidation契約を介して(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) 要求の開始。## **ユーザーエクスペリエンスを向上させるための技術プロトコル****EIP-7702: EOA アカウント コードの設定**EOAアカウントを任意のコントラクトアカウントに変身させることで、使用体験を大幅に向上させます。EOAアカウントの使用には、次のようないくつかの欠点があります。* 私鍵やニーモニックを記録し保管する必要があるため、新規ユーザーの登録と使用はハードルが高いです。* EOAアカウントは、1つのトランザクションにつき1つの操作しか実行できず、例えば、UniswapでUSDTをETHに交換したい場合は、まずUSDTを承認するためのトランザクションを開始してから、別のトランザクションを送信して交換を実行する必要があります。*アカウントの一部の操作を第三者に引き渡してユーザーに代わって操作するなど、ユーザーがすべての雑用を個人的に処理し、操作ごとにトランザクションに署名する必要があるなど、精緻化できない権限管理。* リカバリメカニズムはありません。秘密鍵やニーモニックを自己管理する必要があり、失くした場合はアカウントの資産を取り戻すことはできません。スマートコントラクトアカウント(Safeなど)の場合、上記の問題を解決できます。*ユーザーは、携帯電話(またはコンピューター)のセキュリティチップの秘密鍵を使用して承認に署名でき、秘密鍵やニーモニック単語を覚えたり、電子メールを使用して承認に署名したり、その他のさまざまな承認方法を使用したりできます。* 複数の操作を同じトランザクションでまとめることができ、元の複雑なDApp操作は、1つの署名承認と1つのトランザクションのみで完了できます。*ユーザーは、第三者に自分のアカウントを管理する権限を与えることができますが、同時に、「どの契約と対話できるか」、「どのようなアクションが実行できないか」、「資産の転送を伴う場合にのみ使用できるアセットの数」、「週に実行できない操作の数」などの制限を指定できます。* Recoveryメカニズムを追加し、自分の助記ワードや携帯電話やメールを失った場合でも、Recoveryメカニズムを介してアカウントの資産を新しいアカウントに移動できるようにします。EIP-7702提案は、EOAアカウントがコントラクトアカウントに変身する能力を付与するものです。ユーザーはEOAの秘密鍵で変身のメッセージに署名し、署名内容には「Chain ID」「変化するコントラクトアドレス」および「EOAのNonce値」が含まれています：* Chain ID：A 链の署名が B 链で再生されるのを防ぐために使用されます。ただし、Chain ID が 0 に設定されている場合、すべてのチェーンで変身することを意味します。* 変更したい契約アドレス：もしもあなたが安全な契約アドレスを入力した場合、あなたのEOAアカウントは安全な契約に変更されます；もし空のアドレス（address(0)）を入力した場合、変更をキャンセルし、単なるEOAアカウントに戻ります。* EOA のNonce値：署名の再利用を防止するために使用されます。Nonce値が増加すると、元の署名は無効になります。ただし、いくつかのポイントに注意する必要があります：1. EOA秘密鍵は引き続き使用できますユーザーのEOAアカウントが契約になっても、元のEOAアカウントと同様に引き続き使用できます。 例えば、EOAアカウントがSafeコントラクトになった場合、Safeインターフェースを使用したり、Safeトランザクションプロセスを実行したり、元のEOAウォレットでトランザクションの署名と送信を続行したりできます。 ただし、これは、アカウントのセキュリティが秘密鍵に限定されていることも意味します。2. EOA秘密鍵のセキュリティのままですユーザーの EOA がマルチサインに変わっても、彼が EOA の秘密鍵を失くしていない限り、彼のアカウントのセキュリティは常に EOA の秘密鍵のセキュリティです：彼は引き続き秘密鍵またはニーモニックをしっかり保管する必要があり、そのため彼のアカウントはマルチサインと同じくらい安全にはなりません。3. EOAアカウントのStorageはフォーマットされませんEOAアカウントがコントラクトに変換され、そのストレージにデータを書き込む場合、データが明示的に削除されない限り、EOAアカウントが別のコントラクトに変換されるか、変換がキャンセルされるため、ストレージに書き込まれたデータはフォーマットされないため、開発者は以前の変換コントラクトによって残されたデータを読み取らないように注意する必要があります。4. EIP-7702プロセスには初期化が含まれていません一般契約アカウントは通常、初期化ステップを必要とします。アカウントのデプロイ時に、アカウント所有者の情報（たとえば公開鍵またはアドレス）を同期して書き込むことで、デプロイステップが抜ける（Frontrun）のを防ぎ、アカウント所有権を失わないようにします。これは通常、契約アカウントをデプロイするファクトリー契約が「デプロイ+初期化」を実行しますが、EIP-7702は直接変更するため、ファクトリーが契約をEOAにデプロイするのではなく、攻撃者がユーザーの変身署名をコピーしてトランザクションを先にブロックチェーンに送信し、ユーザーの変身を行い、アカウントを攻撃者が制御可能な状態で初期化することができるため、開発者はEIP-7702に注意する必要があります。可能な予防方法として、初期化関数内でEOAアカウントの署名を確認することが挙げられます。そのようにすることで、抜かれても、攻撃者はそのEOAアカウントの署名を生成して初期化を完了することができません。5. 財布は変化するリクエストをチェックする必要がありますウォレットは、ユーザーのチェックを適切に行う必要があり、悪意のあるDApp Webサイトがユーザーに変換トランザクションに署名するように要求したときに要求を停止し、ユーザーに警告する必要があります。 次に、コントラクトに変換する方法の例をいくつか示します。*変更された安全なイサカアカウント*イサカアカウント## **DAppテクニカルプロトコル****EIP-2537: BLS12-381 曲線演算プリコンパイラ**BLS曲線を利用したゼロ知識証明アプリケーションのコストを削減し、より実現可能にする。EIP-2537 では、安価な BLS 曲線演算を提供するために、いくつかの新しいプリコンパイル コントラクトが追加され、BLS 曲線に基づくゼロ知識証明アプリケーションの開発がより実現可能になりました。**EIP-2935: 状態への履歴ブロック ハッシュの保存**開発者やノードがシステム契約のストレージから過去のメモリブロックのハッシュ値を直接読み取ることができます。開発者が以前のメモリブロックの内容を証明する必要がある場合、たとえば、オプティミスティックロールアップ詐欺チャレンジがトランザクションが1000個の前のメモリブロックに存在することを証明したい場合、チャレンジャーはそれを直接言うことはできません。「1000個のメモリブロック以前にこの取引が実際に存在したことを信じてください」彼は証拠を提出しなければならないが、「1000個の以前のメモリブロックにこれらの内容が含まれている」と直接証明する証拠はないため、メモリブロック「チェーン」の方法で、1つのメモリブロックずつ前に証明し、1000個の以前のメモリブロックに到達し、その後そのメモリブロックにその取引が存在することを証明しなければなりません。! [](https://img.gateio.im/social/moments-feb53cd10aa04617ec26d6c9499564e8)△ 各ブロックは親ブロックを指しているので、履歴内の任意のブロックをさかのぼって証明できます。 現在、番号10000のメモリブロックであり、不正チャレンジが番号9000のメモリブロックがトランザクションXを持っていることの証明を提供したいとすると、チャレンジャーはメモリブロック10000のハッシュから始めて、最初にメモリブロック10000に接続されている親メモリブロック9999のハッシュを証明し、次にメモリブロック9998を証明する必要があります。 メモリブロック9000までは、メモリブロック9000の内容がトランザクションXを含むように提案される。EIP-2935 以降は、最大 8192 個の以前のメモリ ブロックのハッシュを格納するシステム コントラクト (0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC に展開) があります。 新しいメモリ ブロックが生成されるたびに、システム コントラクトが自動的に更新され、前のブロックのハッシュがシステム コントラクトに書き込まれます (以前の 8192 個のメモリ ブロックのハッシュが書き換えられます)。このように、Optimismtic Rollup詐欺チャレンジの例では、チャレンジャーは、一度に1つのメモリブロックを証明するために前のメモリブロックに戻る必要はなく、メモリブロック10000チェーンの現在の状態において、システムコントラクトの特定のストレージ(メモリブロック9000に対応する)の値がメモリブロック9000のハッシュ値であることを直接証明することができる。 範囲がメモリブロック1000のように8192を超える場合、メモリブロック1808のハッシュ値(=10000〜8192)を証明し、次いで、メモリブロック1808のチェーンの現在の状態におけるシステムコントラクト内のメモリブロック1000のハッシュ値を証明するのは、せいぜいもう1つのステップである。将来的には、ライトノードはすべての履歴メモリブロックのブロックヘッダーを保存する必要はなくなり、履歴内のメモリブロックのハッシュやメモリブロックの内容を使用する必要がある場合に、前の不正チャレンジの例の証明メソッドを使用して証明を提供するように他の人に依頼するだけで済みます。**EIP-7623::通話データコストの増加** calldata を使用してデータを公開するコストを増やして、ブロック ガス制限と BLOB 制限を増やすのに十分なセキュリティで保護された領域を確保します。ロールアップのデータ リリースに対する需要が高まる中、EIP-4844 でロールアップが非常に安価な方法でデータを配置できるように BLOB が導入された後、BLOB の数を増やすことは、コミュニティが楽しみにしているアップグレードでした。! [](https://img.gateio.im/social/moments-fb891fa4e8169325d2baeef74a31f1ba)△ ブロックガスリミットの引き上げを支持するバリデーターが増えています。しかし、Block Gas Limit の増加やブロブの数の増加など、取引データ量が増加するためにEthereumのP2Pネットワークにさらなる負荷をかけることになり、これにより攻撃者の攻撃効率が向上することになります。データの公開コストも増加しない限り、攻撃者の攻撃効率が向上することになります。EIP-7623プロトコルのリリース後、コールデータのコストは、元の「ゼロバイト:4ガス、非ゼロバイト:16ガス」から「ゼロバイト:10ガス、非ゼロバイト:40ガス」に2.5倍に増加します。もともと、攻撃者がすべてのブロックガスリミット(30M)を使用してガベージデータを配置した場合、メモリブロックのデータサイズは約1.79MB(30M/16)になりますが、平均メモリブロックサイズは約100KBにすぎません。 ブロックガスリミットを40Mに増やすと、攻撃者は約2.38MBのメモリブロックを生成できます。 コールデータコストが2.5倍になると、攻撃者の効率は30Mで最大0.72MB、40Mで0.95MBに低下するため、ブロックガスリミットとブロブをより確実に増やすことができます。 ただし、この技術プロトコルは、「calldataを使用してデータを公開しない」一般ユーザーに影響を与えたくないため、トランザクションの総ガス使用量を2つの方法のいずれか高い方で計算します。1.トランザクションのガス使用量を計算する元の方法は、古いコールデータコストで計算されます:つまり、コールデータは「ゼロバイト:4ガス、非ゼロバイト:16ガス」の方法で計算され、トランザクション実行によって消費されたガスとデプロイメントコントラクトによって消費されたガスが加算されます。2. 単純に calldata Gas 使用量を計算しますが、新しいコストを使用して計算します。つまり、calldata を「ゼロバイト: 10 Gas、非ゼロバイト: 40 Gas」の方法で計算しますが、実行に消費されるGasや契約のデプロイに消費されるGasは含まれません。したがって、一般的な「calldata をデータ公開に使用しない」ユーザー（たとえば、Uniswap で交換するユーザー）にとって、主なGas消費は実行部分にあります。したがって、calldata を新しいコストで計算しても、実行に消費されるGasを超えることはありません。そのため、一般的なユーザーは影響を受けません。本当に影響を受けるのは規模が小さいRollupです。Blobは固定サイズで固定料金なので、小さなRollupはBlobを使用すると効率が悪くなり、calldataを使用した方がコストパフォーマンスが良いですが、EIP-7623の後、これらの小さなRollupのコストは2.5倍に増加します。そのため、これらはBlobを使用するか、Blobを共有してコストを分担する方法を考える必要があります。**EIP-7691: Blob スループットの増加** *Blobの数量を増やし、Rollupにより多くのデータを公開するスペースを追加します。*EIP-7691 では、ブロブの数が "ターゲット: 3 ブロブ、最大: 6 ブロブ" から "ターゲット: 6 ブロブ、最大: 9 ブロブ" に増加し、ロールアップにより多くのデータをパブリッシュするための領域が増えます。注:さらに、Blob手数料市場には、手数料調整のスピードが瞬時に足りない、手数料の下限が低すぎるなど、微調整が必要な設計がいくつかありますが、これはこの技術プロトコルが解決しようとしている問題ではありません。## **その他の技術プロトコル****EIP-7549: 委員会インデックスを検証から外す**バリデーターの投票内容を調整して、投票の集計を容易にし、P2Pネットワークへの負担を軽減します。各検証者は各エポックごとにランダムに委員会に割り当てられ、そして内存块の投票では、各委員会の検証者の投票はまとめられ、P2Pネットワークでの投票の数量を減らすことができますが、検証者の投票には「その検証者が何番目の委員会に属しているか」という情報が含まれており、これにより異なる委員会の投票はまとめることができず、それぞれが同じ内存ブロックに投票しても集計することができません。EIP-7549は、バリデーターが最初の委員会に属しているという情報を投票コンテンツから削除し、投票コンテンツが同じ場合に異なる委員会のバリデータを集約できるようにし、P2Pネットワークで可決される投票数をさらに減らし、P2Pネットワークへの圧力を軽減します。**EIP-7840: EL構成ファイルにBlobスケジュールを追加**実行レベルでBlobパラメータの設定ファイルを作成し、実行レベルのノードが共通層のノードにBlob関連パラメータを問い合わせる手間を省きます。現在、ブロブ関連のパラメータはコンセンサスレイヤーノードに保存されていますが、実行レイヤーノードはこれらのパラメータを必要とする場合もあるため(例:RPC eth\_feeHistory)、コンセンサスレイヤーノードに問い合わせる必要があります。EIP-7840は、実行レイヤーでBlob関連のパラメータに設定ファイルを作成し、実行レイヤーノードはこの設定ファイルを介してBlob関連のパラメータを直接読み取ることができ、共通層ノードに問い合わせる必要はありません。
Ethereum Pectra ハードフォーク介绍
著者名 NIC Lin, Medium
Pectraのハードフォークは2025年3月にメインネット展開を予定しています。Pectraのアップグレードには11の技術提案（EIP）が含まれており、それらは次のとおりです：
ステーキングに関する技術協定
EIP-6110: BLS12-381 曲線演算プリコンパイル
ユーザーがステーキングに参加するための処理プロセスを簡素化し、待ち時間を大幅に短縮します。
ユーザーのステーキング方法は、32 ETHを実行レイヤーに預けてイベントログに記録し、その後、コンセンサスレイヤーがイベントログを解析してステーキングに参加したかどうかを判断し、ステーキングに参加したユーザーが検証者になります。
ただし、共識層の検証者は最初にどの時間点に合意に達したかを指定する必要があります。さもないと、一部の検証者が5つの新しいエントリを見る一方、他の検証者は3つしか見ないことに気付くかもしれません。そのため、共識層の検証者は、どの実行層ブロック（eth1data）を参照するか投票し、皆が同じ実行層ブロックを見ていることを確認します。
しかし、最初の設計では、実行レイヤーで重大なエラーが発生してチェーンが分岐することを避けるために、参照される実行レイヤーブロック（eth1data）は約10時間前のものになります。これにより、重大なエラーが発生した場合、コンセンサスレイヤーの開発者が適切に対応するための十分な時間が確保されますが、これはステーキングに参加するためにも10時間以上待たなければならないことを意味します。
!
△CLブロック内の10900000eth1data、そこに記録されているブロックハッシュは、10時間前に登場した実行層ブロックの21683339です。
EIP-6110の技術プロトコルを実行した後、ユーザーの契約に関する担保データは直接実行レイヤーの一部になります。共識レイヤーブロック自体が実行レイヤーブロックを含むため（eth1dataではない）、共識レイヤーの検証者はもはや「参照する実行レイヤーブロックが同じであることを確認する」必要がありません。共識レイヤーブロックが3分の2以上の検証者の投票によって確認されると、参加者は同じ実行レイヤーブロックを見ているという共識に達します。したがって、担保に参加したユーザーは、最短で約13分後に実行レイヤーブロックが処理されると有効になります。同様に、共識レイヤークライアントは担保データを処理するために元々使用していた複雑なロジックを削除できます。
EIP-7002: 履歴ブロック ハッシュを状態に保存
これは、バリデーターが預金や収益をアンステークまたは引き出しするためのプロセスを改善し、バリデーターのリスクを軽減するために使用できます。
ステーキングに参加するには、バリデーターキーと出金認証情報の2つのキーが必要です。
Validator Keyは、バリデーターの作業内容を検証するために使用され、Withdrawal Credentialは、バリデーターがステーキングから退出する際に担保金と収益が送金されるアドレスを検証するために使用されます。また、現在、ステーキングからの退出にはValidator Keyが必要です。
Validator Keyを失くすと、バリデータの作業を実行できなくなり、ステーキングも取り消せなくなります。Withdrawal Credentialを失くすと、全てのステークと収益が失われます。また、一部のユーザーはLidoなどのサードパーティのステーキングサービスを利用しており、これらのプラットフォームを使用する際には、ユーザー自身でWithdrawal Credentialを保管する必要があり、その際にはValidator Keyはサービスプロバイダーによって保管され、バリデータの作業を代行されます。
EIP-7002テクノロジーを実行すると、ユーザは「Withdraw コンテラクト」を呼ぶことができます（ありとは0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAAにデプロイされている）。このここで、プレスチェクトウィジェンをイヵアウディングしようとしています（イエクスト）。ウィジェンドーのキーを失望した場合も、このここを使用してプレスチェクトを退出することができます。
注意：あなたの出金証明書がまだBLS公開鍵形式である場合は、まずELアドレス形式に変更する必要があります。
EIP-7251: MAX_EFFECTIVE_BALANCE
ステーキング枠上限を大幅に引き上げることで、検証者の数を減らし、上限に達していない検証者は自動的にステーキング報酬を受け取ることができます。
ユーザーは、検証者として登録するために最大 MAX_EFFECTIVE_BALANCE の量のETHを提供する必要があり、それ以上でもそれ以下でもない（現在のMAX_EFFECTIVE_BALANCEは32ETHです）。1024ETHを保有しているユーザーがステーキングを行う場合、32回に分けてステーキングを行い、32の検証者を有効にし、32の検証者ノードを実行できます。そして、積極的にステーキングに参加することで、現在約100万の検証者が存在し続け、共識レイヤーの状態データがより多くなり、共識レイヤーのp2pネットワーク層の負荷がより大きくなることにつながっています。なぜなら、各スロット（12秒ごと）で数万の検証者の署名がp2pネットワーク層で継続的に伝播および集約される必要があるからです。
EIP-7251テクニカルプロトコルの実装後、最小ステーキング制限(MIN_ACTIVATION_BALANCE)は32ETHのままですが、上限(MAX_EFFECTIVE_BALANCE)は2048ETHに大幅に引き上げられ、32~2048の間で任意の量のETHをステーキングでき、ステーキング報酬を得ることができ、定期的に収入を引き出す必要がなくなり、32ETHを蓄積した後も新しいETHをステーキングし続けることができます。
現時点では、既存の検証者は特にステークを解除してから再度統合する必要はありません。代わりに、新しく実行レイヤーに追加された「マージデポジット用の契約」（0x00431F263cE400f4455c2dCf564e53007Ca4bbBbにデプロイされています）を直接利用できます。検証者の引き出し資格情報を使用して、契約を呼び出してデポジットの統合リクエストを開始できます。
注:引き出し資格情報がBLS公開鍵形式の場合は、最初にELアドレス形式に切り替える必要があります。
EIP-7685: 共通実行レイヤー要求
正式なEL-> CL情報パイプラインを確立し、ユーザーとステーキングサービスがコンセンサスレイヤーに直接リクエストを送信できるようにします。
ユーザーは実行レイヤーからコンセンサスレイヤーに直接リクエストを送信でき、ステーキングサービス(Lidoなど)はより分散化された方法で運用できます。 例としては、EIP-7002 のステーク解除要求や EIP-7251 の預金統合要求などがあります。 この技術プロトコルがなければ、LidoユーザーはLidoノードサービスプロバイダーを信頼して、コンセンサスレイヤーでステーキング解除またはマージデポジットを実行する必要があります。 この技術プロトコルにより、Lido のユーザーは、実行レイヤーのガバナンス コントラクトを通じて直接要求を送信できます。
これらのリクエストには、異なるタイプのリクエストを区別するためのリクエストタイプがあり、リクエストは異なるコントラクトを介して開始され、最終的にこれらのリクエストは実行レイヤーのメモリブロックに書き込まれるため、コンセンサスレイヤーは、個々の解析ロジックを記述することなく、実行レイヤーのメモリブロックを介してこの情報を直接取得できます。
EIP-6110、EIP-7002 および EIP-7251 はすべて EIP-7685 によって定義された標準に基づいてリクエストを作成します：
(0x00000000219ab540356cbb839cbe05303d7705fa) 要求の開始。
(0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) 要求の開始。
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) 要求の開始。
ユーザーエクスペリエンスを向上させるための技術プロトコル
EIP-7702: EOA アカウント コードの設定
EOAアカウントを任意のコントラクトアカウントに変身させることで、使用体験を大幅に向上させます。
EOAアカウントの使用には、次のようないくつかの欠点があります。
スマートコントラクトアカウント(Safeなど)の場合、上記の問題を解決できます。
*ユーザーは、携帯電話(またはコンピューター)のセキュリティチップの秘密鍵を使用して承認に署名でき、秘密鍵やニーモニック単語を覚えたり、電子メールを使用して承認に署名したり、その他のさまざまな承認方法を使用したりできます。
EIP-7702提案は、EOAアカウントがコントラクトアカウントに変身する能力を付与するものです。ユーザーはEOAの秘密鍵で変身のメッセージに署名し、署名内容には「Chain ID」「変化するコントラクトアドレス」および「EOAのNonce値」が含まれています：
ただし、いくつかのポイントに注意する必要があります：
ユーザーのEOAアカウントが契約になっても、元のEOAアカウントと同様に引き続き使用できます。 例えば、EOAアカウントがSafeコントラクトになった場合、Safeインターフェースを使用したり、Safeトランザクションプロセスを実行したり、元のEOAウォレットでトランザクションの署名と送信を続行したりできます。 ただし、これは、アカウントのセキュリティが秘密鍵に限定されていることも意味します。
ユーザーの EOA がマルチサインに変わっても、彼が EOA の秘密鍵を失くしていない限り、彼のアカウントのセキュリティは常に EOA の秘密鍵のセキュリティです：彼は引き続き秘密鍵またはニーモニックをしっかり保管する必要があり、そのため彼のアカウントはマルチサインと同じくらい安全にはなりません。
EOAアカウントがコントラクトに変換され、そのストレージにデータを書き込む場合、データが明示的に削除されない限り、EOAアカウントが別のコントラクトに変換されるか、変換がキャンセルされるため、ストレージに書き込まれたデータはフォーマットされないため、開発者は以前の変換コントラクトによって残されたデータを読み取らないように注意する必要があります。
一般契約アカウントは通常、初期化ステップを必要とします。アカウントのデプロイ時に、アカウント所有者の情報（たとえば公開鍵またはアドレス）を同期して書き込むことで、デプロイステップが抜ける（Frontrun）のを防ぎ、アカウント所有権を失わないようにします。これは通常、契約アカウントをデプロイするファクトリー契約が「デプロイ+初期化」を実行しますが、EIP-7702は直接変更するため、ファクトリーが契約をEOAにデプロイするのではなく、攻撃者がユーザーの変身署名をコピーしてトランザクションを先にブロックチェーンに送信し、ユーザーの変身を行い、アカウントを攻撃者が制御可能な状態で初期化することができるため、開発者はEIP-7702に注意する必要があります。可能な予防方法として、初期化関数内でEOAアカウントの署名を確認することが挙げられます。そのようにすることで、抜かれても、攻撃者はそのEOAアカウントの署名を生成して初期化を完了することができません。
ウォレットは、ユーザーのチェックを適切に行う必要があり、悪意のあるDApp Webサイトがユーザーに変換トランザクションに署名するように要求したときに要求を停止し、ユーザーに警告する必要があります。 次に、コントラクトに変換する方法の例をいくつか示します。
*変更された安全なイサカアカウント *イサカアカウント
DAppテクニカルプロトコル
EIP-2537: BLS12-381 曲線演算プリコンパイラ
BLS曲線を利用したゼロ知識証明アプリケーションのコストを削減し、より実現可能にする。
EIP-2537 では、安価な BLS 曲線演算を提供するために、いくつかの新しいプリコンパイル コントラクトが追加され、BLS 曲線に基づくゼロ知識証明アプリケーションの開発がより実現可能になりました。
EIP-2935: 状態への履歴ブロック ハッシュの保存
開発者やノードがシステム契約のストレージから過去のメモリブロックのハッシュ値を直接読み取ることができます。
開発者が以前のメモリブロックの内容を証明する必要がある場合、たとえば、オプティミスティックロールアップ詐欺チャレンジがトランザクションが1000個の前のメモリブロックに存在することを証明したい場合、チャレンジャーはそれを直接言うことはできません。
「1000個のメモリブロック以前にこの取引が実際に存在したことを信じてください」彼は証拠を提出しなければならないが、「1000個の以前のメモリブロックにこれらの内容が含まれている」と直接証明する証拠はないため、メモリブロック「チェーン」の方法で、1つのメモリブロックずつ前に証明し、1000個の以前のメモリブロックに到達し、その後そのメモリブロックにその取引が存在することを証明しなければなりません。
!
△ 各ブロックは親ブロックを指しているので、履歴内の任意のブロックをさかのぼって証明できます。
現在、番号10000のメモリブロックであり、不正チャレンジが番号9000のメモリブロックがトランザクションXを持っていることの証明を提供したいとすると、チャレンジャーはメモリブロック10000のハッシュから始めて、最初にメモリブロック10000に接続されている親メモリブロック9999のハッシュを証明し、次にメモリブロック9998を証明する必要があります。 メモリブロック9000までは、メモリブロック9000の内容がトランザクションXを含むように提案される。
EIP-2935 以降は、最大 8192 個の以前のメモリ ブロックのハッシュを格納するシステム コントラクト (0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC に展開) があります。 新しいメモリ ブロックが生成されるたびに、システム コントラクトが自動的に更新され、前のブロックのハッシュがシステム コントラクトに書き込まれます (以前の 8192 個のメモリ ブロックのハッシュが書き換えられます)。
このように、Optimismtic Rollup詐欺チャレンジの例では、チャレンジャーは、一度に1つのメモリブロックを証明するために前のメモリブロックに戻る必要はなく、メモリブロック10000チェーンの現在の状態において、システムコントラクトの特定のストレージ(メモリブロック9000に対応する)の値がメモリブロック9000のハッシュ値であることを直接証明することができる。 範囲がメモリブロック1000のように8192を超える場合、メモリブロック1808のハッシュ値(=10000〜8192)を証明し、次いで、メモリブロック1808のチェーンの現在の状態におけるシステムコントラクト内のメモリブロック1000のハッシュ値を証明するのは、せいぜいもう1つのステップである。
将来的には、ライトノードはすべての履歴メモリブロックのブロックヘッダーを保存する必要はなくなり、履歴内のメモリブロックのハッシュやメモリブロックの内容を使用する必要がある場合に、前の不正チャレンジの例の証明メソッドを使用して証明を提供するように他の人に依頼するだけで済みます。
EIP-7623::通話データコストの増加
calldata を使用してデータを公開するコストを増やして、ブロック ガス制限と BLOB 制限を増やすのに十分なセキュリティで保護された領域を確保します。
ロールアップのデータ リリースに対する需要が高まる中、EIP-4844 でロールアップが非常に安価な方法でデータを配置できるように BLOB が導入された後、BLOB の数を増やすことは、コミュニティが楽しみにしているアップグレードでした。
!
△ ブロックガスリミットの引き上げを支持するバリデーターが増えています。
しかし、Block Gas Limit の増加やブロブの数の増加など、取引データ量が増加するためにEthereumのP2Pネットワークにさらなる負荷をかけることになり、これにより攻撃者の攻撃効率が向上することになります。データの公開コストも増加しない限り、攻撃者の攻撃効率が向上することになります。
EIP-7623プロトコルのリリース後、コールデータのコストは、元の「ゼロバイト:4ガス、非ゼロバイト:16ガス」から「ゼロバイト:10ガス、非ゼロバイト:40ガス」に2.5倍に増加します。
もともと、攻撃者がすべてのブロックガスリミット(30M)を使用してガベージデータを配置した場合、メモリブロックのデータサイズは約1.79MB(30M/16)になりますが、平均メモリブロックサイズは約100KBにすぎません。 ブロックガスリミットを40Mに増やすと、攻撃者は約2.38MBのメモリブロックを生成できます。 コールデータコストが2.5倍になると、攻撃者の効率は30Mで最大0.72MB、40Mで0.95MBに低下するため、ブロックガスリミットとブロブをより確実に増やすことができます。 ただし、この技術プロトコルは、「calldataを使用してデータを公開しない」一般ユーザーに影響を与えたくないため、トランザクションの総ガス使用量を2つの方法のいずれか高い方で計算します。
1.トランザクションのガス使用量を計算する元の方法は、古いコールデータコストで計算されます:つまり、コールデータは「ゼロバイト:4ガス、非ゼロバイト:16ガス」の方法で計算され、トランザクション実行によって消費されたガスとデプロイメントコントラクトによって消費されたガスが加算されます。 2. 単純に calldata Gas 使用量を計算しますが、新しいコストを使用して計算します。つまり、calldata を「ゼロバイト: 10 Gas、非ゼロバイト: 40 Gas」の方法で計算しますが、実行に消費されるGasや契約のデプロイに消費されるGasは含まれません。したがって、一般的な「calldata をデータ公開に使用しない」ユーザー（たとえば、Uniswap で交換するユーザー）にとって、主なGas消費は実行部分にあります。したがって、calldata を新しいコストで計算しても、実行に消費されるGasを超えることはありません。そのため、一般的なユーザーは影響を受けません。
本当に影響を受けるのは規模が小さいRollupです。Blobは固定サイズで固定料金なので、小さなRollupはBlobを使用すると効率が悪くなり、calldataを使用した方がコストパフォーマンスが良いですが、EIP-7623の後、これらの小さなRollupのコストは2.5倍に増加します。そのため、これらはBlobを使用するか、Blobを共有してコストを分担する方法を考える必要があります。
EIP-7691: Blob スループットの増加
Blobの数量を増やし、Rollupにより多くのデータを公開するスペースを追加します。
EIP-7691 では、ブロブの数が "ターゲット: 3 ブロブ、最大: 6 ブロブ" から "ターゲット: 6 ブロブ、最大: 9 ブロブ" に増加し、ロールアップにより多くのデータをパブリッシュするための領域が増えます。
注:さらに、Blob手数料市場には、手数料調整のスピードが瞬時に足りない、手数料の下限が低すぎるなど、微調整が必要な設計がいくつかありますが、これはこの技術プロトコルが解決しようとしている問題ではありません。
その他の技術プロトコル
EIP-7549: 委員会インデックスを検証から外す
バリデーターの投票内容を調整して、投票の集計を容易にし、P2Pネットワークへの負担を軽減します。
各検証者は各エポックごとにランダムに委員会に割り当てられ、そして
内存块の投票では、各委員会の検証者の投票はまとめられ、P2Pネットワークでの投票の数量を減らすことができますが、検証者の投票には「その検証者が何番目の委員会に属しているか」という情報が含まれており、これにより異なる委員会の投票はまとめることができず、それぞれが同じ内存ブロックに投票しても集計することができません。
EIP-7549は、バリデーターが最初の委員会に属しているという情報を投票コンテンツから削除し、投票コンテンツが同じ場合に異なる委員会のバリデータを集約できるようにし、P2Pネットワークで可決される投票数をさらに減らし、P2Pネットワークへの圧力を軽減します。
EIP-7840: EL構成ファイルにBlobスケジュールを追加
実行レベルでBlobパラメータの設定ファイルを作成し、実行レベルのノードが共通層のノードにBlob関連パラメータを問い合わせる手間を省きます。
現在、ブロブ関連のパラメータはコンセンサスレイヤーノードに保存されていますが、実行レイヤーノードはこれらのパラメータを必要とする場合もあるため(例:RPC eth_feeHistory)、コンセンサスレイヤーノードに問い合わせる必要があります。
EIP-7840は、実行レイヤーでBlob関連のパラメータに設定ファイルを作成し、実行レイヤーノードはこの設定ファイルを介してBlob関連のパラメータを直接読み取ることができ、共通層ノードに問い合わせる必要はありません。