イーサリアムのロードマップの実装の進捗状況を 1 つの記事で学びましょう

原文の編集: The Way of DeFi

原文の編集: The Way of DeFi

注: このドキュメントは、イーサリアム ロードマップ上のさまざまなプロジェクトのエントリ ポイントとして機能することを目的としており、さらに詳しく知りたい人向けに簡単な概要とリンクを提供します。

これは生きた文書です。ここで提供されている情報が不明確、不正確、古い、または適切なリンクがない場合はお気軽にご連絡ください。

ロードマップ上の矢印で示されているように、リストされているフェーズは連続したものではなく、さまざまな取り組みが並行して行われています。

1. 合併

目標: 理想的、シンプル、堅牢、分散型のプルーフ オブ ステーク (PoS) コンセンサスを確立すること。

何が行われたのか

1. 2020 年 12 月 1 日 - ビーコン チェーンが開始されました。

• バリデーターによってステークされたETHによって保護されたイーサリアムコンセンサスレイヤーの導入。

• コンセンサス仕様ではフェーズ 0 と呼ばれています (Vitalik と Danny Ryan の注釈付きバージョン)。

2. 2021 年 10 月 27 日 - ウォームアップ フォーク (Altair) - コンセンサス クライアント開発者が調整されたハード フォーク アップグレードを試行します。

• Altair はライトクライアントをサポートするために同期委員会を導入し、いくつかのペナルティを調整しました。

• アルタイルのお知らせ;

• Altair 仕様 (注釈付きバージョン)。

• Altair に関する「ETH 2 の新機能」記事。

3. 2022年9月15日 - 統合されました！ PoW はもうありません - コンセンサス層と施行層はブロック 15,537,394 で大規模にマージされました。

次は何ですか

1. 引き出し – バリデーターがステークした ETH ステークの全部または一部を引き出すことができます。

• Capella フォークはコンセンサス層への変更を指定します。

• EIP-4895 は実行層への変更を指定します。

• Tim Beiko の出金に関するよくある質問。

• 追加情報を含む出金メタ仕様。

2. 分散バリデータ - マルチ署名を導入します。n 人が同じバリデータを共有し、n 人中 m-of-n がその動作方法について同意する必要があります。

• 偶発的なスラッシュを防止し、アクセスしやすくすることでステーキングを強化します (たとえば、必要な 32 ETH をトラストレスレスに複数の参加者に分配することで)。

• これはプロトコル内のものではなく、SSV や Obol などのチームが取り組んでいます。

3. マージの表示 - フォーク選択ルール (バリデーターの投票方法) を調整して、攻撃の種類を軽減します。

• 基本的に、誠実なバリデーターがチェーンの正しい先頭について自分の意見を「押し付ける」ことを可能にし、悪意のあるバリデーターが投票を分割し、後で意のままにブロックを再編成する可能性を減らします。

• ethresear.ch には、(非常に技術的な) 研究背景が豊富に記載されています。

4. 集約の改善 - イーサリアムはできるだけ多くのバリデーターをサポートするよう努めていますが、各バリデーターが各ブロックに対して投票する (および他のすべてのバリデーターの投票を検証する) と帯域幅を大量に消費します。次に良いのは署名を集約することですが、これには制限があり、より適切に実行できる可能性があります。

• BLS 集約の利点に関する人気のある科学投稿。

• 潜在的な候補: ホルン。

5. シングル スロット ファイナリティ (SSF) - チェーンはエポック (12.8 分) ではなく、スロットごと (12 秒) に決定されます。

• SSFへの経路。

• 署名の集約の改善に加えて、次の 2 つのことに対処する必要があります。

(1) SSF コンセンサス アルゴリズム - 既存の SSF 互換アルゴリズムでは十分ではありません。バリデーターの 1/3 以上がオフラインであってもチェーンをアクティブに維持できるアルゴリズムが必要です。

(2) SSF バリデーターの経済学 - 最終的にバリデーターの数を制限しなければならない場合、参加をどのように制限し、どのような犠牲を払うのでしょうか?

6. シークレットリーダー選挙（SLE）

• 現在、ブロックを提案するために選択されたバリデーター (スロット リーダー) は事前にわかっているため、潜在的な DoS 攻撃が今後のブロックのリーダーを具体的にターゲットにすることが可能になります。

• ランダムシャッフルを伴う単一の SLE プロトコルに関する ethresear.ch の投稿: ブロックとリーダーシップの証明を明らかにするまで、リーダー自身を除いて誰がスロットのリーダーになるかはわかりません。

• 非単独の秘密リーダー選挙も選択肢となるかもしれない。

7. より多くのバリデーターのサポート - 継続的な長期的な取り組み: より多くのバリデーターを安全にサポートすることが常に望ましいです。

8. 量子安全なアグリゲーションに適した署名 - イーサリアムを量子コンピューター攻撃から安全にします。

• イーサリアムで使用されている BLS 署名スキームの背後にある暗号化は、量子コンピューターによって解読されたことが知られていますが、既知の量子安全な代替署名スキームは BLS 署名スキームほど効率的に集約されません (したがって、量子安全性と量子安全性を両立する方法が必要です)および集計に優しい)。計画);

• 2 つの主要な量子セキュリティ手法は STARK と Lattice に基づいています。

9. EIP-4844 の実装 - EIP-4844 をイーサリアム メインネットに適用します。

• 説明、予定スケジュール、仕様など、信頼できるセットアップを作成するには「儀式」が必要です。

• EIP-4844 実装タイムラインの概要。

10. 基本的なロールアップ展開 - 以下に依存します。

• EIP-4844 - BLOB 領域の使用可能な容量を制限する「すべてのノードがすべてのデータをダウンロードする」性質のため、スケーリングは依然として基本的/限定的であると考えられています。

• 制限付き補助輪のロールアップ (提案されたマイルストーンを参照)。

11. 完全なロールアップ展開 - 以下に応じて異なります。

• データ可用性サンプリングのための P2P 設計: データ シャーディングに必要なネットワークに関わるすべての取り組みと研究

• DA サンプリング クライアント: 数キロバイトのランダム サンプリングを通じてデータが利用可能かどうかを迅速に判断できる軽量クライアントを開発します。

• 効率的な DA 自己修復: 最悪のネットワーク条件 (悪意のあるバリデータ攻撃や多数のノードの長時間にわたるダウンタイムなど) の下でもすべてのデータを効率的に再構築できます。

• 補助輪のないロールアップ: 完全に分散化されたシーケンサー、トラストレスな不正行為証明者、不変の契約など。

12. 量子セキュリティと信頼できない設定の約束 - イーサリアムを量子コンピューターの影響から免れます。

• 多項式コミットメント (KZG) は効率的かつ強力ですが、量子安全ではなく、信頼できるセットアップが必要です。より理想的な長期コミットメントに関する研究が進行中であり、最終的な目標は内部で KZG を「ホットスワップ」することです。

2. 災い

関連リンク：

関連リンク：

• 信頼できる中立性によって導かれます。

• MEVに関するさまざまなツイート。

• MEV および PBS に関する記事。

• PBS のリンクのリスト。

何が行われたのか

1. プロトコル外の MEV マーケット - MEV-Boost ミドルウェアにより、一般のバリデーターは複雑な MEV 戦略を自ら実行することなく MEV から利益を得ることができます。

• 検閲の問題があるため、解決策自体は完全ではありません。

• これらの合意外市場の回復力を高めるためのアイデアや計画については、「回復力のコスト」と「SUAVE」を参照してください。

次は何ですか

1. 包含リストまたは代替案 - ブロック提案者がブロックビルダーに制限を課す、つまりトランザクションを含めることを強制します。

( 1 ) にはリストの注釈が含まれます。

(2) ブロック提案者に負担をかけずにブロック構築者を制約するための研究。

2. プロトコル内 PBS – ブロック ビルダーの市場をプロトコルに直接組み込みます。

3. MEV バーン - オンチェーンエコノミーから抽出された価値をブロックチェーンに取り込ませます。

(1) 提案者オークションによる MEV 提案の直接破棄。

(2) 委員会主導の MEV スムージングにより、プロトコルが MEV を認識できるようになります。

(3) 経済的インセンティブを通じて設定されたバリデーターを制限すると、ネガティブ発行を通じて間接的に MEV が燃焼されます。

4. アプリケーション層 MEV の最小化 - L1 とは直接関係ありませんが、このプロジェクトには開発者が dapps を設計する際に MEV を考慮することが含まれます。 MEV 最小化戦略を採用する dapp の例をいくつか示します。

分散ビルダートラック

ブロック提案が分散化されたままであるため、ブロック構築が集中化されるという別の問題が発生しています。ロードマップ上の他のすべてのプロジェクトが集中ブロック構築による最悪の悪影響を最小限に抑えることを目指しているにもかかわらず、ブロック構築を複数のノードに分散できることは依然として大きな利点です。

• BLOB 構築 - 一般的な消費者向けハードウェアが実行できる複数のノードにわたるデータ シャーディングの高帯域幅と処理要求をオフロードする方法を見つける。

• 事前確認サービス - ユーザーに自分のトランザクションが次のブロックに含まれるという強力な保証を提供します。

• 鉛保護 - サンドイッチ トランザクションなどの有害な MEV を最小限に抑え、分散ビルドを確実に中立に保ちます。

これは、非常にオープンな設計上の考慮事項を備えた依然として活発な研究分野であるため、最初の 2 つの項目をプロトコルに含めるべきかどうかは不明です (したがって、ロードマップ上では疑問符のステータスになっています)。

関連リンクをいくつか示します。

• 分散ブロック構築について言及しているマージドブロック構築についての話: https://www.youtube.com/watch?v=KP 5 ppCRH 0 iM

• 分散型ブロック ビルダーと話す: https://www.youtube.com/watch?v=fAgrIdyWIqc

• 分散ブロック構築に関するいくつかの考え: https://github.com/flashbots/mev-boost/issues/139

3. ザ・ヴァージ

目標: ブロックの検証は非常に簡単である必要があります。N バイトのデータをダウンロードし、いくつかの基本的な計算を実行し、SNARK を検証すれば完了です。

このフェーズは基本的に、最終的にライト クライアントを実装することで「クライアント ギャップ」を埋めることになります。誰もがフル ノードを実行したいわけではないし、フル ノードを実行できるわけでもありません。 The Verge の目標は、実行が簡単で、多くのストレージと帯域幅を必要としない、トラストレスまたはトラストを最小限に抑えた代替手段を導入することです。 The Verge の最終目標は、これらのライト クライアントが今日のフル ノードと同じセキュリティ保証を提供することです。

すべては、SNARK や STARK などのゼロ知識技術に依存しており、これらの技術自体は多項式コミットメント スキームに依存しています。関連リンクをいくつか示します。

• zk-SNARK がどのように実装されるかを簡単に紹介します。

• STARKの分析;

• ある程度の数学とプログラミングの知識がある場合は、この記事を読むことで zk-SNARK が何であるかを理解できます。

• イーサリアムのスケーリングにおける多項式コミットメントスキームの役割について。

何が行われたのか

1. 最も深刻な EVM DoS 問題、主にガス価格の問題が解決されました。これはベルリンのアップグレードで修正されました。

2. 基本的なライト クライアント サポート (同期委員会) - 同期委員会のおかげで、コンセンサス層に従うライト クライアントを簡単に構築できます。

• Helios クライアントが同期委員会をどのように利用しているかを確認してください (およびこれらの委員会がどのように機能するかについての優れた記事)

次は何ですか

1. SNARK / STARK ASIC - プルーフの作成専用に構築されたハードウェア。

2. Verkle ツリー - グローバル状態に使用されるデータ構造をより効率的なデータ構造に置き換えます。

(1) Verkle ツリーのリンクされたリスト。

(2) 主な利点は、ライトクライアントがブロックヘッダーのみを使用して口座残高などを簡単に検証できる非常に短い証拠を持っていることです。同期委員会を利用して、特定のブロックが実際にメインブロックの一部であることをすでに検証できます。鎖;

(3) 正しい仕様、安全に移行する方法、および状態の更新/編集の EVM ガス コストにどのような影響を与えるかを理解することに依存します (パージでの自己破壊の禁止にも依存します)。

3. SNARK ベースのライト クライアント – SNARKify 同期委員会の移行により、現在の同期委員会がどのバリデーターで構成されているかを迅速に証明します

4. 完全に SNARK されたイーサリアム - 以下の 3 つの項目は、イーサリアムが非常に効率的でトラストレスなブロック検証のファイナリティを実現するための主要なマイルストーンを構成します。

(1) Verkle 証明用の SNARK - Verkle 証明を SNARK に組み込むことにより、ブロックには、変更する部分状態の短い独立した証明が含まれるため、ブロック N-1 の状態全体を検証してブロックかどうかを検証する必要がなくなります。 N はそれを正しく変更します。

(2) コンセンサス状態遷移のための SNARK — 信頼を最小限に抑えた同期委員会から、コンセンサス層で発生するすべてのことの完全なトラストレス検証への移行。

(3) L1 EVM の SNARK - zk-EVM を L1 に直接統合することで、zk-EVM に対するロールアップ チームの取り組みを活用します (強化されたロールアップに関する投稿を参照)。

5. L1 ガス制限を増やす - トラストレスな方法でブロックを検証するために「すべてのノードがすべてを保存する必要がある」という今日の負担を取り除くことで、より大きなブロックを持つことで、L1 のスケーラビリティをより簡単に得ることができます (これにより、すべての L2 拡張機能が自動的に複合化されます)。

6. 量子安全な SNARK (STARK など) に切り替える - イーサリアムを量子コンピューター攻撃から免れるようにする (SNARK の有効性は、量子コンピューターによって解読されることが知られている暗号化に依存しますが、STARK は解読されません)。

4. 粛清

目標: 古い履歴をクリーンアップすることで、プロトコルを簡素化し、技術的負債を排除し、ネットワークへの参加コストを制限します。

何が行われたのか

1. ほとんどのガス払い戻しを廃止します - すべてのガス価格の再設定はベルリンのアップグレードで行われます。

2. ビーコン チェーンの高速同期 - すべての開発作業は、オリジンからではなく、最も最近完了したエポックから同期されます (ほとんどのコンセンサス クライアントでは「チェックポイント同期」と呼ばれます)。

3. EIP-4444 仕様 - EIP 仕様を参照。

次は何ですか

1. 履歴の有効期限 - 古い履歴を期限切れにすることで、ストレージ要件、同期時間、コードの複雑さを軽減します。

(1) このツイッター投稿を参照してください。

(2) EIP-4444 の実装に依存し、他の手段 (ポータル ネットワークなど) を介した代替履歴へのアクセスに依存します。

(3) 歴史的満了に伴う Vitalik の AMA。

2. ステータスの有効期限 - ステータスに関する「一度支払うとデータを永久に保存できる」という問題全体を解決します。

(1) このアイデアは、状態の未使用部分を自動的に期限切れにし、ユーザーが必要なときに期限切れの状態を復元するために使用できるバークル ツリー ルートのみを保持することです。

(2) ステータスの有効期限に関する Vitalik の AMA。

(3) 信頼する: 基本状態の有効期限仕様 - 実際にどのように行うか、潜在的なロードマップ (およびその他のオプション) を参照してください。

• アドレス空間の拡張 - アドレス サイズを 20 バイトから 32 バイトに増加して、衝突を防ぎ、状態サイクルに関するデータを追加します。

• アプリケーション分析 - 現在のアプリケーション/契約がどのように破られる可能性があるか、またそれらがどのように適合するかを調べます。

3. ログの改革 - イベント ログの仕組みを簡素化し、履歴イベントをより効率的に検索します。

4. シリアル化調整 - 実行層はデータのシリアル化に RLP を使用しますが、コンセンサス層は SSZ を使用します。これにより、RLP が削除され、あらゆる場所で SSZ が使用されます。

5. 古いトランザクション タイプを削除する - クライアントからコードの複雑さを取り除くために、古いトランザクション タイプ (EIP-2718 を参照) のサポートを停止します (下位互換性を犠牲にして)。

6. EVM の簡略化されたトラック。

(1) SELFDESTRUCT を無効にする - このオペコードは多くの問題の原因です (関連する EIP: EIP-4758 および EIP-4760 と議論)。

(2) ガス メカニズムの簡素化 - ここで説明したガス関連の EVM 機能の多くを削除することが含まれます。

(3) プリコンパイル --> EVM 実装 -- プリコンパイルされたコントラクトを削除し、直接 EVM 実装をサポートします (つまり、大規模なモジュール操作。The Splurge を参照)。

5. 散財

目標: その他すべてを修正する

優先度の高いアップグレードには必要のないすべての優れた改善は、The Splurge に属します。最大の改善項目はアカウントの抽象化ですが、既存のものに対する小さな調整も行われています。

何が行われたのか

1. EIP-1559 - この有名な EIP には、ETH の書き込み以外にも多くの利点があります。

2. ERC-4337 仕様 - この ERC は、コア プロトコル (ERC-4337 の最初の説明記事) を変更せずにアカウント抽象化を導入することを目的としています。

次は何ですか

1. 最終段階の EIP-1559 – EIP-1559 は複数の側面を通じて強化されます。

2. EVM 改善トラックと、パージから EVM の最終段階までの簡略化されたトラック。

(1) EVM オブジェクト フォーマット (EOF) — 導入時に EVM バイトコードの検証とバージョン管理を可能にする EIP のセット。この説明記事と Twitter スレッドを参照してください。

(2) 大規模なモジュロ演算 - ロードマップの暗号化の多くは、非常に大きな数値のモジュロ演算に依存しています。これは、EVM で直接より効率的に実行できます。

(3) EVM のさらなる改善 - EVM を改善するために追加する価値のあるもの - または複雑さを取り除くために削除されたもの。

3. 最終段階のアカウント抽象化に至るアカウント抽象化トラック。詳細については、次の項目に関する Vitalik の説明を参照してください。

(1) ERC-4337 - 実際の採用に向けて、互換性のあるスマート ウォレットを開発します。

(2) 自発的な EOA 変換 - EIP を通じて、通常の口座にコードを不可逆的に追加して、契約口座、つまり 4337 規格を満たすスマート ウォレットに変換できます。

(3) 契約内変換 - 既存のすべてのアカウントに対して上記の変換を必須にします。

4. Verifiable Delay Function (VDF) - 本質的には「非並列化可能なプルーフ・オブ・ワーク」で、特に PoS のランダム性を強化します (VDF とその潜在的な用途に関する ethresear.ch の投稿を参照してください)

5. ダストアカウントの解決策を模索する - 価値以上に移動コストがかかる「ダストファンド」を節約します。ここにはたくさんのアイデアがあります: https://ethereum-magicians.org/t/some-medium-term-dust-cleanup-ideas/6287