Ethlabs が Hegotá で優先していることとその理由
イーサリアムの方向性は、その上で構築する人々、利用する人々、ETH を保有する人々、あるいは単にその可能性を信じる人々にとって重要です。その未来は最終的に、毎日イーサリアム上で構築する人々、アプリケーション、コミュニティによって決定されますが、ネットワークアップグレードは、プロトコルが彼らのニーズに応えるために進化する主要な方法の 1 つです。Hegotá は Glamsterdam に続く次期イーサリアムネットワークアップグレードであり、この文書では、Ethlabs がイーサリアムが Hegotá で何を優先すべきだと考えるか、そしてその理由を共有します。
Ethlabs は、設立から 8 週間の イーサリアムと ETH のための非営利 R&D ラボ であり、私たちの使命はイーサリアムを世界経済の決済レイヤーにすることです。私たちは、実際のイーサリアムの使用とプロトコル開発の間に位置し、ユーザー、ウォレット、アプリケーション、ロールアップ、機関、ETH 保有者、研究者、クライアントチームの 声に耳を傾ける ことに時間を費やしています。時には、私たち自身も オンチェーンで構築 することもあります。なぜなら、アリーナに参加せずにアリーナを構築することはできないからです！私たちは、優れたプロトコルエンジニアリングが優れた製品を可能にし、優れた製品がプロトコルの次の方向性を決定づけるのに役立つべきだと信じています。
Hegotá の範囲は現在、イーサリアムのオープンな技術プロセスを通じて形成の初期段階にあり、以下の提案は多くの個人、研究チーム、クライアントチームの作業を反映しています。この文書は、私たちが優先することを推奨する内容と、まだ見解が形成中の分野についての透明性のある説明です。これらは、他の人に評価、挑戦、改善を促したいと考えている立場であり、今後数日から数週間かけて議論し、さらに学ぶにつれて、これらを反復していきます。
Hegotá アップグレードについて、提案されたすべての EIP を考慮すると、イーサリアムにとって最優先事項と見なす分野は次のとおりです。
- より強力な検閲耐性: 誰でも、自分が誰であるか、イーサリアムを何に使用するかに関係なく、トランザクションを含めることができるべきです。
- より高速なイーサリアム: より高速なブロックは、より高速な確認、より新しいオンチェーン価格、そしてより高速なファイナリティを意味します。
- ネイティブアカウント抽象化: アカウントは、パスキー、スポンサー付きトランザクション、トークンでのガス支払い、バッチ処理、より強力なプライバシーをサポートし、ポスト量子鍵への道筋を持つべきです。
- 継続的な L1 スケーリング: アプリケーションには、需要が急増した場合でも、手頃な価格で予測可能な容量が必要です。
オープンに活動することは Ethlabs の中核的な目標であり、そのため 毎週のアップデートを執筆 し、今回のような機会には、非常に長い技術的な記事を投稿して考えを共有しています 😅。また、ハイライトだけを知りたい方のために、今後数週間でより短いコンテンツも公開する予定です。次の部分は長くて技術的になります。すべてを読む勇気のある方、幸運を祈ります！
まず最初に：EIP プロセスは実際どのように機能するのか？
提案自体の詳細に入る前に、重要なポイントが 1 つあります。Hegotá のスコーピングプロセスの第 2 フェーズが始まったばかりです。第 1 フェーズでは、FOCIL が Hegotá のヘッドライナーとして選ばれました。 8 月 6 日には、ヘッドライナー以外の EIP を提案する期限があり、ACD プロセスは今後、Hegotá アップグレード全体を評価する方向に進みます。
以下のすべての EIP は現在、ヘッドライナープロセス を経た EIP を除き、PFI（Proposed for Inclusion） 段階にあります。EIP の包含提案はパーミッションレスであり、最終的なアップグレードに採用されるものはほとんどありません。
具体的には、実装作業が進むにつれて、提案は段階的にレビューと出荷への確信度が高まっていきます。
- PFI（Proposed for Inclusion）: アップグレードに対してアイデアが提案されました。この段階はパーミッションレスであり、クライアントのサポートや最終的な包含を意味するものでは ありません。
- CFI（Considered for Inclusion）: クライアントチームが提案をレビューし、プロトタイプ作成とテストを行う意向があります。
- SFI（Scheduled for Inclusion）: 実装とテストが順調に進むことを前提として、広く包含の意向があります。
このプロセスがどのように機能するかについて詳しく知りたい方は、Tim Beiko の簡単な解説を こちら でご覧になることをお勧めします。
注意事項：この記事の読み方
私たちは、Hegotá の EIP 優先順位に関する見解を表現するために、Forkcast のティアリスト に従っています。判断を最小限に抑えるため、レビューしたすべての EIP を次の 4 つのティアにマッピングします。
- [S-tier] 包含を強く推奨。
- [A-tier] 実装の複雑さ、影響分析、採用などの残りの障害が解決されれば、包含を推奨。
- [B-tier] 価値はあるが、今回のアップグレードには無理がある。
- [D-tier] 現在の形での Hegotá への包含は推奨しない。
- [forming opinion] この EIP についてはまだ意見を形成中。
これらは Ethlabs の 推奨事項 であることに注意してください。私たちは主に、目的、仕様、および実装の複雑さの理解可能な範囲に基づいて各提案を評価します（Frames や Quick Slots など、より確実性や直接的な関与がある場合を除く）。また、プロセスが進むにつれて、ethPandaOps、テストチーム、クライアントからの評価に基づいて見解を更新します。
[CL] は EIP がコンセンサスレイヤークライアントに影響を与えることを意味し、[EL] は実行レイヤークライアントに影響を与えることを意味します。
私たちは複数の EIP（FOCIL、Frame Transactions、Quick Slots を含む）の共同執筆者であり、関与していることに注意してください。すべての EIP を、関与の有無に関わらず独立して評価するよう努めていますが、私たちの立場を評価する際にはこの点を考慮してください。
tl;dr
CL ランキング
この特定の [CL] ランキングは、Forkcaster で こちら から反復できます。
EL ランキング
この特定の [EL] ランキングは、Forkcaster で こちら から反復できます。
それでは、前置きはこれくらいにして、現在の Hegota アップグレード全体に対する私たちの見解をご紹介します。
Hegotá のテーマ
0. FOCIL：検閲耐性の強化
EIP-7805: FOCIL はすでに SFI されており、Hegotá のヘッドライナーとして確定しています。Ethlabs チームの 3 名（Francesco、Barnabé、Julian）がその共同執筆者であり、私たちはその包含を強く支持します。決定はすでに確定しているため、ここでは簡潔に述べます。すべての人に対して中立なチェーンだけが、すべての人にとっての信頼のルートになり得ます。これにより、イーサリアムが世界経済、そしてその中のすべての個人にとって真の決済レイヤーへとスケールできるようになります。
1. Quick Slots：より高速なイーサリアム
イーサリアムの 12 秒スロットは、ユーザー価値を低下させるレイテンシコストです。したがって、私たちは [CL] EIP-8198: Quick Slots [S-tier] を Hegotá に含めることを強く推奨します。その理由は 4 つあります。
- より高速なトランザクション確認による L1 上の UX の改善。
- L1 上のオンチェーン市場がより新しい価格で動作し、スプレッドと LP エコノミクスが改善される。
- ファイナリティと高速確認ルールはスロット時間を継承するため、ブロックが高速化されるにつれて両方とも高速化され、イーサリアムとの相互運用性が向上する。
- 1 秒あたりのブロック提案者が増えることで、検閲耐性が向上する。これには経済的検閲耐性も含まれる。つまり、一定期間ブロックを空の状態に保つために支払う必要のある金額が増加する。
イーサリアムのユニークな分散化を維持しながら高速化することで、イーサリアムのブロックスペースの価値が高まり、その価値はネットワークと ETH に蓄積されます。減少するたびに、ユーザーに即座に価値が提供されます。最後に、より高速なブロックは、アプリケーション開発者から最も要望の多かった変更の 1 つです。
今すぐ開始する理由は、スロット時間の短縮は一度きりの変更では決してないからです。スケーリングと同様に、実際に提供された短縮は、ロードマップ上の約束よりもアプリケーションに確実性をもたらします。6 秒未満のスロットへの道は、スロット時間を変更可能にし、それを反復的に変更することから始まります。EIP-8198 は作業を 2 つに分割します。
- 仕様とクライアントコードでスロット時間を更新しやすくするための 1 回限りのリファクタリング。
- Hegotá での最初の短縮。その後、ロードマップが進み、安全性に関する経験的証拠が得られるにつれて、後続のフォークでさらに短縮。
Hegotá は、1 回限りのコストを支払うのに適したフォークです。Glamsterdam の ePBS はすでにスロットを再構築しています。Hegotá はコンセンサスレイヤーにとって比較的軽いフォークであり、I* での 分離コンセンサス によってこのウィンドウは閉じられます。そのため、1 回限りのリファクタリングのための CL 帯域幅は、今後数フォークにわたって再び利用できなくなる前に、今利用可能です。
つまり、今後最低 2 年間は 12 秒に留まるか、Hegotá で約 1 年後に 10 秒を実現し、その後 1 年以内に 10 秒未満を実現するかの選択です。これらの 2 つの短縮は理論上の改善ではありません。それらは直接、ユーザー価値の向上とネットワークエコノミクスの改善をもたらします。そろそろ始める時だと思います。
最も一般的な反論
ここでは、クライアント開発者や EF Protocol との予備的な議論で提起された 4 つの重要なポイントについて説明します。
1. 実装の複雑さ: ミリ秒精度のスロットタイミングは、ePBS の作業を通じてすでにコンセンサス仕様にマージされており、EIP-8198 の CL および EL 仕様のドラフトが存在し、ベースフィー、ガスリミット、ブロブスケジュールは、1 秒あたりの動作を維持するために再スケーリングされています。残りのコストは、固定スロット時間を想定するクライアントやツールのエッジケースとテストです。1 回限りのリファクタリングは、まさにこの作業を前倒しします。その後、各短縮はパラメータ変更になります。
2. zkEVM 証明: 主な 2 つの問題は、相対的な証明時間と一定の証明オーバーヘッドです。
2.1 相対的な証明時間は、スロット時間に占める証明の割合と、スロット時間が変わったときにこの割合がどのように変化するかを測定します。スロット内の関連する瞬間の簡単な説明を以下に示します。現在のビルダーは、前のペイロードのリリースを監視し、すぐに構築を開始できます。現在のビーコンブロックは、現在のスロットのペイロードをコミットします。このペイロードは、次のビーコン提案者のブロックリリース前に証明される必要があります。
証明の場合、最小相対時間は、ビーコンブロックリリースのレイテンシを差し引いたフルスロットです。ビーコンブロックリリースのレイテンシは圧縮不可能ですが、構造上短いため、現時点では根本的に制限するものではありません。また、最適化されたビルダーがペイロードの構築中に同時に証明することで、ビーコンブロック提案者によって勝利ペイロードがコミットされる前に証明を開始できる可能性もあります。
2.2 zkEVM 証明は、一部の固定オーバーヘッドを除き、主にブロックサイズに比例してスケーリングします。スロットが高速化されると、固定オーバーヘッドがより頻繁に支払われることになり、同じスループットに対してより多くのレイテンシが追加されます。レイテンシの予算が固定されている場合、良好なスループットを依然として得られるようにする必要があります。ここでは 2 つの機会が見られます。第一に、エンジニアリングの進歩により、これらの固定操作のレイテンシは引き続き低下するでしょう。第二に、EIP-7862 で説明されているように、ステートルートの計算を遅延させることで、証明の多くをクリティカルパスの外に移動できるため、圧縮不可能な操作のレイテンシ予算を増やすことができます。これら 2 つの機会の収束は、より高速なスロットが将来の十分なスループット向上を妨げないことを示しています。
3. ポスト量子移行: 分離コンセンサスアプローチは、将来のコンセンサスアーキテクチャに関して安定していると見なされるのに十分な支持を得ています。分離とは、ファイナリティ投票をブロック生成のクリティカルパスの外に移動することを意味します。特に、PQ 署名の大規模な集約と、関連するすべての再帰的 STARK メカニズムは、クリティカルパスの外に置かれます。ブロックの生成と、結果として得られるチェーンの先頭を追跡するためのフォーク選択ルールの取得のために残るのは、現在 512 のバリデーター、おそらく 256 で構成されると予想されるサブコミッティです。ポスト量子署名サイズは大きくなりますが、提案された 10 秒のスロット時間内で伝播するのに十分であり、将来的にはそれより短くなる可能性もあります。
4. スマートコントラクトとインフラ: スマートコントラクトとインフラにおけるスロット時間への依存は現在調査中です。スマートコントラクトについては、Sourcify と提携 して、検証済みのすべてのコントラクトの分析を実行しています。EIP-4788: Beacon block root in the EVM に従って保存された、履歴ビーコンブロックルートに対するスロット時間更新の影響を研究しています。インフラに関しては、事例として、Etherscan はスロット時間の変更により負荷が増加する可能性が高いが、インフラは Proof-of-Work 時代の可変スロット時間に構築されていたため、多くの変更は必要ないと述べています。
2. アカウント抽象化：UX、セキュリティ、プライバシーの向上
イーサリアムとその広範なエコシステムは、ネイティブ AA が長らく待たれており、パスキーウォレット、スポンサー付きトランザクション、ERC20 ガス支払い、トランザクションバッチ処理などの UX 上の利点をもたらします。
しかし、ネイティブ AA への道のりは特に困難でした。なぜなら、AA はクライアント、L2、ウォレット、RPC、開発ツールなど、イーサリアムスタックのすべての部分に触れるため、非常に多様なステークホルダーからの賛同が必要だからです。このため、どの AA EIP もイーサリアムのコンセンサス主導の開発プロセスを通過することは困難であり、EIP が出荷された後も実際の採用を達成することは困難です。
したがって、Hegotá のネイティブ AA 提案である Frame Transactions を A ティアに置きます。これは、技術的に S に十分でないからではなく、解決に膨大な調整を必要とする実際の採用リスクを考慮したいからです。AA におけるチームのバックグラウンドを考慮して、Ethlabs は L2 やウォレットなどのステークホルダーと協力して、ネイティブ AA の成功したローンチを実現することで、Frame Transactions を市場に投入する上で主要な役割を果たすことを目指しています。
それでは、Hegotá の具体的な AA 提案について説明します。
[EL] EIP-8141: Frame Transactions [A-tier]
私たちは、EIP-8141: Frame Transactions がイーサリアムのネイティブ AA システムの最良の候補であると考えています。他のネイティブ AA 提案と比較して、Frames にはイーサリアムの CROPS マンデートに独自に適合するいくつかの望ましい特性があります。
- パーミッションレスなアカウントイノベーション: 検証ロジックは EVM コードによって処理されるため、開発者は任意の検証ロジックを自由に開発できます。これは、検証ロジックのホワイトリストを義務付ける他の AA アプローチとは対照的です。
- プライバシープロトコルのファーストクラスサポート: 最初のポイントの当然の帰結として、Railgun などのプライバシープロトコルはフレームトランザクションの検証ロジックを処理でき、ユーザーは現在のように中央集権的なリレイヤーに依存せずにプライベートトランザクションを送信できます。これにより、プライバシープロトコルは大幅にプライベートで検閲不可能になります。
- ポスト量子安全性: フレームトランザクションは、イーサリアムの広範な PQ ロードマップを念頭に置いて開発されました。たとえば、フレームトランザクションは署名を集約できるように明示的に設計されており、イーサリアムは最終的に、個々の署名の検証に非常にコストがかかる場合でも、PQ 署名に低いガスを請求できるようになります。
Frame Transactions の主な弱点は、その最大の強みにも起因します。検証が EVM コードによって処理されるため、検証は固定コストではなく動的コストを誘発し、L2 などの高 TPS チェーンにとって課題となる可能性があります。この問題は、EIP-7819 などのフレームトランザクションに基づくさらなる EIP または ERC を通じて対処できると楽観視しています。これにより、トランザクションは静的に検証ロジックを示すことができ、シーケンサーは必要に応じてネイティブコードで検証を「ショートカット」できます。また、L2 や EF と協力してフレームトランザクションのベンチマークを実施し、パフォーマンスのボトルネックを特定して対処する予定です。
[CL][EL] Frame Transactions アドオン
フレームトランザクションの拡張と見なすことができ、その機能に基づいて構築する多数の EIP があります。
[EL] EIP-8250: Keyed Nonces for Frame Transactions [A-tier]
- この EIP は概念的に EIP-8141: Frame Transactions の一部であると考えており、それと一緒に出荷されるべきだと考えています。
- この EIP は、フレームトランザクションに 2D ナンスを導入します。2D ナンスにより、アカウントは並列トランザクションをメンプールに送信できるようになり、プライバシープロトコルはヌリファイアーを 2D ナンスとして保存できるようになります。これは、2D ナンスが読み取りと保存のコストが非常に低い特別なストレージであるため、プライバシートランザクションは、今日のように通常の動的ストレージにヌリファイアーを保存する場合と比較して、ガスを大幅に節約できるため重要です。これは、Glamsterdam のストレージ再価格設定（EIP-8037: State Creation Gas Cost Increase）のコンテキストで特に重要です。
[EL] EIP-8272: Recent Roots for Frame Transactions [B-tier]
- これは、Frame トランザクションでプライバシープロトコルを使用する際のエクスペリエンスを向上させる別の EIP です。プライバシープロトコルは、検証中に最近のコミットメントルートにアクセスする必要があります。通常のストレージに保存すると、コストがかかるだけでなく、Frames のパブリックメンプールルールと競合する可能性があります。EIP-8272 は、これらのルートをリングバッファに保存するシステムコントラクトを公開することでこれらの問題を解決し、古いルートを自動的に削除します。
- この EIP は特定のユースケースに対してフレームにかなりの複雑さを追加するため、B ティアに分類しました。また、同じ目標を達成するためのより一般的/エレガントな方法があるかどうか確信が持てません。
[CL] EIP-8369: VOPS Profiles for FOCIL Eligibility [B-tier]
- この EIP は、Frames と VOPS（有効性のみの部分ステートレスネス）間の相互作用に対処します。VOPS は、メンプールノードがトランザクションを検証するのに十分なステートのみを保存できるようにする提案であり、ステートレスネス（zkEVM による）の世界でもメンプールが検閲耐性を維持できるようにします。
- この EIP は、コミュニティがまだ完全に合意していない特定のステートレスネスのビジョンに強く結びついているため、B ティアに分類しました。
[EL] EIP-7906: Transaction Assertions via State Diff Opcode [B-tier]
- この EIP は、トランザクション結果の静的な監査可能性を向上させます。ユーザーは何が起こるべきかを主張することはすでにできますが、他に何も起こらなかったことを主張することはできません。ステート変更がないことの証明には、新しいオペコードが必要です。肯定的なアサーション（例：WETH 残高が少なくとも 1.5 増加）と否定的なアサーション（他のステート変更なし）を組み合わせることで、ユーザーはシミュレーションなしで、トランザクションの全体的な影響を構造的に制限できます。ハードウェアウォレットが明確な受益者の 1 つです。
- 複雑さを考慮すると、ハードフォークに含めることは非常に確定的な選択になります。これは、(a) クライアントチームがこの特定の EIP のニュアンスと影響を本当に理解している場合、および (b) テスト範囲と複雑さが非常によく理解されている場合にのみ行うことを提案します。
[EL] EOA 移行 [B-tier]
[EL] EIP-7851: Code-Controlled EOA Delegation [B-tier] と [EL] EIP-8151: Account Code Restricted ecRecover [B-tier] は、ペアの標準として見るのが最適であり、EOA がスマートアカウントに移行する方法のストーリーを一緒に提示します。このストーリーでは、EOA はまず EIP-7702 を介してスマートアカウントに委任します。次に、EIP-7851 が導入するオペコードにより、7702 委任が永続的になり、ルート ECDSA 鍵が無効になります。一方、EIP-8151 は ecrecover に非アクティブ化を認識させるため、古い鍵は Permit スタイルのフローを介して資金を引き出すことができなくなります。
このペアを B ティアに評価するのは、EOA をスマートアカウントに移行する多くのアプローチの 1 つにすぎず、この特定のアプローチは広範なレビューや賛同を得ていないからです。特に、このアプローチがマルチチェーンの問題に答えていないことを懸念しています。同じ EOA は L2 上でどのように移行するのでしょうか？ユーザーは、まだ存在しないチェーンを含む、すべてのチェーンで同じアクションを実行する必要があり、UX が悪化します。L2 が EOA 移行の「信頼のルート」として L1 を活用できる、より良いアプローチがある可能性があると考えているため、ユーザーがすべての EVM チェーンに対して 1 回移行できるようにするアプローチのために A/S ティアを確保します。
[EL] PQ 署名スキーム [A-tier]
Hegotá は、ポスト量子署名への信頼できる道筋を確立する必要がありますが、コミットする前に適切なメカニズムを確認する必要があります。
- EIP-8355: Add ML-DSA verification プリコンパイル。Frame Transactions と並んで、ポスト量子アカウントセキュリティを具体化します。
- 代替案: PQ サポートをアクティブ化せずに事前登録するか、後で PQ 鍵に対応できる派生フォーマットを定義します。
[EL] EIP-7819: SETDELEGATE 命令 [A-tier]
- ネイティブ AA が Hegota に導入される可能性が高いため、新しいスマートアカウントのデプロイコストを低く抑えることが重要ですが、Glamsterdam では EIP-8037 により、アカウントのデプロイは実際にはより高価になります。EIP-7819 を使用すると、新しいアカウントはプロキシコントラクトの代わりに単純なデリゲートポインターを使用するため、作成する必要のある新しいステートの量が大幅に削減され、デプロイコストが削減されます。
- アカウントのデプロイコストが低くなれば、AA を採用する際の障壁が大幅に低下すると考えているため、この EIP を A ティアに分類しました。
3. パフォーマンスエンジニアリング：継続的な L1 スケーリング
Glamsterdam は、イーサリアムが R&D に取り組む方法に変化をもたらし、プロトコル設計とクライアント作業の両方において、パフォーマンスが第一級の R&D 制約として扱われるようになりました。遅延実行、リソースの再価格設定、および多くのクライアント最適化作業により、過去 2 年間で 30M から（少なくとも）200M へのスケーリングが可能になりました。一般的に、パフォーマンス作業は私たちに選択肢を与えます。得られた余裕は、スケーリング、スロットの短縮、ノード要件の引き下げ、またはこれらすべてに使用できます。
今日でも、継続的なスケーリングは必要性であると考えています。アプリケーションは、現在の価格だけでなく、イーサリアムが時間の経過とともに予測可能にブロックスペースの供給を拡大できるかどうかに基づいて、どこで構築するかを決定します。一貫した増加を提供することは、ロードマップ上の約束だけよりも確実性をもたらします。メインネットの容量は、需要の急増に対処できるにはまだほど遠いです。イーサリアムの 11 回目の誕生日には、1 日あたりの中央値ベースフィーはわずか約 0.1 gwei でしたが、NFT ミントにより、しばらくの間 10 gwei を超え、トランザクションコストの中央値は約 1 ドル、90 パーセンタイルは 5 ドル以上に達しました。したがって、Glamsterdam のスケーリング推進は Hegotá にも継続されるべきです。
まとめると、以下の EIP は Glamsterdam のスケーリングの勢いを継続すると同時に、その背後にあるより広い原則を強化します。パフォーマンスは、クライアント作業とプロトコル設計の両方において、第一級の関心事であり続けるべきです。
[EL] EIP-8131 & EIP-8279 [S-tier]: データ再価格設定バンドル
Glamsterdam の次に、次の制約となるのはペイロード伝播です。これは、ペイロードバイトのソースの違いがガス計算に一貫して反映されていない、または全く反映されていないことに一部起因します。EIP-8131: Unified Transaction Content Floor は、既存のトランザクションフロアを実行前に既知のコンテンツに拡張し、EIP-8279: Block Access List Byte Floor は、実行中に動的に生成される BAL バイトをカバーします。
この動的な計測により、EIP-8279 は明らかにこの 2 つの中でより複雑です。しかし、これらはバンドルとして考えることをお勧めします。これらは連携して、トランザクションに関連するバイトの一貫した計算を確立し、ほとんどの通常のデータ量の多くないトランザクションに影響を与えることなく、最悪のケースのペイロードを制限します。これにより、基礎となるリソース計算のギャップが修正され、さらなるガスリミット増加への道が開かれます。
[CL][EL] EIP-8146: Block Access List Sidecars [A-tier]
EIP-8146 は、BAL をペイロードとは別に伝播させることでクリティカルパス自体を改善し、伝播を向上させ、実行クライアントに状態プリフェッチとポストステートルート計算の先行スタートを与えることで、再価格設定を補完します。これは、私たちが活用すべき低いところにある果実のようなものだと考えています。実装作業は主に使い慣れた CL ゴシップ機構であり、特に EL 主体になりつつあるフォークにおいて、労力が少なく価値の高い EIP です。
その他の関連 EIP
[EL] CPSB 再調整 [A-tier]
- 非常にシンプルな変更であり、パイプラインに残し、計画されているガスリミット増加と状態および実行ガスの使用状況の観察に基づいて必要と判断された場合に、2 つのうちの 1 つを含めることを推奨します。
- EIP-8368: CPSB Recalibration for New Gas Limit: EIP-8037 への事前計画されたフォローアップであり、状態バイトあたりのコスト (CSPB) がガスリミットの関数ではなく静的にされたという事実を補償するもので、純粋に実装とテストの簡素化のためです。アイデアは、ブロックごとの調整を、ガスリミットが増加するにつれて状態の成長を目標に保つために必要に応じて、フォーク時の 1 回限りの調整に置き換えることでした。現在の CPSB は 150M のガスリミットで調整されているため、Hegotá での調整が必要になる可能性が高いです。
- EIP-8372: Normalized state gas limit: 依然としてかなり最小限の EIP-8368 のスーパーセットであり、CPSB だけよりもきめ細かい調整を可能にし、相対的な価格設定の誤りにより状態成長目標または通常のガス目標のいずれかが未達になることを補償します。
[EL] EIP-7862: Delayed State Root [B-tier]
- 仕様化は簡単ですが、クライアント実装の複雑さは私たちの知る限りあまり理解されていません。ステートルートはコードベースに広く浸透しています。
- 競争力のあるブロック構築へのアクセス障壁を下げる（高速なステートルート計算）ことにはある程度の利点がありますが、EIP の最も実質的な利点は将来的にあると私たちは考えています（ステートルート計算を証明するためのより多くの時間）。
- EL はすでに Hegotá の重い側です。
[CL] EIP-8341: Partial Execution Payload Commitments [D-tier]
- 却下を推奨します：利点は小さく（ステートルート計算をわずかに遅らせる）、緊急性はなく、EIP-7862: Delayed State Root（はるかに多くの時間を与える）に取って代わられています。
その他の EIP
ここでは、残りの EIP を大まかにトピックごとにグループ化して説明します。いくつかの EIP については、まだ意見を形成中です。今後数日から数週間のうちに、クライアントチームや EIP の著者からさらに学ぶにつれて、このドキュメントを更新します。
Hegotá は EL に偏ったハードフォークになりそうなので、規律を守り、EL 側の EIP がクリアすべきハードルを高く設定することをお勧めします。FOCIL と Quick Slots を除いて、Hegotá を比較的 CL ライトに保つことが望ましいと考えています。つまり、範囲を狭くすることで、クライアントチームがより大規模なアーキテクチャ移行に備えるための帯域を確保できます。
[CL] 発行
私たちは意図的に EIP-8363: Tapered Issuance Burn にティアを割り当てません。発行はコアデベロッパーが単独で決定すべき事項ではなく、ティアリストはコアデベロッパーへの明示的な推奨であると考えています。ほとんどの EIP では、ACD プロセスは決定が主に技術的であり、コミュニティが効果的にコアデベロッパーに委任しているため、うまく機能します。発行は、コミュニティ自体が大まかな合意に達する必要がある金融政策の問題であるという点で異なります。コアデベロッパーの意見は重要ですが、その公開討論へのインプットとしてです。EIP-8363 を他の EIP と同列にランク付けすることは、それを通常の ACD 決定として扱うことになり、そうすべきではないと考えます。
技術的には、EIP-8363 に沿った発行の変更にはメリットがあると考えています。それが対処する問題は現実のものです。より多くの ETH がステーキングされるにつれてスラッシングの信頼性は低下し、高いステーキング比率は報酬が主に希薄化を相殺することを意味し、規模の経済は大規模オペレーターとソロステーカーの間のギャップを広げ続けています。変更には、影響の不確実性からステーク分布、金融政策の固定化クロックのリセットに至るまで、リスクもあります。Ansgar のスレッド は両方の側面を示しており、私たちの立場を反映しています。私たちの中には、過去に発行の変更を主張し、その道のりに引き続き確信を持っている者もいます。
発行の決定は、Hegotá の他のすべてのスコープ決定の後に行うことをお勧めします。これにより、コミュニティの議論に必要な時間が与えられ、スコーピングプロセス自体から注意がそらされるのを防ぎます。
[CL] ステーキング機能
ステーキングの改善は価値がありますが、ユーザー向けのメリットは、厳密に必要でない限り、インフラストラクチャのみの変更よりも優先されるべきです。
[CL] EIP-8015: Remove deposit and eth1data fields [A-tier]
- 技術的負債の非常にシンプルなクリーンアップ。EIP-7688: Forward compatible consensus data structures のおかげで、無関係なフィールドのマークル証明は影響を受けないため、チェーンコンシューマーへの影響はありません。
[EL][CL] EIP-8237: Independent CL/EL Sync [B-tier]
- ePBS によって導入されたビーコンブロックとペイロードの分離に基づいて、EL と CL が独立して同期できるようにします。これにより、イーサリアムクライアントの複雑な部分を簡素化できる可能性があると考えています。
[CL] EIP-8205: Withdrawal credentials preregistration [D-tier]
- 却下を推奨します。この EIP は、委任ステーキングにおける実際の問題に対するプロトコル内のソリューションを提供しますが、既存の事前入金ソリューションで十分であり、追加された機構の複雑さは現在正当化されないと考えています。
[CL] EIP-8148: Custom sweep threshold for validators [D-tier]
- 却下を推奨します。この EIP は、その利点（主にホームオペレータープールからのわずかな追加統合を促進すること）に対して複雑すぎる（新しいシステムコントラクト、新しい実行リクエスト、CL 機構）と考えています。ステークがどのように分散されているかを考えると、これがバリデーター全体の統合に大きな影響を与えるとは思いません。
[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [D-tier]
- 却下を推奨します。これはおそらく、より多くのサイドチャネリングにつながるだけだと考えています。さらに、MEV バーン戦略に関する長年の議論は、幅広い研究コンセンサスに達した提案には至りませんでした。
[CL] EIP-7716: Anti-correlation attestation penalties [D-tier]
- 却下を推奨します。ステーキングインセンティブにおけるこのようなかなり大規模な変更が正当化されるという十分に明確な証拠はないと考えています。さらに、ステーキングインセンティブは、おそらく分離されたコンセンサスの一部として再構築されるでしょう。
[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [D-tier]
- 却下を推奨します。素晴らしいクリーンアップですが、今後の大規模な分離コンセンサス移行に先送りする価値があると考えています。
[CL] EIP-8359: Beacon Block Reporting Field [意見形成中]
[CL] さらなる PQ 準備
これらの提案は、将来のポスト量子移行に先立って、残りの BLS 依存関係を削減します。
[CL] EIP-8365: BLS withdrawal credential retirement [A-tier]
- レガシーな引き出し資格情報を廃止し、プロトコルの簡素化と将来の PQ 移行の簡素化の準備を整えます。
- 非常にシンプルであることを考えると、今含める価値があると考えています。
[CL] EIP-8367: Balance sunset for retired BLS validators [D-tier]
- 却下を推奨します。EIP-8365: BLS withdrawal credential retirement がアクティブ化される前または後に、ほとんどの 0x0 バリデーターが資金を引き出すかステーキングを継続できるようにするために、資格情報の変更 (BLSToExecutionChange) を行う可能性が高いと考えています。残りの 0x0 ステークに対処するためのメカニズムを導入する緊急性はあまりないと考えています。EIP-8365 のみを含め、次のステップを決定する前にその結果を確認することをお勧めします。
[CL] EIP-8321: Hash-Chain RANDAO [D-tier]
- 却下を推奨します。RANDAO を単独でポスト量子安全にしても、バリデーターの BLS 鍵が脆弱なままである間はプロトコルレベルのセキュリティはほとんど向上しませんが、バリデーターあたり約 32 バイト、新しい秘密管理機構、およびほとんど単一目的のメカニズムが追加されます。より広範な PQ コンセンサス設計は未定のままです。私たちは反復的な移行を支持しますが、その最初のステップは、最終的な設計によって取って代わられるリスクを冒すのではなく、合意されたロードマップに従うべきです。
[EL][CL] zkEVM 準備
ほとんどの zkEVM 準備は、限られたユーザーセットにとってフルノード運用を容易にするという短期的なメリットしか提供しませんが、実装の帯域を消費し、EVM をより高価にする可能性があります。長期的な価値がこれらの即時コストを明確に正当化する変更のみを含めるべきです。
[CL] EIP-8025: Optional Execution Proofs [D-tier]
- この EIP はハードフォークを必要としません。Hegota にバンドルするという提案は、純粋に優先順位の表明であり、私たちはその選択に同意しません。作業は継続されるべきですが、Hegotá はそれによってブロックされるべきではありません。
- オプションの証明をリリースする前に、まず最終状態を定義し、その後それに向けて加速するように努めるべきであり、長期的なバリデーター/状態モデルの明確なビジョンがないままオプションの証明をリリースするべきではありません。
- 中心となる未解決の質問は、バリデーターが状態に関してどのような役割を持つべきかです。つまり、完全にステートレスになるのではなく、状態の一部を提供または保持し続けるべきかどうかです。バリデーターは実際のハードウェアとネットワーク価値を持つコアノードコホートであるため、その役割を弱める変更は、より高いハードルをクリアする必要があります。
[EL] EIP-7666: EVM-ify the identity precompile [A-tier]
- 便利で小さな変更
[EL] EIP-8200: EVMification [B-tier]
- EIP-8200 は、3 つのネイティブプリコンパイルを同等の EVM バイトコードに置き換えます。2 つはほとんど使用されておらず、移行は簡単そうです。3 つ目は SNARK 検証で広く使用されているため、その削除をサポートする前に影響評価が必要です。
- 影響分析の結果、影響を受けるユーザーの移行コストが低いことが判明した場合、または 3 つ目のプリコンパイルが範囲から除外された場合、EIP-8200 を [A-tier] に移動します。
[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [D-tier]
- ガスコストの非常に大きな増加によりかなり破壊的であり、緊急性はありません
- リスクを軽減するには、影響分析を実施するか、後日、何らかの形式のブロックレベルのウォーミング（またはこれらの値のアドホックなウォーミング）とともに行うことで、影響を軽減できます。
[EL] EIP-8268: Storage Roots in Block Access Lists [B-tier]
- BAL サイズへの具体的な影響、およびトランザクションコストへの関連する影響（EIP-8279 は BAL バイトに課金することを提案しています）の分析が必要になる可能性があります。これは、タッチされた各アカウントの BAL エントリに追加のストレージトライルートが追加されるためです。
[EL] EVM 機能
Hegotá は依然としていくつかのアドホックな EVM 決定を必要とします。Hegotá 後、イーサリアムは、より広範な EVM エコシステムによって形成された長期的な EVM ロードマップに向けて取り組むべきだと考えています。Ethlabs はそれに貢献します。
[EL] EIP-5920: PAY opcode [A-tier]
- 非常にシンプルであり、EVM が持つべき良いプリミティブだと考えています
- 具体的なユースケースをよりよく理解することが重要です
[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [A-tier]
- L2 にとって非常に便利で、L1 にとっては実質的なコストはありません（情報提供のみ）
[EL] コードの再利用 / 重複排除 [B-tier]
- EIP-8058: Contract Bytecode Deduplication Discount と EIP-8298: SETCODEFROM Code Reuse Instruction はどちらも、コントラクトコードがクライアント内の対応するアカウントとは別に保存され、コードハッシュがそれらの間のポインタとして機能するという事実を活用しようとしています。したがって、同一の共有コードは重複排除されて保存できます。どちらの EIP も、アカウントコードハッシュを、他の場所に存在するコードのハッシュに安価に設定する方法を提供します。
- これは魅力的な一般的なアイデアだと考えていますが、バイナリツリーへの影響と前方互換性を理解することが重要です。現時点では 2 つの間で好みはありません。
[EL] メモリ価格設定改革 [B-tier]
- Hegota でメモリ改革を実行したいかどうかを決定する必要があります。現在、この評価を行うための設計空間の十分な理解があるかどうかは明らかではありません。
EIP-7686: Linear EVM memory limits
- より小さな変更で、2 次メモリ拡張コストを排除するだけです。
EIP-7923: Linear, Page-Based Memory Costing
- より深く、より原則に基づいた再作業ですが、より複雑です。
[EL] EIP-8219: Checked Arithmetic Opcodes [B-tier]
- 全体的に、EVM に安全な算術演算を追加することは有用と思われます。
- 価格設定はベンチマークで確認する必要がありますが、その複雑さはどの程度でしょうか？
- ベンチマークと影響分析（どれだけのトランザクションがどの程度恩恵を受けられるか、どのコンパイラがサポートを追加するか？）があれば、A-tier になる可能性があります。
[EL] EIP-8360: TCREATE Opcode [B-tier]
- この EIP は、トランザクションスコープの一時的なコントラクトを作成する機能を導入します。これは一般的に持っておくと便利なプリミティブです。
- EIP はかなりの複雑さを追加します。より徹底的な実装とテストの複雑さの評価があれば、A-tier になる可能性があります。
[EL] EIP-7645: Alias ORIGIN to SENDER [D-tier]
- 却下を推奨します：破壊的な変更であり、ORIGIN の不適切な使用です。
[EL] EIP-8182: Private ETH and ERC-20 Transfers [D-tier]
- 却下を推奨します：大規模な変更であり、zk 依存関係を追加します。もし導入されるとしても、それは目玉機能であるべきだと考えています。
[EL] EIP-2488: Deprecate the CALLCODE opcode [意見形成中]
[EL] EIP-4758: Deactivate SELFDESTRUCT [意見形成中]
[EL] EIP-7979: Call and Return Opcodes for the EVM [意見形成中]
[EL] EIP-8173: Foundations of EVM Control Flow [意見形成中]
[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [意見形成中]
[EL] EIP-8030: P256 algorithm support [意見形成中]
[EL] EVM 価格設定
Glamsterdam は、全体的なスループットを制約する過小評価されたオペレーションの価格を引き上げました。Hegotá の EVM 価格設定提案は、主に反対側、つまり個々のオペレーションの現在のコストがその使用を制限しているものの、ネットワークのスケーラビリティには影響しないものの価格を引き下げることに対処しています。したがって、これらは EIP ごとの影響が低い、あると便利なものです。私たちは対象を絞った再価格設定には前向きですが、新しい計測メカニズムを導入する提案は、その設計が健全で、熱心なチャンピオンによって十分にリスクが軽減されている場合にのみ含めるべきです。
[EL] EIP-8358: Net Gas Metering for Account Changes [B-tier]
- 影響については確信が持てません。サンプリングされた 900 のメインネットブロック、約 40 万トランザクションにおいて、全トランザクションの 2.07% がガスを節約し、ブロックガスの 1.14% が節約されます。
[EL] EIP-7973: Warm Account Write Metering [意見形成中]
[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [意見形成中]
[EL] EIP-7971: Hard Limits for Transient Storage [意見形成中]
[EL] EIP-3298: Removal of refunds [意見形成中]
[EL] EIP-8374: Persist Warm Access Sets Across Reverts [意見形成中]
[EL] EIP-8115: Batch priority fees at end of block [意見形成中]
[EL] EIP-8188: Last-Written Block for Accounts and Slots [意見形成中]
[EL][CL] 実行データとインデックス作成
[EL][CL] EIP-7668: Remove bloom filters [意見形成中]
[EL][CL] EIP-7807: SSZ execution blocks [意見形成中]
[EL] EIP-8116: Replace cumulative receipt fields [意見形成中]
[EL] EIP-8304: Trustless log and transaction index [意見形成中]
[EL][CL] ネットワーキング
イーサリアムの P2P レイヤーには、特にトランザクション、ブロブ、アテステーションがネットワーク全体でどのように伝播されるかにおいて、対象を絞った改善の余地があります。
[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [A-tier]
- ブロブ数のスケーリングにおけるボトルネックとしての完全な再構築とフルカストディノードのパフォーマンスを一般的に防止します。
- 価値があり、最終的には何らかの形式の分散再構築がプロトコルに組み込まれるべきです。これにより、バリデーターのカストディを削除できる可能性があります。
- 複雑さをよりよく理解する必要があります。
[CL] EIP-8142: Block-in-Blobs (BiB) [D-tier]
- 時期尚早であり、強い緊急性はなく、かなり土壇場であり、多くの疑問が残っています（KZG かどうか？新しいゴシップトピックかどうか？）。
- ブロック生成のクリティカルパスに KZG を導入したくありません。代替案は不明確であり、さらなる複雑さを追加します。
[CL] EIP-8243: Batching Attestations at Source [D-tier]
- これに依存してファイナリティまでの時間を短縮できるかどうかは不明であり、負荷に明確な制限を設けていません。
- メカニズムの DoS 耐性は完全には明らかではありません。
[EL] EIP-8077: eth/XX - announce transactions with nonce [意見形成中]
[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [意見形成中]
[CL] EIP-8334: Bundled Attestation Propagation [意見形成中]
もし何らかの理由でまだここにいてくださっているなら、最後までお読みいただきありがとうございます。ご質問があればお気軽に返信してください。できる限りお答えいたします！もし読み飛ばして、巨大なテキストの壁を覗き込むことが日曜日の過ごし方ではなかったためにここまでスクロールしてきたなら、次の部分が短いことを知って喜んでいただけるでしょう。
最後に（もう少しだけ）...
イーサリアムのアップグレードは、賭け金が高いために複雑です。世界中の何千ものノードが同じスロットで新しいルールに切り替わり、その間ネットワークは一瞬たりとも停止しません。その厳格さが、イーサリアムが出荷してきたすべてのアップグレードを支え、その結果、11 年間 の 100% の稼働率を祝う分散型ネットワークが実現しました。
Hegotá に関する私たちの立場は、現時点での最良の評価ですが、議論や実装作業からの新しい証拠が私たちの見解を変えるたびに、私たちの考えを更新します。
これらの EIP の中には Ethlabs のメンバーによって作成または推進されたものもあれば、イーサリアム全体の非常に広大で、才能があり、善意にあふれた研究者、クライアント開発者、個人の貢献者からのものもあります。しかし、それらすべてが成功するためには、クライアントチーム、ウォレット、アプリケーション、L2、インフラプロバイダー、機関、ノードオペレーター、そして最終的にはユーザー間の協力が必要です。イーサリアムは世界共通のプロジェクトであり、意味のあるネットワークの進歩は決して一つの組織の仕事ではありません。
私たちはこのエコシステムの小さな一部であることに感謝しており、イーサリアムがその可能性を実現するのを支援できることを楽しみにしています。
– Ethlabs
