ConsenSys開発者：イーサリアムメインネットの統合は完璧である必要はなく、Goerliテストネットの問題は大したことではない

注: 元の著者はConsenSys開発者の Ben Edgington です。この記事では、 Goerliテストネットのマージ中に発生した問題について言及しました。彼は、この問題は大したことではなく、その後のイーサリアムメインネット統合計画には影響しないと説明した。彼の意見では、イーサリアムのメインネット統合は完璧である必要はない。

編集者: Overnight Porridge、The Way of Metaverse

Ethereum メインネット統合の TTD が決定されました! 587500000000000000000000000 という数字が、現代の最も重要な整数のリストに加わりました。イーサリアムのプルーフ・オブ・ワーク・チェーンがこれだけの難易度に達すると、ネットワーク全体がプルーフ・オブ・ステーク（PoS）に切り替わります。

この数は、Goerli テストネットの統合が成功した後の開発者のコ​​ンセンサス会議中に決定されました。ハッシュレートの変動により、マージが行われる正確な時間は数日ずれる可能性がありますが、メインネットのマージは 9 月 15 日頃に行うことを目標としています。最新の合併予測タイミングは、いつものように bordel.wtf または Matthew Rabinowitz のスプレッドシートで確認できます。

TTD の選択は Mario Havel の分析に基づいていますが、これは開発者によってまだ完全に確認されておらず、来週の最終クライアント バージョンがリリースされる前に修正される可能性があることに注意してください。

したがって、結合されたパスは次のようになります。

1. 8 月 18 日: すべてのコア開発者の電話会議中に TTD 番号のマージを承認しました。

2. 8月22日：最終TTDを含むクライアントバージョンが完成しました。

3. 8月23日：イーサリアム財団が公式ブログで発表しました。

4. 9 月 6 日、11:34:47 UTC: ビーコン チェーン Bellatrix は、エポック 144896、スロット 4636672 でアップグレードされました。

5. 9月15日頃：シャンパンパーティー。

Goerli テストネットマージレビュー

イーサリアムの Goerli テストネットは、8 月 11 日午前 1 時 50 分 UTC 頃に予定されていた TTD に到達し、Prater ビーコン チェーン テストネットと統合されました。

このマージは完璧には行かず、さまざまな問題により、理想的には期待していた 15 分ではなく、完了までに 40 分かかりました。しかし、合併は完了し、最終的には成功しました。

関連する問題についてはコンセンサス開発者の電話会議で議論したので、ここでは繰り返しません。個々の問題のより詳細な分析へのリンクを含む問題追跡ツールもあります。 TTD 基準を満たす候補ブロックが 2 つあると、いくつかの問題が発生します。一部の Besu クライアントが誤ってそのうちの 1 つを拒否したため、一部の Teku ノードがしばらくの間間違ったフォークに配置されてしまいました。メインネットでは複数の端末候補が存在する可能性はありますが、その可能性はテストネットの場合よりもずっと低くなります。とにかく、このバグが修正されることを願っています。さらに、クライアント チームの 1 つが (再び) ノードを誤って構成していなかったら、おそらくずっと前に作業は終わっていたでしょう。

合併から数時間後、Goerli-Prater はほぼ正常なパフォーマンスに戻りました。

つまり、全体として、深刻なことは何も起こらず、次のステップに進むのに十分な自信を持っています。正直、メインネットの統合がそのように進んだらとても嬉しいです。マージは完璧である必要はありません。

Bankless と EthStaker による Goerli 合併ライブストリームの視聴回数は 21,000 回を超えました。

さらに、CryptoGucciはGoerliの合併プロセスに関する概要記事を執筆し、The Block、 Decrypt 、 The Defiant 、 Blockworks 、 CNBCなどのメディアも報道しました。

ゴエリシャドーフォーク（6）

もう随分前のことのように思えますが、8月4日にGSF6が開催され、大変盛況でしたので、Pariさんのメモをもとに概要をご紹介します。

1. クライアント側に問題はなく、すべての組み合わせが同期され、遷移は正しく処理されました。

2. 2 つのノードのディスク容量が不足していたため、参加率が低下しました (97% から 94%)。

3. 移行中、ネットワークの約 30% が MEV-Boost を実行していましたが、インドの 1 つのノード (おそらくマシンに欠陥があった) でのレイテンシ関連の問題を除けば、他の問題は発生しませんでした。

合併の準備

Somer Esat はステーキング ガイドを更新し、Goerli マージ構成を追加しました。 Somer のガイドは、CoinCashew のガイドとともに、ビーコン チェーン ステーキングの標準となりつつあり、私は自分の構成を設定する際に彼の Teku ガイドを使用しました。これらは統合された Goerli テストネットのみをカバーしていますが、メインネットのセットアップが進むにつれて、Teku、Lighthouse、Nimbus、Prysm なども含めて更新されると思います。

EthStaker の最新のバリデータ ワークショップをご覧ください。ノードでの MEV-Boost の設定についても説明しています。役に立つアドバイスや質疑応答がたくさんある素晴らしいセッションでした。次回の会議は24日に予定されています。

Infura の優れたマージ ワークショップは継続中です。最新のものは次のとおりです。

1. 8 月 2 日: 私の尊敬する同僚 Matt Nelson が主催する実行クライアントおよび合意クライアント ワークショップ。

2. 8月9日：複数のバリデーターとステーキングサービス（SaaS）の実行。

マージされた構成のリストは次のとおりです。

研究開発

1. MEV ブーストを実行する場合は、信頼が必要であることを考慮する必要があります。特に、現在の設計では、ステーカーはリレーが適切に機能することを信頼する必要があります。つまり、リレーヤーはブロック値を正しく報告し、有効なブロックを提供し、バリデータが署名した後はブロックを保留しません。リピーターを正直に保つ方法の 1 つは、リピーターを監視することです。そこで Alex Stokes は、障害情報を収集し、各リピーターのスコアとして報告できるリピーター監視設計を提案しました。ステーカーは、情報に基づいた判断を下し、どのリレーサーバーを訪問するかを決めることができます。

2. これを書いている時点では、ethresear.ch にはまだアクセスできませんが、私は Danksharding のパフォーマンス向上に役立つ KZG マルチプルーフの構築に関するこの画期的な研究を認識しています。