実用的な情報丨Ethereum 2.0 が 1.0 とどのように統合されるかの詳細な説明

注: 元の著者は、Ethereum 2.0 のコーディネーターである Danny Ryan (djrtwo) です。この記事では、Ethereum 1.0 が Ethereum 2.0 とどのように統合されるかを詳しく説明します。彼の紹介によれば、eth1+eth2 を組み合わせたクライアントでは、eth2 クライアントが PoS とシャーディングのコンセンサスの複雑さを処理でき、接続された eth1 クライアントは eth1 エンジンになり、ステータス、トランザクション、仮想マシンなどの複雑さを処理できます。

(写真提供: tuchong.com)

Ethereum 1.0とEthereum 2.0クライアントの関係

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

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

この記事の内容を理解するには、Ethereum 2.0 とステートレス Ethereum の概念について基本的な知識を持っていることが前提条件となります。

明確な分業

eth1+eth2 の統合の目的は、アップグレードされた Ethereum 2.0 コンセンサス環境で既存の Ethereum 1.0 の状態、エコシステム、およびソフトウェアを活用することです。

簡単に言えば、現在 eth2 クライアントと考えられているものは、コア PoS とシャーディング コンセンサスを処理します。本質的に、eth2 プロトコルと eth2 クライアントは、データと (最終的な) 状態が詰まった多数のシャード チェーンである一連の「もの」を生成し、それに対して合意に達するのに非常に優れているように設計されています。 eth1 の現在の PoW コンセンサス レイヤーと比較すると、eth2 の「コンセンサス レイヤー」ははるかに高度で複雑です。

現在、eth1 クライアントは、1 つのチェーンのみを備えた比較的シンプルで薄いコンセンサス レイヤーを持ち、プロトコル外部のハードウェアで複雑さの大部分を PoW が処理します。 eth1 クライアントの複雑さと最適化のほとんどは、ユーザー層 (状態の保存/管理、状態の同期、仮想マシンの実行、トランザクション処理、トランザクション プールなど) にあります。

この関心の分離により、eth1 が eth2 にシャードとして組み込まれるときに、適切なペアリングが可能になります。eth2 クライアントは PoS とシャードされたコンセンサスの複雑さを処理でき、接続された eth1 クライアントは eth1 エンジンになり、状態、トランザクション、仮想マシン、およびユーザー層に近いものの複雑さを処理できます。

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

eth1 と eth2 クライアント ソフトウェアを組み合わせるには、さまざまなアプローチ (完全な統合、eth1 をライブラリとしてインポート、両者間の通信プロトコルなど) がありますが、この記事では、最も侵襲性が低くモジュール化されたアプローチ、つまり eth2 クライアントと簡素化された eth1 エンジン間のネイティブ通信プロトコルに焦点を当てます。

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

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

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

eth2 エンジンは eth1 エンジンと一緒に実行され、eth2 クライアントによって駆動される RPC を介してローカルで通信します。

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

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

1. ビーコン チェーンとビーコン ステート (システムの残りの部分が構築されるコア コンセンサス オブジェクト)。

2. シャード チェーン (1. eth1 シャード チェーン、2. 多数のデータ専用シャード チェーン)。

3. メモリプールの操作 [図示せず] (認証、デポジット、終了など)

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

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

イーサリアム 1.0 エンジン

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

2. eth1 状態 (現在の Ethereum のユーザー層 eth1 の状態)。

3. トランザクション ストレージ プール Mempool (ユーザー トランザクション メモリ プール、ブロック生成の準備)。

4. P2P インターフェース (1. 現在の Ethereum 上のトランザクション ゴシップ、2. 状態同期、3. eth1 シャード ブロック ゴシップなし)。

5. eth2 クライアントからの RPC (すべての呼び出しは eth2 クライアントによって実行されます);

コンセンサス

コアコンセンサスの観点から見ると、eth2 クライアントはビーコン チェーン、データ シャード チェーン、eth1 シャード チェーンの構築を担当し、促進します。 eth2 クライアントが eth1 シャード チェーンとコア コンセンサス (ビーコン チェーン/状態) に関して持っている知識は、RPC を介して eth1 エンジンに直接提供されます。

具体的には、接続された eth1 エンジンは独自のコンセンサスを維持できないため、eth2 クライアントにアクセスできる必要があります。現在の Ethereum の 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 ユーザー状態ルートです。

以下では、eth1 の状態が eth2 クライアントに関連するさまざまな状況について説明します。

1. eth1 エンジンのない eth2 クライアント

コア eth2 プロトコルは、追加の eth1 エンジンなしで実行できます。単一の eth2 クライアントは、ビーコン チェーンとシャード チェーン (eth1 シャードを含む) の両方を追跡できます。 eth1-engine がないと、クライアントはステートレス eth1 シャード ブロックを実行できないため、それらを完全に検証したり、そこから有用なユーザー情報を取得したりすることはできません。ただし、eth2 コアのコンセンサスとバリデーターに関する想定に基づくと、eth1 シャード チェーンのヘッドは依然として安全に見つけることができます。

2. ステートレス eth1 エンジンを備えた eth2 クライアント

バリデータノードを実行するには、eth1 エンジンが接続された eth2 クライアントを実行する必要があります。これはステートレスな方法 (つまり、eth1 の状態全体をローカルに保存しない) で実行できるため、eth1 シャード ブロックには実行に使用できる監視機能があります。ビーコン委員会は、eth1 エンジンにステートレス呼び出しを行うことで、シャード ブロック データの可用性と eth1 に関するデータの有効性をチェックできます。

バリデーターに加えて、多くのユーザー/アプリケーション ノードもステートレスまたはセミステートフル eth1 エンジンを使用して実行される場合があります。シン eth2 クライアントを使用して eth1 シャード チェーンの先頭を追跡し、ステートレスまたはセミステートレスの方法で対話します。

3. ステートフル eth1 エンジンを備えた eth2 クライアント

eth1 シャード ブロックを生成するバリデーターを実行するには、接続された eth1 エンジンと完全な eth1 状態で eth2 プロトコルを実行する必要があります (開発者はステートレス ブロック生成方法を検討していますが、簡単にするためにここでは説明しません)。その後、ローカル状態とトランザクション メモリ プール (TX メモリ プール) を使用して、必要に応じて新しい有効なブロックを形成できます (詳細は後述)。

バリデーターに加えて、ブロック エクスプローラー、アーカイブ ノード、状態プロバイダーなど、多くのユーザー/アプリケーション ノードも完全にステートフルな eth1 エンジンを使用して実行される場合があります。

ネットワーク

簡単にするために、eth2 と eth1 は最初は独自のネットワーク スタックとプロトコルを維持します。責任の移管 (eth1 シャード ブロック ゴシップなど) に対応して、開発者は特定の既存の eth1 プロトコル (eth1 シャード ブロック ゴシップなど) の使用を非推奨にし、eth2 プロトコルに置き換えました。初期のプロトタイピング段階の後、またはそれ以降の段階で、ネットワーク スタックを統合するために eth1 プロトコルを libp2p に移行することが必要になる場合がありますが、これは必須ではありません。

eth2-client と eth1-engine は同じ discv5 DHT にアクセスできますが、適切に機能するピアを個別に検索し、接続を個別に維持します。

欧州連合

ノードは複数の機能を持つ論理ネットワーク ID の背後に配置されているため、結合された eth1+eth2 クライアントは 1 つの ENR を使用します。

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. 受領書の取得)

2. NOT (ブロックハッシュ、ブロックヘッダー、または本文に関連するメッセージ)

3. eth2 クライアント プロセスが eth1 ブロック ゴシップを実行するのはなぜですか?

eth2 は、シャード ブロックの生成、ゴシップ、検証を処理するために特別に設計されています。私たちの目標は、eth1 シャードを標準シャードにして、他のシャードと可能な限り一貫性を持たせることです。コアコンセンサスに関して、eth1 ブロックと他のシャードの主な違いは、eth1 エンジンに対してブロックコンテンツを実行/検証する機能です。

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

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

トランザクションゴシップとメモリプール

eth1 エンジンは、現在の Ethereum とほぼ同じ方法で、ユーザー トランザクション ゴシップと eth1 トランザクション ストレージ プールを維持します。ブロック生成の準備として、ゴシップとストレージ プールのメンテナンスに同じネットワーク プロトコルとローカル メカニズムを使用できます。

主な違いは、使用されたトランザクションの知識がどのように決定されるか、およびストレージ プールがブロック生成にどのように使用されるかにありますが、これらはストレージ プールの外部のレイヤーにあると言えます。

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

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

ブロック生産

eth2 プロトコルでは、すべてのブロック (ビーコン ブロック、シャード ブロック、eth1 シャード ブロック) は、コア コンセンサスに基づいて PoS バリデーターによって生成され、署名される必要があります。このため、eth2 クライアントは最終的にすべてのブロックの生成に責任を負います。

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

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

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

次のステップは何ですか？

全体的なデザインが全員に承認された場合、次の手順は次のとおりです。

1. eth2 クライアントが eth1 エンジンを駆動するという前提が既存の eth1 ソフトウェアと一致しており、予期しない負担をかけないことを確認します。

2. eth1 エンジンを駆動するために使用される、より明確に定義された通信プロトコル。例: new_head(block)、validate_block_transition(block)、get_proposal(parent_root) など。

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

4. Ethereum 2.0 フェーズ 1 仕様のスケーリング

5. プロトタイプ！

この記事は著者ダニー・ライアンの許可を得て翻訳されています。