- イーサリアムはプルーフ・オブ・ステークに移行します。 まずは、ベラトリックスアップグレードで、この移行(マージと呼ばれる)をビーコンチェーンでアクティベートする必要があります。 その後、特定のTotal Difficultyの値に到達した時点で、プルーフ・オブ・ワークのチェーンがプルーフ・オブ・ステークに移行します。
- ベラトリックスアップグレードは、ビーコンチェーンでエポック**144896**に予定されています。これは、2022 年 9 月 6 日の午前 11:34:47 UTCです。
- マージがトリガーされるTerminal Total Difficultyの値は、**58750000000000000000000**です。この値には、2022 年 9 月 10 日から 20 日の間に到達すると予想されています。
- 注：以前の発表でお知らせしたとおり、キルンテストネットは廃止されます。 キルンは、オペレーターによって 2022 年 9 月 6 日に終了されます。
背景
いよいよ、イーサリアムのプルーフ・オブ・ステークのアップグレードが実施されます。 すべてのパブリックテストネットのアップグレードは正常に完了しています。今回のマージは、イーサリアムメインネットに対して実施される予定です。
マージは、これまでのネットワークアップグレードとは 2 つの点で異なります。 まず、ノードオペレーターは、コンセンサスレイヤ(CL)と実行レイヤ(EL)のいずれか一方のみではなく、両方を同時にアップデートする必要があります。 さらに、アップグレードは 2 つのフェーズでアクティベートされます。最初のフェーズはベラトリックスと呼ばれるもので、ビーコンチェーンのエポックの高さによってトリガーされます。2 番目のフェーズはパリと呼ばれ、実行レイヤのTotal Difficultyの到達値によってトリガーされます。
アップグレード情報
時期
マージは、2 段階のプロセスです。 最初に、コンセンサスレイヤでネットワークのアップグレード(ベラトリックス)が行われます。これは、エポックの高さによってトリガーされます。 続いて、実行レイヤでプルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行(パリ)が行われます。これは、Total Difficultyと呼ばれる特定のTerminal Total Difficulty(TTD)しきい値によってトリガーされます。
ベラトリックスアップグレードは、ビーコンチェーンでエポック**144896**に予定されています。これは、2022 年 9 月 6 日の午前 11:34:47 UTCです。
実行レイヤの移行段階であるパリは、実行レイヤでTerminal Total Difficulty (TTD)の値が**58750000000000000000000に到達するとトリガーされます。これは、2022年9月10日から20日**の間になると予想されています。 TTDの正確な到達日は、プルーフ・オブ・ワークのハッシュレートによって変動します。 推定される移行タイミングは、bordel.wtfおよび797.io/themergeでご確認いただけます。
実行レイヤがTTD以上に到達すると、次のブロックはビーコンチェーンのバリデータのみによって生成されます。 ビーコンチェーンがこのブロックを確定すると、マージのプロセスは完了したと見なされます。 通常のネットワークの状態では、これは TTD 到達後の最初のブロックが生成された後の 2 エポック(つまり、約 13 分間)に発生します。
新規の JSON-RPC ブロックタグであるfinalizedは、確定された最後のブロックを返します。マージ後のブロックが存在しない場合は、エラーを返します。 このタグをアプリケーションで使用して、マージが完了しているかどうかを確認できます。 また、スマートコントラクトでオペコードDIFFICULTY (0x44)を照会することでも、マージが行われたかどうかを知ることができます。このオペコードの名称は、マージ後はPREVRANDAOに変更されます。 インフラプロバイダーは、確定状況に加えて全体的なネットワークの安定性も監視することが強く推奨されます。
クライアントリリース
以下のクライアントリリースで、イーサリアムメインネットでのマージがサポートされています。 ノードオペレーターは、コンセンサスレイヤと実行レイヤの両方のクライアントでアップデートを実行する必要があります。そうしない場合、マージ中またはマージの完了後にネットワークから除外されます。
実行するクライアントを選択する際には、バリデータは、実行レイヤ(EL)とコンセンサスレイヤ(CL)の両方でマジョリティクライアントを実行するリスクについて、特に留意する必要があります。 そのリスクと影響については、こちらに説明があります。 現時点での実行レイヤ(EL)とコンセンサスレイヤ(CL)のクライアント分布の推定値、およびクライアントの切り替えのガイドについては、こちらをご参照ください。
コンセンサスレイヤ
実行レイヤ
警告：ゲスの v1.10.22 バージョンには、データベースの重大な問題があります。このバージョンは使用しないでください。すでに v1.10.22 にアップグレード済みである場合は、できる限り速やかに v1.10.23 にアップグレードする必要があります。
アップグレードの仕様
マージのための、コンセンサス(合意形成)機能に関連した重要な変更が、以下の 2 カ所で行われます。
- consensus-specs リポジトリのBellatrixディレクトリ：コンセンサスレイヤの変更
- execution-specs リポジトリのParis仕様：実行レイヤの変更
上記に加え、次の 2 つの仕様によって、コンセンサスレイヤと実行レイヤの相互作用の方法が指定されます。
- エンジン API：execution-apis リポジトリで指定され、コンセンサスレイヤと実行レイヤの通信に使用する
- オプティミスティック同期：consensus-specs リポジトリのsyncフォルダで指定され、実行レイヤクライアントの同期中にコンセンサスレイヤがブロックをインポートするために、およびコンセンサスレイヤからのチェーンの先頭の部分的なビューを実行レイヤに提供するために使用する
マージに関するバグ発見報奨金のボーナス
マージに関連する脆弱性発見の報酬は、現在から 9 月 8 日までの期間、4 倍に増額されます。 深刻なバグを発見した場合に支払われる報酬の上限額は、**100 万米ドル(約 1 億 3680 万円)**です。
詳細については、バグ発見報奨金制度をご参照ください。
よくある質問
ノードオペレーターは、何をすればよいでしょうか?
マージ後、イーサリアムのフルノードは、ビーコンチェーンでプルーフ・オブ・ステークを実行するコンセンサスレイヤ(CL)クライアントと、ユーザー状態を管理し、トランザクションに関連する計算を行う実行レイヤ(EL)クライアントの 2 つを合わせたものになります。 この 2 つのクライアントは、エンジン APIと呼ばれる新しい JSON-RPC 方式を使用して、認証されたポートを介して通信します。 実行レイヤ(EL)クライアントとコンセンサスレイヤ(CL)クライアントは、JWT シークレットを使用して互いを認証します。 ノードオペレーターは、この値の生成方法と構成方法について、クライアントのドキュメントを確認する必要があります。
言い換えると、ビーコンチェーンですでにノードを実行していた場合は、実行レイヤクライアントも実行する必要があります。 同様に、現在のプルーフ・オブ・ワーク・ネットワークでノードを実行していた場合は、コンセンサスレイヤクライアントを実行する必要があります。 2 つのクライアントが安全に通信するためには、それぞれのクライアントに JWT トークンを渡す必要があります。 この手順の詳細は、ethereum.org のウェブサイト内の更新された「ノードの実行」セクションに記載されています。
ビーコンノードとバリデータクライアントはどちらもコンセンサスレイヤのクライアントリリースの一部ですが、ビーコンノードの実行とバリデータクライアントの実行は、明確に異なるものであることに留意してください。 ステーカーは両方を実行する必要がありますが、ノードオペレーターが実行しなければならないのは、ビーコンノードのみです。 この 2 つのコンポーネントの詳細については、この投稿で説明しています。
また、重要な点として、各レイヤは独立したピアを維持し、独自の API を公開します。 ビーコンAPI とJSON-RPC API は、どちらも引き続き期待どおりに機能します。
ステーカーは、何をすればよいでしょうか?
上記で説明したように、ビーコンチェーン上のバリデータは、マージ後はコンセンサスレイヤクライアントだけでなく、実行レイヤクライアントも実行する必要があります。 これはマージ前から強く推奨されていることですが、一部のバリデータは、これまでサードパーティーのプロバイダーに委託していました。 委託が可能だったのは、実行レイヤで必要なデータは、預入コントラクトへの更新だけだったためです。
マージ後は、作成および証明するブロックのユーザートランザクションと状態遷移が有効であることをバリデータが確認する必要があります。 そのためには、各ビーコンノードと実行レイヤクライアントをペアリングする必要があります。 単一のビーコンノードと実行レイヤクライアントのペアに、複数のバリデータをペアリングすることも可能です。 バリデータの責任が拡大しますが、ブロックを提案するバリデータには、現在はマイナーに支払われている、関連するトランザクションのプライオリティーフィーが与えられます。
バリデータ報酬はビーコンチェーン上で引き続き発生しますが、次回のネットワークのアップグレードまで引き出せません。一方、トランザクションフィーは支払われ、焼却され、実行レイヤ上で配布されます。 バリデータは、トランザクションフィーの受領先として任意のイーサリアムアドレスを指定できます。
**コンセンサスレイヤクライアントのアップデート後は、必ずバリデータクライアントの構成の一部としてfee recipientを設定して、管理するアドレスにトランザクションフィーが確実に送付されるようにしてください。**サードパーティーのプロバイダーを使用してステークを行っている場合は、フィーの割り当て先の指定は選択したプロバイダーに応じて異なります。
ステーキングランチパッドにはマージの準備状況チェックリストが用意されており、ステーカーが準備プロセスの各ステップを完了したことを確認できるようになっています。 また、イーサステーカー(EthStaker)は、マージに向けたバリデータの準備に関するワークショップも開催しています。このワークショップは今後も開催予定です。
メインネットをプルーフ・オブ・ステークに移行するための準備として、テストネットでバリデータを実行したいと考えているステーカーは、ゴエリ(現在はプラーターと統合済み)を利用できます。ゴエリにもステーキングランチパッドのインスタンスが用意されています。
Terminal Total Difficultyの値に到達すると予想される日付に幅があるのはなぜですか?
ブロックあたりの追加増分難易度は、変動しやすいネットワークのハッシュレートに依存します。 ネットワークのハッシュレートが増えるほど、より早くTTDに到達します。 同様に、ネットワークのハッシュレートが減少すれば、TTDの到達は遅くなります。 ハッシュレートのレベルが大幅に低下した場合は、ロプステンで行ったようにTTD Overrideによって調整できます。
アプリケーション/ツールデベロッパーは何をすればよいでしょうか?
以前の投稿で説明したとおり、マージはイーサリアムにデプロイされたコントラクトのサブセットには最小限の影響しか与えないため、破損のおそれはないはずです。 さらに、ユーザー API エンドポイントの大部分は安定しています(eth_getWorkなどのプルーフ・オブ・ワーク固有のメソッドを使用している場合を除く)。
とはいえ、イーサリアム上のほとんどのアプリケーションは、オンチェーンコントラクトよりもはるかに複雑です。 フロントエンドコード、ツール、展開パイプライン、その他のオフチェーンコンポーネントが意図したとおりに機能することを確認するには、今こそ絶好のタイミングです。 セポリアまたはキルンで、開発者が完全なテストとデプロイメントのサイクルを完遂し、ツールや依存関係に関する問題をプロジェクトの管理者に報告することを強くお勧めします。 どこで問題をオープンすればよいかわからない場合は、こちらのリポジトリをご利用ください。
また、マージ後はセポリアとゴエリを除いたすべてのテストネットが非推奨となることにご注意ください。 ロプステン、リンケビー、またはキルンを使用しているユーザーは、ゴエリまたはセポリアへの移行を計画する必要があります。 詳細については、こちらをご参照ください。
イーサリアムユーザーまたはイーサ所有者がしなければいけないことはありますか?
イーサリアムアプリケーションをオンチェーンで使用している場合、イーサを取引所で所持している場合、セルフカストディのウォレットで所持している場合のいずれであっても、何もする必要はありません。 使用しているアプリケーション、取引所、ウォレットから追加の指示や推奨を提示された場合は、本物からの指示または推奨であることを確認する必要があります。 詐欺にご注意ください。
マイナーがしなければいけないことはありますか?
ありません。 イーサリアムメインネットでマイニングを行っている場合は、マージ後はネットワークが完全にプルーフ・オブ・ステークで稼働するようになることに注意してください。 その時点でマイニングできなくなります。
マイナーまたはノードオペレーターが、アップグレードに参加しなかった場合はどうなりますか?
イーサリアムクライアントを最新バージョン(上記リストを参照)にアップデートせずに使用し続けた場合、アップグレードが実行されたときに、そのクライアントはフォーク前のブロックチェーンに同期します。
マージ後のイーサリアムネットワークでは古いルールに従う非対応のチェーンは動作せず、イーサの送信や運用を行えなくなります。
バリデータは自分のステークを引き出すことはできますか?
できません。 マージは、これまでのイーサリアムのアップグレードで最も複雑なものになります。 ネットワーク障害のリスクを最小限に抑えるため、今回は移行以外の変更を除外した最小限のアップグレードとすることが採択されました。
ビーコンチェーンからの引き出しが可能となるのは、おそらくマージ後の最初のアップグレード時になります。 現在、コンセンサスレイヤと実行レイヤの仕様の検討が進められています。
ほかに質問がある場合は、どうすればよいですか?
9 月 9 日(金)の 14:00 UTC に、次回のマージ・コミュニティコールが開催されます。このイベントには、クライアントチームのデベロッパー、イーサステーカー(EthStaker)、研究者などが集まります。ぜひご参加ください。
謝辞
イーサリアムのプルーフ・オブ・ステークへの移行がようやく実現します。 マージのためのあらゆる調査、仕様作成、開発、分析、テスト、ブレーク、修正、説明に貢献してくださったすべての方にお礼を申し上げます。
長期にわたり、非常に多くの方にご貢献いただきました。この場ですべての方のお名前を挙げることはできませんが、心より感謝いたします。 皆さまのご協力なしに、この大事業は実現できませんでした。
マージは、 間もなく実施されます。
この投稿記事のカバー画像の作成者である Joseph Schweitzer と Tomo Saito に感謝の意を表します。