イーサのハードフォークを分析する - ペクトラのアップグレード

はじめに

前回の投稿では、Ether Validatorのライフサイクルを詳しくレビューし、今後のElectraハードフォークに関連する複数の側面について議論しました。さて、今回は来るべきElectraとPragueのアップグレードにおける変更点に焦点を当て、その詳細を説明します。

イーサ2.0の「プルーフ・オブ・ステーク」ハードフォークの歴史は複雑です。既存の実行レイヤーにビーコンレイヤーを追加することから始まり、ビーコンレイヤーがプルーフ・オブ・エクイティのコンセンサスを開始する間、プルーフ・オブ・ワークを維持した（Phase0とAltairのハードフォーク）。その後、PoSはBellatrixハードフォークで完全に有効化された（ただし、引き出しは有効化されなかった）。その後、Capellaハードフォークで引き出しが許可され、検証者のライフサイクルが完了した。最近のハードフォークDeneb（Dencun（Deneb/Cancun）アップグレードの一部）では、証明書を含めるための時間窓、自発的な引き出しの処理、検証者の交換制限など、ビーコンチェーンのパラメータに細かな改訂が導入された。Dencunの主な変更は実行レイヤーで発生し、ブロブトランザクション、ブロブガス、ブロブに対するKZG約束が導入された。SELFDESTRUCT操作は非推奨である。

さて、プラハ/エレクトラ（つまりペクトラ）のハードフォークでは、実行層とコンセンサス層に重要なアップグレードが導入されました。リド・プロジェクトの監査役として、我々は主にこのハードフォークにおけるコンセンサスとプレッジ関連の変更に関心を持っている。しかし、プラハの実行レイヤーの変更は、イーサネット・ネットワークと検証者に影響を与える重要な機能を含んでいるので、無視することはできない。これらの変更の詳細に飛び込んでみましょう。

ペクトラの上位レベルの概要

エレクトラはビーコン層に多数の機能を導入します。

• 検証者の有効残高を（固定の32ETHではなく）32～2048ETHの間で変化させることができます。

• バリデータがセカンダリの「引き出し」認証情報を介して引き出しを開始できるようにします（アクティブなバリデータキーは不要になります）。

• ビーコンレイヤーがEth1入金を処理する方法を変更しました(入金契約からのイベントを解析しなくなりました)。

• ビーコン層で通常のEth1コントラクトからのリクエストを処理するための新しい共通フレームワークを追加しました（Electra以前のデポジットがどのように管理されていたかに似ています）。

同時に、Pragueは実行レイヤーに以下の変更を導入しました:

• 。zkSNARKエビデンスを検証するためのBLS12-381曲線をサポートする新しいコンパイル済みコントラクト（人気のあるBN254曲線に加えて）。

• 最大8192個の履歴ブロックハッシュを保存し、アクセスするための新しいシステムコントラクト（ステートレスクライアントに便利）。

• ブロックサイズを縮小するためにcalldataガスのコストを増加させ、calldataを多用する操作（ロールアップなど）をDencunで導入されたblobに移行するようプロジェクトに促します。="text-align: "left;">Eth1ブロックカウントごとにより多くのブロブをサポートし、それらのカウントを読み取るAPIを提供します。

• EOA（外部所有アカウント）が独自のアカウントコードを持つことを許可することで、マルチコールの実行や他のアドレスへの実行の委任など、EOAが実行できる操作が大幅に拡張されます。

詳細については、関連するイーサネット向上提案 (EIP) を参照してください:

• EIP-7251: Increase MAX_EFFECTIVE_BALANCE

• EIP-7002: Execution Layer Triggerable Exit

• EIP-61_BALANCE

• EIP-6110: Validator Deposits on Chainの提供

• EIP-7549: Move Committee Index out of Proof

• EIP-7685: Generic Execution Layer Request

• EIP-7685: Generic Execution Layer Request

• EIP-2537: Pre-compilation of BLS12-381 Curve Operations

• EIP-2935: Save Historical Block Hash in State（履歴ブロック・ハッシュをステートに保存）

• EIP-7623: calldata コストを増加

• EIP-7691: blob スループットを増加

• EIP-7691: blob スループットを増加

• EIP-7840: ELプロファイルへのブロブスケジューリングの追加

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

EIP-7691: ブロブスループットの増加

EIP-7691: ブロブスループットの増加

これらのEIPの中には、主にコンセンサス（ビーコン）レイヤーに関係するものもあれば、実行レイヤーに関係するものもあります。ある種の操作（入出金など）は、コンセンサス層と実行層の間で同期された変更を必要とするため、いくつかのEIPは両方の層にまたがっている。このような相互依存性のため、ElectraとPragueを分離することは現実的ではないので、それぞれのEIPを順番にレビューし、それぞれのケースで影響を受けるイーサネットコンポーネントを指定します。バリデータを起動するには、最低でも spec.min_activation_balance (32 ETH) が必要です。有効化されると、バリデータはこの最大有効残高で開始するが、有効残高を spec.injection_balance (16 ETH) まで減らすことができ、この閾値に達すると退去させられる。この「最小」ロジックはElectraでも変更されていないが、spec.max_effective_balanceが2048ETHに増加した。 その結果、検証者は有効化するために32～2048ETHの間でデポジットを行うことができ、そのすべてが有効残高に寄与する。このシフトは、"32 ETH- Proof of Equity "から "Proof of Equity "への移行を意味します:)

この変数Effective_Balanceは今後使用されます:

• ブロック提案者である確率を、有効残高に比例して増加させる

• 同期委員会のメンバーである確率を、有効残高に比例して増加させる

• 最初の2つの活動は、バリデーターにとって最もやりがいのある活動です。その結果、エレクトラ後は、大きな誓約を持つバリデーターは、有効残高に比例して、ブロック提案や同期委員会に参加する頻度が高くなります。

  もう1つの影響はカットに関するものです。

  • 「即時」および「遅延」カットバックペナルティは、高い誓約を持つバリデータほど大きくなります。

  • 「遅延」削減ペナルティも、誓約総額の「削減」部分が大きくなるにつれて、誓約総額の高い削減バリデータで大きくなる。

  • 有効残高の多いバリデーターを報告する報告者は、削減された誓約の割合が多くなります。

  Electraはまた、バリデータの残高のうち、内部告発者がカットして受け取る部分を定義するカット率の変更も提案しています。

  次は無効化の影響です。バリデーターが活動中（証明中または提案中）にオフラインになると、無効スコアが蓄積され、サイクルごとに無効ペナルティが課されるようになります。これらのペナルティも、バリデータのアクティブ残高に比例します。

  有効残高が増加すると、バリデータの「交換限度額」も変化する。エレクトラ以前」のイーサでは、バリデータは通常同じ有効残高を持っており、退出時の交換制限は「1サイクルで退出できる誓約総数の最大1/65536（spec.churn_limit_quotient）」と定義されていました。これにより、同じ誓約を持つバリデーターが退出する数が「固定」される。しかし、'エレクトラ以降'は、数人の'クジラ'だけが退場することになるかもしれない。

  もう1つの考慮点は、1つのバリデータインスタンスで多数のバリデータキーを回転させることです。大規模なバリデータは現在、大規模なプレッジに対応するために、1つのインスタンスで数千のバリデータを実行し、32ETHの部分に分割することを余儀なくされています。Electraでは、この動作はもはや必須ではありません。報酬と確率は誓約額に応じてリニアにスケールするため、財務的な観点からは、この変更はほとんど影響しません。したがって、各32 ETHのベリファイア100個は、3200 ETHのベリファイア1個に相当する。さらに、複数のアクティブなバリデータ鍵が同じEth1引き出し認証情報を持つことができ、すべての報酬を単一のETHアドレスに引き出すことができるため、報酬の統合に伴うガスコストを回避することができる。しかし、多数の鍵を管理することは、さらなる管理コストを発生させます。

  バリデータの残高を集約する機能は、新しいタイプの実行レイヤーのリクエストを追加します。これまでは入金と出金がありました。これからは、もう1つのタイプ、すなわち集約リクエストが追加される。これは2つのバリデータを1つにまとめるものである。操作リクエストは、ソース認証者の公開鍵とターゲット公開鍵 を含み、入出金と同様に処理される。集約はまた、入出金と同様に、保留中のリクエストと残高の入れ替えを制限する。

  以下のように要約されます:

  • 小規模で独立した検証者のために、Electraは有効残高（および報酬）を自動的に増やす機能を導入します。残高（と報酬）を自動的に増やす機能を導入しました。これまでは、32ETHを超える余剰金は引き出すことしかできなかったが、Electraでは、この余剰金は最終的に有効残高に寄与される。ただし、有効残高はspec.effective_balance_increment（1ETH）の倍数でしか増やせないため、次の「1ETHの上限」に達した後にしか増えないことになります。

  • 大規模な独立ベリファイアの場合、Electraは複数のアクティブなベリファイアのキーを1つに統合できるようにすることで、管理を大幅に簡素化します。これはゲームチェンジャーではありませんが、1x2048プレッジを実行することは、64x32プレッジを管理するよりもはるかにシンプルであることは確かです。

  • ユーザーから少額の誓約を集め、検証者に分配するモバイル誓約プロバイダーにとって、Electraは誓約分配スキームにより柔軟性を与えますが、固定された32ETHのアクティブ残高に基づく検証者のアカウンティングの深刻なリファクタリングも必要となります。

  もう1つの重要なトピック、特にリスクと報酬を評価しようとする新規参加者に関連するのは、検証者の過去のデータと利益の見積もりです。Electra以前は（そしてこの記事を書いている時点でも）32、ETHキャップ（事実上、最小または最大のいずれか）によって、過去のデータに統一性が生まれていた。有効残高、報酬、個別カットペナルティ、ブロック提案頻度、その他の指標は、すべてのバリデーターで同じでした。この均一性により、イーサは統計的な異常値なしにコンセンサスメカニズムをテストすることができ、ネットワークの挙動に関する貴重なデータを収集することができます。

  Electraの後、誓約の分布は大きく変化するでしょう。大規模なバリデーターは、ブロック提案や同期委員会により頻繁に参加し、カットイベントではより大きなペナルティに直面し、遅延カット、活性化キュー、終了キューにより大きな影響を与えるでしょう。このため、データ集計に課題が生じる可能性があるが、イーサネットのコンセンサスにより、非線形計算は最小限に抑えられる。唯一の非線形コンポーネントは、基本報酬の計算にsqrt(total_effective_balance)を使用し、これはすべてのバリデータに適用される。このため、バリデータの報酬と削減は「1ETHあたり」ベースで見積もることができます（より正確には、spec.effective_balance_incrementに従って見積もることができますが、これは将来変更される可能性があります）。

  詳細については、バリデータの動作に関する以前の投稿をご覧ください。

  EIP-7002: トリガー可能な実行レイヤーの終了

  Reference: EIP-7002

  References.align: left;">イーサネットの各認証者は、2つの鍵ペア（アクティブ鍵と離脱鍵）を持つ。アクティブな公開BLS鍵は、ビーコンチェーンにおけるバリデータのプライマリIDとして機能し、この鍵ペアはブロックへの署名、認証、カット、同期委員会アグリゲーション、および（このEIP以前は）自発的な離脱（遅延後にバリデータの合意離脱を開始するため）に使用される。2 番目の鍵ペア（「引き出し認証情報」）は、別の BLS 鍵ペアまたは通常の Eth1 アカウント（秘密鍵とアドレス）にすることができます。ETHアドレスへの引き出しには、アクティブなBLS秘密鍵によって署名された引き出しメッセージが必要になりました。このEIPは変更されました。

  実際には、2つの（アクティブキーと引き出しキーの）ペアの所有者が異なることがあります。認証者のアクティブキーは、サーバーの実行、稼働の維持など、認証の職務を担当し、引き出しの認証情報は、通常、報酬を受け取り、資金の責任を負う誓約の所有者によって管理されます。現在、引き出し認証情報を管理する誓約所有者のみが、バリデータの引き出しを開始することができ、報酬の引き出しのみを行うことができる。このような状況では、バリデータの有効な鍵所有者は、バリデータの残高を事実上「人質」として保持することができる。ベリファイアはオプトアウトメッセージに「事前署名」して誓約所有者に渡すことができるが、 この回避策は理想的ではない。さらに、現在のところ、引き出しと退出には、専用のAPIを介してビーコン層の検証者とのやりとりが必要です。

  最適な解決策は、誓約所有者が通常のスマートコントラクト呼び出しを介して終了と引き出しの両方の操作を実行できるようにすることです。これは標準的なEth1の署名チェックを含み、操作を大幅に簡素化します。

  このEIPでは、ETHアドレスから専用のスマートコントラクトに標準トランザクションを送信することで、誓約所有者が引き出しと終了をトリガーできるようにします（「デポジット」コントラクトを使用する既存のデポジットプロセスに似ています）。引き出し（または十分な誓約が削除された場合の終了）プロセスは以下の通りです：

  • 誓約者はシステムの「引き出し」コントラクトに引き出しリクエスト（「in」リクエスト）を送信します。

  • コントラクトは、潜在的な悪意のある攻撃を軽減するために特定の手数料（ETH）を請求し、EIP-1559と同様に、リクエストキューがビジー状態になると手数料が増加します。

  • コントラクトは、「入」出金/退出リクエストをストレージに保存します。

  • ビーコンレイヤーにブロックが提案されると、キュー内の「入」出金/退出要求がストレージから取り出されます。

  • ビーコンレイヤーは「入」リクエストを処理し、アクティブな検証者の残高とやりとりし、検証者が引き出すスケジュールを立て、「出」引き出しリクエストを形成する。

  • 'out' withdrawal requestは実行レイヤーで処理され、プレッジャーはETHを受け取ります。保留中の」入金キューを経由してビーコンレイヤーに「移動」しますが、引き出しは異なるスキームに従います。これらはビーコン層で（CLIを介して）トリガーされ、その後Eth1ブロックに「移動」される。要求はEth1レベルで作成され、「pending」入金/出金/マージキューで処理され、ビーコンレベルで処理される。引き出しのような「出力」操作については、出力キューも処理され、結果はEth1ブロックで「決済」される。

    このEIPを使えば、プレッジャーはバリデータのCLIと直接やり取りしたり、バリデータのインフラにアクセスしたりすることなく、通常のETHトランザクションを使ってバリデータを引き出したり終了したりすることができます。これにより、特に大規模なプレッジプロバイダーにとっては、プレッジ操作が大幅に簡素化されます。バリデータのインフラはほぼ完全に分離することができ、アクティブなバリデータの鍵だけを維持すればよい。これにより、独立したプレッジャーがアクティブバリデーターのアクションを待つ必要がなくなり、コミュニティステーキングモジュールのようなリドのサービスのオフチェーン部分が大幅に簡素化されます。

    その結果、このEIPはプレッジ操作を「完了」させ、Eth1レイヤーに完全に移行し、インフラのセキュリティリスクを大幅に削減し、独立したプレッジイニシアティブの分散化を強化します。

    EIP-6110：検証者預託のオンチェーン提供

    参考文献：EIP-6110

    現在、預託はシステム内のイベントを通じて達成されています。は、システムの'deposit'コントラクトのイベントを通じて達成されます（以前の記事で詳しく説明しました）。このコントラクトはETHとバリデータのクレデンシャルを受け入れ、'Deposit()'イベントを発行し、それが解析されてビーコンレイヤーで入金リクエストに変換される。このシステムにはいくつかの欠点がある。ビーコンチェーンレイヤーでeth1dataをポーリングする必要があり、これは大きな待ち時間を追加する。さらに、ビーコンレイヤーは実行レイヤーに問い合わせる必要があり、さらに複雑さが増す。これらの問題は、EIPで詳しく説明されている。これらの問題の多くを扱う必要のない、より単純なアプローチは、指定された場所のEth1ブロックに直接入金要求を含めることである。このメカニズムは、以前のEIPで説明した引き出し処理フローに似ています。

    このEIPで提案されている変更は有望です。eth1data処理を完全に削除できるようになり、ポーリングや、Eth1側のイベントとビーコン層での預金の包含の間の長い遅延（現在は約12時間）の必要性がなくなります。また、預金契約のスナップショットのロジックも削除される。このEIPは、入金処理を簡素化し、前述の出金処理スキームと整合させます。

    プレッジャーとバリデーターの両方にとって、これらの変更はデポジットとバリデーターの有効化の間の遅延を大幅に削減します。必要な補充も、バリデーターがカットされたときに速くなります。

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

    EIP-7685: Generic Execution Layer Request

    参考文献: EIP-7685

    このEIPは、最初の3つの入出金レイヤーにあるはずでした。このEIPは最初の3つの預金/引き出し/合併関連EIPに含まれるはずでした。しかし、Eth1（実行）とビーコン（コンセンサス）のチェーンブロック（レイヤー）間で独自データを一貫して移動させる必要性が高まっていることを強調するため、ここで紹介する。このEIPは両方のレイヤーに影響し、通常のETHトランザクションによってトリガーされるリクエストの処理をより効率的にします。

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

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

    • バリデータのマージが処理される必要がありますが、これもEth1->ビーコンリクエストです。

    これら3つの操作は、実行層とビーコン層を切り替えるときに、さまざまなタイプのリクエストを一貫して処理する必要性を示しています。さらに、Eth1レイヤーのみを使用してこれらの操作をトリガーする機能が必要である。これは、バリデータのインフラストラクチャを誓約管理インフラストラクチャから分離することを可能にし、それによってセキュリティを向上させるためである。したがって、このようなリクエストを管理するための共通のソリューションは、実用的かつ必要である。

    このEIPは、少なくとも3つの主要なシナリオ（入金、引き出し、統合）の枠組みを確立します。そのため、以前のEIPではWITHDRAWAL_REQUEST_TYPEやDEPOSIT_REQUEST_TYPEのようなフィールドが導入され、今回のコンソリデーションではCONSOLIDATION_REQUEST_TYPEのようなフィールドが追加されます。 さらに、このEIPは共通のメカニズム（参照定数：PEND_REQUEST_TYPE）も含むかもしれません。メカニズム（参照定数：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つの目的で使用されています：

    • BLS12-381のような楕円曲線上の数学的演算は、現在主に2つの目的で使用されています。align: "left;">BLS署名。これらの署名を検証するために「ペアリング」と呼ばれる特別な操作が使用されます。BLS署名は複数の署名を1つに集約するため、検証者に広く使用されています。検証者は、BLS12-381曲線に基づくBLS署名に依存しています（ただし、BN254のようなペアリングをサポートする任意の曲線の実装を使用することもできます）。

    • ペアリングが証明の検証に使用されるzkSNARK証明の検証。さらに、Dencunハードフォークによって導入された大規模ブロックへのKZGコミットメントも、ブロックコミットメントの検証にペアを使用しています。

    スマートコントラクトでBLS署名やzkSNARK証明を検証したい場合、これらの「ペア」を計算しなければならず、計算コストが非常にかかります。イーサネットはすでにBN254曲線演算のためのコンパイル済みコントラクトを持っている（EIP-196とEIP-197）。しかし、BLS12-381カーブ（現在ではより安全で広く使われていると考えられている）はまだプリコンパイルされていません。このようなプリコンパイルがない場合、スマートコントラクトでペアリングやその他の曲線操作を実装するには、ここに示すように多くの計算が必要となり、膨大な量のガス（～10^5～10^6ガス）が消費されます。

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

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

    EIP-2935: Preserving historical block hashes in state

    参考文献: EIP-2935

    このEIPは、81のブロックハッシュを保存することを提案しています。EIPは、ステートレスクライアント（ロールアップなど）やスマートコントラクトに拡張履歴を提供するために、ブロックチェーンの状態に8192（～27.3時間）の履歴ブロックハッシュを保存することを提案しています。BLOCKHASHオペコードの現在の挙動を維持し、256ブロックの制限を維持する一方で、履歴ハッシュの保存と取得に特化した新しいシステム・コントラクトを導入することを提案している。このコントラクトは、ブロックが実行レベルで処理される際にset()オペレーションを実行する。そのget()メソッドは、リングバッファから希望のブロックハッシュを取得するために、誰でもアクセスすることができます。

    現在、EVMで過去のブロックハッシュを参照することは可能ですが、アクセスは最新の256ブロック（～50分）に制限されています。しかし、特に（以前のブロックのデータを証明する必要がある）クロスチェーンアプリケーションや、定期的に以前のブロックハッシュにアクセスする必要があるステートレスクライアントでは、古いブロックデータへのアクセスが重要な場合があります。

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

    EIP-7623:calldataコストの増加

    参考文献: EIP-7623

    calldataコストは、EVMで直接収集された履歴データにアクセスするためのものです。calldataコストは、利用可能なトランザクションペイロードのサイズを調整し、場合によっては(例えば、引数として大きな配列やバイナリバッファを渡すとき)大きなものになる可能性があります。calldataの大幅な使用は、現在のロールアップ状態を含むcalldataを通してペイロードを送信するロールアップに主に起因する。

    大規模で証明可能なバイナリデータをブロックチェーンに導入することは、ロールアップにとって非常に重要であり、Dencun（Deneb-Cancun）のアップグレードでは、そのようなユースケースのための重要なイノベーションであるブロブトランザクション（blob transaction）が導入された。ブロブ取引は専用の「ブロブ」ガスコストを持っており、その本体は一時的に保存されるものの、その暗号証明（KZGコミットメント）はハッシュとともにコンセンサスレイヤーに統合される。その結果、ブロブはデータを格納するためにcalldataを使用するよりもロールアップのためのより良いソリューションを提供します。

    ロールアップにデータをブロブに移行するよう促すことは、「アメとムチ」のアプローチで達成できる。ブロブガスのコスト削減は「にんじん」の役割を果たし、このEIPはcalldataのコストを増加させることで「てこ」の役割を果たし、トランザクションにおける過剰なデータ保存を抑制する。このEIPは次のEIP-7691（ブロブスループットの増加）を補完し、ブロックごとに許可されるブロブの最大数を増やします。

    EIP-7691：ブロブスループットの増加

    参考: EIP-7691

    以前のDencunのハードフォークでは、ブロブはブロックごとに許容される最大数を増やしました。Dencunハードフォークのブロブが導入され、「ブロックあたり」のブロブの最大数と目標数の初期値は保守的な推定値でした。これは、p2pネットワークがバリデータノード間の大きなバイナリオブジェクトの伝播をどのように扱うかを予測するのが複雑なためである。以前の設定はうまく動作することが証明されており、新しい値をテストする適切なタイミングである。

    以前のEIP-7623（calldataのコストを増加させた）と組み合わせることで、この調整はrollupがcalldataからblobにデータを移動することをさらに促します。最適なブロブ・パラメーターの探索は続く。

    EIP-7840：ELプロファイルにブロブ・スケジューリングを追加する

    参考文献：EIP-7840

    このEIPは、ターゲットおよび最大「ブロックごと」ブロブカウント（前述）とbaseFeeUpdateFraction値をイーサネット実行レイヤ（EL）構成ファイルに追加することを提案します。また、クライアントがノードAPIを介してこれらの値を取得することもできます。この機能は、ブロブガスコストの見積もりなどのタスクに特に便利です。

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

    Reference: EIP-7702

    これは非常に重要な EIP です。Etherユーザーにとって大きな変化をもたらす非常に重要なEIPです。ご存知の通り、EOA（外部所有口座）はコードを持つことはできませんが、トランザクション署名（tx.origin）を提供することができます。対照的に、スマートコントラクトはバイトコードを持つが、「その」直接署名を開始することはできない。追加の自動化された検証可能なロジックを必要とするユーザーインタラクションは、現在のところ、外部コントラクトを呼び出して目的のアクションを実行することによってのみ実行できる。しかしこの場合、外部コントラクトは後続のコントラクトの msg.sender となり、「ユーザーではなくコントラクトからの呼び出し」となります。

    このEIPでは、新しいSET_CODE_TX_TYPE=0x04トランザクションタイプが導入されます（以前は、古い0x1トランザクション、ベルリンとEIP-1559アップグレードの新しい0x02トランザクション、Dencunで導入された0x03 blobトランザクションがありました）。この新しいトランザクション・タイプは、EIP-1559用の新しいトランザクションの作成を可能にする。この新しいトランザクション・タイプでは、EOA口座のコードを設定できる。事実上、EOAは「自身のEOAアカウントのコンテキストで」外部コードを実行できる。外部から見ると、トランザクションの間、EOAは外部の契約からコードを「借りて」実行しているように見える。技術的には、これはEOAアドレスの「コード」ストア（このEIP以前は、EOAでは常に空でした）に特別な認証データ・タプルを追加することで実現されます。

    現在、このEIPで提案されている新しい0x04トランザクションタイプは、配列を含んでいます:

    authorisation_list = [[chain_idアドレス, nonce, y_parity, r, s], ...]。

    各要素は、指定されたアドレスから（最後に有効だった認証エントリから）、口座がコードを使用できるようにします。このようなトランザクションを処理する際、指定されたEOAのコードは特別な0xef0100 ||アドレス値（23バイト）に設定され、アドレスは希望するコードを持つコントラクトを指し、 ||は接続を表し、0xef0100は通常のスマートコントラクトには含まれない特別なマジックバリューを表します（EIP-3541による）。このマジック値は、このEOAが通常のコントラクトとして扱われず、通常のコントラクトのように起動できないことを保証します。

    このEOAがトランザクションを開始すると、指定されたアドレスがEOAのコンテキストで適切なコードを呼び出すために使用されます。このEIPの完全な実装の詳細はまだわかっていませんが、大きな違いをもたらすことは確かです。

    大きな影響の1つは、EOAから直接複数のコール（マルチコール）を行う機能です。マルチコールはDeFiで進行中のトレンドであり、多くのプロトコルが強力なツールとしてこの機能を提供しています（Uniswap V4、Balancer V3、Euler V2など）。このEIPにより、EOAから直接複数のコールを開始することが可能になりました。

    たとえば、この新機能はDeFiの一般的な問題である、apply() + anything()が2つの別々のトランザクションを必要とする非効率性に対処しています。このEIPは、approve(X)+deposit(X)のようなことを単一のトランザクションで行うことを可能にする一般的な「事前承認」ロジックを可能にします。

    EOAに「代わって」トランザクションの実行を委任できるもう1つの利点は、スポンサーシップの概念です。スポンサーシップは、新しいユーザーがイーサに参入するのを助けるために、よく議論され、非常に切望されている機能です。

    EOAに関連するプログラム可能なロジックは、セキュリティ制限の実施、支出の上限設定、KYC要件の実施など、多くの可能性を解き放ちます。

    もちろん、このシフトは多くの設計上の問題も提起します。その一つは、署名に含まれるか含まれないかによって、同じ署名が複数のネットワークで有効かどうかを決定するchain_idの使用です。もう一つの複雑な問題は、オブジェクトコードのアドレスを使うか、実際のバイトコードを埋め込むかの選択である。これら2つのアプローチにはそれぞれユニークな特徴と限界がある。さらに、nonceの使用は、パーミッションが「多目的」なのか「単一目的」なのかを定義する上で重要な役割を果たす。これらの要素は、一括無効化署名や使いやすさなどの側面を含む、機能性やセキュリティの問題に影響を及ぼし、Vitalikは、さらに探求する価値のある議論（こちら）でこれらの問題を提起しました。

    この変更がEtherのセキュリティメカニズムの1つであるtx.originに影響することは注目に値します。 このEIP実装の詳細が必要ですが、require(tx.origin == msg.sender)の動作が変更されるようです。このチェックは、msg.sender がコントラクトではなく EOA であることを確実にする最も信頼できる方法です。EXTCODESIZE をチェックする（コントラクトかどうかをチェックする） などの他の方法は、通常は失敗し、回避することができます（コンストラクタを呼び 出したり、トランザクションの後に定義済みのアドレスにコードを配置するなど）。これらのチェックはリエントリー攻撃やフラッシュ・レンディング攻撃を防ぐために使われるが、外部プロトコルとの統合も妨げてしまうため、理想からはほど遠い。このEIPの後、信頼性の高いrequire(tx.origin == msg.sender)チェックでさえも時代遅れになりつつあるようだ。EOA」と「contract」の区別はもはや適用されないので、プロトコルはこれらのチェックを削除して適応しなければならないでしょう。

    従来のEOAとスマートコントラクトの隔たりは曖昧になり続けています。このEIPは、各アカウントが本質的に実行可能なコードであるTONのようなデザインにイーサを近づけます。プロトコルとのインタラクションがより複雑になるにつれて、エンドユーザーのエクスペリエンスを向上させるためにプログラム可能なロジックを使用することは、この進化の自然な部分です。

    結論

    プラハ/エレクトラ（ペクトラ）のアップグレードは2025年3月に予定されています。

    • 最大2,048ETHの可変バリデーター有効誓約、これは誓約の分布やバリデーターのスケジュールを劇的に変化させ、大規模な誓約プロバイダーの管理を統合することで小規模な誓約の管理を簡素化します。

    • 実行レイヤーとコンセンサスレイヤー間の相互作用を改善し、Eth1実行ブロックとビーコンチェーンブロック間のデータ交換を簡素化します。これにより、入金、アクティブ化、出金、退出が大幅に簡素化され、これらのプロセスが高速化され、コンセンサス層と実行層間のさらなる相互作用のための基礎が築かれます

    • 新しい「ペアリングに優しい」BLS12-381プリコンパイルとzkSNARK検証を経由して、スマートコントラクトで直接安価なBLS署名をサポートします。zkSNARK 検証

    • ブロブ取引のしきい値を増やし、calldata コストを引き上げることで、ロールアップにブロブ取引を採用するよう促す

    おわかりのように、ペクトラは、約定層だけでなく、誓約層や合意層でも、エンドユーザーのエクスペリエンスに大きな影響を与えようとしています。開発がまだ進行中であるため、現段階ではコードを通してこれらの変更のすべてを詳細に分析することはできませんが、今後の投稿でこれらのアップデートを取り上げる予定です。