元のタイトル:「注釈付きイーサリアムロードマップ」
原文編集：domothy、ETH中国語サイト
この記事は、最新の Ethereum ロードマップに基づいてコンテンツに注釈を付けており、読者に理解していただくことを目的としています。イーサリアムのロードマップ上記の各セクションではエントリ ポイントが提供され、各セクションでは簡単な概要が説明されています。
注: ロードマップ上の矢印で示されているように、リストされているさまざまな部分は継続的な作業ではなく、それらの進歩は並行して行われます。
マージ
目標: 理想的で、簡潔で、堅牢で、分散型の PoS コンセンサス メカニズムを実現すること。
終わった仕事
2020 年 12 月 1 日 — ビーコンチェーンの発売
Ethereum PoS コンセンサス層を導入し、検証者はこの層のネットワーク セキュリティを維持するために ETH を誓約します。
ビーコンチェーンはコンセンサス仕様で呼び出されますステージ0(ヴィタリックさんの注釈付きバージョンそしてダニー・ライアンの注釈付きバージョン）；
2021 年 10 月 27 日 - ウォームアップ フォーク (Altair) - コンセンサス層クライアント開発者は、ハード フォークのアップグレードの調整に関するテストを実行しました。
ライトクライアントライトクライアント、ペナルティにいくつかの調整を加えました。
「What’s new in ETH 2 」アルタイルを解説した号。
2022 年 9 月 15 日 — 統合!捕虜退職 - でブロック高さ 15537394コンセンサス層と実行層の統合を完了します。
次のステップ
引き出し — バリデーターがデポジットの全部または一部を引き出すことができます。
分散型バリデーター 「マルチシグ、ただしステーキング用」。n 人が同じバリデーターを共有し、n 人中 m 人がその動作方法について同意する必要がある手法。
偶発的なスラッシュを防止し、参加を容易にすることでステーキングメカニズムを強化します (例: 必要な 32 ETH をトラストレスに複数の参加者に分割することによって)。
ビューのマージ — フォーク選択ルール (バリデーターの投票方法) を調整して、1 種類の攻撃を軽減します。
本質的には、悪意のある検証者が投票を分割し、自分たちに有利なブロックを再編成する可能性を減らすために、正直な検証者に正しいチェーンヘッドを「強制」することです。
ethresear.ch の投稿この研究には多くの (非常に技術的な) 背景があります。
集約の改善 — Ethereum はできるだけ多くのバリデーターをサポートするよう努めていますが、すべてのバリデーターがすべてのブロックに投票する (そして他のすべてのバリデーターの投票を検証する) と帯域幅を大量に消費します。次善の策は署名を集約することですが、これには制限があり、より適切に実行できる可能性があります。
シングル スロット ファイナリティ (SSF) - 1 つおきのエポック (12.8 分) ではなく、1 スロット (12 秒) ごとにチェーン状態をファイナライズします。
単一スロットでのファイナリティへの道（中国バージョン）;
署名の集約を改善することに加えて、次の 2 つのことを解決する必要がありました。
- SSF コンセンサス アルゴリズム - 既存の SSF 互換アルゴリズムでは十分ではありません。1313 を超えるバリデーターがオフラインであってもチェーンを維持できるアルゴリズムが必要です。
- SSF バリデーターの経済学 - 最終的にバリデーターの数を制限しなければならない場合、参加率をどのように制限すればよいのでしょうか?また、どのような犠牲を払わなければならないのでしょうか?
シークレットリーダー選挙 (SLE)
現在、ブロックを提案するために選択されたバリデーター (単一スロットのリーダー) は事前にわずかにわかっているため、潜在的な DoS 攻撃が特に今後のブロックのリーダーをターゲットにすることが可能になります。
ethresear.chランダム シャッフルに基づく単一秘密のリーダー選出のプロトコルに関する投稿があります。リーダーの証明とともにブロックを公開するまで、リーダー自身を除いて、誰がこのスロットのリーダーになるかはわかりません。
非単一シークレットリーダー選挙それもオプションかもしれません。
より多くのバリデーターをサポートする — 継続的な長期的な取り組み: より多くのバリデーターを安全にサポートすることが常に私たちの目標です。
量子安全で集合体に優しい署名 — イーサリアムを量子安全にすることは、量子コンピューターが正当な懸念となる前にイーサリアムを量子安全にするための長期的な取り組みの一環です。
使用される BLS 署名スキームは、量子コンピューターによって解読されることが知られている暗号に基づいていますが、量子安全であることが知られている代替署名スキームは、BLS ほど効率的に署名を集約できません (したがって、量子安全性と集約性の両方を備えたスキームが必要です) -フレンドリー）;
2 つの主要な量子セキュリティ方式は次のとおりです。スタークベースそして格子ベース。
The Scourge (隠れた危険を解決する)
関連リンク：
関連リンク：
終わった仕事
プロトコル外の MEV マーケットプレイス — MEV-Boost ミドルウェアを使用すると、一般のバリデーターは、複雑な MEV ポリシー自体を実行することなく、MEV から利益を得ることができます。
このソリューションはそれ自体では完成しません。レビュー質問；
記事を読む "The Cost of Resilience"そして"The Future of MEV is SUAVEこれらの協定外の MEV 市場をより回復力のあるものにする計画について知るため。
次のステップ
パケット リストまたは代替案 - ブロック提案者がブロック ビルダーに制約を課す、つまりトランザクションを強制的に含めるようにします。
プロトコル内 PBS — ブロック構築マーケットをプロトコルに直接書き込みます。
MEV バーン — ブロックチェーンがオンチェーンエコノミーから抽出されるはずだった価値をキャプチャできるようにします。
アプリケーション層 MEV の最小化 — この作業は L1 とは直接関係ありません。開発者は、Dapps を設計するときに MEV を念頭に置く必要があります。 MEV 最小化戦略を採用している DApp の例をいくつか示します。例。
分散ビルダールート。ブロック提案プロセスが分散化されているため、ブロック構築が集中化されるという別の問題が発生します。ロードマップ上の他のすべては、ブロック構築の集中化という最悪のシナリオを最小限に抑えるように設計されていますが、ブロック構築を多くのノードに分散できることは依然として大きな利点です。
BLOB 構造 - 通常の消費者向けハードウェアが実行できる多くのノードにわたるデータ シャーディングの高帯域幅と処理要件をオフロードする方法を見つける。
事前確認サービス - ユーザーに自分のトランザクションが次のブロックに含まれるという強力な保証を提供します。
フロントランニング保護 - サンドイッチ攻撃などの有害な MEV を最小限に抑え、分散ビルド プロセスが信頼できる中立的な状態を維持します。
関連リンク：
関連リンク：
ザ・ヴァージ（ボーダー）
目標: ブロックの検証は非常に簡単である必要があります。N バイトのデータをダウンロードし、いくつかの基本的な計算を実行し、SNARK を検証すれば完了です。
この部分は基本的に「」を埋めることについてです。クライアント側の欠点”: 誰もが完全なノードを実行したいわけではありませんし、実行できるわけでもありません。 The Verge の目標は、実行が簡単で、多くのストレージや帯域幅を必要としない、トラストレスまたはトラストを最小限に抑えた代替手段を導入することです。 The Verge の最終目標は、これらのライト クライアントが現在のフル ノードと同じセキュリティ保証を提供することです。
これはすべて、SNARK や STARK のようなゼロ知識技術に依存しており、これらの技術自体は多項式コミットメント スキームに依存しています。これに関するいくつかのリンクを次に示します。
zk-SNARKが可能な理由をご紹介（中国バージョン）
終わった仕事
最悪の EVM DoS 問題が修正されました。主にガス価格設定で、これはベルリンのアップグレードで修正されました。
基本的なライト クライアント サポート (同期委員会) — 同期委員会のおかげで、コンセンサス層に従うライト クライアントを簡単に構築できます。
学ぶヘリオスクライアント同期委員会がどのように利用されるか (これらの委員会がどのように機能するかについての適切な説明)。
次のステップ
EIP-4844 の実装 — EIP-4844 をメイン ネットワークに導入する
基本的なロールアップ スケーリング — 以下に依存して機能します。
EIP-4844 - BLOB 領域の使用可能な容量を制限する「すべてのノードがすべてのデータをダウンロードする」性質のため、達成されるスケーラビリティは依然として基本的/限定的であると考えられます。
ロールアップの制限付き補助輪フェーズ (記事ではロールアップ補助輪を削除することを提案しています)路線図）；
フル ロールアップ スケーリング — 次の作業に依存します。
DAS (データ可用性サンプリング) の P2P 設計: データ シャーディング ネットワーク接続の問題を含むいくつかの作業と研究。
データ可用性サンプリング クライアント: 数キロバイトをランダムにサンプリングすることで、データが利用可能かどうかを迅速に判断できる軽量クライアントを開発します。
効率的な DA 自己修復: 最悪のネットワーク条件 (悪意のあるバリデータ攻撃や大規模なブロック ノードの長時間のダウンタイムなど) の下でもすべてのデータを効率的に再構築できます。
補助輪なしのロールアップ: 完全分散型シーケンサー、信頼できない不正行為の証明、不変の契約など。
量子安全で信頼できる初期化の約束 — イーサリアムを量子安全にすることは、量子コンピューターが正当な懸念となる前にイーサリアムを量子安全にするための長期的な取り組みの一環です。
効率的かつ強力ですが、あらゆる場所で使用される多項式コミットメント (KZG) は量子的に安全ではなく、信頼できる初期化が必要です。より理想的な長期使用を約束する研究が進行中であり、最終的な目標は内部で KZG をホットスワップすることです。
SNARK / STARK 特定用途向け集積回路 — プルーフの作成専用のハードウェア。
Verkle ツリー — グローバル状態に使用されるデータ構造をより効率的なバージョンに置き換えます。
主な利点は、ライトクライアントがヘッダーだけを見て口座残高などを簡単に検証できる非常に簡潔な証明を生成できることです。クライアントはすでに同期委員会を利用して、特定のブロックヘッダーが実際にメインブロックの一部であることを検証できます。鎖;
適切な仕様を作成し、安全な移行を確保し、状態の更新/編集の EVM ガス オーバーヘッドにどのような影響を与えるかを把握する必要があります (これは、パージ パートの「自己破壊」をキャンセルする作業にも依存します)。
SNARK ベースのライト クライアント — 同期委員会の状態遷移の SNARK 証明を生成し、どのバリデーターが現在の同期委員会を構成しているかを迅速に証明します。
SNARK に完全に基づいたイーサリアム — 次の 3 つの項目が合わせて「イーサリアムの最終像非常に効率的でトラストレスなブロック検証を実装するための重要なマイルストーン:
Verkle 証明用の SNARK - Verkle 証明を 1 つの SNARK に組み込むことにより、ブロックには、変更する部分状態の短い独立した証明が含まれるため、ブロック N を検証するためにブロック N-1 の全体の状態を検証する必要はありません。正しく変更されました。
コンセンサス状態遷移のための SNARK — 信頼を最小限に抑えた同期委員会から、コンセンサス層で起こっているすべての完全なトラストレス検証まで。
L1 EVM の SNARK - zk-EVM のロールアップ チームによって行われた作業を活用し、zk-EVM を L1 に直接統合します。
- プロトコルに記載されているロールアップについて読む役職；
L1 ガス キャップの増加 — 「すべてのノードがすべてを保存する必要がある」という現在の負担を取り除くことによるトラストレス検証ブロックにより、L1 のスケーラビリティを高めるためにより大きなブロックを形成することが容易になります (これにより、すべての L2 拡張の効果が自動的に強化されます)。
量子安全な SNARK (STARK など) への移行 — イーサリアムの量子安全化は、量子コンピューターが正当な懸念となる前にイーサリアムを量子安全にするための長期的な取り組みの一環です。
SNARK は量子コンピューターによって解読可能であることが知られている暗号に基づいていますが、STARK は解読可能ではありません。
パージ
目標: プロトコルを簡素化し、技術的負債を解消し、履歴データをクリーンアップすることでネットワークへの参加コストを制限します。
終わった仕事
ほとんどのガスリターンをクリア — すべてガスの価格改定ベルリンではアップグレード作業が行われています。
ビーコン チェーンの高速同期 — すべての開発作業は、ジェネシスからではなく、最も最近完了したエポック (ほとんどのコンセンサス レイヤー クライアントでは「チェックポイント同期」と呼ばれます) から同期するように行われています。
EIP-4444 仕様 - 読み取り学ぶ。学ぶ。
次のステップ
履歴データの休止状態 — 古い履歴状態を休止状態にすることで、ストレージ要件、同期時間、およびコードの複雑さを軽減します。
この記事を読む長いツイッター；
EIP-4444 の実装、つまり次のような他の手段に依存します。Portal Network) 歴史的な状態の代替案にアクセスするため。
Vitalik による履歴データの休止状態AMA；
状態休止状態 — 状態に関して、「1 回限りの支払い、データの永久保存」の問題を修正します。
このアイデアの主な目的は、状態の未使用部分を自動的に冬眠させ、ユーザーが必要に応じて休止状態をアクティブ化するために使用できるバークル ツリー ルートだけを残すことです。
状態休止メカニズムの VitalikAMA；
以下のジョブに依存します。
- 基本的なステートフル Hibernate 仕様: それをどのように実装するかについては、これを参照してください。潜在的なロードマップ（そしてその他のオプション）；
- アドレス空間拡張:アドレスサイズを増やす、競合を防止し、ステータス サイクルに関するデータを増やすために、20 バイトから 32 バイトに増加しました。
- アプリケーション分析: 現在のアプリケーション/契約がどのように破壊されるのか、またこれらのアプリケーション/契約がどのように適応する必要があるかを把握します。
ログ改革 - 簡略化イベントログ歴史上の出来事をより効率的に検索するために機能します。
シリアル化調整 - 実行層の使用RLPデータのシリアル化とコンセンサス層は SSZ を使用します。SSZ は徐々に RLP を放棄し、SSZ。
古いトランザクション タイプの削除 - 古いトランザクション タイプのサポートを停止します (「EIP-2718 ) クライアント側のコードの複雑さを削除します (下位互換性は多少犠牲になります)。
EVM簡素化ルート
SELFDESTRUCT をキャンセルします — このオペコードは多くの問題の原因です。
- 《SELFDESTRUCT を排除するための実用的な回避策「このオペコードを削除する理由と方法について説明します。
- 関連する EIP:EIP-4758 、 EIP-4760 同様に話し合う；
ここここ言及された;
プリコンパイル -> EVM 実装 — プリコンパイルされたコントラクトを放棄し、直接 EVM 実装を採用します (つまり、大規模なモジュール操作。The Splurge を参照)。
散財
目標: その他の項目を完璧にする。
より高い優先順位を必要としない良いものはすべて、The Splurge のこのセクションに属します。最大のものはアカウントの抽象化、ただし、既存のコンテンツにも小さな調整が加えられています。
終わった仕事
EIP-1559 — 有名なEIP持ってきました多くの利点、ETHを破壊するだけではありません。
ERC-4337 仕様 —ERCコアプロトコルを変更せずにアカウント抽象化を導入することを目的としています
次のステップ
EVM の改良ルートと The Purge の簡略化されたルートを合わせて、EVM の最終形式を形成します。
EVM オブジェクト フォーマット (EOF) — 導入時に EVM バイトコードの検証とバージョン管理を可能にする複数の EIP のセット。これを読んで下さいそしてそしてツイッターの投稿；
大規模なモジュラー操作 — ロードマップの暗号化の多くは、大量のモジュラー操作に依存しています。これは、EVM で直接より効率的に実行できます。
EVM のさらなる改良 - EVM を改善するために追加する価値のあるもの、または取り除く複雑さを取り除くためのもの。
アカウント抽象化の最終形式を実装するアカウント抽象化ルート。以下の詳細については、Vitalik の記事を参照してください。説明する：
ERC-4337 — 互換性があり実用化されたスマートウォレットの開発。
EOA アカウントの自発的変換 - EIP を通じて、通常のアカウントはコードを不可逆的に追加してコントラクトに変換することができます。つまり、4337 互換のスマート ウォレットになります。
契約書には、既存のすべてのアカウントに対して上記の変換を強制することが書かれています。
Verifiable Delay Functions (VDF) — 本質的には「非並列プルーフ・オブ・ワーク」です。PoSなどで使われるランダム性の強化。
これを見てください役職、VDF とその潜在的な用途の紹介
ここここたくさんのアイデアをご覧ください。
IOS
Android