イーサリアム財団: イーサリアム メインネット統合のお知らせ

出典: イーサリアム財団公式ブログ

• Ethereum は Proof of Stake (PoS) に移行しています。この遷移は「マージ」と呼ばれ、最初に Bellatrix アップグレードを介してビーコン チェーンでアクティブ化する必要があります。その後、特定の合計難易度値に達すると、Ethereum Proof-of-Work (PoW) チェーンは Proof-of-Stake (PoS) に移行します。

• 計画によれば、Bellatrixのアップグレードは、 2022年9月6日11時34分47秒（UTC）、ビーコンチェーンの144896番目のエポックに実行される予定だ。

• マージのトリガーとなるターミナルの合計難易度値は58750000000000000000000であり、 2022 年 9 月 10 日から 20 日の間になると予想されます。

• 注意: 以前に発表されたとおり、Kiln テストネットは廃止され、オペレーターは 2022 年 9 月 6 日にシャットダウンされます。

背景

長年の努力の末、ついにイーサリアムの PoS アップグレードが実現しました!すべてのパブリック テストネットのアップグレードが正常に完了し、Ethereum メインネットへのマージ アップグレードがスケジュールされました。

この合併は、これまでのネットワークのアップグレードとは 2 つの点で異なります。まず、ノード オペレーターは、コンセンサス レイヤー(CL)クライアントと実行レイヤー(EL)クライアントのどちらか一方だけではなく、両方を更新する必要があります。次に、このアップグレードは 2 つのフェーズでアクティブ化されます。最初のフェーズはBellatrixと呼ばれ、ビーコン チェーンの特定のエポックの高さで完了します。 2 番目のフェーズはパリと呼ばれ、実行レイヤーが所定の合計難易度値に達すると完了します。

アップグレード情報

時間

合併は2つの段階に分かれています。最初のステップは、特定のエポックの高さでコンセンサス レイヤーでトリガーされるBellatrix ネットワークのアップグレードです。次に、実行レイヤーは、ターミナル合計難易度 (TTD) と呼ばれる特定の合計難易度値によってトリガーされるパリと呼ばれるステップで、プルーフ・オブ・ワーク (PoW) からプルーフ・オブ・ステーク (PoS) に移行します。

Bellatrix のアップグレードは、ビーコン チェーンがブロック 144896 に到達した2022 年 9 月 6 日午前 11 時 34 分 47 秒 (UTC) に実行される予定です。

実行レイヤーのアップグレードであるパリは、TTD の合計難易度値が58750000000000000000000達したときにトリガーされます。これは2022 年 9 月 10 日から 9 月 20 日の間になると予想されます。 TTDに到達する正確な日付はプルーフ・オブ・ワークの計算能力の状況に依存し、移行時間の推定値はbordel.wtf[1]と797.io/themerge[2]で確認できます。

実行レイヤーが所定の TTD 値に達するかそれを超えると、ビーコン チェーン バリデーターが後続のブロックの生成を担当します。ビーコン チェーンがブロックを確定すると、マージ アップグレードは完了したとみなされます。通常のネットワーク状況では、TDD 難易度値に達した後に生成される最初のブロックは、2 エポック (約 13 分) で確定されます。

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

クライアントバージョン

次のクライアント バージョンは、Ethereum メインネットへのマージ アップグレードをサポートしています。ノード オペレーターは、マージ中およびマージ後にネットワーク上に留まるために、実行レイヤー クライアントとコンセンサス レイヤー クライアントの両方を実行する必要があることに注意してください。

実行するクライアントを選択する際、バリデータは EL と CL で多数のクライアントを実行するリスクに特に注意する必要があります。これらのリスクとその結果についての説明は、ここ[ 4]でご覧いただけます。また、実行層とコンセンサス層のクライアントの分布の推定値や、あるクライアントから別のクライアントに切り替える際のガイダンスもここで見つけることができます。 [ 5]

1) コンセンサス層クライアント

クライアント:ライトハウス

バージョン: v3.0.0

ダウンロードリンク:

https://github.com/sigp/lighthouse/releases/tag/v3.0.0

クライアント:ロードスター

バージョン: v1.0.0

ダウンロードリンク:

https://github.com/ChainSafe/lodestar/releases/tag/v1.0.0

クライアント: Nimbus

バージョン: v22.8.0

ダウンロードリンク:

https://github.com/status-im/nimbus-eth2/releases/tag/v22.8.0

クライアント: Prysm

バージョン: v3.0.0

ダウンロードリンク:

https://github.com/prysmaticlabs/prysm/releases/tag/v3.0.0

クライアント:テク

バージョン: 22.8.1

ダウンロードリンク:

https://github.com/ConsenSys/teku/releases/tag/22.8.1

2) 実行層クライアント

クライアント:ベス

バージョン: 22.7.1

ダウンロードリンク:

https://github.com/hyperledger/besu/releases/tag/22.7.1

クライアント:エリゴン

バージョン: v2022.08.02-alpha

ダウンロードリンク:

https://github.com/ledgerwatch/erigon/releases/tag/v2022.08.02

クライアント: go-ethereum (geth)

バージョン: v1.10.23

ダウンロードリンク:

https://github.com/ethereum/go-ethereum/releases/tag/v1.10.23

クライアント: Nethermind

バージョン: v1.14.0

ダウンロードリンク:

https://github.com/NethermindEth/nethermind/releases/tag/1.14.0

警告: geth v1.10.22 には重大なデータベースの問題が含まれています。このバージョンは使用しないでください。このバージョンのクライアントを使用している場合は、できるだけ早く v1.10.23 にアップグレードしてください。

アップグレード仕様

マージされるコンセンサス クリティカルな変更は、次の 2 つの場所で指定されます。

1. コンセンサスレイヤーは、コンセンサス仕様リポジトリのBellatrixカタログに従って変更されます[ 6]。

2. 実行層は実行仕様リポジトリ内のパリ仕様[ 7]に従って変更されます。

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

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

2. コンセンサス仕様リポジトリのsync ‌ [ 9] フォルダで指定されている楽観的同期は、コンセンサス層が実行層クライアントと同期するときにブロックをインポートし、前者から後者までのチェーンヘッドの部分的なビューを提供するために使用します。

バグバウンティプログラムの統合

今から 9 月 8 日まで、マージ関連のバグバウンティはすべて 4 倍の乗数になります。重大なバグに対する報奨金は最大 100 万ドル支払われます。

詳細については、バグバウンティプログラムをご覧ください。

https://bounty.ethereum.org/

よくある質問

1. ノードオペレーターとして何をすればよいですか?

合併後、Ethereum フルノードは、プルーフオブステーク ビーコン チェーンを実行するコンセンサス レイヤー (CL) クライアントと、ユーザー状態を管理し、トランザクション関連の計算を実行する実行レイヤー (EL) クライアントの組み合わせになります。実行層（EL）とコンセンサス層（CL）のクライアントは、エンジンAPIと呼ばれる新しいJSON RPCメソッドセットを使用して、認証されたポートを介して通信します。 [ 10] EL クライアントと CL クライアントは、JWT キーを使用して相互に認証します。ノード オペレーターは、この値を生成および構成する方法については、クライアントのドキュメントを参照する必要があります。

つまり、ビーコン チェーン上ですでにノードを実行している場合は、実行レイヤー クライアントも実行する必要があります。同様に、現在の Proof-of-Work (PoW) ネットワーク上でノードを実行する場合は、コンセンサス レイヤー クライアントも実行する必要があります。安全に通信するには、JWT トークンを各クライアントに渡す必要があります。 ethereum.orgウェブサイト[11]の「ノードの実行」セクションが更新され、これらの手順がより詳細に説明されています。

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

さらに、各層は独立したピア ノードのセットを維持し、独自の API を公開することに注意してください。ビーコンAPI[13]とJSON RPC API[14]はどちらも期待どおりに動作し続けます。

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

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

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

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

コンセンサス クライアントを更新した後は、バリデータ クライアント設定の一部としてfee recipient必ず設定し、トランザクション手数料が自分が管理するアドレスに送信されるようにしてください。ステーキングにサードパーティプロバイダーを使用する場合、これらの手数料の分配方法を決定するのは、選択したプロバイダー次第です。

Staking Launchpadにはマージ準備チェックリスト[ 15]があり、ステーカーはこれを使用してプロセスの各ステップを完了していることを確認することができます。 EthStaker はバリデーター準備ワークショップも開催しており、今後もワークショップを開催する予定です。

メインネットの PoS 移行に備えてテストネットでバリデーターを実行したいステーカーは、Staking Launchpad インスタンスも備えた (現在は統合されている) Goerli テストネットで実行できます。

3. ターミナル総合難易度 (TTD) の推定日付範囲が広いのはなぜですか?

各ブロックの難易度は、不安定なネットワークの計算能力に応じて増加します。より多くのコンピューティング能力がネットワークに加われば、TTD にさらに早く到達できるようになります。同様に、計算能力がネットワークから失われると、TTD の到着時間が遅れます。ハッシュレート レベルが大幅に低下した場合は、Ropsten テストネットで行われたように、TTD カバレッジ値を調整できます。

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

前回の投稿で述べたように、この統合は Ethereum にデプロイされたコントラクトのサブセットに最小限の影響しか与えず、コントラクトが破損することはありません。さらに、ほとんどのユーザー API エンドポイントは安定したままになります ( eth_getWorkなどのプルーフ・オブ・ワーク固有のメソッドを使用している場合を除きます)。

とはいえ、Ethereum 上のほとんどのアプリケーションには、単なるオンチェーン契約以上のものが含まれます。今こそ、フロントエンド コード、ツール、デプロイメント パイプライン、その他のオフチェーン コンポーネントが期待どおりに動作することを確認するときです。開発者は、Sepolia または Goerli で完全なテストとデプロイメント サイクルを実行し、ツールや依存関係の問題があればそれらのプロジェクトのメンテナーに報告することを強くお勧めします。問題をどこに報告すればよいかわからない場合は、このリポジトリを使用してください。

また、Sepolia と Goerli を除くすべてのテストネットは、統合後に廃止されることにご注意ください。 Ropsten、Rinkeby、または Kiln のユーザーの場合は、Goerli または Sepolia への移行を計画する必要があります。詳細については、このリンク[16]を参照してください。

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

オンチェーンで Ethereum アプリを使用している場合でも、取引所で ETH を保有している場合も、自己管理型ウォレットで保有している場合も、何もする必要はありません。使用するアプリ、取引所、またはウォレットが追加の指示や提案を提供している場合は、それらの指示や提案がそれらからのものであることを確認する必要があります。詐欺にご注意ください！

6. Ethereum マイナーとして他に何かできることはありますか?

いいえ、Ethereum メインネットでマイニングを行っている場合は、合併後、ネットワークは完全に Proof of Stake (PoS) アルゴリズムに基づいて実行されるため、その時点で POW マイニングは不可能になることを知っておく必要があります。

7. マイナーまたはノードオペレーターがアップグレードに参加しない場合はどうなりますか?

最新バージョン (上記に記載) に更新されていない Ethereum クライアントを使用している場合、ネットワークがアップグレードされると、クライアントはフォーク前のブロックチェーンに同期されます。

古いルールに従う互換性のないチェーンに閉じ込められ、イーサを送信したり、統合された Ethereum ネットワークで操作したりできなくなります。

8. バリデーターとして、ステークした ETH を引き出すことはできますか?

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

合併後の最初のアップグレードで、ビーコン チェーンからの撤退が導入される可能性があります。コンセンサス層と実行層の仕様が開発中です。

9. 他に質問があるのですが、どこに問い合わせればよいですか?

9 月 9 日 14:00 UTC にマージに関するコミュニティ コールが開催され、クライアント開発者、ETHStaker メンバー、研究者などと一緒に参加できます。

謝辞

イーサリアムのプルーフ・オブ・ステーク（PoS）への移行は長い間計画されてきました。 The Merge に関するあらゆる調査、開発、分析、テスト、破壊、修正、説明に貢献してくれたすべての人に感謝します。

長年にわたる貢献者は多すぎてここには書ききれませんが、あなたは自分が誰であるかを知っています。皆さんがいなければ、この大聖堂を建てることはできなかったでしょう。

合併はいつ行われますか?とても速くなります。