イーサリアムのコア開発者最新会議の要約：Pectraアップグレード、PeerDASの再構築

原文标题：《Ethereum All Core Developers Execution Call #194 Writeup》

作者：Christine Kim

编译：Ladyfinger，BlockBeats

编者按：

イーサリアムのすべてのコア開発者による実行電話（ACDE）は、2週間ごとに開催され、主にイーサリアムの実行層（EL）への変更について議論し、調整します。今回はACDE第194回電話会議で、EIP7732、EIP 2537操作のガスコストの更新分析、PeerDASなどの議題が重点的に議論されました。

会議中、Geth開発者のMarius van der Wijdenは、イーサリアムからマージ前のフィールドを削除する方法を提案し、同期中のノードの帯域幅を削減できることを示しました。Galaxy Digitalの研究副社長Christine Kimは、会議の要点を詳細に記録し、BlockBeatsが原文を以下のように編纂しました：

2024年8月15日、イーサリアムコア開発者実行会議（ACDE）第194回電話会議がイーサリアム財団の研究者Alex Stokesの主催で行われました。この会議では、主に実行層（EL）の変更と調整の問題が議論されました。

今週、開発者たちはPectraアップグレードのテスト進捗を更新しました。その後、EOFコード変更の準備状況が議論され、これらの変更はPectra開発ネットワークに組み込まれる予定で、EIP 2537操作のガスコスト分析も更新されました。Prysm開発者「Potuz」は、EIP 7732を紹介しました。これは、提案者とブロックビルダーをイーサリアムプロトコル内で分離することを目的とした正式な提案です。Erigon開発者のGiulio Rebuffoは、イーサリアムクライアントの技術的負債を減らすために、実行APIから「totalDifficulty」フィールドを削除することを提案しました。Geth開発者のMarius van der Wijdenは、イーサリアムのワイヤープロトコルからいくつかのマージ前のフィールドとメッセージを削除することを提案し、ノードの同期中の帯域幅消費を減らすことを目指しました。開発者たちはまた、DencunではなくPectraの上でPeerDAS仕様を再設定することについて簡単に議論し、EIP 4444の実装進捗についての更新を共有しました。

Pectra Devnets

Pectra Devnet 2は非常に安定しています。Devnet 2の情報ページには、マージブロックビルダー仕様に関連し、devnet上でそれらをテストすることに関する未解決の問題があるようです。EF開発運用エンジニアのParithosh Jayanthiは、Teku/ErigonノードとPrysmクライアントにも問題があると述べました。

開発者の目標は、2週間以内にEIP 7702更新仕様を持つPectra Devnet 3をリリースすることです。すべてが計画通りに進めば、開発者はその後EOFを開発ネットワークに追加し、Pectra Devnet 4を作成する予定です。

Geth開発者のMarius van der Wijdenは、EIP 2537のガスコストに関する最新の分析を共有しました。背景として、EIPはBLS12-381曲線操作のための新しいプリコンパイルを作成しました。これにより、スマートコントラクト開発者はBLS12-381曲線上で経済的に効率的な方法で署名の集約などの操作を実行できるようになります。Van der Wijdenは、彼とGethチームの同僚Jared WasingerがBLS操作とそのさまざまなマシンでのガス使用状況に基づいて策定したベンチマークに従って、プリコンパイルの再価格設定を提案しました。Van der Wijdenは、他の開発者にもEIP 2537のガス使用状況について独自のベンチマークを実行して結果を検証するよう奨励しました。

EIP 7732

Prysm開発者「Potuz」は、EIP 7732の更新を共有しました。EIP 7732は、検証者を第三者のブロックビルダーに直接接続するためのプロトコル内のソリューションです。マージ以来、検証者はMEV報酬を含むブロックを受け取るために、リレーと呼ばれる仲介者に依存してきました。EIP 7732はリレーの必要性を排除し、検証者がより信頼を必要としない方法でMEVを取得できるようにします。Potuzは、EIP 7732の現在の設計は実行層（EL）やエンジンAPIを変更する必要がないことを強調しました。彼はさらに、EIP 7732はトランザクションをブロックに含めることを強制する提案であるインクルードリストとも互換性があると付け加えました。EIP 7732に関する詳細は、このGoogleスライドプレゼンテーションで確認できます。

マージ前の技術的負債の削減

イーサリアムがプルーフ・オブ・ステークに移行して以来、イーサリアムコードベースの一部はもはや有用でも必要でもなくなっています。例えば、難易度爆弾は、プルーフ・オブ・ステークに基づく開発作業を強制するメカニズムであり、一定の期間後にプルーフ・オブ・ワークでブロックを作成できなくします。以下の2つの提案は、ノードのパフォーマンスを向上させ、プロトコルの複雑性を減らすために、コードベースのこのような部分を削除することを目的としています。

• Erigon開発者のGiulio Rebuffoは、実行APIから「totalDifficulty」フィールドを削除することを提案しました。
• Geth開発者のMarius van der Wijdenは、イーサリアムワイヤープロトコルからいくつかのプレマージフィールドとメッセージを削除することを提案しました。

他の開発者は電話会議でこれら2つの提案に対して前向きなフィードバックを提供しました。開発者たちは、会議終了後に非同期でより詳細に両者をレビューすることに同意しました。

PeerDAS

PeerDASに関して、ニンバス開発者の「Dustin」は、Denebの上でPeerDASを開発し続けるのではなく、Pectra EIPの上でPeerDASのリベースを加速することを提案しました。彼は、Pectraには不安定で変更される可能性のあるいくつかのEIP（例えばEIP 7702とEOF）があると述べました。Dustinは、PeerDASを安定したPectra EIPのサブセットに再構築し、PeerDAS開発ネットワーク上のEIP 7702とEOFトランザクションを除外することを提案しました。開発者たちは、Pectra上でPeerDASの基盤を再構築する他の方法について議論しました。一般的に支持され、この方向に進むことが始まりました。

Stokesは電話会議の参加者に、来週の月曜日午後2時（世界標準時間）からPectraテスト電話会議が定期的に開催され、devnet仕様とスケジュールをさらに調整することを思い出させました。

EIP 4444

EIP 4444には重大な更新はありません。NethermindとNimbusチームの代表は、ユーザーが期限切れの履歴データにアクセスするための代替ネットワークプロトコルであるPortal Networkとの協力を構築していると述べました。