Parse Ethereumの今後のハードフォーク – ペクトラアップグレード

導入

以前の記事では、Ethereum Validatorのライフサイクルを詳細にレビューし、今後のElectra Hard Forkに関連する複数の側面について議論しました。今度は、今後のエレクトラとプラハのアップグレードの変化に焦点を当て、それらを詳細に説明する時です。

Ethereum 2.0の「ステークの証明」の歴史は複雑です。ビーコン層がステークコンセンサスの証明を開始する一方で、既存の実行レイヤーにビーコン層を追加することから始まります。その後、POSはBellatrixハードフォークで完全にアクティブになります（ただし、撤退は有効になりません）。その後、Capella Hard Forkは引き出しを許可し、バリデーターのライフサイクルを完了します。最近のハードフォークデネブ（Dencun（Deneb/Cancun）アップグレードの一部）は、証明、自発的出口の取り扱い、バリデーター交換制限を含むタイムウィンドウなど、ビーコンチェーンパラメーターに軽微な改訂を行いました。DenCunの主な変化は、実行層で発生し、BLOBトランザクション、BLOBガス、BLOBのKZGの約束、および自己破壊操作の放棄を開始します。

現在、プラハ/エレクトラ（つまりペクトラ）ハードフォークは、実行およびコンセンサスレイヤーに重要なアップグレードを導入しています。Lidoプロジェクトの監査人として、私たちは主にこのハードフォークのコンセンサスとステーキング関連の変更に焦点を当てています。ただし、プラハの実行レイヤーの変更を無視することはできません。これらには、イーサリアムネットワークとバリデーターに影響を与える重要な機能が含まれているためです。これらの変更の詳細を掘り下げましょう。

ペクトラのより高いレベルの概要

Electraは、ビーコン層に多数の機能を紹介しています。メインの更新には次のものがあります：

• 検証剤の有効なバランスを32人から2048 ETHの間で変えることができます（固定32 ETHではなく）。

• 検証者は、二次「引き出し」バウチャーを介して出口を開始できます（アクティブ検証剤キーは不要になります）。

• ビーコン層がETH1堆積物を処理する方法を変更します（イベントは預金契約から解析されなくなりました）。

• ビーコン層の通常のETH1契約からのリクエストを処理するための新しい共通フレームワークを追加します（エレクトラ堆積物の管理方法と同様）。

一方、プラハは次の変更を実行層に導入しました。

• ZKSNARKの証拠を検証するためにBLS12-381曲線をサポートする新しい事前縮小契約（一般的なBN254曲線を除く）。

• 最大8192の履歴ブロックハッシュを保存およびアクセスするための新しいシステム契約（ステートレスクライアントにとって非常に便利です）。

• CallDataガスコストを増やしてブロックサイズを削減し、DenCunで導入されたBlobsにロールアップなどのCallData集約型の操作を移行するプロジェクトを奨励します。

• ETH1ブロックごとにより多くのブロブをサポートし、これらの数値を読み取るためのAPIを提供します。

• EOA（外部所有アカウント）が独自のアカウントコードを持つことができるようにし、Multicallsの実行や実行の委任の実行など、EOAができることを大幅に拡大します。

さらなる議論のために、関連するイーサリアム改善提案（EIP）を参照しましょう。

• EIP-7251：MAX_EFFECTIECT_BALANCEを追加しました

• EIP-7002：実行レイヤーが出口をトリガーします

• EIP-6110：検証装置堆積物はチェーン上で提供されます

• EIP-7549：委員会指数を証明から移動します

• EIP-7685：一般的な実行レイヤーリクエスト

• EIP-2537：BLS12-381曲線操作の事前補償

• EIP-2935：状態で履歴ブロックハッシュを保存します

• EIP-7623：CallDataコストを増やします

• EIP-7691：BLOBスループットが増加します

• EIP-7840：EL ConfigurationファイルにBLOBスケジュールを追加します

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

これらのEIPの一部は主にコンセンサス（ビーコン）層を含みますが、他のEIPは実行層に関連しています。特定の操作（堆積物や引き出しなど）には、コンセンサス層と実行層の間の同期の変更が必要であるため、いくつかの2つの層に及ぶものもあります。この相互依存のため、エレクトラとプラハを分離することは非現実的であるため、各EIPを順番に確認し、それぞれの場合に影響を受けるイーサリアムコンポーネントを指定します。

EIP-7251：MAX_EFFECTIECT_BALANCEを追加しました

参照：EIP-7251

最初のフェーズ0ハードフォーク以来、イーサリアムの持分の証明を準備するために、検証剤の最大有効なバランスは32 ETHにエレクトラまで固定されています。検証者の要件を少なくともspec.min_activation_balance（32 ETH）をアクティブにします。アクティベーション後、バリデーターはこの最大有効なバランスで開始しますが、有効なバランスをSpec.ejection_Balance（16 ETH）に減らし、このしきい値に達したときに排出することができます。この「最小」ロジックはElectraでは変わらないままですが、Spec.max_efftectient_balanceは2048 ETHに増加しています。したがって、バリデーターは32〜2048 ETHを堆積させてアクティブにすることができ、そのすべてが有効なバランスに寄与します。このシフトは、「ステークの32頭」から「ステークの証明」へのシフトを示しています:)

この変数有効なバランスは、次のために使用されます。

• 効果的なバランスに比例して、ブロック提案者になる可能性を高める

• 効果的なバランスに比例して、同期委員会のメンバーになる可能性を高める

• 相対的な削減と非アクティブな罰則の量を計算するための根拠として

最初の2つのアクティビティは、バリデーターにとって最もやりがいのあるアクションです。したがって、エレクトラの後、大規模なステーキングのバリデーターは、有効なバランスに比例する頻度で、ブロック提案および同期委員会により頻繁に参加します。

別の影響はカットに関係しています。すべてのカットは、検証剤の有効なバランスに比例します。

• 「即時」および「遅延」カットは、高い利害関係のバリデーターにとってさらに大きくなります。

• 総誓約を備えたカットオフバリエーターを備えた「遅延」カット罰金も大きくなります。これは、総誓約の「カットオフ」部分が大きくなるためです。

• より高い有効なバランスでバリデーターを報告する内部告発者は、株式の減少の大部分を受け取ります。

エレクトラはまた、カット比の変更を提案し、スラッシュされたバリデーターのバランスの一部を定義し、内部告発者によってそれを受け取りました。

次は無効性の影響です。アクティブ（証明または提案）するとバリデーターがオフラインになると、無効性スコアが蓄積され、各サイクルの無効性ペナルティが課されます。これらの罰則は、バリデーターの有効なバランスにも関係しています割合関係。

有効なバランスの増加により、検証剤の「交換制限」も変更されています。「Electraの前」では、バリデーターは通常同じ有効なバランスを持ち、出口交換制限は「サイクルでは、最大1/65536（spec.churn_limit_quotient）の総利害がある」と定義されています同じステークで「固定」数の検証者出口を作成します。ただし、エレクトラの後、総誓約の重要な部分を表しているため、「クジラ」は数件の「クジラ」が出るだけかもしれません。

別の考慮事項は、単一の検証剤インスタンスでの多くの検証キーの回転です。大規模なバリデーターは現在、大きなステーキングに対応するために、1つのインスタンスで何千ものバリデーターキーを実行することを余儀なくされており、それらを32のETHセクションに分割しています。エレクトラでは、この動作はもはや必須ではありません。財政的な観点からは、報酬と確率が誓約の量と直線的に拡大されるため、この変化はほとんど影響を与えません。したがって、32 ETHあたりの100のバリデーターは、1つの3200 ETHに相当します。さらに、複数のアクティブ検証キーが同じETH1引き出し資格を持つことができ、すべての報酬を単一のETHアドレスに撤回し、報酬合併に関連するガスコストを回避できます。ただし、大量のキーを管理するには、追加の管理コストが発生します。

バリッタバランスを集約する機能により、新しい実行レイヤー要求タイプが追加されます。以前は、預金と撤退がありました。さて、別のタイプがあります：集約要求。2つのバリデーターを1つに組み合わせます。この操作リクエストには、ソース検証者の公開キーとターゲット公開キーが含まれ、預金と引き出しと同様に処理されます。集約は、預金や引き出しのように、保留中の要求とバランスの交換制限もあります。

概要は次のとおりです。

• 小さな独立したバリデーターの場合、Electraは、実効バランス（および報酬）を自動的に増やす能力を導入します。以前は、32 ETHを超える余剰は撤回することしかできませんでしたが、エレクトラの後、この余剰は最終的にその効果的なバランスに貢献します。ただし、有効なバランスは、spec.efftectient_balance_increment（1 ETH）の倍数のみを増加させることができます。つまり、増加は次の「1 ETH制限」後にのみ発生することを意味します。

• 大規模な独立したバリデーターの場合、Electraは、複数のアクティブなバリッタキーを1つに統合できるようにすることにより、重要な管理の簡素化を提供します。これはゲームを変えることはありませんが、1×2048の株式を操作することは、64×32ステークを管理するよりも間違いなくはるかに簡単です。

• ユーザーからわずかなステーキングを収集し、バリデーター間で割り当てるモバイルステーキングプロバイダーの場合、Electraはステーキング割り当てスキームの柔軟性を高めますが、固定された32 ETH有効なバランスに基づいてバリッタを考慮して、重度のリファクタリングを実行する必要があります。

もう1つの重要なトピックは、リスクと報酬を評価しようとする新しい参加者に特に関連するバリデーターの履歴データと利益の推定です。Electra（この執筆時点で）の前に、32 ETHキャップ（実際には最小または最大の両方）は、履歴データに均一性を生み出しました。すべてのバリデーターには、同じ検証バランス、報酬、個別の削減、ブロック提案頻度、およびその他のメトリックがあります。この均一性により、イーサリアムは統計的な外れ値なしでコンセンサスメカニズムをテストすることができ、それにより貴重なネットワークの動作データを収集します。

エレクトラの後、ステーキングの分布は大幅に変化します。大規模なバリデーターは、ブロック提案と同期委員会により頻繁に関与し、削減の罰則が大きくなり、遅延カット、アクティベーションキュー、出口キューへの影響が大きくなります。これはデータの集約に課題をもたらす可能性がありますが、イーサリアムのコンセンサスは、非線形コンピューティングが最小限であることを保証します。唯一の非線形コンポーネントは、SQRT（Total_efftectient_balance）を使用して、すべてのバリデーターに適用される基本報酬を計算します。これは、Validatorの報酬とカットを「1人のETH」ベースで推定できることを意味します（または、より正確には、Spec.Effent_Balance_Incrementに基づいて、将来変更される可能性があります）。

詳細については、以前の記事に関するBalidatorの動作をご覧ください。

EIP-7002：トリガー可能な実行レイヤーの出口

参照：EIP-7002

Ethereumの各バリデーターには、アクティブキーと引き出しキーの2つのキーペアがあります。アクティブなパブリックBLSキーは、ビーコンチェーンの検証剤の主要なアイデンティティとして機能します。ビーコンチェーンは、ブロック、プルーフ、カット、委員会の集約を同期させるために使用されます。出口）。2番目のキーペア（「撤退バウチャー」）は、別のBLSキーペアまたは通常のETH1アカウント（秘密キーとアドレス）になります。現在、Active BLS秘密キーによって署名された引き出しメッセージは、ETHアドレスに抽出する必要があります。このEIPは変更されました。

実際、これら2つの（アクティブおよび引き出し）キーペアの所有者は異なる場合があります。Verifierのアクティブキーは、検証の責任を担当します。サーバーの実行、正常に実行するなど、撤退バウチャーは通常、報酬を受け取り、資金を担当するステークオーナーによって制御されます。現在、撤退バウチャーを制御する誓約所有者のみが、検証者の出口を開始できず、報酬のみを撤回することができます。この状況により、検証者のアクティブなキーオーナーは、検証者のバランスを「人質」として効果的に保持することができます。検証者は出口メッセージを「事前に署名」して利害関係者に引き渡すことができますが、この回避策は理想的ではありません。さらに、抽出と出口の両方が、現在、専用のAPIを介してビーコン層のバリデーターとの相互作用が必要です。

最良の解決策は、定期的なスマートコントラクトコールを通じて、利害関係者が出口操作と引き出し操作の両方を実行できるようにすることです。これには、標準のETH1署名チェックが含まれ、操作が大幅に簡素化されます。

このEIPにより、利害関係者は、ETHアドレスから専用のスマートコントラクトに標準的なトランザクションを送信することにより、引き出しと終了をトリガーできます（「デポジット」契約を使用して既存のデポジットプロセスと同様）。抽出するプロセス（または十分な利害関係が削除されたときに終了）は次のとおりです。

• プレッジャーは、システムの「撤退」契約に引き出し要求（「リクエストで」）を送信します。

• 契約は、潜在的な悪意のある攻撃を緩和するために特定の料金（ETH）に請求し、EIP-1559と同様に、リクエストキューが忙しいときに料金が増加します。

• 契約により、「In」の引き出し/終了要求が保存されます。

• ブロックがビーコン層に提案されると、キューの「in」の引き出し/出口要求がストレージから取得されます。

• ビーコン層は、「in」要求を処理し、アクティブ検証剤のバランスと相互作用し、検証剤を出るように配置し、「out」引き出し要求を形成します。

• 「Out」の引き出し要求は実行層で処理され、利害関係者はETHを受け取ります。

堆積物はETH1ブロックでトリガーされ、「保留中」のデポジットキューを介してビーコン層に「移動」されますが、引き出しは異なるスキームに従います。それらはビーコン層で（CLIを介して）トリガーされ、その後ETH1ブロックに「移動」します。両方のスキームは、同じ共通フレームワークを使用して動作します（以下に説明するように）：ETH1レイヤーでリクエストを作成し、「保留中」のデポジット/引き出し/マージキューを処理し、ビーコン層で処理します。撤退などの「出力」操作の場合、出力キューも処理され、結果はETH1ブロックで「解決」されます。

このEIPを使用すると、ステーカーは通常のETHトランザクションを使用して、バリデーターCLIと直接対話したり、バリデーターのインフラストラクチャにアクセスしたりせずに、バリデーターを抽出および終了できます。これにより、特に大規模なステーキングプロバイダーにとって、ステーキング業務が大幅に簡素化されます。Verifier Infrastructureは、アクティブ検証剤のキーのみが維持され、すべてのステーキング操作を他の場所で処理できるため、ほぼ完全に分離できるようになりました。それは、独立したステイカーがアクティブなバリデーターのアクションを待つ必要性を排除し、コミュニティステーキングモジュールのようなLidoサービスのオフチェーン部分を大幅に簡素化します。

したがって、このEIPはステーキング操作を「完了」し、ETH1層に完全に移行し、インフラストラクチャのセキュリティリスクを大幅に削減し、独立したステーキングイニシアチブの分散化を強化します。

EIP-6110：チェーンへの検証剤堆積物の供給

参照：EIP-6110

現在、預金は、システムの「デポジット」契約のイベントを通じて達成されています（以前の記事で詳細に説明したように）。契約はETHおよび検証者の資格情報を受け入れ、「Disp（）」イベントを発行します。イベントは、ビーコン層のデポジットリクエストに解析され、変換されます。システムには多くの欠点があります。ビーコンチェーン層のeth1dataに投票する必要があり、それが大幅に遅れを追加します。さらに、ビーコン層は実行レイヤーを照会する必要があります。これにより、複雑さがさらに向上します。これらの問題については、EIPで詳しく説明しています。これらの問題の多くを処理せずに簡単に行う方法は、指定された場所のETH1ブロックに直接預金リクエストを含めることです。このメカニズムは、以前のEIPで説明されている引き出し処理プロセスに似ています。

このEIPで提案されている変更は有望です。ETH1DATA処理は完全に削除できるようになり、ETH1側のイベントとビーコン層の堆積除去（現在約12時間）間の投票または長期の遅延がなくなりました。また、預金契約スナップショットのロジックも削除します。このEIPは堆積物処理を簡素化し、上記の撤退処理スキームに合わせます。

ステーカーとバリデーターの場合、これらの変更は、堆積物とバリデーターの活性化の間の遅延を大幅に減らします。バリデーターが切断されると、必要なサプリメントも高速になります。

このEIPについてこれ以上言うことはありません。ただし、時代遅れのロジックを削除し、プロセスを簡素化し、関係者全員のより良い結果を生み出すことを除いて、これ以上言うことはありません。

EIP-7685：一般的な実行レイヤーリクエスト

参照：EIP-7685

このEIPは、これらのEIPの基礎を築くため、預金/撤回/合併に関連する最初の3つのEIPの前に提案されるべきでした。ただし、ここでの紹介は、ETH1（実行）とビーコン（コンセンサス）チェーンブロック（レイヤー）の間の一貫したモバイル専用データに対する需要の高まりを強調することです。このEIPは2つのレイヤーに影響を及ぼし、従来のETHトランザクションによってトリガーされる要求処理をより効率的にします。現在、私たちは次のように観察しています：

• ETH1ブロックのデポジットイベントは、処理のためにビーコンブロックに「移動」されます。

• ビーコンブロックの引き出し要求（CLIを使用）は、処理のためにETH1ブロックに「移動」されます。

• Verifier Mergeを処理する必要があります。これは、ETH1＆GT;ビーコンリクエストでもあります。

これらの3つの操作は、実行レイヤーとビーコン層を切り替える際に、さまざまなタイプのリクエストの一貫した処理の必要性を示しています。さらに、ETH1レイヤーのみを使用してこれらの操作をトリガーする機能が必要です。これにより、バリデーターのインフラストラクチャをステーキングマネジメントインフラストラクチャから隔離し、セキュリティが改善されるためです。したがって、そのような要求を管理するための一般的なソリューションは、実用的で必要です。

このEIPは、少なくとも3つの主要な状況のフレームワークを確立します：預金、引き出し、および合併。これが、初期のEIPがextreelal_request_typeやdepose_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 Hard Forksによって導入された大規模なチャンクのKZGコミットメントも、ペアリングを使用してブロックコミットメントを検証します。

スマートコントラクトでBLS署名またはZKSNARK証明を確認する場合は、計算上のこれらの「ペア」を計算する必要があります。Ethereumには、BN254曲線動作のために、すでに縮小契約（EIP-196およびEIP-197）があります。ただし、BLS12-381曲線（現在はより安全で、より広く使用されていると見なされています）は、事前コンパイルとしてまだ実装されていません。このような事前化がない場合、ここに示すように、スマートコントラクトでペアリングやその他の曲線操作を実装するには、多くの計算が必要であり、巨大なガスを消費します（約10^5〜10^6ガス）。

このEIPは、特にBLS12-381曲線に基づいた安価なBLSの署名検証で、多くの潜在的なアプリケーションへの扉を開きます。これにより、さまざまな目的でしきい値ソリューションを実現できます。前述のように、Ethereum ValidatorsはBLS12-381ベースの署名を使用しています。このEIPを使用すると、標準のスマートコントラクトが集約された検証剤署名を効率的に検証できるようになりました。これにより、BLS署名はブロックチェーンで広く使用されているため、コンセンサスの証明とネットワーク資産全体のブリッジングを簡素化できます。しきい値BLS署名自体により、投票、分散型乱数生成、多額の署名など​​のための多くの効率的なしきい値スキームの構築が可能になります。

安価なZksnarkの証明検証は、多数のアプリケーションのロックを解除します。多くのZksnarkベースのソリューションは現在、高い証明検証コストによって妨げられており、特定のプロジェクトをほとんど非実用的にしています。このEIPにはそれを変える可能性があります。

EIP-2935：状態で履歴ブロックハッシュを保存します

参照：EIP-2935

このEIPは、ブロックチェーン状態に8192（約27.3時間）の歴史的ブロックハッシュを保存することを提案し、ロールアップやスマートコントラクトなどのステートレスクライアントに拡張履歴を提供します。Blockhash Opcodeの現在の動作を保持し、256ブロックの制限を維持しながら、履歴ハッシュの保存と取得のために特別に設計された新しいシステム契約を導入することをお勧めします。この契約は、実行レイヤーがブロックを処理するときにset（）操作を実行します。get（）メソッドは、リングバッファーから必要なブロックハッシュを取得するために誰でもアクセスできます。

現在、EVMで履歴ブロックハッシュを参照することは可能ですが、アクセスは最新の256ブロック（約50分）に制限されています。ただし、特にクロスチェーンアプリケーション（実証済みの以前のブロックを必要とするデータ）およびステートレスクライアントの場合、古いブロックデータへのアクセスは重要です。

このEIPは、ロールアップおよびクロスチェーンアプリケーションで使用可能な時間枠を拡張し、外部から収集することなくEVMの履歴データに直接アクセスできるようにします。その結果、これらのソリューションはより堅牢で持続可能になります。

EIP-7623：CallDataコストを増やします

参照：EIP-7623

CallDataコストは、トランザクションペイロードの利用可能なサイズを調整し、場合によっては大きくなる可能性があります（たとえば、パラメーターとして大きな配列またはバイナリバッファを渡す場合）。重要なCallDataの使用は、主にロールアップに起因するものであり、現在のロールアップ状態を含むCallDataを介してペイロードを送信します。

ロールアップには、大規模で実績のあるバイナリデータをブロックチェーンに導入することが重要です。Dencun（Deneb-Cancun）のアップグレードは、そのようなユースケースに重要な革新を導入します – BLOBトランザクション（EIP-4844）。Blob Transactionsには、特別な「Blob」ガス料金がありますが、その主題は一時的に保存されていますが、その暗号化された証明（KZG Promise）はハッシュとともにコンセンサス層に統合されています。したがって、BLOBは、CallDataを使用してデータを保存するよりも、ロールアップに適したソリューションを提供します。

ロールアップを奨励して、このデータを「ニンジンとスティック」によって達成できます。BLOBガス料金の削減は「ニンジン」として使用され、このEIPは、「レバレッジ」としてCallDataコストを増やすことにより、トランザクションでの過剰なデータストレージを抑制します。このEIPは、次のEIP-7691（BLOBスループットの増加）を補完し、ブロックごとに許可される最大数のブロブ数を増加させます。

EIP-7691：BLOBスループットが増加します

参照：EIP-7691

BLOBは以前のDencunハードフォークに導入され、「ブロックごと」の最大数と目標数の初期値は保守的な推定値です。これは、P2Pネットワークがバリデーターノード間の大きなバイナリオブジェクトの伝播をどのように処理するかを予測する複雑さによるものです。以前の構成は良好であることが証明されているため、これは新しい値をテストするのに適切な時期になります。以前は、各ブロックのターゲット/最大ブロブ番号を3/6に設定していました。これらの制限は、それぞれ6/9に引き上げられています。

以前のEIP-7623（CallDataコストの増加）と組み合わせると、この調整により、ロールアップがCallDataからBlobsにデータを転送するようにさらに動機付けられます。最高のBLOBパラメーターを見つける作業は続きます。

EIP-7840：EL ConfigurationファイルにBLOBスケジュールを追加します

参照：EIP-7840

このEIPは、ターゲットと最大の「ブロックあたり」ブロブカウント（前述）とbaseFeeupDateFraction値をEthereum実行レイヤー（EL）構成ファイルに追加することを提案しています。また、クライアントはノードAPIを介してこれらの値を取得できます。この機能は、BLOBガスコストの推定などのタスクに特に役立ちます。

EIP-7702：EOAアカウントコードを設定します

参照：EIP-7702

これは、Ethereumユーザーに大きな変化をもたらす非常に重要なEIPです。私たちが知っているように、EOA（外部所有アカウント）はコードを持つことはできませんが、トランザクション署名（TX.ORIGIN）を提供できます。対照的に、スマートコントラクトにはbytecodeがありますが、「it」の直接的な署名を積極的に提案することはできません。追加の自動および検証可能なロジックを必要とするユーザーの相互作用は、現在、外部契約を呼び出すことにより、必要なアクションのみを実行できます。ただし、この場合、外部契約は後続の契約のMSG.SENDEになり、「ユーザーではなく契約からの呼び出し」への呼び出しを引き起こします。

このEIPは、新しいset_code_tx_type = 0x04トランザクションタイプを導入します（以前は古い0x1トランザクション、ベルリンとEIP-1559アップグレードからの新しい0x02トランザクション、およびデンコンで導入された0x03 BLOBトランザクションがありました）。この新しいトランザクションタイプにより、EOAアカウントの設定コードが可能になります。実際、EOAは「独自のEOAアカウントのコンテキストで」外部コードを実行できます。外部の観点から、トランザクションプロセス中に、EOAは外部契約からコードを「借り」て実行するようです。技術的には、これは、EOAアドレスの「コード」ストアに特別な承認されたデータタプルを追加することで達成されます（このEIPの前にEOAの場合は常に「コード」ストアは空でした）。

現在、このEIPによって提案されている新しい0x04トランザクションタイプには、配列が含まれています。

authorization_list = [[chain_id、address、nonce、y_parity、r、s]、…]

各要素により、アカウントは指定されたアドレス（最後の有効な承認項目から）からコードを使用できます。そのようなトランザクションを処理する場合、指定されたEOAのコードは特別な0XEF0100に設定されています（23バイト）。特別な魔法の価値を含めることはできません（EIP-3541による）。この魔法の価値は、このEOAを通常の契約と見なすことができず、通常の契約のように呼ばれることもないことを保証します。

このEOAがトランザクションを開始すると、指定されたアドレスを使用して、EOAのコンテキストで対応するコードを呼び出します。このEIPの完全な実装の詳細は明確ではありませんが、大きな変化をもたらすことは確かです。

大きな影響の1つは、EOAからマルチコールを直接作成できることです。複数の呼び出しはDefiの永続的な傾向であり、多くのプロトコルはこの機能を強力なツールとして提供します（Uniswap V4、Balancer V3、またはEuler V2など）。このEIPを使用すると、EOAから複数の呼び出しを直接開始できるようになりました。

たとえば、この新機能は、defi：approve（） + Anything（）の一般的な問題を解決します。このEIPは、一般的な「事前承認」ロジックを可能にするため、承認（x） +デポジット（x）を単一のトランザクションで完了できます。

EOA委託取引の実行を「代表」できるというもう1つの利点は、スポンサーシップの概念です。スポンサーシップは、新しいユーザーがイーサリアムに入るのを支援するために、頻繁に議論され、非常に望ましい機能です。

EOAに関連付けられたプログラム可能なロジックは、セキュリティ制限の実装、支出キャップの設定、必須のKYC要件など、多くの可能性を解き放ちます。

もちろん、この変更は多くの設計上の問題も提起します。1つの問題は、CHAIN_IDの使用です。これは、署名に含まれるかどうかに応じて、同じ署名が複数のネットワークで有効であるかどうかを決定します。別の複雑な問題は、ターゲットコードのアドレスを使用することと実際のバイトコードを埋め込むことの選択です。これらの2つの方法には、独自の特性と制限があります。さらに、ノンセの使用は、権限が「多目的」または「単一目的」であるかどうかを定義する上で重要な役割を果たします。これらの要素は、バッチ障害の署名や使いやすさなど、機能的およびセキュリティの問題に影響します。Vitalikはこれらの質問を議論（こちら）で提起し、さらなる調査に値します。

この変更がイーサリアムのセキュリティメカニズム、TX.ORIGINに影響を与えることは注目に値します。このEIP実装の詳細は必要ですが、必要性の動作（tx.origin == msg.sender）が変更されるようです。このチェックは、MSG.Senderが契約ではなくEOAであることを確認するための最も信頼できる方法でした。通常、extcodesizeのチェック（契約であるかどうかを確認するため）などの他の方法は、通常失敗し、回避することができます（たとえば、コンストラクターを呼び出したり、トランザクション後に事前定義されたアドレスでコードを展開したりすることにより）。これらのチェックは、再入国および稲妻のローン攻撃を防ぐために使用されますが、外部プロトコルとの統合も妨げるため、理想からはほど遠いものです。このEIPの後、信頼できる要求（tx.origin == msg.sender）チェックでさえ、時代遅れになるようです。「EOA」と「契約」の違いが適用されなくなったため、これらのチェックを削除することでプロトコルを適合させる必要があります。これで、各アドレスに関連するコードがある可能性があります。

従来のEOAとスマートコントラクトの分離はぼやけ続けています。このEIPは、すべてのアカウントが本質的に実行可能なコードであるTonのようなデザインに近づいています。プロトコルとの相互作用がより複雑になるにつれて、プログラム可能なロジックを使用してエンドユーザーエクスペリエンスを改善することは、この進化の自然なプロセスです。

結論は

プラハ /エレクトラ（ペクトラ）アップグレードは、2025年3月に予定されています。最も重要な計画された変更には次のものがあります。

• 2048 ETHまでの可変検証剤有効なステークは、株式分布、検証者スケジュールを大幅に変更し、小規模なステークを統合することにより、大規模なステークプロバイダーの管理を簡素化します。

• 実行レイヤーとコンセンサスレイヤー間の相互作用を改善し、ETH1実行ブロックとビーコンチェーンブロック間のデータ交換を簡素化します。これにより、預金、アクティベーション、引き出し、出口を大幅に簡素化し、これらのプロセスをスピードアップし、コンセンサスレイヤーと実行層の間のさらなる相互作用の基礎を築きます

• スマートコントラクトにおける新しい「ペアフレンドリー」BLS12-381の新しい「ペアフレンドリー」BLS12-381のより安価なBLS署名とZKSNARK検証のサポート

• BLOBトランザクションのしきい値を増やし、CallDataコストを増加させることにより、ロールアップがBLOBトランザクションを採用するよう奨励します

• EOAをプログラム可能なアカウントとして機能させ、複数の通話、スポンサーシップ、およびその他の高度な機能を提供します

ご覧のとおり、ペクトラは、ステーキングレイヤーとコンセンサスレイヤーのエンドユーザーエクスペリエンス、および実行レイヤーに大きな影響を与えます。開発はまだ進行中であるため、これらのすべての変更をこの段階でコードを通じて詳細に分析することはできませんが、将来の記事でこれらの更新をカバーします。