イーサリアム財団: イーサリアムメインネット合併のお知らせ
Unitimes
2022-08-25 07:35
本文约4295字,阅读全文需要约17分钟
イーサリアムメインネットの合併へのカウントダウンが始まった。

元のタイトル: 「イーサリアム財団ブログ: メインネット マージの発表」

著者: プロトコル サポート チーム

オリジナル編集: Unitimes

  • イーサリアムはプルーフ・オブ・ステーク (PoS) に移行します!この遷移はと呼ばれますマージは、まず Bellatrix アップグレードを通じてビーコン チェーン上で有効化する必要があります。その後、特定の合計難易度の値に達すると、イーサリアムの Proof-of-Work (PoW) チェーンは Proof-of-Stake (PoS) に移行します。

  • 計画によれば、ベラトリックスのアップグレードは2022年になる予定9月6日11:34:47 UTC、ビーコン チェーンのエポック 144896。

  • 合併を引き起こす端末の合計難易度値は 58750000000000000000000 であると予想されます。2022年9月10日から20日まで

  • 背景

背景

長年にわたる努力の末、イーサリアムの PoS アップグレードがついに実現しました。すべてのパブリック テストネットは現在正常にアップグレードされており、イーサリアム メインネットへの統合アップグレードがスケジュールされています。

この合併は 2 つの点で過去のネットワーク アップグレードとは異なります。まず、ノードオペレーターは両方を更新する必要があります。コンセンサス層 (CL) クライアントと実行層 (EL) クライアント、そのうちの1つだけではありません。次に、このアップグレードは 2 つのフェーズでアクティブ化されます。最初のフェーズはBellatrix、ビーコン チェーン上の特定のエポック高さで完了します。第 2 段階はと呼ばれます。Paris最初のレベルのタイトル

副題

時間

マージは 2 つのステップに分かれており、最初のステップは特定のエポック高さのコンセンサス層でトリガーされます。ベラトリックス ネットワークのアップグレード。その後、実行層は Proof-of-Work (PoW) から Proof-of-Stake (PoS) に移行します。このステップは、「PoS」として知られています。Paris、ターミナル合計難易度と呼ばれる用語で (TTD) 特定の合計難易度の値によってトリガーされます。

Bellatrix のアップグレードは予定されています2022 年 9 月 6 日午前 11:34:47 UTCビーコンチェーンの高さが144896に達したときに実行します。

そして実行層はパリをアップグレードします。 TTD 合計難易度値に到達しました 58750000000000000000000 にトリガーされます。これは に発生すると予想されます2022年9月10日から9月20日まで同様にbordel.wtf同様に797.io/themerge現れる。

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

新しい JSON-RPC ブロック タグ finalizedによるによるクエリ DIFFICULTY オペコード (0x44)(合併後 PREVRANDAO に名前変更)副題

クライアントのバージョン

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

ここここここここ実行層とコンセンサス層におけるクライアントの分布の推定値と、あるクライアントから別のクライアントに切り替えるためのガイドラインを見つけます。

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

クライアント:Lighthouse 

バージョン: v3.0.0

ダウンロードリンク

クライアント:Lodestar 

バージョン: v1.0.0

ダウンロードリンク

クライアント:Nimbus 

バージョン: v22.8.0

ダウンロードリンク

クライアント:Prysm 

バージョン: v3.0.0

ダウンロードリンク

クライアント:Teku 

バージョン: 22.8.1

ダウンロードリンク

クライアント:Erigon 

バージョン: v2022.08.02-アルファ

ダウンロードリンク

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

バージョン: v1.10.23

ダウンロードリンク

クライアント:Nethermind 

バージョン: v1.14.0

ダウンロードリンク

副題

アップグレード仕様

マージされたコンセンサス キーの変更は、次の 2 か所で指定されます。

1. コンセンサス層はコンセンサス仕様リポジトリに基づいていますBellatrix目次変化。

2. 実行層は、Paris仕様変化。

これに加えて、他の 2 つの仕様では、コンセンサス層と実行層のクライアントがどのように対話するかをカバーしています。

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

2. コンセンサス仕様リポジトリ内sync副題

バグ報奨金プログラムの導入

現在から 9 月 8 日までの間、すべてのマージ関連のバグ報奨金には 4 倍の乗数が適用されます。重大なバグの報奨金は最大 100 万ドルに達する場合があります。

詳細については、を参照してください。副題 。

FAQ

1. ノードオペレーターとして何をすべきですか?

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

つまり、ビーコン チェーン上でノードがすでに実行されている場合は、実行層クライアントも実行する必要があります。同様に、現在のプルーフ・オブ・ワーク (PoW) ネットワーク上でノードを実行する場合は、コンセンサス層クライアントも実行する必要があります。安全に通信するには、JWT トークンを各クライアントに渡す必要があります。 ethereum.org Web サイトの「ノードの実行」セクションこのアップデートでは、手順がさらに詳しく説明されています。

この記事この記事これら 2 つのコンポーネントの違いについて詳しく説明します。

そしてBeacon APIそしてJSON RPC APIどちらも引き続き期待どおりに機能します。

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

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

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

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

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

ステーキング Launchpad には、マージ準備チェックリスト、関係者がプロセスの各ステップを確実に完了するために使用できます。 EthStaker はバリデーター準備ワークショップも開催しており、さらに多くのワークショップが予定されています。

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

3. TTD の推定日付範囲がこれほど広いのはなぜですか?

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

4. アプリケーションまたはツールの開発者は何をすべきですか?

前回の投稿で述べたように、このマージはイーサリアム上にデプロイされたコントラクトのサブセットに最小限の影響を与え、いずれも破られるべきではありません。また、ほとんどのユーザー API エンドポイントは安定したままになります (eth_getWork などのproof-of-work 固有のメソッドを使用しない限り)。

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

また、Sepolia と Goerli を除くすべてのテストネットは、マージ後に非推奨になることに注意してください。 Ropsten、Rinkeby、または Kiln のユーザーの場合は、Goerli または Sepolia への移行を計画する必要があります。詳細については、次を参照してください。このリンク 。

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

イーサリアム アプリケーションをオンチェーンで使用している場合でも、ETH を取引所で保有している場合でも、自分が保管しているウォレットに保管している場合でも、何もする必要はありません。使用しているアプリ、取引プラットフォーム、またはウォレットが追加の指示やアドバイスを提供している場合は、それらの指示やアドバイスがそれらからのものであることを確認する必要があります。詐欺に注意してください!

6. イーサリアムマイナーとして他にできることは何ですか?

いいえ、イーサリアムのメインネットでマイニングを行っている場合は、合併後、ネットワークは完全にプルーフ オブ ステーク (PoS) アルゴリズムの下で実行され、その時点で POW マイニングは不可能になることを知っておく必要があります。

7. 私がマイナーまたはノードオペレーターであり、アップグレードに関与していない場合はどうなりますか?

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

古いルールに従って互換性のないチェーンに留まり、イーサを送信したり、マージされたイーサリアム ネットワーク上で操作したりできなくなります。

8. バリデーターとして、誓約した ETH 権利を撤回できますか?

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

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

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

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

ありがとう

イーサリアムのプルーフ・オブ・ステーク(PoS)への移行は長い間進められてきました。 The Merge に関するすべての研究、開発、分析、テスト、破壊、修正、説明に貢献してくださった皆様に感謝します。

長年にわたる貢献者は多すぎてここにリストすることはできませんが、あなたが誰であるかはご存知でしょう。皆さんの協力なしではこの大聖堂を建てることはできませんでした。

元のリンク

元のリンク

Unitimes
作者文库