クリスティン・キム著
編集者: Luccy、BlockBeats
編集者注: イーサリアムのオール コア開発者コンセンサス コール (ACDC) は、イーサリアム コンセンサス レイヤー (CL) への変更について話し合い、調整するために 2 週間ごとに開催されます。これは 135 回目の ACDC カンファレンスコールであり、主に Pectra Devnet 1、PeerDAS Devnet 1、および Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP) のテスト ネットワークの準備に焦点を当てています。
開発者は、ソフトウェア パッケージのメンテナンス、EIP の組み込みプロセス、イーサリアム コンセンサス レイヤーのアップグレードの新しいラウンドの命名などの問題について徹底的な議論を行いました。さらに、セッションでは、Electra 仕様に基づく実装の進捗状況、Ethereum ノードがデータを処理および検証する方法に対する PeerDAS ネットワークの変更の影響、BLOB ガス制限の増加を巡る複雑なエンジニアリングの問題についても触れられました。
Galaxy Digital のリサーチ担当副社長である Christine Kim は、この会議の要点を詳細に記録し、原文を次のようにまとめました。
2024 年 6 月 13 日、イーサリアム開発者は All Core Developers Consensus (ACDC)Call#135会議のために Zoom に集まりました。 ACDC コールは、イーサリアム財団の研究者アレックス・ストークスが主催する隔週シリーズで、開発者がイーサリアム コンセンサス レイヤー (CL、ビーコン チェーンとも呼ばれる) への変更について話し合い、調整します。今週、開発者らは、Pectra Devnet 1、PeerDAS Devnet 1、および Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP) の 3 番目の専用テスト ネットワークの準備について話し合いました。
発表
開発者は 2 つの発表でミーティングを開始しました。イーサリアム財団 DevOps エンジニアのパリトシュ ジャヤンティ氏は、イーサリアム パッケージ Kurtosis モジュールのメンテナンスと開発は、イーサリアム財団 DevOps (EF DevOps) で働くエンジニアのグループである ethPandaOps チームが引き継ぐと述べました。このパッケージは、開発者が過去にイーサリアム テスト ネットワークや、さまざまなクライアント実装を監視およびテストするための Grafana データ ダッシュボードなどの関連ツールを起動するために使用されてきました。 Kurtosis 技術チームから ethPandaOps チームへのこのパッケージの移行は、一部のリンクが Kurtosis チームではなく ethPandaOps チームによって管理される GitHub リポジトリにリダイレクトされるため、ユーザーに影響を与える可能性があります。 Jayanthi 氏はユーザーに対し、ソフトウェア リンクを更新し、ethPandaOps チームからの新しいリリースに注目するようアドバイスしています。
2 番目の発表は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコ氏によって行われました。ベイコ氏は、段階的にイーサリアムのアップグレードにEIPを含める新しいプロセスの導入に取り組んでいると述べた。彼は、「含める予定」、「含める予定」、および「含める予定」というラベルを定義する EIP 草案を作成しました。同氏は、開発者がこのドキュメントを確認してフィードバックを提供してくれることを望んでいます。同氏は、次回のACD会議までに文書を完成させたいと考えていた。
エレクトラ
Electra の次のメジャー バージョン v1.5.0-alpha.3 のコード仕様がほぼ完成しました。開発者は、コンセンサス仕様 GitHub リポジトリのプル リクエスト (PR)#3768を次のバージョンにマージすることに同意しました。このプルリクエストは、Nimbus 開発者の Etan Kissling によって作成されました。彼は、データのシリアル化の問題を避けるために、「committee_bits」フィールドをデータの途中ではなく「Attestation」の末尾に追加する必要があると指摘しました。 PR#3768に加えて、Stokes 氏は、Electra 仕様の次のメジャー バージョンがリリースされる前に解決する必要がある未解決の問題が他にもあるかどうかを尋ねました。 Jayanthi 氏は Zoom チャットで、実行層 (EL) を通じてトリガーされるバリデーターの統合にはいくつかの未解決の問題があると述べました。ストークス氏は、会議後、EL によって引き起こされるバリデーター統合の状況をフォローアップすることをメモしました。
最新の Electra 仕様の実装進捗状況に関して、会議に出席したコンセンサス層 (CL) クライアント チームのほとんどは、v1.5.0-alpha.3 後 1 ～ 2 週間以内に新しいバージョンをテストできる状態にできると述べました。が確定されます。開発者らは、次の Pectra 開発ネットワークである Pectra Devnet 1 のタイミングを数週間以内に再検討することに同意しました。
PeerDAS
次に、開発者は PeerDAS の実装の進捗状況について話し合いました。 PeerDAS は Ethereum のネットワークを改良したもので、BLOB トランザクションを通じてユーザーが送信した大量の任意のデータを処理および検証するノードの能力を強化します。 Stokes 氏は、開発ネットワーク上で PeerDAS の個別のアクティベーション サイクルをアクティブにすることで、開発者が他の Pectra EIP と並行して PeerDAS を開発するという前回の ACDC 会議での決定を思い出しました。
Lodestar 開発者の Gajinder Singh 氏は、PeerDAS に関する最近の分科会セッションでの議論に基づいて、開発者は Deneb アップグレードに加えて、他の Pectra EIP とは別の開発ネットワーク上で PeerDAS をアクティブ化することになると述べました。 Teku開発者のEnrico Del Fante氏は、開発者にとっては、常に変化するPectraのコード仕様ではなく、以前のイーサリアムアップグレードのDenebですでに確立された安定したコード仕様に基づいてPeerDASを構築する方が簡単だと述べた。 Jayanthi 氏は、現在 PeerDAS 実装を他の Pectra EIP 実装とマージすると、テスト中に、特にエラーの原因を特定しようとするときに複雑さが発生する可能性があることに同意しました。同氏は、2 つのワークフローを分離しておき、実装がより安定したら統合することを提案しました。 Stokes氏もこれに同意し、開発者は約1カ月以内にPeerDASと他のPectra EIP実装のマージを再検討できると述べた。
PeerDAS Devnet 1 の立ち上げに関しては、クライアント チームはテストネットの立ち上げ準備がいつ整うかについて明確な見積もりを持っていません。セッションでの個別の見積もりは、およそ 2 週間から 1 か月の範囲でした。 Stokes 氏は、クライアント チームが PeerDAS 実装に取り組む時間がより多く取れる数週間以内に、ネットワーク開発のスケジュールを再検討することを提案しました。
次にベイコ氏は、PeerDAS はコアのイーサリアム プロトコルの変更ではなくネットワークの改良であるが、それでもコードの変更が Pectra アップグレードのメタ EIP に含まれることを望んでいると指摘しました。メタ EIP 文書は、イーサリアムのアップグレードに含まれるすべてのコア プロトコルの変更をリストした公開文書です。 Beiko 氏は、PeerDAS は Pectra の「最大の機能」であり、ハード フォークのアクティベーションは必要ありませんが、開発者が Pectra メインネットのアクティベーションに間に合うよう真剣に準備していることを示すために、ドキュメントに含める必要があると指摘しました。これには異論はありません。
BLOB ガス制限を増やす
PeerDAS は、ノードが Ethereum ピアツーピア ネットワーク層を通じてデータを処理および伝播する方法を変更します。ユーザー、特にレイヤー 2 ロールアップがこれらの変更の恩恵を受けるには、開発者はブロックあたり 6 BLOB という現在の制限をより高いしきい値に増やす必要があります。これにより、BLOB (任意のデータ) のスループットが向上します。 BLOB 制限を変更するには、イーサリアム コア プロトコルの変更が必要になります。開発者らが今週のカンファレンスで議論したように、これには、プロトコル スタック内の定数値を単に調整するだけではなく、より複雑なエンジニアリング作業が必要になる可能性があります。
Stokes 氏は、ブロブ ガス制限を変更する際に、実行層 (EL) とコンセンサス層 (CL) の間の依存関係を切り離すことを提案しました。現在、ブロブ ガス制限を変更するには、EL および CL プロトコルを変更する必要があります。 Stokes 氏は、これらの依存関係を解消し、開発者がハードコードされた BLOB ガス制限を EL から安全に削除し、完全に CL に任せられるようにする方法を提案しました。イーサリアム財団（EF）の研究者ダンクラッド・ファイスト氏は、ELとCLの間の依存関係の問題に加えて、ブロブのガス制限を変更することによるブロックのガス計算への波及効果も重要であると指摘した。 「最善のアプローチは、計算方法を変更することだ」とファイスト氏は語った。「ガス価格の計算がELで行われるのはおそらくバグだ。それはCLにあるはずだが、今は変更するのが難しい。...簡単ではない。 」
開発者は、ブロブのガス制限とブロック内のガス計算を変更するための最良の方法を引き続き調査することに同意しました。開発者はまた、Pectra で PeerDAS をアクティブ化すると、ブロブ ガス制限の増加が伴うかどうかについて議論を続けることに同意しました。開発者は、変更をまとめてロールアウトするか、複数のハード フォークにまたがって段階的に実装するかについて意見が分かれています。
Jayanthi 氏は、PeerDAS がメインネットでアクティブ化されるまで、開発者は PeerDAS がどのように動作するかを正確に知ることができないため、これらの変更を組み込むことは「危険な」決断であると述べました。イーサリアム財団 (EF) の DevOps エンジニアである Barnabas Busa 氏は、Pectra ハード フォークの範囲はすでに非常に大きく、追加のコード変更は必要ないと付け加えました。 「重要なのは、私たちはすでに多くのEIPを持っており、さらに追加し続けると終わりがないように感じます」とブサ氏は言いました。今後 1 年半のテスト中に PeerDAS をリリースして BLOB の数を増やすことが可能です。」
スクリーンネームが「Francesco」である開発者は、ネットワークの変更が BLOB の数の増加を伴わない場合、「Pectra のリスクを軽減する」ために PeerDAS を削除できると提案しました。 Francesco 氏は、「BLOB の数が増えない場合、Pectra の PeerDAS には具体的にどのようなメリットがあるのでしょうか?」と尋ねました。
PeerDAS のテストの難しさをさらに説明するために、Jayanthi 氏は、イーサリアムに BLOB を導入した EIP 4844 のテストでは、イーサリアム メインネットにおける BLOB の実際のパフォーマンスと影響を完全にはシミュレートしていないと指摘しました。 Jayanthi 氏は次のように述べています。「問題は、ネットワークをテストするのが非常に難しいということです。4844 に関連する優れたテストは数多くありましたが、BLOB はテストで確認したものとまったく同じには動作しませんでした。質問: タイミングの問題などが発生するため、PeerDAS が動作する完璧な状況をシミュレートできても、BLOB の数が増加しても実際的な影響はありません。つまり、これが、一度にすべてを行うのではなく、段階的に行うべきだと私が考える主な理由です。」
EF 研究者の Ansgar Dietrichs 氏は、PeerDAS だけでもすでに開発者が BLOB カウント値を選択する必要があるため、BLOB 数の増加を PeerDAS と関連付けることは間違いであるとコメントしました。開発者はイーサリアムメインネットと同じ番号を選択できますが、PeerDAS がどの番号を使用するかを決定する必要があります。同じ番号を選択する唯一の理由は、開発者がエラー発生時に現在の Deneb 仕様の BLOB 伝播メカニズムにフォールバックできるようにするために PeerDAS の複雑さを高めたことです。 Dietrichs 氏は、テストの複雑さへの懸念により、Pectra は 1 つではなく 2 つのハード フォークでアクティブ化されるべきだという彼の見解をさらに強めていますが、だからといって PeerDAS を BLOB 数の変更から切り離すべきだと考えているわけではないと付け加えました。
SSZアップデート
Kissling は、3 つの SSZ 関連 EIP に関する進捗状況を共有しました。これらの EIP の実装は、Teku、Grandine、Lighthouse などの複数のクライアントですでに進行中であると同氏は述べました。開発者らはこれらのSSZ EIPの開発ネットワークスケジュールについて議論を開始し、次回のACDC会議でPectraアップグレードの対象に含める可能性があると同氏は述べた。
Fスターのネーミング
Ethereum Magicians には、Electra の後の次の Ethereum コンセンサス レイヤー (CL) アップグレードの名前について議論する投稿があります。開発者は、エグゼクティブ レイヤー (EL) アップグレードの名前を、プラハ: 大阪にちなんで決定しました。 CL アップグレードの候補名は、Fulu、Felis、Formosa、Funi です。これらの名前は、「F」で始まるメジャー スター命名規則に従っており、ビーコン チェーンの 6 番目のネットワーク全体のアップグレードに適しています。ストークス氏は電話会議に参加した開発者に対し、マジシャンズ スレッドのトピックについて検討するよう求めました。