元のタイトル: 「イーサリアムの全コア開発者コンセンサスコール#120の書き込み」

原作者：クリスティーン・キム

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

最後の会議

10 月 19 日、イーサリアム開発者は All Core Developers Execution (ACDE) Call#120ミーティングのために Zoom に集まりました。 ACDE カンファレンスコールは、イーサリアム財団の研究者ダニー・ライアンが主催する隔週の一連の会議であり、開発者はイーサリアムコンセンサスレイヤー (CL) への変更について話し合い、調整します。今週、開発者は次のトピックの進捗状況に焦点を当てています。

1. CL 仕様のバージョン 1.4.0-beta.3。

2. Devnet-10 の起動条件。

3. Lodestar および EthereumJS クライアントを保守するソフトウェア開発者である Gajinder Singh による BLOB レイテンシー分析。

召喚

Danny Ryan は、「Summoning」と呼ばれる、カンクン/デネブ (デンクン) アップグレード用の新しい CL コード仕様のリリースを発表しました。このバージョンは、CL GitHub リポジトリで正式にバージョン 1.4.0-beta.3 としてマークされており、2 つの主な変更が含まれています。

1. メインネット KZG 構成: Ethereum Trusted Setup Ceremony の出力に必要なフォーマット作業を完了し、最新の CL 仕様リリースに組み込みました。

2. 新しいゴシップ ルール: Teku 開発者の Enrico Del Fante は、CL ノードがブロックあたりの最大ブロブ数 (現在仕様で定義されている 6 個) を超えて伝播しないようにする新しいゴシップ ルールを作成しました。これにより、バリデーターは、ブロックごとに 6 BLOB を超える無効なメッセージをネットワークにスパム送信できなくなります。

デブネット-10

CL 仕様のバージョン 1.4.0-beta.3 の変更は、次の開発ネットワークである Devnet-10 でテストされます。ただし、Devnet-10 を軌道に乗せるにはいくつかのハードルがあります。イーサリアム財団の DevOps エンジニアである Barnabas Busa 氏は、クライアント チームが新しいソフトウェア バージョンをリリースするのをまだ待っていると述べました。これらの準備が整ったら、ブサ氏は 10 月 20 日火曜日に次の開発ネットワークを立ち上げたいと考えています。

「Potuz」という仮名を使用する Prysm クライアントの開発者は、「go-kzg」に変更が加えられるまで、最新の CL 仕様に含まれるメインネット KZG 構成を Geth および Prysm にマージできないと指摘しました。 「go-kzg」は、KZG コミットメント スキームを Go プログラミング言語に実装する別個のコード リポジトリです。開発者らは電話会議で、go-kzg、Geth、Prysm リポジトリ間の依存関係について不満を表明しました。 Potuz 氏と他の開発者が EIP 4844 の KZG ライブラリの使用に関して課題を提起したのはこれが初めてではありません。

イーサリアム財団の DevOps エンジニアであるパリトシュ・ジャヤンティ氏は、開発者はメインネット KZG 構成や新しいクライアントのリリースなしで Devnet-10 を起動できるが、これは開発者が Devnet-10 で新しいコードをテストせず、代わりにリリースされたコードを Devnet-10 で再テストすることを意味すると述べました。デブネット-9。

今週の Devnet-9 で、開発者は CL クライアント実装の問題を発見しました。イーサリアム財団のテストチームのマリオ・ベガ氏は、バリデーターが無効なデータブロック（ブロブ）を適切に処理できなかったと説明した。 Vega氏は、バリデーターが悪意を持って有効なデータブロックを一部のノードにブロードキャストし、無効なデータブロックを他のノードにブロードキャストした場合、無効なデータブロックを受信したノードはチェーンの先頭を追跡できなくなると述べた。この問題に対処するために、これらの条件を簡単に再現し、新しいクライアント リリースに対してテストするハイブ テストが作成されました。これにより、開発者は問題の修正が機能しているかどうかをすぐに確認できるようになります。

この問題に関して、Enrico Del Fante 氏は、ブロック内の既存の BLOB コミットメントと一致しないインデックスを持つ 1 つ以上の BLOB がブロックに含まれている場合、Teku クライアントはそのブロックをインポートしないと述べました。イーサリアム財団の研究者であるダンクラッド・ファイスト氏は、無効なブロブを含むブロックを意図的に提案するバリデーターには、イーサリアム・ピアツーピア・ネットワークの計算負荷が増大する可能性と、ブロックを受信する一部のバリデーターが同期を失わせる可能性があること以外に利点はないと指摘しました。ネットワークを使って。 Feist氏は、そのような行為から金銭的な利益は得られず、たとえバリデーターがそうした行為を行ったとしても、イーサリアムのピアツーピア層にかかる追加の計算負荷はブロックあたりのブロブの最大数によって制限されるだろうと強調した。

それにもかかわらず、バリデーターがこのアクションを実行するのを防ぐために、開発者は新しいスラッシュ条件を追加する可能性について議論しています。新しいスラッシュ条件は、バリデーターがピアツーピア層に意図的にストレスを与えることを防ぐために、ブロックに無効な BLOB が含まれているかどうかを監視しようとします。しかし、イーサリアムバリデーターの経済学を変えるには調査と分析に多額の費用がかかるため、ライアン氏は、デンクンの次のアップグレードであるプラハ/エレクトラの文脈でこの提案をさらに議論することを提案しました。

Ryan 氏は、開発者は Dencun の CL 仕様でこの状況に適切な動作を設定でき、BLOB インデックスがブロックコミットメントと一致しない場合でも、バリデーターはブロックをインポートする必要があると付け加えました。彼は、バリデーターには、Del Fante が説明した方法で無効な BLOB を含むブロックを伝播する経済的インセンティブがないため、そのような不合理な動作による潜在的なネットワーク負荷は、ブロックあたりの BLOB の最大数によって最大限に制限されると主張しました。したがって、短期的には CL 仕様への軽微な変更で問題を解決できますが、開発者は将来のアップグレードに向けて、新しい削減条件など、より恒久的な解決策を検討できます。

Jayanthi と Ryan は、開発者がクライアント上でメインネット KZG 構成をセットアップし、Mario Vega によって提起された問題を解決するまで、少なくとも Devnet-10 は Prysm クライアント上で起動されないことを再確認しました。 Ryan 氏は、新しい削減条件に関する議論は、Dencun ではなく、Prague/Electra アップグレードの文脈でのみ行われ、無効な BLOB を含むブロックをインポートするための CL 仕様の変更が Devnet-10 の立ち上げの障壁になるべきではないと強調しました。 Prysm と Lighthouse のクライアント チームの代表者は、ソフトウェアのアップデートを明日 10 月 20 日にリリースすると述べました。

ブロック遅延解析

10月14日土曜日のシェアで、イーサリアムクライアントLodestarとEthereumJSのメンテナであるGajinder Singh氏は、ゴシップ伝播に基づいたBLOB数とブロックインポート待ち時間の関係についての新しい分析を共有しました。 Singh 氏は、Devnet-9 を使った実験で、バリデーターが受信した BLOB の数が増えると、ブロックの遅延が大幅に増加したと指摘しました。

以下の表は、Singh の調査結果をまとめたものです。最初の列には、到着した完全なブロックの割合がリストされ、表内の値はブロックのインポートにかかった秒数を表します。

チャンクのインポート待機時間 (秒単位) とチャンクに含まれる BLOB の数。出典: ガジンダー・シン、Twitter

Singh 氏は、ブロックごとに BLOB が 1 つだけあれば待ち時間は無視できるが、2 つを超えると大幅な待ち時間が発生するとツイートしました。ダンクラッド・ファイスト氏は、シン氏の分析データは、イーサリアムメインネット上で大規模なブロックを伝播する実験の結果とは大きく異なると述べた。 「このデータが正しいということはありえないようです」とFeist氏は主張し、BLOBはブロックと並行して処理されるため、BLOBの処理遅延をブロック時間に加算することは、メインネットのブロック伝播時間を予測する不正確な方法であると付け加えた。 BLOB によるブロック伝播に関する Singh の予測は、次の場所にあります。

Singh 氏は Twitter で、ブロックごとに BLOB が 1 つだけあれば待ち時間は無視できるが、2 つを超えるとかなりの待ち時間が発生すると述べました。しかし、ダンクラッド・ファイスト氏は、シン氏の分析データは、イーサリアムメインネット上で大規模なブロックを伝播する実験の結果とは大きく異なると指摘した。 「このデータが正しいように見えるわけがない」とFeist氏は主張し、BLOBはブロックと並行して処理されるため、メインネットのブロック伝播時間を予測するためにBLOB処理の待ち時間をブロック時間に加算するのは不正確な方法であると付け加えた。 BLOB によるブロック伝播に関する Singh の予測は、ここで見つけることができます。ファイストはシン氏の分析を「過度に悲観的」だと批判した。

意見の相違にもかかわらず、Feist 氏と Ryan 氏は、Singh の分析が他のクライアント チームにとって確かに参考になるものであることに同意しています。ライアンは、他の CL チームに、同様のデータと結果が得られるかどうかを確認するために、Devnet-9 でシンの実験を再現してみるよう勧めました。 BLOB 導入後のブロック レイテンシーに関する新しいデータがある場合、Ryan 氏は来週の ACDE コールでこのトピックを再検討することを提案しました。

「オリジナルリンク」