イーサリアムコア開発者最新会議の要約：Pectraアップグレードの開始、PeerDAS実装の進捗についての議論

原文标题：《Ethereum All Core Developers Consensus Call #138 Writeup》
作者：Christine Kim
编译：Ladyfinger，BlockBeats

編者按：
イーサリアム全コア開発者コンセンサスコール（ACDC）は、2週間ごとに開催され、主にイーサリアムのコンセンサスレイヤー（CL）に対する変更を議論し調整します。今回はACDC第138回電話会議で、Pectra Devnet 1の立ち上げ、信号ブロック体とエンジンAPI構造の変更、安定コンテナイーサリアム改善提案（EIPs）をPectraに組み込むこと、すなわちEIP 7688とEIP 7495、PeerDASの更新など、複数の議題が取り上げられました。会議中、開発者たちはPectraアップグレードの準備状況を審議し、PeerDAS実装に関するいくつかの未解決の問題と提案について議論しました。さらに、Nimbusの開発者エタン・キスリングはEIP 7688とEIP 7495の実施作業の進捗を共有し、これらの提案がイーサリアムのデータシリアル化方法のアップグレードにとって重要であることを強調しました。Galaxy Digitalの研究副社長クリスティン・キムは本会議の要点を詳細に記録し、BlockBeatsは原文を以下のように編纂しました：

2024年7月25日、イーサリアムの開発者たちはZoomを通じて第138回全コア開発者コンセンサス（ACDC）会議を開催しました。ACDC会議は2週間ごとに行われる会議シリーズで、開発者たちはこれらの会議でイーサリアムのコンセンサスレイヤー（CL）、すなわち信号チェーンの変更について議論し調整します。今週の会議はイーサリアム財団（EF）の研究員アレックス・ストークスが主催しました。開発者たちは以下の内容について議論しました：

· Pectra Devnet 1の立ち上げ

· 信号ブロック体とエンジンAPI構造の変更

· 安定コンテナイーサリアム改善提案（EIPs）をPectraに組み込むこと、すなわちEIP 7688とEIP 7495

· PeerDASの更新およびそのメインネットでの実施スケジュール

Pectra Devnet 1 Pectra

Devnet 1は7月23日火曜日にオンラインになりました。しかし、ネットワークは不安定です。イーサリアム財団の開発運営エンジニア、パリトシュ・ジャヤンティは、Erigonクライアントがdevnetの立ち上げ後すぐに問題に直面したと述べました。その後、devnet上でブロードキャストされたEIP 7702トランザクションがネットワークを3つの状態に分裂させました。開発者たちはクライアントをデバッグし、チェーン分裂の問題を解決しています。

ExecutionPayloadEnvelopeの導入

Prysmの開発者ポトゥズは、信号チェーンブロックの実行ペイロード構造に対する重要な改善と、それに伴うエンジンAPIの調整を提案しました。この提案は、コンセンサスレイヤー（CL）クライアントが状態遷移データを保存および処理するプロセスを簡素化することを目的としています。Pectraアップグレードの実施に伴い、CLクライアントは状態遷移を正しく実行するために実行ペイロードの特定の部分にアクセスする必要があります。しかし、既存の設計はこれらのクライアントが実行ペイロード内のいくつかの不要な情報を無視する原因となっています。

Pectraアップグレードは、CLクライアントが実行レイヤー（EL）から必要な状態遷移データを要求するか、ローカルにブロックの重要な部分を保存することを要求します。Pectraアップグレード後のCLクライアントの効率を向上させるために、ポトゥズは「bindedexecutionpayload_envelope」と呼ばれる新しい構造を導入することを提案し、実行状態遷移に必要な重要な情報を集中して保存します。このような改善は、CLクライアントが状態遷移を計算する際の速度と効率を大幅に向上させるでしょう。彼はまた、これらの調整が将来のネットワークアップグレード、例えばシンプルシリアル化（SSZ）形式との互換性を確保することを強調しました。

Lighthouseプロジェクトの開発者マーク・マッキーは、これらの変更を実施しなければ、CLクライアントのPectraテストネットでのパフォーマンスが影響を受ける可能性があると警告しました。Tekuプロジェクトの開発者ミハイル・カリニンはこれに対して慎重な姿勢を示し、Pectra内のEIPs実装の複雑さを解決するためにプロトコルを変更する必要が本当にあるのか疑問を呈しました。ポトゥズは、既存のプロトコル設計には根本的な問題があり、修正が必要だと主張しました。彼は「現在の設計は理念的に欠陥があり、CL状態遷移にとって重要なデータと完全に無関係なデータを同じレベル、同じメッセージで混在させています。したがって、私は現在の設計が間違っていると思い、この誤りを修正するために努力しています。」と述べました。

ストークスは、開発者たちにGitHubでこの提案についての議論を続けるよう促しました。

Devnet 2のエンジンAPI更新

上記の議論に関連して、Gethの開発者「Lightclient」はエンジンAPIに対する別の変更を提案しました。この変更は、ELクライアントがブロック変換をより容易に行えるようにすることを目的としています。ELクライアントは、ブロック内の空のフィールドと空のフィールドを解釈することでブロックのバージョンを特定します。しかし、プラハのEIP 7685により、フォークタイムテーブルがなければELクライアントはこれらのフィールドに基づいてブロックのバージョンを区別できません。過去のアップグレードのタイムテーブルを参照するオーバーヘッドを避けるために、LightclientはすべてのリクエストをエンジンAPI内の単一のタイプに統一し、ELがCLに渡して解釈させることを提案しました。

Lightclientは、ブロックの解釈がELとCLの間で異なることを指摘し、この場合CLがリクエストデータを表現するのに適していると述べました。「私たちがブロック自体を扱うとき、ブロックには『これはBellatrixブロックです。』という概念がありません。CL上でのように。異なるタイプのフォークブロックを区別するのは非常に良い仕事だと思います。しかし、EL上では、ほぼすべてのクライアント実装がこのように行っていると思います。私たちはすべてのブロックタイプを表すブロックを持っており、存在するもの、例えば値の空値を使用して、その[フォーク]がアクティブかどうかを判断しています。」

Nimbusの開発者「ダスティン」はこの提案に反対し、Lightclientの提案がELとCLでのブロック解釈の複雑さを十分に解決していないと述べました。「これは単にELからCLに複雑さと混乱を移すだけであり、両方の場所で機能します。CLに移すことは問題を解決することにはなりません。……それは単に問題を移動させただけです。」とダスティンは言いました。

ストークスは、CLがリクエストの解釈を処理するのに適していると主張し、開発者たちにポトゥズとLightclientがGitHubで提案したエンジンAPIの変更をより注意深く検討するよう提案しました。

PectraにおけるEIP 7688と7495

Nimbusの開発者エタン・キスリングは、イーサリアムのシリアル化方法をSSZに更新することを推進しています。Pectraの目的のために、彼はスマートコントラクト開発者が依存できるデータ構造を導入するための2つの中間EIPs、7688と7495を特定しました。これにより、将来のSSZ関連の変更と互換性を持たせることができます。キスリングは、Rocketpoolのような流動的なステーキングプールや、TekuやLodestarなどの他のクライアントチームからの支持を得ていることを指摘しました。

ストークスはCLクライアントチームにPectraに新しいEIPsを追加しないよう警告しました。「Pectraはすでに非常に大きいです。特に、最終的にフォークにPeerDASがある場合は。ある時点で、私たちはフォークの大きさとそれがもたらすリスクを非常に現実的に考える必要があります。もう一度言いますが、エタンが示したこの機能が真空の中で価値がある理由には同意しますが、これは私たちが行った中で最大のハードフォークの1つ、または最大のものであり、軽視されるべきではありません。」と彼は言いました。

開発者たちは、これらのEIPがPectra devnetにいつ実際に追加できるかについていくつかの懸念を表明しました。なぜなら、Pectra devnetにはPeerDASやEOFなどの多くのEIPがまだ組み込まれていないからです。これに対して、ジャヤンティはまず開発者がこれらのEIPをアップグレードに含めるべきかどうかを明確に決定することを提案しました。ジャヤンティはまた、CLとELのEIPを同じdevnetでテストする際にボトルネックが存在することを警告しました。彼はZoomチャットで「10の直接的なEIPを一緒に出荷すると、フォークの組み合わせテストが非常に複雑になります。そして、私たちは直接的なEIPだけではありません。」と書きました。

マッキーは、EigenLayerチームのようなアプリケーション開発者がPectraで計画されている内容を理解しようとしており、これらの2つのEIPの持続的な不明瞭さが彼らの作業の障害であると共有しました。Lighthouseの開発者ショーン・アンダーソンは、イーサリアム上のアプリケーション開発者からこれらのEIPに関する意見をもっと集めて、それらがアプリケーションにどれほど重要であるかを確認することを提案しました。

ストークスは、この議論を後で再訪し、開発者がPectra Devnet 1の問題を解決することに集中できるようにすることを提案しました。

PeerDASの更新

開発者たちはPeerDASの最新の進展について深く議論しました。アンダーソンは、コンセンサスレイヤー（CL）クライアントチームが前回のPeerDASのdevnetで発見された問題を積極的に修正しており、新しいdevnetを立ち上げる前に実装の安定性を確保していると報告しました。LodestarとEthereumJSの開発者ガジンダー・シンは、最近のPeerDAS実装者会議のフィードバックに基づき、コミュニティが次のPectra devnetにPeerDASを統合する意向を示していると述べました。

ストークスは、イーサリアム財団（EF）研究チームおよび他の開発者との議論に基づき、メインネットでPeerDASを初めて有効化する際には、実装の複雑さを軽減するためにサンプリング機能を省略する必要があるかもしれないと提案しました。彼は、PeerDASの完全な実装には配布、サンプリング、再構築の3つの重要な機能が含まれると説明しました。「現在、PeerDASのPectraにおける仕様はこれら3つのタスクをカバーしています。私の直感では、サンプリング機能が実装プロセスで最大の複雑さをもたらす可能性があります。もしサンプリングが克服できない課題をもたらす場合、Pectraでblobの数を増やし、PeerDASの範囲を減少または調整することを検討できます。」とストークスは説明しました。

ストークスは、このアイデアに関して正式な提案を作成し、開発者コミュニティとさらに議論することを約束しました。シンはこれを支持しました。ストークスはまた、PectraアップグレードにPeerDASを正式に組み込むことを提案しました。これに対して、ジャヤンティはこれがPectra仕様に基づいてPeerDAS仕様を再定義することを意味するのかを尋ね、PeerDASとPectra devnetsを統合することは、両者が不安定であるためにデバッグ作業を複雑にする可能性があると指摘しました。彼は、仕様が安定するまで、2つのワークフローの独立性を保つべきだと提案しました。Tekuの開発者エンリコ・デル・ファンテもジャヤンティの見解に賛同しました。

ストークスは、PeerDAS実装に焦点を当てた多くの開発者がこの会議に参加できなかったことに注意しました。彼は次回のPeerDAS実装者会議でPeerDASの今後のステップについて引き続き議論することを提案しました。

BeaconBlocksByRange V3の追加

Lighthouseプロジェクトの開発者「ダプライオン」は、クライアントが長時間のチェーン分裂が発生した場合に、より効果的にメインチェーンに同期できるようにする改善案を提案しました。彼は、既存の[BeaconBlocksByRange V2] RPCプロトコルには一定の限界があることを指摘しました。「長いフォークのブロックを同期する必要があり、どのブランチがメインチェーンであるか不明な場合、現在のプロトコルに従って、スロット範囲を提出するだけで、ノードは正しいと考えるブロックを返します。状態メッセージを通じてこれらの情報を照会することはできますが、このプロセスには非同期性があり、いくつかの問題を引き起こす可能性があります。現在メインネット上で深刻なフォークが発生していないものの、将来的に同様の事態が発生した場合、これは解決すべき問題となります。」

ダプライオンはさらに、彼が提案した解決策は比較的簡単であり、将来のPectraアップグレードに組み込まれる可能性があると説明しました。これらの改善が差し迫ったものでないにもかかわらず、ストークスは会議に参加した開発者たちにこの提案を注意深く検討し、GitHubで彼らの意見や提案を共有するよう促しました。