元のソース: AllCoreDevs アップデート
著者: ティム・ベイコ
原文翻訳: ETH 中国語 WeChat 公開アカウント
Rayonism が最初にプロトタイプを構築してから 1 年後、現在ではすべてのイーサリアム クライアントにわたって堅牢な統合実装が行われています。
現在の状況から、イーサリアムのプルーフ・オブ・ステークに完全に移行するまでの道は非常に明確になりました。私たちはする必要があります：
1. いくつかのメインネット シャドウ フォークに問題はありません。
2. クライアントはさまざまなマージ テスト スイートに合格しています。
3. 既存のパブリック テストネットでの展開の成功。
以上です！これらの条件が満たされ、数週間以内に安定していることが確認できたら、メインネットのマージの準備をすることができます。
トレント・ヴァン・エップスは、ビーコン・チェーン・デポジット契約の開始からイーサリアムのプルーフ・オブ・ステークへの完全移行までの道のりを描いたこの地図を作成しました。 TTD はターミナル合計難易度、つまりマージが発生したときのことを指すことに注意してください。
シャドウフォーク
シャドウフォーク
過去 1 年間、私たちはネットワーク アップグレード プロセスに新しいステップ、シャドウ フォークを追加しました。
画像の説明
@parithosh_j によるシャドウ フォーク ネットワークの概要
これらのシャドウ フォーク テストネットを実行すると、パブリック ネットワークにできるだけ近い条件下でクライアントがどのように動作するかを観察できます。シャドウ フォークされたネットワークのノードでは、マージが効果的に行われます。その後、メインネット上のトランザクションをフォーク上で再生することができ、メインネットの条件下でノードがどのように動作するかを確認できるようになります。新しいノードをシャドウ フォークに同期して、期待どおりにネットワークに参加していることを確認することもできます。
これらのシャドウ フォーク中に、実行層 (EL) とコンセンサス層 (CL) のすべての組み合わせがテストされ、クライアントの各ペアがその後スムーズに移行して実行されることが目標です。 4 つの実行層クライアントと 5 つのコンセンサス層クライアントがあるため、テストする組み合わせは 20 組あることになります。
これまでに、複数の Goerli シャドウ フォークと 2 つのメインネット シャドウ フォークがありました。 2 番目のメインネット シャドウ フォーク (MSF2) はほぼ完璧に完了しました。もう一つの MSF3 は今週開催される予定です。 MSF3 に問題がなく、その後も安定している場合は、既存のテストネットをアップグレードできます。安全を期すため、テストネットのデプロイ前（およびデプロイ中も）に定期的なシャドウ フォークを引き続き実行します。
それまでの間、私たちは他のテストの取り組みも強化しています。
マージテスト
マージはイーサリアムの実行層とコンセンサス層にまたがるため、テスト用のユニークなアップグレードです。各レイヤーには個別のテスト ツールが多数ありますが、レイヤー間の相互作用をテストするには多くの新しいインフラストラクチャが必要です。
ハイブテスト
Hive は、以前に実行層でのテストに使用していた統合テスト プラットフォームです。過去数か月間、私たちはコンセンサス層の動作をシミュレートする機能を追加し、それをさまざまな実行層クライアントのテストに使用してきました。これは、実行層とコンセンサス層が通信に使用する新しいエンジン API をテストするのに役立ちます。 PoW -> PoS への移行をテストするには、実行層の動作をシミュレートするシミュレーターを追加することも必要です。
現在、クライアント チームは Hive のサポートを優先し、すべてのテスト スイートに合格することを確認しており、テスト チームは実行層のモックを追加することに重点を置いています。
Kurtosis
既存のテスト インフラストラクチャに加えて、[Kurtosis] (https://www.kurtosistech.com/) とも連携しています。これを使用して、マージ プロセスを実行するためにエフェメラル ネットワークを毎日自動的に起動します。
これらのツールは、個々のクライアントの実装上の問題を発見し、さまざまなネットワークの健全性指標を監視するのに役立ちます。この面で状況が安定したら、次のステップはより厳しいネットワーク状態を作り出し、クライアントがどのように回復するかを確認することです。たとえば、移行の直前に実行層またはコンセンサス層のクライアントを一時停止し、マージ後に一時停止を解除するか、マージ後にデータベースを削除して、同期がどのように処理されるかを確認します。
そしてその他すべて
Hive の改善と Kurtosis との連携に加えて、クライアント、調査、テスト チームが構築したテスト ツールの長いリストが、考えられるすべてのコーナー ケースを見つけるのに役立ちました。これらには、ファジング ツール、不良ブロック ジェネレーター、実行層/コンセンサス層シミュレーター、デバッグ API、その他のファジング ツールが含まれます。その他のツールのウィッシュリストは次のとおりです。
私たちの最優先事項は、クライアントに単体/仕様テスト、および Hive と Kurtosis での統合テストに合格してもらうことです。ただし、上記の他のツールは、見逃しているコーナー ケースを見つけてデバッグするのに役立ち、それを通常のテスト スイートに組み込むことができます。
人間側では、マージ テストにより、チーム間の調整とコラボレーションが大幅に強化されます。初めて、コンセンサス層と実行層のクライアント チームは相互に緊密に連携して、ソフトウェアが他の層のすべてのクライアントで確実に動作するようにする必要があります。これにより、テスト インフラストラクチャ全体でのより多くのより深いコラボレーションが可能になります。
パブリックテストネット
シャドウ フォークがスムーズに進み、すべてのクライアントがテスト スイートに合格したら、既存のパブリック テストネット (Ropsten、Goerli、Sepolia) にマージをデプロイする準備が整います。
パブリック テストネットは、メインネットのシャドウ フォークほどクライアントにストレス テストを行いませんが、イーサリアム エコシステム内での広範なコラボレーションが必要です。
合併には以前の Ethereum アップグレードよりも多くのノード ランナーが必要です。過去のアップグレードでは、エグゼクティブ層のノードオペレーターとマイナーは、1 つのソフトウェア、つまりエグゼクティブ層のクライアントをアップグレードするだけで済みました。マージされたアップグレードでは、コンセンサス層クライアントを同時にダウンロード、構成、実行する必要があります。
コンセンサス層に関しては、バリデーターとともにエグゼクティブ層ノードを実行することを常に強く推奨してきました。合併前ではありますが、実行層ノードの運用はサードパーティのサービスプロバイダーに委託することができます。ただし、マージする場合、誓約者は実行層ノードを実行してブロックの正当性を検証し、ブロックを提案するときに取引手数料を受け取る必要があります (実行層ノードの操作をアウトソーシングすると、取引手数料を受け取れない場合があります)。
ノードオペレーター、ステーカー、およびインフラストラクチャープロバイダーは、テストネットへのデプロイメントの準備として、構成が Kiln でテストされていることを確認する必要があります。 EthStaker は、これを行う方法に関するさまざまなチュートリアルも公開しています。
Ropsten、Goerli、Sepolia がフォークして安定したら (さらなる問題が発見されないと仮定して)、メインネットのマージ日を設定する準備が整います。
メインネットワーク
イーサリアムメインネットでのプルーフ・オブ・ステークへの移行は、テストネットでの場合と同じです。そうは言っても、移行は 3 つのステップで行われることをもう一度強調する価値があります。
1. クライアントは、マージをサポートするソフトウェア バージョンをリリースし、プルーフ オブ ワーク チェーンで到達する特定の合計難易度値、つまり最終合計難易度 (TTD) を「リッスン」し始めます。
2. TTD に達すると、次のブロックは、次のビーコン チェーン スロットに割り当てられたベリファイアによってパッケージ化されます。このブロックはマージ後の最初のブロックとなり、エンドユーザーのトランザクションとプルーフ・オブ・ステークのコンセンサスデータ（プルーフ、デポジット、スラッシュなど）が含まれます。
3. 最初にマージされたブロックが確定されます。現時点では、プルーフ・オブ・ワークはイーサリアムのフォーク選択ルールの一部ではなくなりました。言い換えれば、私たちは完全にPoSに移行しました
Danny Ryan による次の図は、そのプロセスを示しています。
一番左のブロックは、マージ前に並行して実行されている実行レイヤーとコンセンサスレイヤーを示しています。PoW (実行レイヤー) ブロックにはトランザクションが含まれ、ビーコンチェーン (コンセンサスレイヤー) ブロックにはプルーフオブステークコンセンサスデータが含まれています。
左から 2 番目の PoW ブロックは、TTD に到達または超過したときです。以下の 3 番目のブロックは合併後の最初のブロックで、プルーフ オブ ステークのコンセンサス データと実行層のトランザクションが含まれています。
4 番目のブロック以降は、proof of work とは関係ありません。これらのブロックが完了すると、その時点からネットワークは、Proof-of-Work に基づく 51% 攻撃のようなものによってのみ侵害される可能性があります。
言い換えると、その時点で、結合は完了です。
この合併は、私たちがイーサリアムに対して計画したアップグレードの中で最も複雑なものです。チームと個人の貢献者は 1 年以上にわたって精力的に取り組んできており、ついにゴールラインが見えてきました。
イーサリアムがプルーフ・オブ・ステークに移行するのを誰もが楽しみにしていますが、手を抜いている場合ではありません。イーサリアム ユーザーとネットワーク上に構築された豊かなエコシステムの安全かつシームレスな移行を確保することが私たちの最優先事項です。私たちは、ほぼ、そこにいる！
いつ統合されるのでしょうか？すぐ。 。 。
元のリンク
