Ethereum 2.0 が 1.0 とどのように統合されるかを詳しく説明する

編集者注: この記事は以下から引用しましたバビット情報（ID：bitcoin8btc）編集者注: この記事は以下から引用しました

バビット情報（ID：bitcoin8btc）

注: オリジナルの著者は、イーサリアム 2.0 のコーディネーターであるダニー ライアン (djrtwo) です。この記事では、彼はイーサリアム 1.0 がどのようにイーサリアム 2.0 とマージされるかを詳細に紹介しました。彼の紹介によると、eth1+eth2 組み合わせクライアントでは、eth2クライアントは PoS とシャード コンセンサスの複雑さを処理でき、接続された eth1 クライアントは状態、トランザクション、仮想マシンなどの複雑さを処理できる eth1 エンジンになることができます。

画像の説明

(写真出典: tuchong.com)<-> eth2 副題イーサリアム 1.0 クライアントとイーサリアム 2.0 クライアントの関係

Vitalik が 2019 年 12 月に初期の eth1 を提案して以来

それ以来、ソフトウェアの観点からこの統合の可能な形態を検討するために研究者の間で活発な議論が行われ、プロトタイピングへの期待は高まるばかりです。私たちのビジョンは、コアのコンセンサス作業がイーサリアム 2.0 クライアント (以下、eth2 クライアントと呼ばれます) によって管理され、状態/ブロックがイーサリアム 1.0 エンジン (以下、eth1 エンジンと呼ばれます) によって管理されるハイブリッドを作成することです。これらは一緒になって eth1+eth2 結合クライアントを形成します。

この記事は、対話、仕様作成、およびプロトタイピングのためのより良い基礎を提供するために、eth2 クライアントと接続された eth1 エンジンの間の責任をより明確に分離することを目的としています。この記事ではプロトコルの詳細 (eth1 クライアントが eth2 エンジンを呼び出す正確な方法など) を定義するものではなく、この記事に含まれる例は説明とその後の議論を支援することのみを目的としていることに注意してください。

この記事の内容を理解するには、イーサリアム 2.0 とステートレス イーサリアムの概念を基本的に理解していることが前提条件となります。

副題

明確な分業

一言で言えば、今日私たちが eth2 クライアントとして考えているものは、シャード コンセンサスだけでなくコア PoS も処理します。基本的に、eth2 プロトコルと eth2 クライアントは、データと (最終) 状態で満たされた多数のシャード チェーンである「もの」の束を生成し、合意に達するのに非常に優れているように設計されています。 eth1 の現在の PoW コンセンサス層と比較して、eth2 の「コンセンサス層」はより高度で複雑です。

現在、eth1 クライアントには比較的シンプルで薄いコンセンサス層があり、チェーンは 1 つだけあり、オフプロトコル ハードウェアの複雑さのほとんどは PoW によって処理されます。 eth1 クライアントの複雑さと最適化のほとんどは、ユーザー層 (状態の保存/管理、状態の同期、仮想マシンの実行、トランザクション処理、トランザクション プーリングなど) にあります。

この懸念の分離により、eth1 がシャードとして eth2 に組み込まれ、eth2 クライアントが PoS とシャード コンセンサスの複雑さを処理でき、補助的な eth1 クライアントが eth1 エンジンになり、状態の複雑さを処理できるようになります。 、トランザクション、仮想マシン、およびユーザーランドに近いもの。

副題

ローカル通信を実現するための最小限の変更

eth1 と eth2 クライアント ソフトウェアを組み合わせる方法には、多くの方法 (完全な結合、eth1 をライブラリとしてインポートする、2 つの間の通信プロトコルを介するなど) がありますが、この記事では、そのうちの 1 つに焦点を当てます。 most 侵襲性を最小限に抑えたモジュール式のアプローチ - eth2 クライアントと簡素化された eth1 エンジン間のネイティブ通信プロトコル。

eth1 および eth2 クライアント実装の多様性を考慮すると、このアプローチにより、クライアント ソフトウェアがどちらかの側にロックインされることがなくなり、クライアント チームが独立した状態を保ち、独自の研究開発作業に集中できるようになり、ソフトウェア プロジェクトをラピッド プロトタイピングのためにほぼ安定した状態に保つことができます。

それで、それはどのように見えるでしょうか？

大まかに、eth1+eth2 を組み合わせたクライアントは次のようになります。

• このうち、eth2 エンジンと eth1 エンジンは連携して動作し、eth2 クライアントが駆動する RPC を通じてローカルで通信します。

• どちらも独自の p2p インターフェイスを維持し、ピアに接続し、それぞれの特定のドメインに関連するネットワーク プロトコルを処理します。

• イーサリアム 2.0 クライアント

• ビーコン チェーンとビーコン状態 (システムの残りの部分を構築するコア コンセンサス オブジェクト)。

• シャード チェーン (1、eth1 シャード チェーン、2、多数のデータのみのシャード チェーン)。

Mempool の操作 [図示せず] (認証、デポジット、終了など)

• P2P インターフェイス (1、コンセンサス層情報、2、eth1 シャード ブロック ゴシップを含む)。

• eth1 エンジンへの RPC (すべての呼び出しは eth2 クライアントによって駆動されます)。

• イーサリアム 1.0 エンジン

• EVM 仮想マシン (eth1 シャード ブロックの実行と検証)。

• P2P インターフェイス (1. 今日のイーサリアムに関するトランザクションのゴシップ、2. 状態の同期、3. eth1 シャード ブロックのゴシップなし)。

コンセンサス

eth2 クライアントからの RPC (すべての呼び出しは eth2 クライアントによって駆動されます)。

副題

コンセンサス

具体的には、接続された eth1 エンジンは、独自のコンセンサスを維持できないため、eth2 クライアントにアクセスできる必要があります。現在のイーサリアムの PoW では、eth1 クライアントはプルーフ・オブ・ワークをチェックし、ツリー構造を形成し、フォーク選択ルールを実行してチェーンの最上位を見つけます。 eth2 では、これらのメカニズムはまったく異なるため、eth2 の核となるコンセンサスを深く理解する必要があります。 eth2 クライアントは、eth1 シャード チェーン ヘッドに関する最新情報を提供するため、eth1 エンジンは eth1 の状態を正確に把握できます。

eth1 エンジンはコンセンサスを促進するために eth2 クライアントに完全に依存しているため、eth2 クライアントと eth1 エンジン間の通信は、eth2 クライアントによって呼び出される eth1 エンジン上のすべてのメソッド (addBlock、getBlockProposal など) であることを提案します。これにより、リーダー/フォロワー関係が強制され、システム推論の複雑さが軽減され、eth1 エンジンに必要なビジネス ロジックが制限されます。

eth2 クライアントとコアコンセンサスの観点から見ると、eth1 シャード チェーンは他のすべてのシャード チェーン (フォークの選択、クロスリンク、ブロック構造、署名など) とほぼ同じように処理されます。主な違いは、シャード ブロックのコンテンツは eth1 エンジンに対して実行できるため、eth1 シャード ブロック データの形式は eth1 に相対的である必要があり、正常に実行するには追加の検証を行う必要があることです。

副題

州

eth2 には、コアコンセンサスに関連する状態、いわゆる「ビーコン状態」があります。ビーコン状態データは小さく (バリデーター セットのサイズに応じてわずか約 10 ～ 40 MB)、コア コンセンサスとシャード チェーンの処理方法を理解するために必要なすべての情報が含まれています。実際、シャード チェーンのコンセンサス関連部分を処理するには、クライアントはビーコン状態 (シャード チェーンのフォーク選択を実行している最新のクロスリンク、現在の検証セット、またはランダムに割り当てられたシャッフルなど) にアクセスできる必要があります。

eth2 の状態は常にユーザー層の状態と相互作用するとは限りません。最も重要な相互作用は、シャード チェーン データの可用性です。実際のユーザー層のデータ ルートはシャード チェーン データ内にあり、eth1 シャード チェーンの場合、現在の Ethereum ユーザー状態のルートになります。

eth2 クライアントに関連した eth1 ステータスのさまざまなケースについては、以下で説明します。

3. ステートフル eth1 エンジンを備えた eth2 クライアントが、eth1 シャード ブロックを生成できるバリデータを実行するには、追加の eth1 エンジンを使用し、eth2 プロトコルを実行するために eth1 状態を完了する必要があります (開発者はステートレス ブロック生成方法を検討していますが、私たちはそうしています)簡単にするために議論しないでください）。その後、ローカル状態およびトランザクション メモリ プール (TX メモリ プール) を使用して、新しい有効なブロックをオンデマンドで形成できます (詳細は後述します)。

通信網

バリデータに加えて、多くのユーザー/アプリケーション ノードも、ブロック エクスプローラー、アーカイブ ノード、状態プロバイダーなど、完全にステートフルな eth1 エンジンで実行できます。

通信網

ENR

簡単にするために、eth2 と eth1 は最初は独自の個別のネットワーク スタックとプロトコルを維持します。責任の変化（eth1 シャード ブロックのゴシップなど）に対応して、開発者は既存の eth1 プロトコルの一部（eth1 シャード ブロックのゴシップなど）を廃止し、eth2 プロトコルに置き換えました。最初のプロトタイピング段階の後、またはさらなる段階で、ネットワーク スタックを統合するために eth1 プロトコルを libp2p に移行する必要がある場合がありますが、これは必須ではありません。

eth2 クライアントと eth1 エンジンは同じ discv5 DHT にアクセスできますが、適切に機能するピアを個別に見つけて、接続を個別に維持します。

副題

eth1 の機能 (状態、トランザクションなど) は、ENR 内の既存の eth (または新しい eth1) キーによって表されます。

eth2 機能 (コア コンセンサス) は、ENR の eth2 キーで表されます。

各プロトコルの存在は、ノードが基礎となるネットワーク プロトコルの種類を識別でき、識別する意思があることを意味します。

副題

ワイヤープロトコル

1. eth2 プロトコル 1. eth2 リクエスト/レスポンス (1. ステータス、2. ビーコン ブロックの同期、3. シャード ブロックの同期); 2. コア コンセンサス ゴシップ (1. ビーコン ブロック、2. 証明、3. eth1 シャーディングを含むブロック) 、4、その他のバリデーター操作); 2、eth1 プロトコル 1、eth1 ワイヤプロトコルのサブセット (1、トランザクションゴシップ、2、getnodedata または新しいメソッドなどの同期メソッド、3、レシート受信の取得)

3. eth2 クライアントが eth1 ブロックのゴシップを処理するのはなぜですか? eth2 は、シャード ブロックの生成、ゴシップ、検証を処理するために特別に使用されます。私たちの目標は、eth1 シャードが標準であり、残りのシャードと可能な限り一貫性があることです。コアコンセンサスに関して、他のシャードと比較した eth1 ブロックの主な違いは、eth1 エンジンに対してブロックのコンテンツを実行/検証できることです。

バリデーターが eth1 シャード ブロックをビーコン チェーンにフォークしているとき、eth2 クライアントは eth1 エンジンを再度呼び出して、ブロックを実行して検証します。

ステートフルな eth1+eth2 結合ノードが新しい eth1 シャード ブロックを受け取ると、eth2 クライアントは eth1 エンジンを再度呼び出してブロックを検証し、ローカル状態ストアを更新します。

副題

トランザクション ゴシップとストレージ プール mempool

eth1 シャード ブロックは、接続された eth2 クライアントから eth1 エンジンに供給されます。これらのブロックに含まれるトランザクションは、現在の Ethereum メインネット PoW ブロックと同様の方法でストレージ プールからパージされる必要があります。

ブロック製作

eth1 シャード ブロックは、接続されている eth2 クライアントに従って、ストレージ プール mempool の内容から生成されます。この RPC メソッドと基礎となる機能は getWork に似ていますが、単なるハッシュではなく完全なブロック コンテンツを返します。

副題

ブロック製作

ビーコン ブロックと非 eth1 シャード ブロックの場合、eth2 クライアントには有効なブロックを生成するために必要なものがすべて揃っています。

eth1 シャード ブロックの場合、eth2 クライアントは、有効なブロックを生成するために、eth1 の状態、トランザクション、およびその他の基礎となる eth1 構造に即時またはいつでもアクセスできます。逆に、指定されたバリデーターが eth1 ブロックを生成すると、eth2 クライアントは実行可能な eth1 ブロック データ (TX、ステート ルートなど) を eth1 エンジンに要求します。次に、eth2 クライアントは、この eth1 ブロック データを完全なシャード ブロックにパックし (スロット、positer_index、positer_signature などを追加)、そのブロックをネットワークにブロードキャストします。

eth1 エンジンは、現在イーサリアムのメインネットが使用しているのと同じ方法で eth1 トランザクション ストレージ プールを管理し、eth2 クライアント情報からの更新を通じて最新の eth1 ヘッド状態を維持するため、有効/実現可能な eth1 ブロック データを生成できます。

• 副題

• 次のステップは何ですか?

• この一般的な設計が合意された場合、次のステップが含まれます。

• eth1 エンジンを駆動する eth2 クライアントに関する前提が既存の eth1 ソフトウェアと一致し、既存の eth1 ソフトウェアに意図しない負荷を課さないようにします。

• new_head(block)、validate_block_transition(block)、get_proposal(parent_root) など、eth1 エンジンの駆動に使用される通信プロトコルをより明確に定義します。

eth1 プロトコルのどのサブセットが必要か、ENR を具体的に使用する方法など、ネットワーク コンポーネントを定義します。