もう一つ重要なトピックは、検証者の履歴データと利益の見積もりであり、新参加者にとって特に関連しており、彼らはリスクとリターンを評価しようとしています。 Electra の前（この記事が書かれた時点で）、32 ETH の上限（実際には最小でも最大でも）は履歴データの中で均一性を生み出しました。すべての検証者の有効残高、報酬、個々の削減罰金、ブロック提案頻度、およびその他の指標は同じです。この均一性により、イーサリアムは統計的な異常値なしでその合意メカニズムをテストし、価値のあるネットワーク行動データを収集することができます。
イーサリアム坊の次回ハードフォーク、Pectraのアップグレードを解析します
イントロダクション
以前の記事では、イーサリアムの検証者のライフサイクルを詳しく説明し、今後のElectraハードフォークに関連するさまざまな側面について議論しました。今は、今後のElectraとPragueのアップグレードに焦点を当て、それらの変更を詳細に説明する時です。
イーサリアム2.0の「プルーフオブステーク」ハードフォークの歴史は複雑です。これは、既存の実行レイヤーにビーコンレイヤーを追加し、ビーコンレイヤーでプルーフオブステークコンセンサスを開始する一方で、実行レイヤーは引き続きプルーフオブワークを維持します（Phase0およびAltairハードフォーク）。その後、Bellatrixハードフォークでは、PoSが完全にアクティブ化されました（ただし、引き出しは有効化されていません）。その後、Capellaハードフォークで引き出しが許可され、バリデーターのライフサイクルが完了しました。最新のDeneb（Dencun（Deneb/Cancun）アップグレードの一部）では、ビーコンチェーンパラメータにわずかな修正が加えられており、自発的な退出とバリデーターの交換制限の処理、証明の時間ウィンドウなどが含まれています。Dencunでは、実行レイヤーで主要な変更が行われ、blobトランザクション、blob gas、blobに使用されるKZGコミットメントが導入され、SELFDESTRUCTオペレーションが廃止されました。
現在、Prague/Electra（Pectraとも呼ばれる）のハードフォークには、実行レイヤーとコンセンサスレイヤーに重要なアップグレードが導入されています。Lidoプロジェクトの監査人として、私たちはこのハードフォークでのコンセンサスとステーキングに関連する変更に主に関心を寄せています。ただし、Pragueでの実行レイヤーの変更を無視することはできません。なぜなら、これらにはイーサリアムネットワークと検証者に重要な影響を与える特性が含まれているからです。これらの変更の詳細について深く掘り下げてみましょう。
Pectra の概要
Electraはビーコンレイヤーに多くの機能を導入しています。主な更新内容は次のとおりです：
*バリデータの有効な残高は32〜2048 ETHの範囲で変動することができます（32 ETHの固定ではありません）。
一方、Prague では、実行レイヤーに以下の変更を導入しました:
関連するEIP (を参照して、より詳細に議論するために、私たちはイーサリアムの改善提案に参加しましょう。
これらのEIPの一部は、主に合意（ビーコン）レイヤーに関連しており、他のものは実行レイヤーに関連しています。預金や引き出しのような操作が合意と実行の両方で同期変更が必要なため、一部は両方のレイヤーをまたぐことがあります。このような相互依存のため、ElectraとPragueを分離することは現実的ではないため、各EIPを順番に見直し、影響を受けるEthereumコンポーネントを指定します。
EIP-7251: MAX_EFFECTIVE_BALANCE の増加
リファレンス: EIP-7251
Phase0の最初のハードフォーク以来、イーサリアムのステーキングの準備のために、エレクトラ以前に、バリデータの最大有効残高は32ETHに固定されていました。バリデータをアクティブにするには、少なくともspec.min_activation_balance（32ETH）が必要です。アクティブ化後、バリデータはこの最大有効残高から始めますが、spec.ejection_balance（16ETH）に達すると排除されます。この「最小」ロジックはエレクトラでも変わりませんが、spec.max_effective_balanceは2048ETHに増加しました。したがって、バリデータは32ETHから2048ETHまでの間でステーキングを行い、これらのすべての金額が有効残高に貢献します。この変化は、「32ETH-ステーキング」から「ステーキング」への移行を示しています:)
この可変有効残高は現在使用されます：
最初の2つのアクティビティは、検証者にとって最も報酬が高い操作です。したがって、Electraの後、大規模なステークを持つ検証者は、ブロック提案と同期委員会により頻繁に参加し、その頻度は彼らの有効残高に比例します。)
もう一つの影響は削減に関連しています。すべての削減罰金は、検証者の有効残高に比例しています：
*「即座に」および「遅延」の削減罰金は、高額なステーキングを行う検証者にとってより大きなものです。
Electraは削減比率の変更を提案し、削減されるバリデータの残高の一部を定義し、報告者が受け取ることができます。
次に、無効性への影響です。検証者が活発な時（証明または提案をする時）にオフラインになると、無効性スコアが蓄積され、各サイクルで無効性罰則が課されます。これらの罰則は、検証者の有効残高に比例しています。
有効残高の増加により、検証者の「交代制限」も変更されました。「Electra 以前」のEthereumでは、通常、検証者は同じ有効残高を持っています。退会の交代限度は「1サイクルにつき、最大で1/65536（spec.churn_limit_quotient）の総ステークが退会できる」ように定義されています。これにより、同じステークを持つ「固定」の検証者の退会数が作成されます。ただし、「Electra 以降」では、一部の「クジラ」のみが退出する可能性があります。それらは総ステークの重要な部分を表しています。
もう1つの考慮事項は、1つの検証者インスタンスで多くの検証者キーを交換することです。現在、大規模な検証者は大量のステークを適応させるために1つのインスタンスで数千の検証者キーを実行する必要がありますが、Electraではこれが必須ではなくなります。財務的には、この変更はほとんど影響しません。報酬と確率はステーク額に比例して線形的にスケーリングされるためです。したがって、32 ETHごとの100人の検証者は3200 ETHの検証者に相当します。さらに、複数のアクティブな検証者キーは同じEth1引き出し証明を持つことができ、すべての報酬を1つのETHアドレスに引き出すことができ、報酬の結合に関連するガスコストを回避できます。ただし、多くのキーを管理することは追加の管理コストを生じさせる可能性があります。
集約検証者の残高の能力は新しい実行レイヤー要求タイプを追加しました。以前は預金と引き出しでした。今、もう1つのタイプがあります：集約リクエスト。それは2つの検証者を1つに統合します。この操作リクエストにはソース検証者の公開鍵とターゲットの公開鍵が含まれ、預金や引き出しと同様に処理されます。集約には処理待ちのリクエストと残高変更の制限もあり、預金や引き出しと同様です。
概要は次のとおりです。
もう一つ重要なトピックは、検証者の履歴データと利益の見積もりであり、新参加者にとって特に関連しており、彼らはリスクとリターンを評価しようとしています。 Electra の前（この記事が書かれた時点で）、32 ETH の上限（実際には最小でも最大でも）は履歴データの中で均一性を生み出しました。すべての検証者の有効残高、報酬、個々の削減罰金、ブロック提案頻度、およびその他の指標は同じです。この均一性により、イーサリアムは統計的な異常値なしでその合意メカニズムをテストし、価値のあるネットワーク行動データを収集することができます。
Electraの後、ステーキングの分布が大きく変化します。大規模な検証者は、ブロック提案および同期委員会への参加が頻繁になり、削減イベントではより大きなペナルティに直面し、遅延削減、アクティブキュー、および退出キューにより大きな影響を受けます。これはデータ集約で課題を引き起こす可能性がありますが、イーサリアムの合意によって非線形計算が最小限に抑えられます。唯一の非線形コンポーネントは sqrt(total_effective_balance) を使用して基本報酬を計算し、これはすべての検証者に適用されます。つまり、検証者の報酬と削減は引き続き「1ETHごと」（または正確には、spec.effective_balance_incrementに基づいて将来変更される可能性があります）で推定されます。
詳細については、以前に弊社が検証者の行動について公開した記事をご覧ください。
EIP-7002：トリガー可能な実行レイヤーの終了
商品番号: EIP-7002
イーサリアムの各バリデータには、アクティブキーと引き出しキーの2つのキーペアがあります。アクティブな公開BLSキーは、バリデータの主なアイデンティティとしてビーコンチェーンで使用され、ブロック、プルーフ、スラッシュ、同期委員会のアグリゲーションに署名するために使用されます（このEIP以前のバリデータの自発的な退出を遅延させるための共識の出口）。2つ目のキーペア（「引き出し証明書」）は、別のBLSキーペアまたは通常のEth1アカウント（秘密鍵とアドレス）であることができます。ETHアドレスへの引き出しは、アクティブBLSプライベートキーによって署名される引き出しメッセージが必要です。このEIPで変更が行われました。
実際には、これら2つの（アクティブおよび引き出し）キーペアの所有者は異なる場合があります。検証者のアクティブキーは、サーバーの実行、正常な運用などの検証責任を担当し、一方、引き出し証明は通常、ステーキング所有者が制御し、報酬を受け取り資金を管理します。現時点では、引き出し証明の所有者は検証者の退出を開始できませんが、報酬を引き出すことはできます。この状況では、検証者のアクティブキー所有者は実質的に検証者の残高を「人質」として抑えています。検証者は退出メッセージを「事前に署名」してステーキング所有者に渡すことができますが、このような回避策は理想的ではありません。さらに、現在、引き出しと退出の両方について、ビーコンチェーンの検証者とのやり取りには専用のAPIが必要です。
最適なソリューションは、ステーク所有者が通常のスマートコントラクトを呼び出して、同時に引き出しと預け入れの操作を実行できるようにすることです。これには標準のEth1署名検証が関与し、操作が大幅に簡素化されます。
このEIPにより、ステーキング所有者は、専用のスマートコントラクトに標準トランザクションを送信することによって引き出しと退出をトリガーし、ETHアドレスからステーキングを行うことができます（これは「預金」契約を使用する既存の手順に似ています）。引き出し（または十分なステーキングが解除されたときの退出）の手順は次のとおりです：
預金はEth1ブロックでトリガーされ、次に「未処理」の預金キューからビーコンレイヤに「移動」されますが、引き出しは異なる方法に従います。これらはビーコンレイヤ（CLIを介して）でトリガーされ、次にEth1ブロックに「移動」されます。現在、2つの方法は同じ一般的なフレームワーク（以下に説明）を使用して操作されます：Eth1レイヤで要求を作成し、「未処理」の預金/引き出し/マージキューを処理し、ビーコンレイヤで処理します。 「出力」操作のような引き出しの場合、出力キューも処理され、結果はEth1ブロックで「決済」されます。
このEIPにより、ステーキングプール参加者は通常のETHトランザクションを使用して、直接的にバリデータCLIとやり取りすることなく、バリデータを引き出すことができます。これにより、特に大規模なステーキングプロバイダにとって、ステーキング操作が大幅に簡素化されます。バリデータのインフラストラクチャは、アクティブなバリデータの鍵を保持するだけでほぼ完全に分離され、すべてのステーキング操作は別の場所で処理できます。これにより、独立したステーキングプロバイダがアクティブなバリデータのアクションを待つ必要がなくなり、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の前に提出されるべきでしたが、それらのEIPの基盤を築いたためです。ただし、ここで紹介するのは、Eth1（実行）とビーコン（合意）チェーンブロック（レイヤー）間で専用データの一貫した移動の需要が増加していることを強調するためです。このEIPは2つの層に影響を与え、通常のETH取引でトリガーされるリクエスト処理を効率的に行います。現時点では、私たちは次のことを観察しています：
これらの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化されたリクエスト）および処理待ちキューの処理と速度制限が含まれるでしょう。
このEIPにはアーキテクチャ的な意義があり、Eth1が統一フレームワークを介してビーコンレイヤーの重要な操作をトリガーできるようになります。最終ユーザーやプロジェクトにとって、これはEth1レイヤーでトリガーされたすべてのリクエストがビーコンレイヤーでより効率的に伝達および処理されることを意味します。
EIP-2537: BLS12-381 曲線操作のプリコンパイル
リファレンス: EIP-2537
深く理解したくない場合は、BLS12-381のプリコンパイルを複雑な暗号ハッシュ操作と見なすことができます。これは現在、スマートコントラクトで使用することができます。興味がある方については、さらに探求してみましょう。
楕円曲線（BLS12-381およびそれに対応するBN-254）に対する数学的な計算は、現在2つの目的に主に使用されています：
スマートコントラクトで BLS 署名や zkSNARK 証明を検証する場合、これらの「ペアリング」を計算する必要があり、これは計算上非常に高価です。イーサリアムには、BN254曲線操作用のプリコンパイルコントラクト（EIP-196およびEIP-197）が既に存在しています。ただし、BLS12-381曲線（現在はより安全で広く使用されていると考えられている）はまだプリコンパイルとして実装されていません。このようなプリコンパイルがない状況では、スマートコントラクト内でのペアリングおよび他の曲線操作の実装には多大な計算が必要で、巨大なgasを消費します（約~10^5から10^6 gas）。
このEIPは、多くの潜在的なアプリケーションに大きな可能性をもたらし、特にBLS12-381曲線に基づく安価なBLS署名の検証においてです。これにより、さまざまな目的の閾値スキームの実現が可能となります。前述のように、イーサリアムの検証者はすでに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コミットメント）とそのハッシュは合意層に統合されています。したがって、データをcalldataに保存するよりも、blobはロールアップにとってより優れた解決策を提供します。
ロールアップはデータをBLOBに移動することで「にんじんと棍棒」の方法で推奨されています。BLOBのガス料金が低下し、にんじんとして機能し、このEIPはcalldataのコストを増加させることで「レバレッジ」として機能し、過剰なデータストレージを抑制します。このEIPは次のEIP-7691（BLOBスループットの増加）を補完し、各ブロックで許可される最大BLOB数を増やします。
EIP-7691：blob スループットの増加
リファレンス: EIP-7691
以前のDencunハードフォークでは、ブロブが導入され、ブロックごとのブロブの最大および目標数の初期値が控えめな推定値でした。これは、P2Pネットワークが大きなバイナリオブジェクトをバリデータノード間でどのように処理するかに関する複雑さを予測するためです。以前の設定はうまく機能しており、これは新しい値をテストする適切な時期となっています。以前は、ブロックごとの目標/最大ブロブ数が3/6に設定されていました。これらの制限はそれぞれ6/9に引き上げられました。
EIP-7623（calldata のコスト増加）を前提として、この調整は rollup に calldata からデータを blobs に移動するようにさらに促進します。最適な blob パラメータを見つける作業はまだ続いています。
EIP-7840：blobスケジューリングをEL構成ファイルに追加
リファレンス: EIP-7840
このEIPでは、EL（Ethereum Execution Layer）の設定ファイルにターゲットと最大「ブロックごと」のblob数（前述の通り）およびbaseFeeUpdateFraction値を追加することを提案しています。また、クライアントはノードAPIを介してこれらの値を取得することができるようになります。この機能は、blobガス料金の推定などのタスクに特に便利です。
EIP-7702：EOAアカウントコードの設定
リファレンス: EIP-7702
これは非常に重要なEIPであり、Ethereumのユーザーに重大な変化をもたらします。私たちが知っているように、EOA（External 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トランザクションタイプには、配列が含まれています：
承認_list = [[チェーン_id, アドレス, ナンス, y_parity, r, s], ...]
各要素は、指定されたアドレスからのコード（最後の有効な許可項目から）を使用するアカウントに許可されています。このようなトランザクションを処理する際、指定された EOA のコードは特別な0xef0100 ||アドレス値（23バイト）に設定されます。アドレスは、必要なコードを持つ契約を指し、||は接続を表し、0xef0100は、一般的なスマートコントラクトに含まれない特別なマジック値を示します（EIP-3541に基づく）。このマジック値により、この EOA が通常の契約と見なされず、通常の契約と同様に呼び出すことができないことが保証されます。
この EOA がトランザクションを開始すると、指定されたアドレスがその EOA のコンテキストで対応するコードを呼び出すために使用されます。この EIP の完全な実装の詳細はまだ明確ではありませんが、それが重要な変更をもたらすことは確実です。
主な影響の1つは、EOAから直接的にマルチコール（multicall）を行うことができることです。マルチコールはDeFiでの持続的なトレンドであり、多くのプロトコルがUniswap V4、Balancer V3、またはEuler V2などの強力なツールとしてこの機能を提供しています。このEIPにより、EOAから直接マルチコールを開始することができるようになりました。
例えば、この新機能はDeFiでよくある問題を解決します：approve() + anything()を行うためには、2つの独立したトランザクションが必要ですが、このEIPにより一般的な「事前承認」ロジックが可能となり、approve(X) + deposit(X)などを1つのトランザクションで行うことができます。
「代表」EOA委托取引を実行するもう一つの利点は、スポンサーシップの概念です。スポンサーシップは、しばしば議論され、新規ユーザーがイーサリアムに参入するのを支援するために非常に望ましい特性です。
EOAに関連付けられたプログラマブルロジックは、セキュリティ制限の実装、支出上限の設定、KYC要件の強制など、さまざまな可能性を開いています。
もちろん、この変化は多くの設計上の問題を提起します。1つの問題は、chain_idの使用であり、同じ署名が複数のネットワーク間で有効かどうかを決定するものであり、署名に含まれるか含まれないかによって異なります。もう1つの複雑な問題は、ターゲットコードのアドレスの使用と実際のバイトコードの埋め込みとの選択です。これら2つの方法には独自の特徴と制約があります。さらに、権限の定義においてnonceの使用は「多目的」なのか「単一の目的」なのかに重要な役割を果たします。これらの要素は、バッチ失効署名や使いやすさなど、機能とセキュリティの問題に影響を与えます。Vitalikはこの問題について議論を提起しました（ここ） 、さらなる探求に値するものです。
注目すべきは、この変更がイーサリアムのセキュリティメカニズムであるtx.originに影響を与えることです。このEIPの実装に関する詳細は必要ですが、require(tx.origin == msg.sender)の動作が変わるようです。このチェックは、msg.senderがEOAであることを確実にする最も信頼性の高い方法であったが、EXTCODESIZE（コントラクトであるかどうかを確認するためのもの）などの他の方法は通常失敗し、回避できる（たとえば、コンストラクタの呼び出しやトランザクション後に予め定義されたアドレスにコードをデプロイするなど）。これらのチェックは再入攻撃やフラッシュローン攻撃を防ぐために行われていたが、理想的ではなく、外部プロトコルとの統合を妨げる。このEIPの後、信頼性の高いrequire(tx.origin == msg.sender)チェックさえも時代遅れになるようです。プロトコルはこれらのチェックを削除して適応しなければならない。なぜなら、「EOA」と「コントラクト」の違いがもはや適用されなくなるからです——今では各アドレスに関連するコードが存在する可能性があります。
伝統的なEOAとスマートコントラクトの分離はますます曖昧になっています。このEIPにより、イーサリアムはTONのような設計により近づき、各アカウントが本質的に実行可能なコードである場合があります。プロトコルとの相互作用がますます複雑になるにつれ、プログラム可能なロジックを使用して最終ユーザーエクスペリエンスを改善することは、この進化の自然な過程です。
まとめ
ブラグ/ Electra（Pectra）のアップグレードは2025年3月に予定されています。最も顕著な計画変更には、
ご覧の通り、Pectraはステーキングおよびコンセンサスレイヤー、および実行レイヤーのエンドユーザーエクスペリエンスに重大な影響を与えるでしょう。これらの変更のすべてをこの時点でコードで詳細に分析することはできませんが、開発は進行中ですので、これらの更新については将来の記事でカバーします。