イーサリアム統合プレビュー: Ropsten テストネット統合の詳細がここに

5月30日、イーサリアムのコア開発者ティム・ベイコ氏は、ロプステン合併発表を発表し、新しいビーコンチェーンが立ち上げられ、6月8日頃にロプステンネットワークに統合され、PoSコンセンサスに移行する予定であると述べた。発表の全文は次のとおりです。

• RopstenはThe Mergeで実行される最初の長期テストネットとなる。

• 新しいロプステンビーコンチェーンは2022年5月30日に開始され、ネットワークのコンセンサスを提供します。

• ロプステンビーコンチェーンは、2022年6月2日スロット24000でマージ互換プロトコルルール（Bellatrix）にアップグレードされます。

• この後、Terminal Total Difficulty (TTD) が選択され、Proof-of-Work チェーンのマージがアクティブ化されます。ノード管理者は、クライアント上で TTD 値を手動で設定する必要があります。

• Ropsten マージの正確なターミナル合計難易度 (TTD) に関する別の発表は、2022 年 6 月 3 日にこのブログに投稿される予定です。ユーザーは、TTD 値が決定されてから数日以内に、短期間でクライアントを構成できるようになると予想されます。

背景

何年もかけて Proof of Stake を Ethereum に導入する作業を経て、現在、最終テスト段階であるテストネットの展開に入っています。

Kintsugi、Kiln、およびいくつかのシャドウフォークでクライアントが実行されるテストを行った後、クライアントチームは、The Merge を介して初期のプルーフオブワーク テストネットである Ropsten を実行する準備が整いました。準備として、ネットワークのコンセンサスを提供するために Ropsten ビーコン チェーンが開始されました。

Ropsten の移行後、他の 2 つのテストネット (Goerli と Sepolia) は、メインネットに焦点が移る前にプルーフオブステークに移行します。 Rinkeby や Kovan などの他のテストネットは、コミュニティによってのみ保守およびアップグレードされる可能性がありますが、クライアント開発者による監視は行われなくなります。

Merge は、以前の Ethereum アップグレードとは 2 つの点で異なります。まず、ノード管理者は、コンセンサス層クライアントと実行層クライアントを、どちらか一方だけではなく、同時に更新する必要があります。次に、アップグレードは 2 段階でアクティブ化されます。第 1 段階はビーコン チェーンのスロットの高さで、第 2 段階は実行レイヤーが合計難易度値に達したときです。

このような状況を踏まえ、The Merge 後に廃止される予定だった Ropsten ネットワークは、開発中に完了するアップグレードを通じて引き続き運用され、以前のネットワーク アップグレードよりも早い段階で、コミュニティがアップグレード プロセスに慣れるための時間がより多く与えられます。

注意: 以下にリストされているクライアント バージョンは、Ethereum メインネットの Proof of Stake への移行には適していません。

アップグレード情報

時間

マージは 2 つの手順で実行する必要があります。これは、スロットの高さによってトリガーされるコンセンサス レイヤーでのネットワーク アップグレードから始まります。次に、ターミナル合計難易度 (TTD) と呼ばれる特定の合計難易度しきい値によってトリガーされ、実行レイヤーがプルーフ・オブ・ワークからプルーフ・オブ・ステークに移行します。

2022 年 6 月 2 日、スロット 24000 で、Bellatrix アップグレードにより、Ropsten Beacon Chain が The Merge に向けて準備されます。その時点で、CL クライアントはプルーフ・オブ・ワーク チェーン上の TTD 値の対象となります。

プルーフ・オブ・ワーク テストネットのハッシュレートは非常に不安定なので、初期の TTD 値は 100000000000000000000000000 という非常に高い値に設定する必要があります。Ropsten の現在のハッシュレートでは、この値に到達するまでに約 250 年かかります。

ビーコン チェーンで Bellatrix のアップグレードが行われると、新しい TTD 値を再選択して通信する必要があります。この値は数日以内に達成される予定です。ユーザーは、この新しい値を使用してノードを構成する必要があります。

Ropsten でこの新しい TTD に達するか超過すると、コード名 Paris と呼ばれる移行の実行レイヤー部分が開始されます。また、Ropsten のハッシュレートは変動しやすいことで有名なので、最終的な総合難易度が発生する実際の時間は不確実である可能性があることにも留意することが重要です。

実行レイヤーが TTD を超えると、次のブロックはビーコン チェーン バリデーターによって完全に生成されます。ビーコン チェーンがこのブロックを完了すると、マージが完了したとみなされます。通常のネットワーク状態を想定すると、このプロセスでは、TTD 後の最初のブロックを完了するのに約 2 期間、つまり約 13 分かかります。

最後に、最後の完了したブロックとともに新しい JSON-RPC ブロック タグが返されます。そのようなマージ後のブロックが存在しない場合はエラーが返されます。このタグは、アプリケーションがマージが完了したかどうかを確認するために使用できます。同様に、スマート コントラクトは、DIFFICULTY OpCode (0x44) (マージ後に PREVRANDAO に名前が変更されました) を照会して、マージが発生したかどうかを判断できます。インフラストラクチャ プロバイダーには、ネットワーク全体の安定性と最終的なステータスを監視することをお勧めします。

クライアントバージョン

次のクライアント バージョンは、Ropsten テストネット上の The Merge をサポートしています。ノード管理者は、マージ中およびマージ後にネットワーク上に留まるために、実行レイヤーとコンセンサス レイヤーの両方のクライアントを実行する必要があります。

前述のとおり、以下のバージョンのターミナル合計難易度値は 1000000000000000000000000000 にハードコードされており、ビーコン チェーンで Bellatrix アップグレードをアクティブ化した後に手動で更新する必要があります。

実行するクライアントを選択する際には、バリデーターが EL と CL で多数のクライアントを実行するリスクに特に注意する必要があります。これらのリスクとその結果についての説明、EL および CL クライアントの現在の分布の推定、およびあるクライアントから別のクライアントに切り替えるためのガイドについては、こちらをご覧ください。

注: 以前に TTD が 43531756765713534 の Ropsten クライアントのバージョンをダウンロードした場合は、ここで指定されているようにバージョンを更新するか、TTD を手動で 1000000000000000000000000000 に上書きする必要があります。

Lodestar 注記: 最新の Lodestar バージョン v0.37.0 の Ropsten TTD 値は 43531756765713534 です。Ropsten Merge との互換性を保つために、現在使用されている TTD は 1000000000000000000000000000 です。Lodestar ユーザーはこの値を手動で上書きする必要があります。

Geth 注記: 最新の go-ethereum (geth) バージョン Sharblu (v1.10.18) の Ropsten TTD 値は 43531756765713534 です。現在 100000000000000000000000000 の TTD を使用する Ropsten Merge と互換性を持たせるには、geth ユーザーは以下を行う必要があります。

• ソースコードの最新のマスターブランチからビルドする

• 最新のDockerイメージを使用する

• クライアントの起動時に次のコマンドを実行して、TTD を手動で上書きします: --override.terminaltotaldifficulty 100000000000000000000000000。

アップグレード仕様

The Merge のコンセンサスにおける主な変更点は、次の 2 つの側面です。

• コンセンサス仕様リポジトリのbellatrixディレクトリの下にあるコンセンサスレイヤーが変更されました。

• 実装レイヤーは、実装仕様リポジトリ内の Paris 仕様に従って変更されます。

これに加えて、コンセンサス層と実行層のクライアントがどのように相互作用するかをカバーする他の 2 つの仕様があります。

• コンセンサス層と実行層間の通信には、execution-apis リポジトリで指定されたエンジン API が使用されます。

• コンセンサス仕様リポジトリの同期フォルダーで指定される Optimistic Sync は、実行レイヤー クライアントが同期するときにコンセンサス レイヤーによってブロックをインポートするために使用され、前者から後者へのチェーン ヘッドの部分的なビューを提供します。

よくある質問

ノードメンテナーとして、何をすべきでしょうか?

合併後、イーサリアムのフルノードは、プルーフ・オブ・ステーク・ビーコン・チェーンを実行するコンセンサス層クライアントと、ユーザー状態を管理し、トランザクション関連の計算を実行する実行層クライアントを統合します。これらは、Engine API と呼ばれる新しい JSON RPC メソッド セットを使用して、認証されたポートを介して通信します。 EL クライアントと CL クライアントは、JWT 秘密キーを使用して相互に認証します。ノードのメンテナーは、これらのファイルを生成および構成する方法については、クライアントのドキュメントを参照する必要があります。

つまり、ビーコン チェーン上ですでにノードを実行している場合は、実行レイヤー クライアントも実行する必要があります。同様に、現在の Proof-of-Work ネットワーク上でノードを実行する場合は、コンセンサス レイヤー クライアントも実行する必要があります。安全に通信するには、JWT トークンを各クライアントに配信する必要があります。

どちらもコンセンサス レイヤー クライアント バージョンの一部ですが、ビーコン ノードの実行はバリデータ クライアントの実行とは異なることを強調することが重要です。ステーカーは両方を実行する必要がありますが、ノードメンテナーは前者のみを実行する必要があります。この記事では、この 2 つの違いについて詳しく説明します。

また、各レイヤーは独立したピアのセットを維持し、独自の API を公開することに注意してください。ビーコン API と JSON RPC API はどちらも引き続き期待どおりに機能します。

最後に、6 月 3 日にこのブログで最終的な Ropsten TTD 値が発表されるので、忘れずに確認してください。

ステーカーとして何をする必要がありますか?

前述のように、ビーコン チェーン上のバリデーターは、コンセンサス レイヤー クライアントに加えて、マージ後に実行レイヤー クライアントを実行する必要があります。マージ前にこれを行うことを強くお勧めしますが、バリデーターはこれらの機能をサードパーティベンダーにアウトソーシングする場合があります。これが可能なのは、実行層に必要なデータはデポジット契約の更新のみであるためです。

マージ後、バリデーターは、ブロック上で作成して証明したトランザクションが有効であることを確認する必要があります。これを行うには、各ビーコン ノードを実行レイヤー クライアントとペアリングする必要があります。複数のバリデーターを単一のビーコン ノードと実行層クライアントの組み合わせとペアにできることに注意してください。これによりバリデーターの責任が拡大される一方で、ブロックを提案するバリデーターには、関連するトランザクションの優先手数料（現在はマイナーに支払われている）を受け取る権利も与えられます。

バリデーター報酬はビーコン チェーンで獲得され、引き出すにはその後のネットワーク アップグレードが必要になりますが、トランザクション手数料は引き続き実行レイヤーで支払われ、バーンされ、分配されます。バリデーターは、トランザクション手数料の受取人として任意の Ethereum アドレスを指定できます。

コンセンサス クライアントを更新した後は、バリデータ クライアント設定の一部として手数料の受取人を必ず設定し、トランザクション手数料が自分が管理するアドレスに送信されるようにしてください。

ステーキングにサードパーティプロバイダーを使用する場合、これらの手数料の割り当て方法を決定するのは、選択したプロバイダー次第です。

テストネットのアップグレードは、バリデーターがセットアップが適切に機能していることを確認し、問題を解決するための最終段階です。

Ethereum メインネットが Proof of Stake に移行する前に、メインネット バリデーターが Ropsten やその他のテストネットで The Merge を実行することを強くお勧めします。

アプリケーションまたはツール開発者として、何をすべきでしょうか?

Ropsten で The Merge がライブ配信されている今こそ、製品が Proof of Stake を通じて移行され、マージ後に適切に動作することを確認するときです。前回の投稿で説明したように、マージは Ethereum にデプロイされたコントラクトのサブセットに最小限の影響しか与えず、いずれも分割されるべきではありません。さらに、ユーザー API エンドポイントの大部分は安定したままです (eth_getWork などのプルーフ・オブ・ワーク固有のメソッドを使用しない限り)。

とはいえ、Ethereum 上のほとんどのアプリケーションには、単なるオンチェーン契約以上のものが含まれます。今こそ、フロントエンド コード、ツール、デプロイメント パイプライン、その他のオフチェーン コンポーネントが適切に動作することを確認するときです。開発者には、Ropsten (または Kiln) で完全なテストとデプロイメント サイクルを実行し、ツールや依存関係に関する問題をプロジェクトのメンテナーに報告することを強くお勧めします。

Ethereum ユーザーまたはETH保有者として、何をする必要がありますか?

いいえ。Ethereum メインネットはこのテストネットの影響を受けません。今後のお知らせは、メインネット移行前にこのブログでお知らせします。

鉱夫として何をする必要がありますか?

いいえ。Ethereum Mainnet または Ropsten でマイニングする場合は、The Merge 後、各ネットワークが完全に Proof of Work で実行されることを知っておく必要があります。その時点で、ネットワーク上でマイニングを行うことはできなくなります。

2022 年 6 月 8 日頃に Ropsten で、今年後半には Ethereum メインネットでマイニングができなくなると予想されます。

バリデーターとして、ステークを取り戻すことはできますか?

できません。マージは、これまでの Ethereum のアップグレードの中で最も複雑なものとなります。ネットワーク中断のリスクを最小限に抑えるために、今回のアップグレードでは移行に関係のない変更を除外する最小限のアプローチを採用しました。

ビーコン チェーンからの引き出しは、マージ後の最初のアップグレードで導入される可能性があります。コンセンサス層と実行層の仕様は現在開発中です。

さらに質問がある場合はどこに問い合わせればよいですか?

Merge コミュニティ ホットラインは、6 月 3 日 14:00 UTC に開始される予定です。クライアント開発者と専門家が、ノード メンテナー、ステーカー、インフラストラクチャおよびツール ベンダー、コミュニティ メンバーからの質問に答えます。

合併はいつ行われますか?

本稿の公開時点では、イーサリアム メインネットのプルーフ・オブ・ステークへの移行の日付はまだ決まっていません。公式リリースではない情報源は詐欺である可能性があります。今後の更新はこのブログに掲載されます。注意してください！

ロプステン氏が問題を発見しなかった場合、クライアントテストが完了したら、イーサリアムの他のテストネットも The Merge を通じて実行されることになる。 Goerli と Sepolia が正常に移行して安定すると、ビーコン チェーン上の Bellatrix アップグレードのスロットの高さが選択され、メインネット移行の難易度値が設定されます。その後、クライアントはメインネット上で The Merge を有効にする新しいバージョンをリリースします。この情報は、このブログやその他のコミュニティのお知らせで説明されます。

今のところ問題は発生していません。ただし、プロセス中に問題が見つかった場合、またはテスト範囲が不十分であると判断された場合は、展開プロセスを続行する前にこれらの問題が解決されます。

そうして初めて、マージの正確な日付を推定することが可能になります。

つづく。