イーサリアムの今後のハードフォークを分析 - Pectra アップグレード

導入

前回の記事では、Ethereum バリデーターのライフサイクルを詳細に確認し、今後の Electra ハードフォークに関連するさまざまな側面について説明しました。さて、これからは、Electra と Prague の今後のアップグレードにおける変更点に焦点を当て、詳細に説明したいと思います。

Ethereum 2.0「プルーフ・オブ・ステーク」ハードフォークの歴史は複雑です。まず、既存の実行レイヤーにビーコンレイヤーを追加し、実行レイヤーがプルーフオブワークを維持しながらプルーフオブステークのコンセンサスを開始しました (Phase0 および Altair ハードフォーク)。その後、Bellatrix ハードフォークで PoS が完全に有効化されました (ただし、引き出しは有効化されていませんでした)。その後、Capella ハードフォークにより引き出しが可能になり、バリデーターのライフサイクルが完了しました。 Dencun (Deneb/Cancun) アップグレードの一部である最近のハードフォーク Deneb では、認証の時間枠の追加、自発的な終了の処理、バリデーターの交換制限など、ビーコンチェーンパラメーターに小さな改訂が導入されました。 Dencun の主な変更は実行層で発生し、BLOB トランザクション、BLOB ガス、BLOB の KZG コミットメントが導入され、SELFDESTRUCT 操作が廃止されました。

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

Pectraの概要

Electra はビーコンレイヤーに多数の機能を導入します。主なアップデートは次のとおりです:

バリデーターの有効残高を 32 ～ 2048 ETH の範囲で設定できるようにします (固定の 32 ETH ではなく)。
バリデーターが二次的な「引き出し」認証情報を使用して終了を開始できるようにします（アクティブなバリデーターキーは不要になりました）。
ビーコンレイヤーが Eth1 デポジットを処理する方法が変更されました (デポジットコントラクトからのイベントを解析しなくなりました)。
ビーコンレイヤー上の通常の Eth1 契約からのリクエストを処理するための新しい一般的なフレームワークを追加します (Electra 以前のデポジットの管理方法と同様)。

同時に、プラハは実行レイヤーに次の変更を導入しました。

zkSNARK 証明を検証するための BLS12-381 曲線 (一般的な BN254 曲線に加えて) をサポートする新しいプリコンパイル済みコントラクト。
最大 8192 個の履歴ブロックハッシュを保存およびアクセスするための新しいシステムコントラクト (ステートレスクライアントに便利)。
コールデータのガスコストを増加してブロックサイズを削減し、コールデータを集中的に使用する操作 (ロールアップなど) を Dencun で導入された BLOB に移行するプロジェクトを奨励します。
Eth1 ブロックあたりの BLOB 数の増加をサポートし、それらの BLOB を読み取るための API を提供します。
EOA (外部所有アカウント) に独自のアカウントコードを許可すると、マルチコールの実行や他のアドレスへの実行の委任など、EOA が実行できる操作が大幅に拡張されます。

さらなる議論については、関連する Ethereum 改善提案 (EIP) を参照してください。

EIP-7251: MAX_EFFECTIVE_BALANCEを増やす
EIP-7002: 実行層のトリガー可能な終了
EIP-6110: オンチェーンバリデータデポジット
EIP-7549: 委員会インデックスを証明から外す
EIP-7685: 汎用実行層リクエスト
EIP-2537: BLS12-381 曲線演算のプリコンパイル
EIP-2935: 履歴ブロックハッシュを状態に保存する
EIP-7623: コールデータコストの増加
EIP-7691: BLOB スループットの増加
EIP-7840: EL 構成ファイルに BLOB スケジュールを追加する
EIP-7702: EOA アカウントコードの設定

これらの EIP の一部は主にコンセンサス (ビーコン) レイヤーに関係していますが、その他は実行レイヤーに関連しています。特定の操作 (入金や出金など) ではコンセンサス層と実行層の間で同期された変更が必要になるため、一部の操作は両方の層にまたがります。この相互依存性のため、Electra と Prague を分離することは現実的ではないため、各 EIP を順番に確認し、それぞれの場合で影響を受ける Ethereum コンポーネントを指定します。

EIP-7251: MAX_EFFECTIVE_BALANCEを増やす

参照: EIP-7251

イーサリアムのプルーフ・オブ・ステークの準備として行われた最初のフェーズ 0 ハードフォーク以来、Electra まで、バリデーターの最大有効残高は 32 ETH に固定されていました。バリデーターをアクティブ化するには、少なくとも spec.min_activation_balance (32 ETH) が必要です。有効化されると、バリデーターはこの最大有効残高から開始しますが、有効残高を spec.ejection_balance (16 ETH) まで減らし、そのしきい値に達すると排除される可能性があります。この「最小」ロジックは Electra でも変更されていませんが、spec.max_effective_balance は 2048 ETH に増加されました。したがって、バリデーターはアクティブ化するために 32 〜 2048 ETH を預けることができ、そのすべてが有効な残高に加算されます。この変化は、「32ETH- Proof of Stake」から「Proof of Stake」への移行を示しています:)

この変動有効残高は、次の目的で使用されます。

実効残高に比例してブロック提案者になる確率が上昇する
有効残高に比例して、同期委員会のメンバーになる確率が上昇します。
相対的な減額と非活動ペナルティ額を計算するための基礎として

最初の 2 つのアクティビティは、バリデーターにとって最も報酬の高い操作です。したがって、Electra 以降、大きなステークを持つバリデーターは、実効残高に比例した頻度で、ブロック提案や同期委員会に頻繁に参加することになります。

もう一つの影響は削減に関係しています。すべてのスラッシングペナルティはバリデータの実効残高に比例します。

即時および遅延スラッシングのペナルティは、ステークの高いバリデーターに対してより大きくなります。
総ステークの「削減」部分が大きくなるため、高額のスラッシュされたバリデーターに対する「遅い」スラッシュペナルティも大きくなります。
より高い有効残高を持つバリデーターを報告する内部告発者は、削減されるステークのより大きな割合を受け取ります。

エレクトラはまた、バリデーターの残高から内部告発者によって削減され受け取られる部分を定義する削減率の変更を提案した。

次は無効効果です。バリデータがアクティブ（証明または提案中）中にオフラインになると、無効スコアが蓄積され、エポックごとに無効ペナルティが課せられます。これらのペナルティはバリデータの実効残高にも比例します。

有効残高の増加に伴い、バリデーターの「交換制限」も変更されました。「エレクトラ以前」のイーサリアムでは、バリデーターは通常同じ実効残高を持ち、終了置換制限は「サイクルでは、合計ステークの最大 1/65536 (spec.churn_limit_quotient) が終了できる」と定義されていました。これにより、同じステークを持つ「固定」数のバリデーターが退出できるようになりました。しかし、「エレクトラ後」には、総保有株数のかなりの部分を占める「クジラ」が少数しか撤退しない可能性がある。

もう 1 つの考慮事項は、単一のバリデータインスタンス上での多数のバリデータキーのローテーションです。大規模なバリデーターは現在、32 個の ETH に分割された大規模なステークに対応するために、単一のインスタンスで何千ものバリデーターキーを実行することを余儀なくされています。 Electra では、この動作は必須ではなくなりました。財務的な観点から見ると、報酬と確率は賭けた金額に応じて直線的に増加するため、この変更による影響はほとんどありません。したがって、それぞれ 32 ETH を持つバリデーター 100 人は、3200 ETH を持つバリデーター 1 人と同等になります。さらに、複数のアクティブなバリデーターキーに同じ Eth1 引き出し認証情報を持たせることができるため、すべての報酬を 1 つの ETH アドレスに引き出すことができ、報酬プールに関連するガスコストを回避できます。ただし、多数のキーを管理すると、追加の管理コストが発生します。

バリデーターの残高を集計する機能により、新しい実行レイヤーリクエストタイプが追加されます。以前は入金と出金がありました。ここで、集約リクエストという別のタイプが存在します。 2 つのバリデータを 1 つに統合します。操作リクエストには、ソースバリデータの公開鍵と宛先の公開鍵が含まれ、入金や出金と同様に処理されます。アグリゲータには、入金や出金と同様に、保留中のリクエストや残高変更の制限もあります。

要約すると:

小規模な独立バリデーター向けに、Electra は有効残高 (および報酬) を自動的に増やす機能を導入します。以前は、32 ETH を超える余剰金は引き出すことしかできませんでしたが、Electra 以降、この余剰金は最終的に実効残高に貢献することになります。ただし、有効残高は spec.effective_balance_increment(1 ETH) の倍数でのみ増加します。つまり、増加は次の「1 ETH 境界」に達した後にのみ発生します。
大規模な独立バリデーターの場合、Electra は複数のアクティブなバリデーターキーを 1 つに統合できるようにすることで、管理を大幅に簡素化します。これはゲームチェンジャーではありませんが、1x2048 ステークを操作することは、64x32 ステークを管理するよりもはるかに簡単です。
ユーザーから小額のステークを集めてバリデーター間で分配する流動性ステークプロバイダーにとって、Electra はステーク分配スキームにさらなる柔軟性をもたらしますが、固定された 32 ETH の実効残高に基づくバリデーターのアカウンティングの大幅なリファクタリングも必要になります。

もう 1 つの重要なトピックは、バリデーターの履歴データと利益の見積もりです。これは、リスクと報酬を評価しようとしている新しい参加者にとって特に重要です。 Electra 以前 (この記事の執筆時点では)、32 ETH の上限 (実際には最小または最大) によって履歴データの一貫性が保たれていました。すべてのバリデーターは、同じ有効残高、報酬、個々のスラッシングペナルティ、ブロック提案頻度、およびその他のメトリックを持ちます。この均一性により、Ethereum は統計的な外れ値なしでコンセンサスメカニズムをテストし、ネットワークの動作に関する貴重なデータを収集できます。

Electra 以降、ステーキングの配分は大きく変わります。大規模なバリデータは、ブロック提案や同期委員会に頻繁に参加し、スラッシングイベントでより大きなペナルティを受け、遅延スラッシング、アクティベーションキュー、終了キューに大きな影響を与えます。これによりデータ集約に課題が生じる可能性がありますが、Ethereum のコンセンサスにより非線形計算が最小限に抑えられます。唯一の非線形コンポーネントは、すべてのバリデーターに適用される基本報酬を計算するために sqrt(total_effective_balance) を使用します。これは、バリデーター報酬とスラッシングが依然として「1 ETH あたり」ベースで（より正確には、将来変更される可能性のある spec.effective_balance_increment に基づいて）見積もることができることを意味します。

詳細については、バリデータの動作に関する以前の記事を参照してください。

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

参照: EIP-7002

Ethereum のすべてのバリデーターには、アクティブキーと引き出しキーの 2 つのキーペアがあります。アクティブな公開 BLS キーは、ビーコンチェーン内のバリデーターの主な ID として機能し、ブロックの署名、証明、スラッシング、同期委員会の集約、および (この EIP の前は) 自発的な終了 (遅延後にバリデーターのコンセンサス終了を開始する) に使用されます。 2 番目のキーペア (「引き出し資格情報」) は、別の BLS キーペアまたは通常の Eth1 アカウント (秘密キーとアドレス) にすることができます。現在、ETH アドレスへの引き出しには、アクティブな BLS 秘密鍵で署名された引き出しメッセージが必要です。この EIP は変更を加えます。

実際には、これら 2 つのキーペア (アクティブキーペアと撤回キーペア) の所有者は異なる場合があります。バリデータのアクティブキーは、サーバーの実行、稼働の維持などの検証業務を担当しますが、引き出しバウチャーは通常、報酬を受け取り資金の責任を負うステーク所有者によって管理されます。現在、バリデータの終了を開始できるのは、引き出し証明書を管理するステーク所有者のみであり、報酬のみが開始されます。この状況では、バリデータのアクティブなキー所有者は、バリデータの残高を事実上人質に取ることができます。バリデーターは終了メッセージを「事前署名」してステーク所有者に渡すことができますが、この回避策は理想的ではありません。さらに、現在、出金と終了の両方で、専用の API を介してビーコンレイヤーバリデーターとやり取りする必要があります。

最適な解決策は、ステークホルダーが定期的なスマートコントラクト呼び出しを通じて終了と引き出しの両方の操作を実行できるようにすることです。これには標準の Eth1 署名チェックが含まれており、操作が大幅に簡素化されます。

この EIP により、ステークホルダーは、ETH アドレスから専用のスマートコントラクトに標準トランザクションを送信することで、引き出しや終了をトリガーできます (「デポジット」コントラクトを使用した既存のデポジットプロセスと同様)。引き出し（または十分なステークが削除された場合の終了）プロセスは次のとおりです。

ステーカーは、システムの「引き出し」コントラクトに引き出しリクエスト（「in」リクエスト）を送信します。
この契約では、潜在的な悪意のある攻撃を軽減するために特定の料金 (ETH 単位) が請求され、EIP-1559 と同様に、リクエストキューがビジー状態になると料金が増加します。
契約は、「in」の引き出し/終了リクエストをストレージに保存します。
ブロックがビーコン層に提案されると、キューに入れられた「in」の撤回/終了要求がストレージから取得されます。
ビーコン層は、「in」リクエストを処理し、アクティブなバリデータの残高とやり取りし、バリデータの終了をスケジュールし、「out」引き出しリクエストを形成します。
「Out」の引き出しリクエストは実行レイヤーで処理され、ステーカーは ETH を受け取ります。

入金は Eth1 ブロックでトリガーされたアクションであり、その後「保留中」の入金のキューを介してビーコンレイヤーに「移動」されますが、出金は別のスキームに従います。これらはビーコンレイヤー (CLI 経由) でトリガーされ、その後 Eth1 ブロックに「移動」されます。現在、両方のシナリオは同じ一般的なフレームワーク (以下で説明) を通じて動作します。つまり、Eth1 レイヤーでリクエストを作成し、「保留中」の入金/引き出し/マージキューを処理し、ビーコンレイヤーで処理します。引き出しなどの「出力」操作の場合、出力キューも処理され、結果は Eth1 ブロックで「決済」されます。

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

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

EIP-6110: バリデーターデポジットのオンチェーンプロビジョニング

参照: EIP-6110

現在、預金はシステムの「預金」契約内のイベントを介して実装されています (以前の投稿で詳しく説明したとおり)。契約は ETH とバリデーターの資格情報を受け入れ、「Deposit()」イベントを発行します。その後、このイベントは解析され、ビーコンレイヤーでデポジット要求に変換されます。このシステムにはいくつかの欠点があります。ビーコンチェーンレベルで eth1data に投票する必要があり、これにより大きな遅延が発生します。さらに、ビーコン層は実行層にクエリを実行する必要があり、さらに複雑になります。これらの問題は EIP で詳細に説明されています。これらの問題の多くに対処する必要がない、より簡単な方法は、指定された場所の Eth1 ブロックに入金リクエストを直接含めることです。このメカニズムは、以前の EIP で説明した引き出しプロセスに似ています。

この EIP で提案されている変更は有望です。 eth1 データ処理は完全に削除できるようになり、Eth1 側のイベントとビーコンレイヤーへのデポジットの組み込みの間にポーリングや長い遅延 (現在は約 12 時間) が発生することがなくなりました。また、デポジット契約のスナップショットを取得するロジックも削除されます。この EIP は入金処理を簡素化し、上記の出金処理スキームと整合させます。

ステーカーとバリデーターにとって、これらの変更により、入金とバリデーターのアクティベーション間の遅延が大幅に短縮されます。バリデーターが削減されると、必要な補充もより早く行われます。

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

EIP-7685: 汎用実行層リクエスト

参照: EIP-7685

この EIP は、預金/引き出し/合併に関連する最初の 3 つの EIP の基礎となるため、それらの EIP の前に提案されるべきでした。ただし、Eth1 (実行) チェーンと Beacon (コンセンサス) チェーン間で専用データを一貫して移動する必要性が高まっていることを強調するために、ここに含まれています。この EIP は両方のレイヤーに影響し、通常の ETH トランザクションによってトリガーされるリクエスト処理をより効率的にします。現在、私たちは次のことを観察しています:

Eth1 ブロック内の入金イベントは、処理のためにビーコンブロックに「移動」されます。
ビーコンブロック内の引き出し要求 (CLI を使用) は、処理のために Eth1 ブロックに「移動」されます。
バリデーターのマージを処理する必要があります。これは、Eth1->Beacon リクエストでもあります。

これら 3 つの操作は、実行層とビーコン層間の遷移時に、さまざまな種類のリクエストを一貫して処理する必要があることを示しています。さらに、バリデータインフラストラクチャをステーク管理インフラストラクチャから分離してセキュリティを向上させることができるため、Eth1 レイヤーのみを使用してこれらのアクションをトリガーする機能も必要です。したがって、このような要求を管理するための一般的なソリューションは実用的かつ必要です。

この EIP は、預金、引き出し、合併という少なくとも 3 つの主要なシナリオのフレームワークを確立します。そのため、以前の EIP では WITHDRAWAL_REQUEST_TYPE や DEPOSIT_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 ハードフォークによって導入された大きなブロックに対する KZG コミットメントでも、ブロックコミットメントの検証にペアリングが使用されます。

スマートコントラクトで BLS 署名または zkSNARK 証明を検証する場合、これらの「ペアリング」を計算する必要がありますが、これは計算コストが非常に高くなります。 Ethereum にはすでに BN254 曲線操作用のコンパイル済みコントラクト (EIP-196 および EIP-197) があります。ただし、BLS12-381 曲線 (現在ではより安全で広く使用されていると考えられています) はまだプリコンパイルとして実装されていません。このようなプリコンパイルがないと、スマートコントラクトでペアリングやその他の曲線操作を実装するには、ここに示すように大量の計算が必要になり、大量のガス (約 10^5 ～ 10^6 ガス) が消費されます。

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

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

EIP-2935: 履歴ブロックハッシュを状態に保存する

参照: EIP-2935

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

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

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

EIP-7623: コールデータコストの増加

参照: EIP-7623

calldata コストは、トランザクションペイロードの使用可能なサイズを規制し、場合によっては大きくなることがあります (たとえば、大きな配列またはバイナリバッファーを引数として渡す場合)。大量の calldata が使用される主な原因は、現在のロールアップ状態を含むペイロードを calldata 経由で送信するロールアップです。

大規模で証明可能なバイナリデータをブロックチェーンに導入することは、ロールアップにとって重要です。 Dencun (Deneb-Cancun) アップグレードでは、このようなユースケースに重要な革新である BLOB トランザクション (EIP-4844) が導入されています。 BLOB トランザクションには専用の「BLOB」ガス料金があり、トランザクション本体は一時的に保存されますが、暗号化証明 (KZG コミットメント) はハッシュとともにコンセンサスレイヤーに統合されます。したがって、BLOB は、calldata を使用してデータを保存するよりも、ロールアップに適したソリューションを提供します。

ロールアップにデータを BLOB に移動するように促すことは、「アメとムチ」アプローチを通じて実現できます。削減された BLOB ガス料金は「ニンジン」として機能し、この EIP はコールデータコストを増やすことで「テコ」として機能し、トランザクションでの過剰なデータ保存を抑制します。この EIP は、ブロックごとに許可される BLOB の最大数を増やす次の EIP-7691 (Blob スループットの増加) を補完します。

EIP-7691: BLOB スループットの向上

参照: EIP-7691

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

以前の EIP-7623 (calldata コストの増加) と組み合わせると、この調整により、ロールアップがデータを calldata から BLOB に移動するインセンティブがさらに高まります。最適な BLOB パラメータの探索はまだ進行中です。

EIP-7840: EL 構成ファイルに BLOB スケジュールを追加する

参照: EIP-7840

この EIP では、Ethereum 実行レイヤー (EL) 構成ファイルに、ブロックあたりの BLOB のターゲット数と最大数 (前述) および baseFeeUpdateFraction 値を追加することを提案しています。また、クライアントは Node API を通じてこれらの値を取得できるようになります。この機能は、BLOB ガス料金の見積もりなどのタスクに特に役立ちます。

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

参照: EIP-7702

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

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

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

authorization_list = [[chain_id, address, 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 の一般的な問題、つまり、2 つの個別のトランザクションを必要とする、approve() + anything() の非効率性を解決します。この EIP は一般的な「事前承認」ロジックを許可し、approve(X) + deposit(X) などの処理を単一のトランザクションで実行できるようにします。

EOA に代わって取引実行を委任できることのもう 1 つの利点は、スポンサーシップの概念です。スポンサーシップは、新しいユーザーが Ethereum に参加できるようにするために頻繁に議論され、非常に望まれている機能です。

EOA に関連付けられたプログラム可能なロジックにより、セキュリティ制限の実装、支出上限の設定、KYC 要件の適用など、多くの可能性が実現します。

もちろん、この変化により多くの設計上の問題も生じます。 1 つの問題は、chain_id の使用です。chain_id は、署名に含まれるかどうかに応じて、同じ署名が複数のネットワークにわたって有効かどうかを決定します。もう 1 つの複雑な点は、オブジェクトコードのアドレスを使用するか、実際のバイトコードを埋め込むかを選択することです。これら 2 つのアプローチにはそれぞれ独自の特性と制限があります。さらに、ナンスの使用は、許可が「多目的」か「単一目的」かを定義する上で重要な役割を果たします。これらの要素は、署名の一括無効化や使いやすさなどの側面を含む、機能とセキュリティの問題に影響します。 Vitalik 氏はこれらの疑問を議論の中で提起しており (こちら)、さらに検討する価値があります。

この変更は、Ethereum のセキュリティメカニズムである tx.origin に影響を与えることに注意してください。この EIP の実装に関する詳細が必要ですが、require(tx.origin == msg.sender) の動作が変わるようです。このチェックは、msg.sender が EOA であり、契約ではないことを確認するための最も信頼性の高い方法です。 EXTCODESIZE をチェックする (コントラクトであるかどうかを確認する) などの他のアプローチは通常失敗し、回避できます (たとえば、コンストラクターを呼び出すか、トランザクション後に定義済みのアドレスにコードをデプロイするなど)。これらのチェックは再入およびフラッシュローン攻撃を防ぐために使用されますが、外部プロトコルとの統合も妨げるため、理想的とは言えません。この EIP 以降では、信頼性の高い require(tx.origin == msg.sender) チェックも廃止されるようです。「EOA」と「契約」の区別は適用されなくなり、すべてのアドレスにコードが関連付けられるようになったため、プロトコルはこれらのチェックを削除して適応する必要があります。

従来の EOA とスマートコントラクトの区別はますます曖昧になっています。この EIP により、Ethereum は、各アカウントが本質的に実行可能なコードである TON のような設計に近づきます。プロトコルとのやり取りがより複雑になるにつれて、プログラム可能なロジックを使用してエンドユーザーエクスペリエンスを向上させることは、この進化の自然な流れです。

結論は

プラハ/エレクトラ (ペクトラ) のアップグレードは 2025 年 3 月に予定されています。最も注目すべき計画変更は次のとおりです。

バリデーターの有効ステークは最大2048 ETHまで変更可能で、ステーク配分やバリデーターのスケジュールを大幅に変更し、小規模なステークを集約することで大規模ステークプロバイダーの管理を簡素化します。
実行層とコンセンサス層間の相互作用を改善し、Eth1 実行ブロックとビーコンチェーンブロック間のデータ交換を簡素化します。これにより、堆積物、アクティベーション、引き出し、出口が大幅に簡素化され、これらのプロセスが高速化され、コンセンサス層と実行層の間のさらなる相互作用の基礎が築かれます。
新しい「ペアリングにやさしい」BLS12-381プレパイルを介したスマートコントラクトでのより安価なBLS署名とZKSNARK検証のサポート
BLOBトランザクションのしきい値を増やし、CallDataコストを増加させることにより、ロールアップがBLOBトランザクションを採用するよう奨励する
EOAをプログラム可能なアカウントとして機能させ、マルチコール、スポンサーシップ、その他の高度な機能を提供します

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

<<: アーサー・ヘイズ: 米国の戦略的ビットコイン準備金は、どのようにすれば最も実現可能でしょうか?

>>: 暗号通貨市場で何が起こったか、そして何が起こるか