イーサリアムコア開発者最新会議の要約：PeerDASの有効化、blobガス制限の引き上げ

元タイトル：《Ethereum All Core Developers Consensus Call #135 Writeup》

著者：Christine Kim

翻訳：Luccy，BlockBeats

編集者注：イーサリアムの全コア開発者コンセンサスコール（ACDC）は、2週間ごとに開催され、主にイーサリアムのコンセンサス層（CL）の変更について議論し調整します。今回はACDC第135回電話会議で、Pectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize (SSZ) イーサリアム改善提案（EIPs）のテストネットの準備に主に焦点を当てました。

開発者たちは、ソフトウェアパッケージのメンテナンス、EIPの包括プロセス、新しいイーサリアムコンセンサス層のアップグレードの命名などの議題について深く議論しました。また、Electra仕様に基づく実装の進捗、PeerDASネットワークの変更がイーサリアムノードのデータ処理と検証に与える影響、blobガス制限の増加に関する複雑なエンジニアリングの問題についても言及されました。

Galaxy Digitalの研究副社長Christine Kimは、会議の要点を詳細に記録し、BlockBeatsが原文を以下のようにまとめました：

2024年6月13日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Consensus (ACDC) Call #135会議に参加しました。ACDC電話会議は、イーサリアム財団の研究員Alex Stokesが主催する2週間ごとのシリーズ会議で、開発者たちはイーサリアムのコンセンサス層（CL、別名信標チェーン）の変更について議論し調整します。今週、開発者たちはPectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize（SSZ）イーサリアム改善提案（EIPs）のための第三の専用テストネットの準備作業について議論しました。

お知らせ

開発者たちは2つのお知らせで会議を開始しました。イーサリアム財団の開発運営（DevOps）エンジニアParithosh Jayanthiは、イーサリアム財団の開発運営（EF DevOps）で働くエンジニアチームであるethPandaOpsチームが、ethereum-package Kurtosisモジュールのメンテナンスと開発を引き継ぐことを発表しました。このソフトウェアパッケージは、開発者がイーサリアムのテストネットや、さまざまなクライアント実装を監視およびテストするためのGrafanaデータダッシュボードなどの関連ツールを起動するために使用されてきました。Kurtosis技術チームからethPandaOpsチームへの移行の過程で、ユーザーに影響を与える可能性があるため、いくつかのリンクがethPandaOpsチームが管理するGitHubリポジトリにリダイレクトされることになります。Jayanthiは、ユーザーにソフトウェアリンクを更新し、ethPandaOpsチームがリリースする新しいバージョンに注意を払うように提案しました。

2つ目のお知らせは、イーサリアム財団のプロトコルサポート責任者Tim Beikoによって発表されました。Beikoは、EIPsを段階的にイーサリアムのアップグレードに組み込む新しいプロセスを導入するために努力していると述べました。彼は、「Proposed for Inclusion」（提案された含有）、「Considered for Inclusion」（考慮された含有）、「Scheduled for Inclusion」（予定された含有）というラベルを定義した草案EIPを作成しました。彼は開発者たちにこの文書をレビューし、フィードバックを提供するように希望しています。彼は次回のACD会議前にこの文書を完成させたいと考えています。

Electra

次のElectraの主要バージョンv1.5.0-alpha.3のコード仕様がまもなく完成します。開発者たちは、コンセンサス仕様のGitHubリポジトリにあるプルリクエスト（PR）#3768を次のバージョンにマージすることに合意しました。このプルリクエストはNimbusの開発者Etan Kisslingによって作成され、「committee_bits」フィールドは「Attestation」の末尾に追加されるべきであり、データの中間ではなく、データのシリアル化の問題を回避するためであると指摘しました。PR #3768に加えて、Stokesは次のElectra仕様の主要バージョンリリース前に解決すべき未解決の問題が他にあるかどうかを尋ねました。JayanthiはZoomチャットで、実行層（EL）によってトリガーされたバリデーター統合にいくつかの未解決の問題があることを言及しました。Stokesは会議後にELトリガーによるバリデーター統合の状態をフォローアップすることを記録しました。

最新のElectra仕様の実装進捗について、会議に出席したほとんどのコンセンサス層（CL）クライアントチームは、v1.5.0-alpha.3が最終決定された後、1〜2週間以内に新しいバージョンをテストする準備が整うと述べました。開発者たちは数週間後に次のPectra開発ネットワークPectra Devnet 1のスケジュールについて再度議論することに合意しました。

PeerDAS

次に、開発者たちはPeerDASの実装進捗について議論しました。PeerDASはイーサリアムのネットワーク改善であり、ノードがユーザーがblobトランザクションを通じて提出する大量の任意データを処理および検証する能力を強化します。Stokesは、前回のACDC会議での決定を振り返り、開発者たちは他のPectra EIPsと並行してPeerDASを開発し、開発ネットワーク上でPeerDASの個別のアクティベーションサイクルを有効にすることを実現することに合意しました。

Lodestarの開発者Gajinder Singhは、最近のPeerDASに関するグループ会議の議論に基づき、開発者たちはDenebアップグレードに基づいて、他のPectra EIPsとは別の開発ネットワーク上でPeerDASを有効にすることを述べました。Tekuの開発者Enrico Del Fanteは、開発者たちは以前のイーサリアムアップグレードDenebで確定された安定したコード仕様の上にPeerDASを構築する方が、変化し続けるPectraコード仕様の上に構築するよりも容易であると述べました。Jayanthiは、現在PeerDASの実装を他のPectra EIPの実装と統合することは、特にエラーの原因を特定しようとする際にテストプロセスで複雑な問題を引き起こす可能性があることに同意しました。彼は、これらの2つのワークフローを分け、両者の実装がより安定した後に統合することを提案しました。Stokesは同意し、開発者たちは約1か月後にPeerDASと他のPectra EIPの実装を統合する件について再度議論できると述べました。

PeerDAS Devnet 1の立ち上げに関する話題では、クライアントチームはテストネットの立ち上げの準備が整う時期について明確な見積もりを持っていませんでした。会議に出席した個人の見積もりはおおよそ2週間から1か月の間でした。Stokesは、数週間後にクライアントチームがPeerDASの実装にもっと時間をかけることができるときに、開発ネットワークのスケジュールについて再度議論することを提案しました。

その後、Beikoは、PeerDASがネットワーク改善であり、イーサリアムのコアプロトコルの変更ではないが、それでもPectraアップグレードのメタEIPにコードの変更を含めたいと述べました。メタEIP文書は、イーサリアムのアップグレードに含まれるすべてのコアプロトコルの変更をリストする公共の文書です。Beikoは、PeerDASがPectraの「最大の特徴」であり、ハードフォークのアクティベーションは必要ないが、開発者たちがPectraメインネットのアクティベーションに向けて準備が整っていることを示すために文書に含めるべきであると指摘しました。これに異議はありませんでした。

blobガス制限の引き上げ

PeerDASは、ノードがイーサリアムのピアネットワーク層を通じてデータを処理および伝播する方法を変更しました。ユーザー、特にLayer-2ロールアップがこれらの変更の恩恵を受けるためには、開発者は現在のブロックごとの6つのblobの制限をより高い閾値に引き上げる必要があります。これにより、より高いblob（任意データ）のスループットが可能になります。blob制限の変更は、開発者が今週の会議で議論したように、イーサリアムのコアプロトコルに変更を加える必要があり、単純にプロトコル技術スタック内の定数値を調整するよりも複雑なエンジニアリング作業が含まれる可能性があります。

Stokesは、blobガス制限を変更する際に、実行層（EL）とコンセンサス層（CL）間の依存関係を分離することを提案しました。現在、blobガス制限の変更はELとCLプロトコルの両方の変更を必要とします。Stokesは、開発者がELからハードコーディングされたblobガス制限を安全に削除し、完全にCLによって決定されるようにするために、これらの依存関係を打破するいくつかの方法を提案しました。イーサリアム財団（EF）の研究員Dankrad Feistは、ELとCLの間の依存関係の問題に加えて、blobガス制限の変更がブロックのガス計算に与える連鎖反応も重要であると指摘しました。Feistは、「最良の方法は計算方法を変更することです。ガス価格の計算がELで行われるのは誤りかもしれません。それはCLで行われるべきですが、今変更するのは難しいです。……これは簡単ではありません。」

開発者たちは、blobガス制限とブロック内のガス計算の変更の最良の方法を調査し続けることに同意しました。開発者たちはまた、PectraでPeerDASをアクティブにする際にblobガス制限が増加するかどうかについても議論を続けることに同意しました。開発者たちは、これらの変更を一緒に組み合わせるべきか、それとも複数のハードフォークで段階的に実施すべきかについて意見が分かれました。

Jayanthiは、これらの変更を組み合わせることは「リスクのある」決定であると述べ、開発者がPeerDASがメインネットでアクティブになる前にその具体的な機能パフォーマンスを知らないからです。イーサリアム財団（EF）DevOpsエンジニアBarnabas Busaは、Pectraハードフォークの範囲がすでに非常に大きく、追加のコード変更を加える必要はないと補足しました。Busaは、「重要なのは、すでに多くのEIPがあることで、私たちは常にもっと多くの内容を追加しており、これが永遠に続くことはありません。したがって、どこかで線を引かなければならず、これが私たちの終点です。私は、今後1年半のテスト期間中にPeerDASをリリースし、blobの数を増やすことは不可能だと思います。」と述べました。

「Francesco」というスクリーン名の開発者は、ネットワークの変更がblobの数の増加を伴わない場合、PeerDASを削除して「Pectraのリスクを低減」できると提案しました。Francescoは、「blobの数を増やさない場合、PectraのPeerDASにはどんな利点があるのか？」と尋ねました。

PeerDASのテストの難しさをさらに説明するために、Jayanthiは、EIP 4844にblobを導入するテストが、イーサリアムメインネットでのblobの実際のパフォーマンスと影響を完全にシミュレートしていないことを指摘しました。Jayanthiは、「問題はテストネットが非常に難しいことです。私たちは確かに4844に関連する多くの素晴らしいテストを行いましたが、blobがメインネットでのパフォーマンスはテスト中のパフォーマンスとは完全に一致しません。私たちは確かに弱いノードが問題を抱えるのを見ました。私たちは確かに時間的な課題などの類似の状況を見ました。これが、たとえ私たちが開発ネットワークでPeerDASとblobの数を増やすことが正常に機能する完璧な状況をシミュレートできたとしても、メインネットには実際の意味がないと考える主な理由です。」と述べました。

EFの研究員Ansgar Dietrichsは、blobの数の増加とPeerDASを関連付けるのは誤りであるとコメントしました。なぜなら、PeerDASだけでも開発者がblobの数値を選択する必要があるからです。開発者はイーサリアムメインネットと同じ数字を選択できますが、PeerDASが使用すべき数字の決定は行われなければなりません。同じ数字を選択する唯一の理由は、開発者がPeerDASの複雑さを増し、エラーが発生した場合に現在のDeneb仕様のblob伝播メカニズムにロールバックできるようにするためです。Dietrichsは、テストの複雑性に関する懸念が、Pectraが2つのハードフォークでアクティブにされるべきだという彼の見解をさらに強化したと付け加えましたが、これはPeerDASがblobの数の変更と分離されるべきだとは考えていないことを意味します。

SSZの更新

Kisslingは、SSZに関連する3つのEIPの進捗更新を共有しました。彼は、これらのEIPの実装作業がTeku、Grandine、Lighthouseを含む複数のクライアントで展開されていることを指摘しました。彼は、開発者がこれらのSSZ EIPの開発ネットワークのタイムラインについて議論を開始し、次回のACDC会議でそれらをPectraアップグレードの範囲に含める可能性があると述べました。

F-Starの命名

Ethereum Magiciansに投稿された記事では、Electraの後の次のイーサリアムコンセンサス層（CL）アップグレードの名前について議論されました。開発者たちは、Pragueの後の実行層（EL）アップグレードの名前を大阪（Osaka）に決定しました。候補のCLアップグレード名には、Fulu、Felis、Formosa、Funiがあります。これらの名前は、Beacon Chainの第6回全体ネットアップグレードに適用される「F」で始まる主要恒星の命名慣習に従っています。Stokesは、通話中の開発者にMagiciansの投稿でこの話題について意見を述べるように求めました。