イーサリアムコア開発者最新会議の要約：Pectraの修正と準備、PeerDASの進展

原文タイトル：《Ethereum All Core Developers Consensus Call #139 Writeup

著者： Christine Kim

編纂： Ladyfinger ， BlockBeats

編者按：

イーサリアムの全コア開発者コンセンサスコール（ACDC）は、イーサリアムのコンセンサス層（CL）、つまりビーコーチェーンの変更について議論し調整することに焦点を当てた、2週間ごとに開催される一連の会議です。第139回ACDC電話会議は、イーサリアム財団（EF）の研究員アレックス・ストークスが主催し、会議の内容はPectra Devnet 2の修正、Devnet 3の準備、PeerDASの実施進捗、そしてイーサリアムノード分布に関する新しいデータを含んでいます。

会議中、開発者たちはPectra Devnet 2の安定性と存在する問題を審議し、今後のDevnet 3の準備作業について議論し、PeerDASの実施進捗について深く掘り下げました。また、EIP 7688の提案も参加者の広範な議論を引き起こしました。この提案は、イーサリアムのデータシリアライゼーション方法の潜在的な変更をサポートするために、前方互換性のあるデータ構造を導入することを目的としています。Galaxy Digitalの研究副社長クリスティン・キムがこの会議の詳細な記録を行い、BlockBeatsが原文を以下のように編纂しました：

2024年8月8日、イーサリアムの開発者たちはZoomを通じて第139回コア開発者コンセンサス電話会議（ACDC）を開催しました。ACDC電話会議は2週間ごとに開催され、開発者たちはここでイーサリアムのコンセンサス層（CL）、すなわちビーコーチェーンの変更について議論し調整します。今週の電話会議はイーサリアム財団（EF）の研究員アレックス・ストークスが主催しました。開発者たちはPectra Devnet 2の修正、Devnet 3の準備、PeerDASの実施進捗、そしてイーサリアムノード分布に関する新しいデータについて議論しました。

Pectra 更新

ストークスは、EFの研究員Hsiao Wei WangがPectraコンセンサス層（CL）仕様の公式更新版alpha.4を近日中にリリースする予定であることを発表しました。このバージョンには前のバージョンに対する多くの改善が含まれています。

Pectra Devnet 2に関する話題について、EFの開発者運営エンジニアバルナバス・ブサは、ネットワークは安定しており、85%のネットワーク参加率に達していると述べました。実行層（EL）クライアントには解決すべき小さな問題がいくつか残っており、主にEthereumJSとErigonに関連しています。ほとんどのCLクライアントはDevnet 2上で安定しています。しかし、ブサはPrysmクライアントに関してさらなる調査が必要な小さな問題を指摘しました。EFのDevOpsエンジニアパリトシュ・ジャヤンティは、Lighthouse、Teku、Besuノード間の問題についてもクライアントチームによる調査が必要であると補足しました。

その後、開発者たちはdevnetの立ち上げに関するコミュニケーションプロセスを改善する方法について議論しました。Prysmの開発者ケイシー・カークハムはZoomチャットでDevnet 2の立ち上げ時間について知らなかったことを指摘しました。Devnet 3の立ち上げ情報がすべてのクライアントチームに正確に伝わるようにするため、開発者たちはPectraのテスト進捗を更新するための定期的な週次会議を設けることを決定しました。具体的な時間はまだ決まっていませんが、これらの会議は毎週月曜日に開催される予定で、Dencunアップグレード前のテスト電話会議に似ています。ジャヤンティは、これらの会議は短く効率的で、15〜30分の間に制限され、Pectra関連のdevnetテスト更新、PeerDASやEOF devnetなどの議題に焦点を当てることを提案しました。

Pectra Devnet 3の議題について議論する際、開発者たちはそれがDevnet 2と同様のEIP構成を引き継ぐことを再確認しました。さらに、Devnet 3は最新設計のEIP 7702を初めて統合し、チームはPectraコアEIPとの互換性を確保するために詳細なテストを行う予定です。Lodestarチームのガジンダー・シンは、Devnet 2で発見されたEIP 7251、すなわちMaxEB提案の問題について言及し、デバッグが行われたものの、次のPectra devnetで解決策を検証するためにさらに深いテストが必要であると述べました。

ACDE #193で議論されたように、新しいEngine API仕様があり、これによりCLクライアントはEL blobトランザクションメモリプールからblobを取得できます。この方法は「getBlobsV1」と呼ばれています。乱用を避けるために、Tekuの開発者エンリコ・デル・ファンテはCL仕様に対するいくつかの明確化を提案しました。ストークスは開発者たちにこれらの明確化を検討するよう提案し、Pectra Devnet 3でこの方法の使用をテストする計画を立てました。

開発者たちはmplexプロトコルの廃止について議論しました。MplexはCLクライアントが単一の通信リンクで複数のデータストリームを送信するために使用されていたプロトコルですが、現在はその維持者によって廃止されています。クライアントチームはyamuxのような新しいデータストリーム多重化技術に移行する計画を立てています。Lodestarのフィル・ンゴは、彼らがyamuxの統合とテストを完了し、新しいプロトコルに直接移行することを好むと発表しました。これは、2つのプロトコルを長期間維持することがクライアントの運用コストを増加させるためです。Nimbusのエタン・キスリングも、彼らのチームがyamuxをテストしていることを明らかにしました。開発者たちは、他のCLクライアントチームのプロトコル移行に関する進捗を引き続き注視し、今後数ヶ月内にmplexから新しい多重化器への移行戦略を再評価する計画を立てました。

エタン・キスリングはPectraの議題においてEIP 7688についての議論を提起しました。この提案は、スマートコントラクト開発者がイーサリアム実行層（EL）のデータシリアライゼーション方法をRLPからSSZに移行する際に、前方互換性のあるデータ構造を導入することを目的としています。Pectraアップグレード自体はSSZを完全に実現するわけではありませんが、EIP 7688の提案はPectra EIPがデータ変更において前方互換性を持つことを確保するためのものです。

アレックス・ストークスは、PectraアップグレードにEIP 7688を追加することに対して慎重な姿勢を示し、アップグレードの規模がすでにかなり大きいと考えています。パリトシュ・ジャヤンティは会議中に、EIP 7688は最も早くDevnet 5でテストされる可能性があると述べました。Lodestar、Prysm、Teku、Lighthouseなどのチームの代表はこの提案に支持を表明しました。ストークスとベイコは、すべての既存のPectra EIPが安定状態に達するまで、新しいEIPをPectraに追加することを避けるべきだと提案しました。キスリングはこの提案を受け入れ、この議題を再度議論するのに最適なタイミングについて尋ねました。具体的な回答は得られませんでしたが、チームは一般的にPectra Devnet 5の立ち上げ前にEIP 7688を再評価すべきだと考えています。

PeerDAS 更新

Prysmクライアントチームの代表は会議でPeerDAS実施の最新進捗を報告し、「blob sidecar」Engine APIリクエストの必要性についての議論を引き起こしました。アレックス・ストークスは次回のPeerDASグループ会議でPeerDASがEngine APIに必要な調整について深く議論することを提案しました。彼はまた、EFの研究員が正式な仕様を草案しており、PeerDASからサンプリングメカニズムを削除することを提案して、アップグレードプロセスの複雑さを軽減することを目的としていることを指摘しました。しかし、最近のPeerDASグループ会議では、参加者はこの措置が将来的にハードフォークを通じてサンプリングを再導入する難易度を増加させる可能性があることを懸念しました。また、サンプリングメカニズムの削除がPectraにおけるblobガス制限の安全性の向上に与える影響は不明です。実行層（EL）とコンセンサス層（CL）内のblobガス制限をデカップリングする提案、EIP 7742が今週の電話会議で再度提起されました。ストークスはこのEIPを更新し、次回のCL電話会議でその導入の可能性とPectraにおけるblobガス制限の調整に関連する議題について議論する計画を立てています。

研究更新

今週の電話会議では、開発者たちは3つの研究議題に集中して議論しました。まず、彼らはEIP 7251の下で、検証者が質権ETH残高を統合する際に遭遇する可能性のあるエッジケースについて探討しました。エタン・キスリングは、検証者の残高が統合中に長時間更新されない可能性があり、これがプロトコルによって同期委員会の責任が誤って割り当てられる原因となる可能性があると提起しました。これに対して、アレックス・ストークスは、この問題はプロトコルが検証者の退出を処理する状況に類似していると応じ、コンセンサス層（CL）仕様にこのエッジケースを記録することを提案しましたが、既存の統合設計を変更することはありません。

次に、開発者たちはイーサリアムネットワーク層の変更、特に「quic ENR entry」の導入について議論しました。Quicは高速UDPインターネット接続を表し、ノードがデータを送受信するのを助けます。ストークスはGitHub上でプルリクエスト（PR）を作成し、quic ENR entryの具体的な変更をさらに詳しく説明することを提案しました。

最後に、ProbeLabはイーサリアムネットワークのノード運用状況に関する継続的な分析を共有しました。報告によると、現在8335ノードがイーサリアムネットワーク上で運用されており、その42%がLighthouseクライアントを使用しています。アメリカで運用されているノードは総数の36%を占め、約半数のノードがデータセンターに展開されています。Prysmの開発者「Potuz」は、データセンターでホスティングされているLighthouseノードの数が自己ホスティングノードを上回っている現象に対して好奇心を示しました。ストークスは、これはLighthouseクライアントの主要なユーザー層が機関や専門のノード運営者を含むためであると推測しました。

会議の終わりに、Potuzは彼が提出した実行有効荷重構造の調整に関するPRをチームにレビューするよう促しました。この提案は前回のACDC電話会議で初めて提起されました。Potuzは迅速な意思決定の重要性を強調し、これらの変更が概念的には簡単に理解できるものであるにもかかわらず、コンセンサス層（CL）仕様に統合することは非常に挑戦的であると指摘しました。彼は開発者たちにこの作業を早期に開始することを提案しました。