ETH Placeのコア開発者による最新の会議の概要:年末までにGoerliシャドウフォークとCancun/Denebアップグレードのテストが行われます

原題:Ethereum All Core Developers Consensus Call #124 Writeup

クリスティン・キムによるオリジナル記事

オリジナルコンピレーション:Luccy、BlockBeats

編集部注:

ETH Workshop All Core Developer Consensus Calls (ACDC) は隔週で開催され、ETH Workshop の Consensus Layer (CL) の変更について議論し、調整します。 これはACDCの124回目の電話会議であり、Devnet #12のアップデート、カンクン/デネブのアップグレードの進捗状況、およびSlashableの普及に関連するトピックをカバーしています。 会議中、開発者は、ノード上の大きなメッセージの増幅効果を減らすために、Libp2pネットワークプロトコルの小さな変更について活発に議論しました。

Galaxy DigitalのリサーチVPであるChristine Kim氏は、BlockBeastsがまとめた会議のハイライトについて詳細にメモしました。

2023 年 12 月 14 日、ETH開発者が All Core Developers Consensus (ACDC) コール #124 セッションのために Zoom に集まりました。 ACDCの電話会議は、ETH Workshop Foundationの研究者であるDanny Ryan氏が主導する隔週の一連の会議で、開発者がETH Workshop Consensus Layer(CL)の変更について議論し、調整します。 今週、開発者はDevnet #12テストネットでのCancun/Denebアップグレードのテストの進捗状況に焦点を当てました。 先週の All-Core Developer Execution (ACDE) ミーティング以降、Prysm クライアントを含むすべての実行レイヤー (EL) とコンセンサス レイヤー (CL) クライアントの組み合わせが Devnet #12 にオンボードされました。 MEV-Boostソフトウェアは有効になっていますが、Prysmとのクライアントの組み合わせは含まれていません。 開発者は、今後1〜2週間以内にGoerliシャドウブランチを立ち上げ、Cancun/Denebのアップグレードをテストし、すべてのクライアントを含める計画を順調に進めていると述べました。 さらに、開発者は、Slashableに関する情報の普及に関するルールと、今後2週間の通話スケジュールについて話し合いました。

Devnet #12 アップデート

ETH FoundationのDevOpsエンジニアであるBarnabas Busa氏は、PrysmをCLクライアントとして使用するものを含め、すべてのEL/CLクライアントの組み合わせがDevnet #12に正常に統合されていると述べた。 Prysmを使用するクライアントポートフォリオは、MEV-Boostソフトウェアでテストされていません。 ただし、Devnet #12 では、MEV ワークフローは他の CL クライアントをテストしています。 最近、Lighthouseクライアントは、MEV関連のバグに対処するためのパッチアップデートを受けました。 さらに、Foundationのもう一人のDevOpsエンジニアであるParithosh Jayanthi氏は、Devnet #12のBesuノードに問題があることに気付き、根本原因の特定にまだ取り組んでいると述べました。 次のステップとして、開発者は意図的に悪意のあるブロックをネットワーク経由で送信し、ブロックジェネレーターをテストし、新しく追加されたPrysmクライアントに対してハイブテストを実行して、Devnetでクライアントの組み合わせのストレステストを行います。 Jayanthi氏は、電話会議中に公開されたDiscordメッセージで、開発者は年末までにGoerliテストネットでシャドウブランチを立ち上げる予定であると述べました。

スラッシュ可能な情報が更新されました

次に、開発者は、カンクン/デネブのアップグレード後のETHでのSlashableのメッセージの拡散とタイミングに関連するいくつかの問題について簡単に説明しました。 背景として、スラッシュ可能な情報には、重複または無効なブロックとブロブの伝播が含まれます。 Lodestarクライアントの匿名開発者であるDapplionは、Beacon Chain APIに新しいイベントを追加して、ノードオペレーターがSlashableイベントについてより迅速に学習できるようにすることを目的としたプルリクエスト(PR)をGitHub経由で作成しました。 Dapplion氏はPRの中で、「大規模なオペレーターにとって、切断イベントの総コストは応答時間に大きく依存します。 操作エラーに関与するキーが多数ある場合、このスラッシュ可能な情報がチェーンに含まれるまでに時間がかかる場合があります。 DapplionのPRは、呼び出しに先立ってBeacon Chain APIの仕様に統合され、PrysmやLighthouseなどのさまざまなCLクライアントチームによって実装されています。

Dapplionは、ブロック伝搬時間の測定に関連するPRも提案しています。 彼は、Cancun/DenebのアップグレードとBLOBトランザクションの導入により、ブロックの伝播時間の測定がより困難になると指摘した。 Dapplion氏は、PRで提案するソリューションについて詳しく説明しています。 開発者がPRスレッドで気付いたように、既存の関連するビーコンチェーンAPIイベントにタイムスタンプフィールドを追加することで、この問題を解決する傾向があります。

Cancun/Deneb のアップグレード後の Slashable 情報の伝播に関連して開発者が議論した 3 つ目のトピックは、BLOB の伝播条件でした。 Lighthouseの開発者である"sean"(GitHubでは"realbigsean")は、既存のBLOB伝播ルールが意図しない結果をもたらしたと指摘した。 電話の中で、ショーンは「ブロードキャスト認証にBeacon APIを使用している場合、ゴシップアプローチが有効なメッセージと無効なメッセージにつながることは予想外です。 これは、技術的には、関連付けられた Slashable ヘッダーの異なる BLOB インデックスを持つ 2 つの BLOB を伝播できるためです。 これらを伝達することはできますが、同じ BLOB インデックスを持つものは伝達できません。 」

ショーンは、ブロブのスラッシュ可能な情報伝播に関する奇妙な振る舞いは、ノードオペレーターが理解して解析するための単なる「奇妙な」結果以外に、ネットワークの健全性に大きな影響を与えないと付け加えました。 したがって、Cancun/Denebのアクティベーションの緊急性はありませんが、彼は開発者が将来のアップグレードでSlashable情報配布を処理するためのルールを変更することを検討することを提案しています。 Danny Ryan氏もこれに同意し、開発者はこの問題をどのように解決するかについて「総合的に」考える時間を取るべきだと述べている。 Ryan氏は、開発者がSlashableのBLOBとブロックの伝播ルールを更新するための包括的な計画を考案する時間を与えるために、1月にこのトピックを再検討することを提案している。

次に、開発者は、多数のブロブを持つブロックなど、大きなメッセージを送信するノードに対する増幅効果を減らすために、libp2pネットワークプロトコルの小さな変更について説明しました。 Seanは、libp2pピアに大きなメッセージの送信を一時停止するように通知するために使用できる新しい「IDONTWANT」制御メッセージを強調しました。 Ryan氏は、このPRを統合するためにlibp2pチームと連絡を取り、さらに遅れがあれば、来週のACDE電話会議でこの問題を再検討すると述べました。