オリジナルタイトルを転送する: プラハ/エレクトラ (ペクトラ) ハードフォークの説明

紹介する

前回の記事では、イーサリアムのバリデーターのライフサイクルについて詳細に説明し、今後のElectraハードフォークに関連するいくつかの側面について議論しました。今度は、ElectraとPragueの両方のアップグレードでの今後の変更に焦点を当て、それらを詳細に説明する時が来ました。

Ethereum 2.0の「証明のためのステーク」ハードフォークの歴史は複雑です。 既存の実行レイヤーにビーコンレイヤーを追加し、ビーコンレイヤーでのステークコンセンサスを開始する一方で、引き続き実行レイヤーでのワーク証明を維持することから始まりました（Phase0およびAltairハードフォーク）。 PoSは、後にBellatrixハードフォークで完全にアクティブ化されました（ただし、出金は有効化されていませんでした）。その後、Capellaハードフォークでは出金が許可され、バリデータのライフサイクルが完了しました。 最新のハードフォークであるDeneb（Dencun（Deneb/Cancun）アップグレードの一部）では、ビーコンチェーンのパラメーターにわずかな変更がもたらされました。これには、証明の含まれる時間ウィンドウ、任意の退出の処理、およびバリデータのチャーンリミットが含まれます。 Dencunでの主な変更は、blobトランザクション、blobガス、blob用のKZGコミットメントのような革新を導入し、SELFDESTRUCT操作を廃止する実行レイヤーにありました。

プラハ/エレクトラのハードフォークは、実行層とコンセンサス層の両方に重要なアップグレードを導入します。Lidoプロジェクトの監査人として、私たちの焦点は主にこのハードフォークでのコンセンサスとステーキングに関連する変更にあります。ただし、プラハの実行層の変更も無視することはできません。なぜなら、これにはイーサリアムのネットワークとバリデータに影響を与える重要な機能が含まれているからです。これらの変更の詳細について見てみましょう。

Pectraの高レベル概要

Electraはビーコンレイヤーに多数の機能を導入しています。主な更新内容は次のとおりです:

• バリデータが32 ETHから2048 ETHまでの効果的な残高を持つことを許可します（固定の32 ETHではなく）。
• 有効な検証者が2次の「出口」資格情報で出口を開始できるようにする（アクティブな検証者キーが不要になりました）。
• ビーコンレイヤーによるEth1入金処理の方法の変更（デポジット契約からのイベント解析からの移行）。
• ビーコンレイヤー上の通常のEth1契約からのリクエストを処理するための新しい汎用フレームワークを追加します（Electra以前に預金が管理されていた方法と似ています）。

一方、プラハは実行レイヤーに変更を導入します。たとえば：

• 人気のあるBN254曲線に加えて、zkSNARK証明を検証するためのBLS12-381曲線をサポートする新しい事前コンパイル済みコントラクトが追加されました。
• ステートレスクライアント向けに最大8192件の履歴ブロックハッシュを格納およびアクセスするための新しいシステム契約。
• ブロックサイズを減らし、プロジェクトがコールデータ集約型の操作（ロールアップなど）を導入されたDencunのブロブに移行するよう奨励するために、コールデータのガスコストを増やしました。
• Eth1ブロックごとのblobの数を増やし、これらの数値を読むためのAPIをサポートします。
• EOAs（外部所有アカウント）が独自のアカウントコードを持つことを許可することで、EOAsが実行できることを大幅に拡張し、マルチコールの実行や他のアドレスに実行を委任するなどが可能になります。

関連するEthereum改善提案（EIP）を参照して、さらなる議論を促進しましょう：

• EIP-7251: 最大有効残高を増やす
• EIP-7002: 実行レイヤーからトリガー可能な終了
• EIP-6110: チェーン上での供給バリデーター預金
• EIP-7549: 委員会インデックスをアテステーションの外に移動
• EIP-7685: 汎目的実行レイヤーリクエスト
• EIP-2537: BLS12-381曲線操作のための事前コンパイル
• EIP-2935: 状態に歴史的なブロックハッシュを保存する
• EIP-7623: コールデータのコストを増やす
• EIP-7691: blob throughput increased
• EIP-7840: EL構成ファイルにblobスケジュールを追加
• EIP-7702: イーサリアムEOAアカウントコードの設定

これらのEIPのうち、一部は主にコンセンサス（ビーコン）レイヤーに関連していますが、他のものは実行レイヤーに関連しています。預金や引き出しのような特定の操作は、コンセンサスレイヤーと実行レイヤーの両方で同期された変更が必要となるため、一部は両レイヤーにまたがっています。この相互依存関係のため、ElectraとPragueを分離することは実用的ではないため、各EIPを順番に見直し、各ケースで影響を受けるEthereumコンポーネントを指定します。

EIP-7251: MAX_EFFECTIVE_BALANCEを増やす

参照：EIP-7251

最初のPhase0ハードフォーク以来、Proof-of-StakeのためにEthereumを準備するために実装され、Electraが実装されるまで、バリデータの最大有効残高は32 ETHで固定されていました。バリデータをアクティブ化するには、少なくともspec.min_activation_balance（32 ETH）が必要です。アクティブ化後、バリデータはこの最大有効残高から始めますが、その有効残高をspec.ejection_balance（16 ETH）まで減らすことができ、その閾値に達すると排除されます。この「最小」の論理はElectraでは変わりませんが、spec.max_effective_balanceが2048 ETHに増加しました。その結果、バリデータはアクティブ化のために32から2048 ETHのどこにでも入金でき、この範囲内のすべての金額が彼らの有効残高に貢献します。この変化は「proof-of-32ETH-stake」から「proof-of-stake」への移行を示しています :)

この変数の有効残高が今後使用されます:

• 有効残高に比例してブロック提案者になる確率を高める
• 有効残高に比例してシンク委員会メンバーになる確率を高める
• 相対スラッシングおよび不活性ペナルティ額の計算の基準として

最初の2つの活動は、バリデータにとって最も報酬の高い行動です。その結果、Electraの後、より多くのステークを持つバリデータが、有効な残高に比例して、より頻繁にブロックの提案や同期委員会に参加することになります。

もう1つの効果はスラッシングに関連しています。すべてのスラッシングペナルティは、バリデータの有効な残高に比例しています:

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

Electraも、スラッシングクォーティエントの変更を提案し、バリデータの残高の一部が削減され、告発者によって受け取られることを定義しています。

非アクティブ時の影響は次のとおりです。バリデータがアクティブな状態でオフラインになると（アテスティングまたはプロポーズ中）、非アクティブスコアが蓄積され、それにより各エポックに非アクティブペナルティが適用されます。これらのペナルティは、バリデータの有効な残高に比例しています。

バリデーターの「シャーニングリミット」も、有効な残高の増加による変更を経験します。 「pre-Electra」のイーサリアムでは、バリデーターは一般的に同じ有効な残高を持ち、退場のシャーニングリミットは「1エポックにつき総ステークの1/65536（spec.churn_limit_quotient）を超えてはならない」と定義されています。これにより、同じステークを持つバリデーターの「固定」数の退場が生じます。 しかし、「post-Electra」では、「クジラ」の数が少ないシナリオが起こる可能性があります。なぜなら、彼らが総ステークの重要な部分を表しているからです。

もう一つの考慮事項は、1つのバリデーターインスタンスで多くのバリデーターキーを回転させることです。大規模なバリデーターは、現在、大きなステークを受け入れるために1つのインスタンスで数千のバリデーターキーを実行することを余儀なくされており、それらを32 ETHの部分に分割しています。Electraでは、この動作がもはや強制されなくなりました。財務上、この変更はあまり違いがありません。なぜなら、報酬と確率はステークされた金額と線形にスケールするからです。したがって、それぞれが32 ETHずつの100のバリデーターは、3200 ETHの1つのバリデーターと同等です。さらに、複数のアクティブなバリデーターキーは同じEth1引き出し資格情報を持つことができ、すべての報酬を1つのETHアドレスに引き出し、報酬の統合に関連するガスコストを回避することができます。ただし、多数のキーを管理することにより、追加の管理コストが発生します。

バリデータの残高を統合する能力は、別の種類の実行レイヤーリクエストを追加します。 以前は、預金と引き出しがありました。 今後は、もう1つのタイプが追加されます：統合リクエスト。 これにより、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キャップ（実際には最小値と最大値の両方）は、歴史データの均一性を作り出しました。 すべてのバリデータは、均等な有効残高、報酬、個別のスラッシュペナルティ、ブロック提案頻度、その他のメトリクスを持っていました。 この均一性により、イーサリアムは統計上の外れ値なしに多数のバリデータでそのコンセンサスメカニズムをテストすることができ、貴重なネットワークの行動データを収集することができました。

Electraの後、ステークの分配が大幅に変更されます。大規模な検証者はブロック提案と同期委員会により頻繁に参加し、スラッシングイベントでより大きなペナルティを受け、延期されたスラッシング、アクティベーションキュー、および終了キューにより大きな影響を与えます。これにより、データ集約に課題が生じる可能性がありますが、イーサリアムのコンセンサスは非線形な計算が最小限に抑えられることを保証します。唯一の非線形要素はsqrt(total_effective_balance)を使用してベースリワードを計算し、これはすべての検証者に均等に適用されます。これは、検証者の報酬とスラッシングがまだ「1 ETHあたり」（または、より正確にはspec.effective_balance_incrementあたり、将来変更される可能性があります）で推定できることを意味します。

詳細については、検証者の行動に関する以前の記事を参照してください。

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

参考: EIP-7002

Ethereumの各検証者には、2つのキーペアがあります：アクティブなキーと引き出し用のキーです。アクティブな公開BLSキーは、ビーコンチェーンにおける検証者の主要なアイデンティティとして機能し、このキーペアはブロック、証明、スラッシング、シンク委員会の集計、および（このEIPまで）任意の退出（検証者のコンセンサスからの遅延後の退出を開始）の署名に使用されます。2番目のキーペア（「引き出しクレデンシャル」）は、別のBLSキーペアまたは通常のEth1アカウント（プライベートキーとアドレス）のいずれかを使用できます。今、ETHアドレスに引き出すには、アクティブなBLSプライベートキーによって署名された引き出しメッセージが必要です。このEIPにより、それが変更されます。

実際には、これら2つの（アクティブと引き出し）キーペアの所有者は異なる場合があります。バリデータのアクティブキーは、バリデーションの任務を担当します：サーバーの実行、運用など。一方、引き出しの資格情報は通常、報酬を受け取り、資金を管理するステークの所有者が制御します。現在、引き出しの資格情報のみを管理するステークの所有者は、バリデータの終了を開始することはできず、報酬のみを引き出すことができます。この状況では、バリデータのアクティブキーの所有者は事実上、バリデータの残高を「人質」として保持することができます。バリデータは終了メッセージを「事前に署名」し、それをステークの所有者に提供することもできますが、この回避策は理想的ではありません。さらに、引き出しと終了の両方は、専用のAPIを使用してビーコンレイヤーバリデータと対話する必要があります。

最適な解決策は、ステーク所有者が通常のスマートコントラクト呼び出しを使用して出口と出金の両方の操作を行えるようにすることです。これには標準のEth1署名チェックが含まれており、操作が大幅に簡素化されます。

このEIPにより、ステーク所有者は、ETHアドレスから専用のスマートコントラクトへの標準トランザクションを介して引き出しと退出をトリガーできます（既存の「Deposit」コントラクトを使用したデポジットプロセスに類似しています）。引き出し（または十分なステークが削除された場合の退出）のプロセスは次のように機能します:

• ステーク所有者はシステムの「引き出し」契約に引き出しリクエスト（「in」リクエスト）を送信します。
• この契約は、特定の手数料（ETHで）を課して、悪意のある攻撃を和らげるために運用され、リクエストキューが混雑していると手数料が増加するなど、EIP-1559と同様に機能します。
• 契約は「in」出金/終了要求をそのストレージに保存します。
• ブロックがビーコンレイヤーに提案されると、キューに入れられた「in」出金/退出リクエストがストレージから取得されます。
• ビーコンレイヤーは「in」リクエストを処理し、アクティブなバリデータのバランスとやり取りし、バリデータを出口にスケジュールし、「out」引き出しリクエストを形成します。
• 「out」の引き出し要求は実行レイヤーで処理され、ステーク所有者はETHを受け取ります。

入金はEth1ブロックでトリガーされ、その後、「保留中」の入金キューを使用してビーコンレイヤーに「移動」されましたが、引き出しは異なるスキームに従いました。ビーコンレイヤー（CLIを介して）でトリガーされ、その後Eth1ブロックに「移動」されました。今後、両方のスキームは同じ汎用フレームワークを使用して動作します（以下に説明）。Eth1レイヤーでのリクエストの作成、保留中の入金/引き出し/集約キューの処理、およびビーコンレイヤーでの処理。引き出しなどの「出力」操作の場合、出力キューも処理され、その結果はEth1ブロックで「決済」されます。

このEIPにより、ステーク所有者は、バリデータCLIとは直接やり取りする必要なく、通常のETH取引を使用してバリデータを取り消し、退出することができます。これにより、特に大規模なステーキングプロバイダーにとって、ステーキング操作が大幅に簡素化されます。バリデータのインフラストラクチャはほぼ完全に分離されるようになり、アクティブなバリデータキーのみを維持する必要があります。一方、すべてのステーキング操作は別の場所で処理できます。これにより、ソロステーカーはアクティブなバリデータのアクションを待つ必要がなくなり、LidoのCommunity Staking Moduleなどのサービスのオフチェーン部分が大幅に簡素化されます。

このEIPにより、ステーキングオペレーションが完全にEth1レイヤーに移行され、インフラセキュリティリスクが大幅に低減され、ソロステーキングイニシアチブの分散化が向上します。

EIP-6110: チェーン上での供給検証デポジット

参照：EIP-6110

現在、預金はシステムの「Deposit」契約を介してイベントを通じて実装されています（以前の記事で詳しく説明されています）。 この契約はETHと検証者の認証情報を受け入れ、 「Deposit（）」イベントを発行し、これらのイベントは後でパースされ、ビーコンレイヤーで預金リクエストに変換されます。 このシステムには多くの欠点があります：ビーコンチェーンレイヤーでeth1dataに投票する必要があり、かなりの遅延が発生します。 さらに、ビーコンレイヤーは実行レイヤーにクエリを送信する必要があり、さらに複雑さが増します。 これらの問題はEIPで詳しく説明されています。 これらの問題の多くを解消するより簡単な方法は、指定された場所に預金リクエストをEth1ブロックに直接含めることです。 このメカニズムは、以前のEIPで説明された引き出し処理プロセスを模倣しています。

このEIPで提案されている変更は有望です。 eth1data処理は完全に削除され、Eth1側のイベントとビーコンレイヤーへの預金の含蓄の間の投票や長時間の遅延を排除します（現在は約12時間）。また、預金契約スナップショットのロジックも削除します。このEIPは預金処理を合理化し、上記の引き出し処理スキームに整合させます。

ステーク所有者とバリデータの両方にとって、これらの変更により、預金とバリデータのアクティベーションの間の遅延が大幅に減少します。バリデータがスラッシュされた場合に必要なトップアップも、より速くなります。

このEIPについて言うことはほとんどありません。古くなったロジックを削除し、プロセスを簡素化し、関係者全員にとってより良い結果を生み出します。

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

参照：EIP-7685

このEIPは、おそらく前の3つの入金/引き出し/統合関連EIPよりも前に提示されるべきでしたが、それらの基盤を築くものとして導入されています。ただし、ここで紹介されているのは、Eth1（実行）とBeacon（コンセンサス）チェーンのブロック（レイヤー）間で特殊データを一貫して移動させるための汎用メカニズムの必要性の高まりを強調するためです。このEIPは両方のレイヤーに影響を与え、定期的なETH取引によってトリガーされるリクエストの処理を効率化します。現在、私たちは次のようなことを観察しています：

• Eth1ブロック内の預金イベントが、処理のためにEth1からビーコンブロックに「移動」されています。
• Beaconブロック内の引き出しリクエスト（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）。

このフレームワークの詳細な実装仕様はまだ利用可能ではありませんが、確かに主要なリクエストタイプ、整合性メカニズム（ハッシングやMerkle-izingリクエストなど）、およびレート制限付きの保留キュー処理が組み込まれるでしょう。

この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 ハードフォークによって導入された) BLOB に対する KZG コミットメントも、BLOB コミットメントを検証するためにペアリングを使用します。

スマートコントラクト内で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: Save historical block hashes in state

参照：EIP-2935

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

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

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

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

参照：EIP-7623

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

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

データをブロブに移行するロールアップを奨励することは、「にんじんとステッキ」というアプローチを用いて達成することができます。「にんじん」としての削減されたブロブガス手数料が機能し、「ステッキ」としてのこのEIPは、コールデータのコストを増やすことにより、トランザクションでの過剰なデータストレージを desu、これによって desu。このEIPは、ブロブスループットの増加を提供する次のEIP-7691（ブロックあたりの許可されるブロブの最大数を増やす）を補完します。

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

参考: EIP-7691

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

EIP-7623（calldata コストの増加）と組み合わせると、この調整はロールアップがデータを calldata から blobs に移行する動機づけをさらに促進します。最適な blob パラメータの検索は続きます。

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

参照: EIP-7840

このEIPでは、「ブロックあたりの」ブロブのターゲットおよび最大数（以前に議論された）およびbaseFeeUpdateFraction値をEthereum Execution Layer（EL）構成ファイルに追加することを提案しています。また、クライアントがノードAPIを介してこれらの値を取得できるようにします。この機能は、特にブロブのガス料金を見積もるなどのタスクに非常に役立ちます。

EIP-7702:EOA アカウント コードを設定する。

参考：EIP-7702

これは非常に重要なEIPで、イーサリアムのユーザーに大きな変更をもたらすものです。私たちが知っているように、EOA（Externally Owned Account）にはコードを持つことはできませんが、トランザクション署名（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における一般的な問題であるapprove() + anything()の非効率性を解消します。このEIPにより、ジェネリックな“事前承認”ロジックが可能となり、approve(X) + deposit(X)などの操作を1つのトランザクションで完了できるようになります。

EOAの代わりにトランザクション実行を委任する能力によって導入されるもう1つの利点は、スポンサーシップの概念です。スポンサーシップは、新しいユーザーをEthereumにオンボーディングする際に頻繁に議論される、非常に望ましい機能です。

EOAに関連するプログラマブルロジックにより、セキュリティ制限の実装、支出限度額の設定、KYC要件の強制など、さまざまな可能性が開かれます。

当然、この変化は多くの設計上の問題も引き起こします。1つの問題は、chain_idの使用です。これは、シグネチャがシグネチャに含まれるか含まれないかに基づいて、複数のネットワークで同じ署名が有効か無効かを判断するものです。また、別の複雑な問題は、ターゲットコードのアドレスを使用するか、実際のバイトコードを埋め込むかどうかです。両方のアプローチには独自の特徴と制約があります。さらに、nonceの使用は、許可が「多用」か「単用」かを定義する上で重要な役割を果たします。これらの要素は、シグネチャの大量無効化や使用の容易さなど、機能とセキュリティ上の懸念事項に影響を与えます。Vitalikは、これらの問題を議論で提起しました（こちら）。これらは、さらに探求する価値があります。

この変更は、Ethereumのセキュリティメカニズムの1つであるtx.originに影響を与えるということを注記することが重要です。このEIPの実装に関する詳細が必要ですが、require(tx.origin == msg.sender)の動作が変わる可能性があります。このチェックは、msg.senderがEOAであることを確認する最も信頼性の高い方法でしたが、他の方法（たとえば、EXTCODESIZEをチェックしてそれがコントラクトであるかどうかを確認する）はしばしば失敗し、バイパスされる可能性があります（たとえば、コンストラクタから呼び出すか、トランザクション後に事前定義されたアドレスにコードを展開することで）。これらのチェックは再入攻撃やフラッシュローン攻撃を防ぐために使用されてきましたが、外部プロトコルとの統合も妨げるため、理想的とは言えません。このEIPの後、信頼性の高いrequire(tx.origin == msg.sender)チェックさえも時代遅れになるようです。プロトコルは、このようなチェックを削除することで適応する必要があります。なぜなら、「EOA」と「コントラクト」の区別はもはや適用されなくなるため、今後はすべてのアドレスが関連付けられたコードを持つ可能性があります。

従来のEOAとスマートコントラクトの分離はますます曖昧になっています。このEIPにより、すべてのアカウントが本質的に実行可能なコードであるTONのような設計にEthereumが近づきます。この進化は自然であり、プロトコルとの相互作用がますます複雑になるため、エンドユーザーのUXを改善するためにプログラム可能なロジックを使用する必要があります。

結論

2025年3月に予定されているプラハ/エレクトラ（ペクトラ）アップグレードの最も重要な計画変更点は次のとおりです:

• 変動するバリデータの有効なステーク、最大2048 ETHまで、これはステークの分配、バリデータのスケジュールを大幅に変更し、大規模なステーキングプロバイダーにとっては、小規模なステークを統合することで管理を簡素化します
• Eth1の実行ブロックとビーコンチェーンブロック間のデータのやり取りを効率化し、デポジット、アクティベーション、引き出し、出口を大幅に簡素化し、これらのプロセスを高速化し、コンセンサス層と実行層のさらなる相互作用の基盤を築きます。
• 新しい「ペアリングに適した」BLS12-381プリコンパイルにより、スマートコントラクトで直接、より安価なBLS署名とzkSNARK検証をサポート
• ブロブトランザクションのハードルを高くし、コールデータのコストを上げることで、ロールアップがブロブトランザクションを採用するよう促し続ける
• EOAがプログラム可能なアカウントとして機能し、マルチコール、スポンサーシップ、その他の高度な機能などの機能で機能できるようにします。

ご覧の通り、Pectraはステーキングおよびコンセンサスレイヤー、および実行レイヤーでのエンドユーザーエクスペリエンスに大きな影響を与えるでしょう。現時点では開発が進行中であり、これらの変更を全て詳細に解析することはできませんが、今後の記事でこれらのアップデートについて取り上げます。

免責事項：

1. この記事は[から転載されましたテックフロー]. Forward the Original Title: The Prague/Electra (Pectra) Hardfork Explained. The copyright belongs to the original author [MixBytes].転載に異議がある場合は、ゲートラーンチーム, そして関連手続きに従ってチームができるだけ早く対応します。
2. 免責事項:この記事で表明された見解や意見は、著者の個人的な見解を表しているにすぎず、投資アドバイスを構成するものではありません。
3. 他の言語版の記事は、gate Learnチームによって翻訳されています。特に指定されていない限り、翻訳された記事は複製、配布、または盗用されてはなりません。