ロプステンのマージ実施の発表

• ロプステンでマージを実施します。これは、長期稼働中のテストネットでは初めての試みとなります
• ネットワークに合意形成(コンセンサス)機能を導入するため、2022 年 5 月 30 日にロプステンの新たなビーコンチェーンがローンチされました
• ロプステンのビーコンチェーンは、2022 年 6 月 2 日のスロット**24000**で、マージに対応したプロトコルルール(ベラトリックス)にアップグレードされる予定です
• その後、このプルーフ・オブ・ワークのチェーンでマージをアクティベートするための最終合計難易度(TTD)が決定されます。 ノードオペレーターは、手動でクライアントにこの値を設定する必要があります
• ロプステンのマージで使用される正確な最終合計難易度は、2022 年 6 月 3 日にこのブログで発表される予定です。 このTTD値は、決定されてから数日のうちに到達すると予想されています。そのため、ユーザーは、発表後すぐにクライアントの構成を変更できるよう、あらかじめ準備を整えておく必要があります

背景

わたしたちはイーサリアムにプルーフ・オブ・ステークを導入するための長い取り組みを経て、ついにテストの最終段階であるテストネットのデプロイメントを開始しました。

クライアントチームは、すでにキンツギ 🍵、キルン 🔥🧱 、および多くののシャドーフォークでクライアント実装をテスト済みです。そして今回いよいよ、もっとも古いプルーフ・オブ・ワークのテストネットであるロプステンでマージを実施します。 まず準備として、ロプステンのビーコンチェーンをローンチしてこのネットワークに合意形成(コンセンサス)機能を導入しました。

ロプステンの移行が完了した後、さらに 2 つのテストネット(ゴエリとセポリア)をプルーフ・オブ・ステークに移行する予定です。その後、メインネットにフォーカスをシフトします。 リンケビーやコヴァンなどのその他のテストネットについては、コミュニティによって別途メンテナンスやアップグレードが行われる可能性はありますが、クライアントの開発者による監視はなくなります。

マージは、従来のイーサリアムのアップグレードとは 2 つの点で異なります。 まず、ノードオペレーターは、合意レイヤーと実行レイヤーのいずれか一方のみのクライアントではなく、両方についてアップデートを実行する必要があります。 さらに、アップグレードは 2 つのフェーズでアクティベートされます。フェーズのトリガーはそれぞれ、ビーコンチェーンのスロットの高さと実行レイヤーの合計難易度の到達値です。

上記の点から、マージ後に非推奨となるロプステンのネットワークでは、これまでのネットワークアップグレードと比較して、開発プロセスのより早い段階でアップグレードが実行されることになります。 そのため、コミュニティはより多くの時間をかけて、アップグレードプロセスについて知識を深めることができます。

注：以下のクライアントリリースは、イーサリアムメインネットのプルーフ・オブ・ステークへの移行には適していません。

アップグレード情報

時期

マージは、2 段階のプロセスです。 最初に、合意レイヤーのネットワークのアップグレードが行われます。これは、スロットの高さによってトリガーされます。 続いて、実行レイヤーがプルーフ・オブ・ワークからプルーフ・オブ・ステークに移行します。これは、最終合計難易度(TTD)と呼ばれる特定の合計難易度しきい値によってトリガーされます。

2022 年 6 月 2 日のスロット**24000**に行われるベラトリックスアップグレードにより、ロプステンのビーコンチェーンのマージの準備が整います。 その時点で、合意レイヤー(CL)クライアントはプルーフ・オブ・ワークのチェーン上でTTD値のリッスンを開始します。

プルーフ・オブ・ワークのテストネットのハッシュレートは非常に変動しやすいため、最初のTTD値は、100000000000000000000000という非常に高い値に設定されます。 ロプステンの現在のハッシュレートでは、この値に到達するまでに最長 250 年かかります。

ビーコンチェーンのベラトリックスアップグレードの完了後、新たなTTD値が決定され、発表されます。この値は、数日の間に到達すると予想されています。 ユーザーは、この新しい値を使用してノードを構成する必要があります。 クライアントごとの構成方法は、こちらに記載されています。

ロプステンでこのTTD値に到達するかまたはこの値を超えると、実行レイヤーの移行の段階(パリというコードネームが付けられています)が開始されます。 しかし、ロプステンのハッシュレートは変動しやすいことで知られています。そのため、最終合計難易度に到達する実際の時間は、上記の予想とは異なる可能性があります。

実行レイヤーがTTDを超えると、次のブロックはビーコンチェーンのバリデータのみによって生成されます。 ビーコンチェーンがこのブロックを確定すると、マージは完了したと見なされます。 通常のネットワークの状態を想定した場合、これは TTD 到達後の最初のブロックがヒットした後の 2 エポック(つまり、約 13 分間)に発生します。

新規の JSON-RPC ブロックタグであるfinalizedは、確定された最後のブロックを返します。マージ後のブロックが存在しない場合は、エラーを返します。 このタグをアプリケーションで使用して、マージが完了しているかどうかを確認できます。 また、スマートコントラクトでオペコードDIFFICULTY (0x44)を照会することでも、マージが行われたかどうかを知ることができます。このオペコードの名称は、マージ後はPREVRANDAOに変更されます。 インフラプロバイダーは、確定状況に加えて全体的なネットワークの安定性も監視することが強く推奨されます。

クライアントリリース

以下のクライアントリリースで、ロプステンテストネットでのマージがサポートされています。 ノードオペレーターは、合意レイヤーと実行レイヤーの両方のクライアントでアップデートを実行する必要があります。そうしない場合、マージ中またはマージの完了後にネットワークから除外されます。

上記でも触れたように、以下のリリースでは、最終合計難易度の値として 100000000000000000000000がハードコーディングされています。この値は、ビーコンチェーンでベラトリックスアップグレードがアクティベートされた後に、手動でアップデートする必要があります。

実行するクライアントを選択する際には、バリデータは、実行レイヤー(EL)と合意レイヤー(CL)の両方でマジョリティクライアントを実行するリスクについて、特に留意する必要があります。 そのリスクと影響については、こちらに説明があります。 現時点での実行レイヤー(EL)と合意レイヤー(CL)のクライアント分布の推定値、およびクライアントの切り替えのガイドについては、こちらをご参照ください。

**注：**ロプステンの TTD 値が43531756765713534に設定されているクライアントリリースをすでにダウンロード済みの場合は、リリースをアップデートするか、こちらの手順に従って、TTD 値を手動で100000000000000000000000に上書きする必要があります。

合意レイヤー

**ロードスターに関する注：**ロードスターの最新リリースであるv0.37.0のロプステンの TTD は、43531756765713534という古い値です。 ロプステンのマージに対応するために、ロードスターのユーザーは、マージで使用される新しい TTD 値100000000000000000000000に手動で上書きする必要があります。 上書き方法については、チームのリリース発表の投稿をご覧ください。

実行レイヤー

**ゲスに関する注：**ゴー・イーサリアム(ゲス)の最新リリースであるシャ―ブルー(v1.10.18)のロプステンの TTD は、43531756765713534という古い値です。 ロプステンのマージに対応するために、ゲスのユーザーは、以下のいずれかの方法を使用して、マージで使用される新しい TTD 値100000000000000000000000に変更する必要があります。

• 最新のマスターブランチのソースからビルドする
• 最新のDocker イメージを使用する
• クライアントの開始時にコマンド--override.terminaltotaldifficulty 100000000000000000000000を実行して、手動で TTD 値を上書きする

アップグレードの仕様

マージのための、合意形成(コンセンサス)機能に関連した重要な変更は、以下の 2 カ所で行われます。

• consensus-specs リポジトリのbellatrixディレクトリ：合意レイヤーの変更
• execution-specs リポジトリのParis仕様：実行レイヤーの変更

上記に加え、次の 2 つの仕様によって、合意レイヤーと実行レイヤーの相互作用の方法が指定されます。

• エンジン API：execution-apis リポジトリで指定され、合意レイヤーと実行レイヤーの通信に使用する
• オプティミスティック同期：consensus-specs リポジトリのsyncフォルダで指定され、実行レイヤークライアントの同期中に合意レイヤーがブロックをインポートするために、および合意レイヤーからのチェーンの先頭の部分的なビューを実行レイヤーに提供するために使用する

よくある質問

ノードオペレーターは、何をすればよいでしょうか?

マージ後、イーサリアムのフルノードは、ビーコンチェーンでプルーフ・オブ・ステークを実行する合意レイヤークライアントと、ユーザー状態を管理し、トランザクションに関連する計算を行う実行レイヤークライアントの 2 つを合わせたものになります。 これらは、エンジン APIと呼ばれる新しい JSON-RPC 方式を使用して、認証されたポートを介して通信します。 実行レイヤー(EL)クライアントと合意レイヤー(CL)クライアントは、JWT シークレットを使用して互いを認証します。 ノードオペレーターは、その生成方法と構成方法について、クライアントのドキュメントを確認する必要があります。

言い換えると、ビーコンチェーンですでにノードを実行している場合は、実行レイヤークライアントも実行する必要があります。 同様に、現在のプルーフ・オブ・ワーク・ネットワークでノードを実行していた場合は、合意レイヤークライアントを実行する必要があります。 2 つのクライアントが安全に通信するためには、それぞれのクライアントに JWT トークンを渡す必要があります。

ビーコンノードとバリデータクライアントはどちらも合意レイヤーの一部ですが、ビーコンノードの実行とバリデータクライアントの実行は、明確に異なるものであることに留意してください。 ステーカーは両方を実行する必要がありますが、ノードオペレーターが実行しなければならないのは、ビーコンノードのみです。 この 2 つのコンポーネントの詳細は、この投稿で説明しています。

また、各レイヤーは独立したピアを維持し、独自の API を公開します。 ビーコンとJSON-RPC API は、どちらも期待どおりに機能し続けます。

6 月 6 日から 7 日の間に、このブログをもう一度ご覧になり、ロプステンの最新の TTD 値の発表についてご確認ください。

ステーカーは、何をすればよいでしょうか?

上記で説明したように、ビーコンチェーン上のバリデータは、マージ後は合意レイヤークライアントだけでなく、実行レイヤークライアントも実行する必要があります。 マージ前は、推奨されてはいませんでしたが、サードパーティーのプロバイダーに委託することが可能でした。 これが可能だったのは、実行レイヤーで必要なデータは、預入コントラクトへの更新だけだったためです。

マージ後は、作成および証明するブロックのトランザクションが有効であることをバリデータが確認する必要があります。 そのためには、各ビーコンノードと実行レイヤークライアントをペアリングする必要があります。 単一のビーコンノードと実行レイヤークライアントのペアに、複数のバリデータをペアリングすることも可能です。 バリデータの責任が拡大しますが、ブロックを提案するバリデータには、現在はマイナーに支払われている、関連するトランザクションのプライオリティーフィーが与えられます。

ビーコンチェーン上で発生したバリデータ報酬は、次回のネットワークのアップグレードまで引き出せません。しかし、トランザクションフィーは引き続き支払われ、焼却され、実行レイヤー上で配布されます。 バリデータは、トランザクションフィーの受領先として任意のイーサリアムアドレスを指定できます。

合意レイヤークライアントのアップデート後は、必ずバリデータクライアントの構成の一部としてフィーの受領者を設定して、管理するアドレスにトランザクションフィーが確実に送付されるようにしてください。

サードパーティーのプロバイダーを使用してステークを行っている場合は、フィーの割り当て先の指定は選択したプロバイダーに応じて異なります。

テストネットのアップグレードは、バリデータにとってセットアップを確認して問題を解決する最後のチャンスです。 マージのための準備としての、ロプステンのビーコンチェーンでのバリデータの実行について詳しくは、ロプステンのステーキングローンチパッドをご参照ください。

イーサリアムメインネットのバリデータは、メインネットがプルーフ・オブ・ステークに移行される前にロプステンおよびその他のテストネットでマージを試されることを強くお勧めします。

アプリケーション/ツール開発者は何をすればよいでしょうか?

ロプステンでマージが実行される今こそ、プルーフ・オブ・ステークへの移行時およびマージ後にアプリケーションやツールが意図するとおりに機能するかどうかを確認する最適なタイミングです。 以前の投稿で説明したとおり、マージはイーサリアムに展開されたサブセットコントラクトには、最小限の影響しか与えないため、破損の恐れはないはずです。 さらに、ユーザー API エンドポイントの大部分は安定しています(eth_getWorkなどのプルーフ・オブ・ワーク固有のメソッドを使用している場合を除く)。

とはいえ、イーサリアム上のほとんどのアプリケーションは、オンチェーン・コントラクトよりもはるかに複雑です。 今こそ、フロントエンドコード、ツール、展開パイプライン、およびその他のオフチェーン・コンポーネントが意図したとおりに機能することを確認するときです。 ロプステン(またはキルン)でフルテストと展開サイクルをすべて実施し、ツールや依存関係に関する問題をプロジェクトの管理者に報告することを強くお勧めします。 問題をオープンする場所をご存知ない場合は、こちらのリポジトリを使用してください。

イーサリアムユーザー、またはイーサ所有者がしなければいけないことはありますか?

いいえ。 イーサリアムメインネットは、このテストネットの影響を受けません。 今後、メインネットの移行前に、このブログでアナウンスを行う予定です。

マイナーがしなければいけないことはありますか?

いいえ。 イーサリアムメインネットまたはロプステンでマイニングを行っている場合は、マージ後はどちらのネットワークも完全にプルーフ・オブ・ステークで稼働するようになることに注意してください。 その時点で、マイニングできなくなります。

ロプステンのマージは 2022 年 6 月 8 日前後に、イーサリアムメインネットのマージは今年後半になると予想されています。

バリデータは自分のステークを引き出すことはできますか?

いいえ。 マージは、これまでのイーサリアムのアップグレードで最も複雑なものになります。 ネットワーク障害のリスクを最小限に抑えるため、今回は移行以外の変更を除外した最小限のアップグレードとすることが採択されました。

ビーコンチェーンからの引き出しが可能となるのは、おそらく、マージ後の最初のアップグレード時になります。 合意レイヤーと実行レイヤーの仕様については、現在進行中です。

ほかに質問がある場合は、どうすればよいですか?

6 月 3 日 14:00 UTC に、マージ・コミュニティコールの開催が予定されています。 クライアントの開発者や研究者が参加し、ノードオペレーター、ステーカー、インフラプロバイダー、ツールプロバイダー、コミュニティメンバーからの質問に回答します。

マージの時期

この投稿の公開時点で、イーサリアムメインネットのプルーフ・オブ・ステークへの移行日は決定していません。 「移行時期が決まっている」などと語る情報源は、詐欺である恐れがあります。 今後のアップデートはこのブログに掲載しますので、 これらの詐欺には十分ご注意ください!

ロプステンで問題が見つからなければ、クライアントテストの完了後にイーサリアムのその他のテストネットでマージが実施されます。 ゴエリとセポリアが正常に移行して安定した場合は、ベラトリックスのアップグレードのためにビーコンチェーンのスロットの高さが選択され、メインネットの移行に難易度が設定されます。 次に、クライアントはメインネットでのマージを可能にするリリースを作成します。 これらについては、ブログやその他のコミュニティの出版物で発表が行われます。

上記は、すべてが順調に進むことを前提としています。 プロセスのいずれかの時点で問題が見つかった場合、またはテストカバレッジが不十分であると判断された場合、展開プロセスは一時中断し、問題の解決後に再開します。

その時点で初めて、マージの具体的な実施日を見積もることができます。

つまりは、🔜 ということです。