ETH Workshop Core Developersの最新ミーティングの概要:2024年1月上旬にテストネットでCancunアップグレードをアクティブ化する

原題:Ethereum All Core Developers ution Call #176 Writeup

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

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

編集部注:

ETH Workshop All Core Developer Consensus Calls (ACDE) は 2 週間ごとに開催され、ETH Workshop Execution Layer (EL) の変更について議論し、調整します。 これはACDEの176回目の電話会議であり、カンクン/デネブのアップグレード、Devnet #12のテストの進捗状況、およびプラハ/エレクトラのアップグレード計画に関する議論を取り上げます。

開発者は、Cancun/Deneb のアップグレードが Devnet #12 でどのようにテストされたかについて、進捗状況とさまざまなクライアント チームによって発見されたいくつかの問題、BLOB の伝播、MEV (Maximum Extractable Value) などの技術的な課題を含めて説明しました。 今後のプラハ/エレクトラのアップグレードのために、開発者は一連の可能な技術的変更を提案しました。

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

2023 年 12 月 7 日、Zoom for All Core Developers (ACDE) のコール #176 にETH開発者が集まりました。 ACDC電話会議は、ETH Foundationのプロトコルサポート責任者であるTim Beikoが主導する隔週の一連の会議で、開発者がETH Placeのエグゼクティブレイヤー(EL)の変更について議論し、調整します。 今週、開発者はDevnet #12でCancun/Denebアップグレードのテストについて議論しました。 彼らは、休暇が終わった後の1月上旬にGoerliテストネットワークでのアップグレードETHアクティブ化日を調整することに合意しました。 さらに、1月上旬には、次回のETHワークショップのアップグレードであるPrague/Electraにどのようなコード変更を含めるべきかについて、議論を開始する予定です。

Devnet #12 アップデート

Devnet #12 での Cancun/Deneb アップグレードのテストは順調に進んでいます。 FoundationのDevOpsエンジニアであるParithosh Jayanthi氏は、RetとLighthouseの2つのクライアントでいくつかのバグが発見され、2つのクライアントチームが緊急修正に取り組んでいることを明らかにした。 MEVワークフローをより徹底的にテストするために、DevOpsチームはDevnet #12のより多くのバリデーターでMEV-Boostソフトウェアを有効にすることに注力しています。 Jayanthi氏によると、彼のチームはFlashbotsのMEVリレー実装に少なくとも1つのバグを発見しました。 ETH財団の研究者であるDanny Ryan氏は、リレーに障害が発生した場合にバリデーターがローカルブロックビルドに切り替えられるようにするには、代替メカニズムをチェックするための追加のテストが必要であることを強調しました。

クライアント固有のチームアップグレードについては、Prysmクライアントの開発者であるTerence Tsao氏によると、彼のチームはACDC #122中讨论的 ブロブ伝播の更新された設計に取り組んでいるという。 Tsao氏は、Prysmクライアントが来週、おそらく来週、テストのためにDevnet #12に参加する準備ができていることを確認した。 Besuクライアントの開発者であるJustin Florentine氏は、BesuはDevnet #12から移行する準備ができていると述べた。 Nethermind、Erigon、Lodestar、Tekuのクライアントチームの代表者も、パブリックETHテストネットでアップグレードのテストを継続する準備ができていると述べました。

クライアントの準備状況に基づいて、Beikoは、開発者が休暇を終えたらすぐにハードフォークの日付を調整することをお勧めします。 Prysm クライアントが参加してから数週間以内に Devnet #12 で大きなバグが発見されないと仮定すると、Beiko 氏は Goerli での Cancun/Deneb のアクティベーションは 1 月中旬頃に発生する可能性が高いと述べています。 Teku チームの Ben Edgington 氏は、ブロックあたりのブロブの数を 2 から 3 に変更することに自信があるかどうかを開発者に尋ねました。 Ryan は、大規模なシャドウ フォークと Goerli での Cancun/Deneb のアクティベーション中に増加したブロブ ターゲットの追加テストを提案しています。 Beiko氏は、Goerliでのアップグレードアクティベーションが、ブロックごとの3つのブロブターゲットの「最後の重要なテスト」になることを確認しました。 問題が見つからなかった場合、開発者はメインネットのアクティベーションに増加した数のBLOBを引き続き使用します。

全体として、Beiko氏は、開発者は今から休暇の終わりまでの間、Devnet #12のアップグレードをテストし続けると述べた。 DevOpsチームは、1月の真のGoerliハードフォークに備えて、12月末までに少なくとも1つのGoerliシャドウフォークを立ち上げる予定です。 開発者が新年に集まる場合、Goerliハードフォークのアクティベーションの日付について話し合います。

ビルダーオーバーライドフラグ

次に、Tsao氏はクライアントチームに、ビルダーオーバーライドフラグの実装の進捗状況について尋ねました。 ビルダーオーバーライドフラグは、Cancunアップグレードの新しいブールフィールドであり、実行レイヤークライアントがコンセンサスレイヤークライアントに、ビルダーが検閲アクティビティを検出した場合、バリデーターがサードパーティのビルダーを使用する代わりにローカルブロック生成にフォールバックする必要があることを示すために使用できます。 Tsao氏が強調しているように、ビルダーのレビューアクティビティを検出する方法の実装の詳細は主観的であり、意図的にクライアントチームに設計を任せています。 ビルダーオーバーライドフラグの詳細については、ACDC#112およびACDE#165の議事録を参照してください。

「Lightclient」というスクリーンネームで通っているGethクライアントチームの開発者は、彼のチームがフラグを実装したが、「近い将来」の公式リリースでマージしないと述べた。 BesuとNethermindのチームの代表者は、このオプションのフラグはまだクライアントに実装されていないと述べました。 Tsao氏は、フラグは有用なツールであり、ステーキングプールや大規模なバリデータノードオペレーターが特定の「タイムゲーム」に参加するのを思いとどまらせるために、できるだけ早く実装するのが最善であると強調しました。 Tsao氏は、バリデーターはブロックの伝播を遅らせることでより多くのMEV(Maximum Extractable Value)を獲得でき、カンクンのアップグレード後にBLOBが導入された後は、ブロックの伝播に遅れが生じると説明しました。 これらの遅延の間、バリデーターは、より収益性の高いMEVトランザクションをブロックに含めることを選択する場合がありますが、これはタイムリーなBLOBの伝播には最適ではありません。

Prysmチームの仮名開発者(Potuzというスクリーンネーム)は、BLOBトランザクションが通常のトランザクションと競合することを確認した上で、「BLOBは手数料だけでなく、レイテンシー自体や、ブロックを遅らせることで得られるすべてのMEVとも競争する必要があります。 ブロブの手数料メカニズムを設計するとき、私はそれがブロックされていない、または考慮されていない市場だと思っていました。 Tsao氏は、さらなる議論のために、Ethereum Research Discordでこの問題を再び取り上げると述べました。 さらに、ライアンは、イーサリアム財団の研究者であるキャスパー・シュワルツ・シリング氏とマイク・ノイダー氏による、Ethresearchのウェブサイトに掲載された「タイミングゲーム」に関する最新の投稿を紹介しました。

プロジェクトの進捗

次に、Beiko氏は、ETHワークショップのアップグレード計画プロセスに関連する3つの最新情報を共有しました。 まず、ACDCの #123上讨论的那样 と同様に、Beikoはカンクン/デネブのアップグレードのためのメタEIP文書を作成し、カンクン/デネブに含まれるすべてのETH改善提案(EIP)をリストアップしました。 GitHub で EIP 番号 7569 で作成されています。 さらに、Beiko は以前のすべてのアップグレードの Meta EIP ドキュメントとして EIP 7568 を作成しましたが、開発者はアップグレードに含まれる EIP のリストを追跡するための専用ドキュメントを作成しませんでした。 EIP 7568 は、アップグレード コードの仕様にリンクされています。

次に、Beiko氏は、Ethereum MagiciansのWebサイトに新しいディスカッションスレッドを作成し、次のネットワークアップグレードであるPrague/Electraを特定したと発表しました。 彼は開発者に、過去2回のハードフォークのように、実行レイヤー(EL)とコンセンサスレイヤー(CL)のアップグレードをバンドルするかどうかについて批判的に考えるよう求めました。 EIP 7002 などの特定のコード変更を有効にするには、EL と CL の両方を変更する必要があるため、Prague と Electra の両方のアップグレードを調整する必要があります。 ただし、Verkle ツリーなど、その他のコード変更の場合は、実装を再設計する方法があり、CL をアップグレードするだけで済みます。

Ryan氏は、Verkleツリーと並行して作業しているコンセンサス層(CL)の開発者も、データの可用性サンプリングをサポートするためにコードを変更していると指摘した。 Beiko氏は、Prague/Electraのアップグレードで見たいすべてのEIPについて詳細に説明するのではなく、休暇中にすべての候補コードの変更を確認し、1月に真剣に議論する準備をするように開発者にアドバイスしています。 Potuz氏もこれに同意し、バリデーターのセットサイズという増大する問題に対処するために設計されたEIPはETHプラハ/エレクトラにおける重要なコード変更になるだろうと付け加えた。 コード変更の複雑さに基づいて、Beikoは、Verkleやデータ可用性サンプリングなどの特定のEIPについて、開発者が休暇後に専用の会議を開催して、これらの大規模なプロトコルの変更について詳細に話し合うことを推奨しています。