ゴエリ/プラーターのマージ実施の発表

• 最後のテストネットのプルーフ・オブ・ステークへの移行では、ゴエリがプラーターとマージされます。 マージ後、ゴエリ/プラーターの統合ネットワークでは、ゴエリの名称がそのまま使用されます。
• マージの準備を整えるためのプラーターのアップグレードであるベラトリックスは、エポック**112260で開始されます。これは、2022年8月4日12:24 UTC**になると予想されています。
• ベラトリックスがアクティベートされた後、ゴエリで合計難易度の値**10790000に到達したとき、ゴエリ/プラーターのマージが行われます。これは、2022年8月6日から12日**の間になると予想されています。
• 個々のステーカーは、マージ後もゴエリのバリデータセットを利用してテストネットのバリデータを実行できます。 ゴエリ/プラーターのバリデータは、プラーターローンチパッドで開始できます。

背景

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

さまざまなデブネット、シャドーフォーク、非推奨テストネットでのマージを経て、先日、セポリアのプルーフ・オブ・ステークへの移行が完了しました。 これで、移行が完了していないテストネットは、ゴレリ(および関連するビーコンチェーンのプラーター)だけになりました。

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

アップグレード情報

時期

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

ベラトリックスアップグレードは、プラータービーコンチェーンのエポック**112260で開始される予定です。これは、2022年8月4日12:24 UTCになると予想されています。 実行レイヤーでの移行段階であるパリは、ゴエリでターミナル合計難易度(TTD)の値10790000に到達するとトリガーされます。これは、2022年8月6日から12日**の間になると予想されています。

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

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

クライアントリリース

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

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

合意レイヤー

実行レイヤー

アップグレードの仕様

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

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

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

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

よくある質問

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

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

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

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

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

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

ゴエリ/プラーターのマージは、メインネットが移行される前に、バリデータが正しく構成されていることを確認する最後のチャンスです。 メインネットで予期しない問題が発生しないように、今回、移行を実施することを強くお勧めします。

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

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

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

**合意レイヤークライアントのアップデート後は、必ずバリデータクライアントの構成の一部としてフィーの受領者を設定して、管理するアドレスにトランザクションフィーが確実に送付されるようにしてください。**サードパーティーのプロバイダーを使用してステークを行っている場合は、フィーの割り当て先の指定は選択したプロバイダーに応じて異なります。

プラーターのステーキングローンチパッドには、マージの準備状況チェックリストが用意されており、ステーカーが準備プロセスの各ステップを完了したことを確認できるようになっています。 さらに、イーサステーカー(EthStaker)チームが、7 月 29 日にマージに向けたバリデータの準備に関するワークショップを開催します。

ターミナル合計難易度の値に到達すると予想される日付に幅があるのはなぜですか?

ブロックあたりの増分難易度は変動しやすいため、TTD値に到達する期間の予想は、ブロックの高さやエポックの高さを使用する予想よりも難しく、予想される範囲が広くなります。 メインネットの移行の場合も、プルーフ・オブ・ワークのハッシュレートは変動しやすいため、予想が難しく、予想される範囲が広くなることに注意しておく必要があります。

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

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

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

さらに、マージ後はセポリアとゴエリ以外のすべてのテストネットが非推奨となることにご注意ください。 ロプステン、リンケビー、またはキルンを使用しているユーザーは、ゴエリまたはセポリアへの移行を計画する必要があります。 詳細については、こちらをご参照ください。

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

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

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

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

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

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

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

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

イーサステーカー(EthStaker)コミュニティでは、ディスコード(Discord)チャンネルが開設されており、ステーカーやノードオペレーターからの質問に対する回答を得ることができます。 こちらからディスコード(Discord)に参加し、#goerli-praterチャンネルを使用して支援を求めることができます。 なお、上記でも触れたように、イーサステーカー(EthStaker)チームが、7 月 29 日にマージに向けたバリデータの準備に関するワークショップを開催します。

さらに、8 月 12 日 14:00 UTC に、マージ・コミュニティコールの開催が予定されています。 クライアントの開発者や研究者が参加し、ノードオペレーター、ステーカー、インフラプロバイダー、ツールプロバイダー、コミュニティメンバーからの質問に回答します。 このコミュニティコールは、ゴエリ/プラーターのマージ後に開催される予定であることにご注意ください。

マージの時期

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

ゴエリ/プラーターのマージで問題が見つからなければ、クライアントが完全な機能を備えたリリースを利用できるようになり次第、メインネットのビーコンチェーンのベラトリックスアップグレードのためにスロットの高さが選択され、メインネットの移行のために合計難易度が設定されます。 次に、クライアントはメインネットでのマージを可能にするリリースを作成します。 これらについては、ブログやその他のコミュニティの出版物で発表が行われます。

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

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

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