イーサリアムコア開発者最新会議の要約：EIP 3074の削除に同意し、EIP 7702を含む

原文标题：《All Core Developers Execution Call #188 Writeup》
作者：Christine Kim
编译：Luccy，BlockBeats

編者按：
イーサリアムの全コア開発者コンセンサス電話（ACDE）は、2週間ごとに開催され、主にイーサリアム実行層（EL）への変更について議論し、調整を行います。今回はACDE第188回電話会議で、開発者たちはイーサリアム実行層の変更について議論し、調整を行いました。

会議では、新しい実行API機能、Gethの最低優先小費要件、Pectra開発ネットワーク0と1の議論、Pectraのフォーク範囲、歴史データの期限切れなど、多くの重要な議題が取り上げられました。開発者たちはこれらの議題について深く議論し、Pectraアップグレードの範囲、タイムライン、具体的な実施詳細についていくつかの合意に達しました。

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

2024年5月23日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Execution (ACDE) call #188会議に参加しました。ACDE電話会議は、イーサリアム財団プロトコルサポート責任者Tim Beikoが主催する、2週間ごとに開催されるシリーズ会議で、開発者たちはイーサリアム実行層（EL）への変更について議論し、調整を行います。今週、開発者たちは以下の内容について議論しました：

• 実行APIに新機能を追加し、ユーザーが取引の「戻りデータ」（returndata）にアクセスできるようにする
• Gethの最低優先小費要件
• Pectra Devnet 0と1
• Pectraフォークの範囲
• Portal Networkの歴史データ期限切れ統合。

· 彼らはPectra Devnet 0からEIP 3074を削除し、次の開発者重視のPectraアップグレードテストネットPectra Devnet 1にEIP 7702を含めることに合意しました。

取引受領書に戻りデータ（Returndata）を追加

スマートコントラクトプログラミング言語Vyperの開発者Charles Cooperは、実行APIのエンドポイントを調整し、ユーザーが取引受領書を取得する際に取引の戻りデータ（returndata）も受け取れるようにすべきだと提案しました。Cooperは、現在開発者が戻りデータを取得する一般的な方法、例えば取引トラッキングは標準化されておらず、すべてのクライアントで広くサポートされていないと説明しました。Rethなどのクライアントチームからのフィードバックに基づき、Cooperは、取引の戻りデータ（returndata）を取得するための新しいエンドポイントを実行APIに作成するという別の解決策を示しました。開発者たちは電話会議でこの提案について合意に達しませんでした。Beikoは、開発者がGitHubで議論を続け、会議外で非同期的にこの問題を解決しようとすることを提案しました。

最低マイナー小費要件

その後、Geth開発者Péter Szilágyiは、最近数週間のユーザーによるGethクライアントのデフォルト設定への懸念を提起しました。EIP 1559が実施されて以来、Gethクライアントは常に取引のデフォルト最低優先小費要件を強制しています。合併後、デフォルトの1 gwei優先小費は正常に機能せず、最近になってSzilágyiのチームによって発見され修正されました。このデフォルト設定が復元された後、ユーザーはGethクライアントで構築されたブロックが他のブロックよりも明らかに空であることに気付きました。なぜなら、それらはほとんど優先小費のない取引を除外しているからです。これにより、デフォルト設定がブロック提案者や構築者のダイナミクスに悪影響を及ぼす可能性についての懸念が生じました。なぜなら、それは優先費用のない有効な取引の遅延処理を引き起こす可能性があるからです。

Nethermindの開発者Tomasz K. Sta ń czakは、Gethのデフォルト最低優先小費要件は重要ではない問題であり、プロトコル開発者は標準化や強制を試みるべきではないと述べました。EF研究者Ansgar Dietrichsは、現在イーサリアムの取引基礎費用が非常に低いため、デフォルトの最低優先小費を引き下げることを提案しました。他の開発者は、Gethのデフォルト最低優先小費を固定金額ではなく基礎費用のパーセンテージとして設定することを提案しました。しかし、Beikoはこれに反対し、優先小費は取引がブロックに含まれるための費用ではないと考えています。それは、取引が次のブロックに含まれることを優先的に保証するためだけに使用されるべきであり、基礎費用の変動に基づくデフォルト最低優先小費を使用することは、基礎費用の変化を歪める可能性があると述べました。なぜなら、一部の価値が取引の優先小費に反映されるからです。

Beikoは、議論の別の視点は、構築者がゼロ小費ブロックを作成し、提案者に対してオフチェーンの支払いを提供することをどのように奨励するかであると付け加えました。この状況は、デフォルトの最低優先小費要件がある場合でもない場合でも発生する可能性がありますが、デフォルト値を設定することは、構築者がゼロ小費ブロックを作成しないように奨励する規範を形成する可能性があります。Szilágyiは、ある意味で、構築者がブロックにゼロ小費取引を含めるべきかどうかは哲学的な問題であると述べました。ネットワークの観点から見ると、これらの取引は有効であり、したがってブロックに含まれるべきです。しかし、財務的動機を持つ提案者の観点から見ると、ゼロ小費取引をブロックに含めることには経済的利益がないため、含めるべきではありません。

開発者たちは、Gethチームが彼らが最も良いと思うデフォルト値を設定すべきだと広く考えています。検証ノードの運営者は、このデフォルト値を自由に変更でき、他の実行層クライアントを使用することもできます。

Pectra Devnet -0

イーサリアム財団（EF）の開発者運営エンジニアParithosh Jayanthiは、Pectra開発ネットワークの状況を更新しました。最初の開発ネットワークは、先週ケニアで開催されたNyota Interopというイーサリアムプロトコル開発者のオフラインミーティングで立ち上げられました。Jayanthiは、開発ネットワークにはすべての実行層とコンセンサス層のクライアントが含まれていると述べました。しかし、EIP 3074はまだ集中的なテストを受けておらず、修正が必要なバグが存在します。クライアントチームは、次の開発ネットワークPectra Devnet 1の立ち上げの準備を進めており、後者にはEIP 2935の実装に関する変更が含まれます。

Pectra範囲変更

開発者たちはその後、Pectraアップグレードの範囲の変更について議論しました。独立したイーサリアムプロトコル開発者Danno Ferrin、Reth開発者Georgios Konstantopoulos、Solidityチームの代表者は、PectraにEOFを含めることを支持しました。Geth開発者Marius van der Wijdenは、彼がEOF仕様を実装していると述べました。しかし、彼はEOFの複雑性のため、EOFを含めることは確実にPectraアップグレードのアクティベーションを遅らせるだろうと強調しました。LodestarとEthereumJSの開発者Gajin der Singhは、Zoomチャットで開発者は現在のPectraバージョンのリリースに集中すべきであり、アップグレードの範囲を拡大すべきではないと述べました。EF研究者Alex StokesとPiper Merriamは、Singhの見解に同意しました。

EOFについての議論の後、開発者たちはEIP 7702の進捗について議論しました。EIP 7702は、イーサリアム共同創設者Vitalik ButerinによってEIP 3074の代替案として提案されました。EIP 7702の重要な詳細、例えばその取り消し可能な設計については、まだ解決されていません。「dror」という名前の開発者はZoomチャットで、「EIP 7002はEIP 3074の一つのバージョンであり、以前はnonceとチェーンID（chainID）を持つバージョンのみが受け入れられていました。これらは現在削除されており、私たちはその理由を再議論する必要があります。これらの制限について再度議論することを提案します。」と書きました。Besu開発者Daniel Lehrnerは、EIP 7702の設計についてウォレット開発者からのさらなる意見を求めることを提案しました。Erigon開発者Andrew Ashikhminは、ユーザーがウォレットを介さずに権限を取り消す方法が必要であると強調しました。

Beikoは、EIP 7002の実施詳細について別の小グループ会議で議論を続けることを提案しました。同時に、開発者たちはDevnet 0からEIP 3074を削除し、Devnet 1にEIP 7702を追加することに合意しました。

Pectraに追加される予定の他の2つのEIPは、EIP 7623（calldataコストの増加）とEIP 7212（secp256 r1曲線のプリコンパイルのサポート）です。EF研究者Toni Wahrstätterは、EIP 7623の最新の進捗を共有し、スマートコントラクトウォレット開発者Ulaş ErdoğanはEIP 7212の最新の進捗を共有しました。開発者たちは、これらの2つのEIPがPectraに含まれるべきかどうかについて合意に達しませんでした。

Pectraタイムラインの期待

Konstantopoulosは、開発者がイーサリアムメインネットでPectraアップグレードをいつアクティブにすべきかについて言及しました。通話前に共有された文書の中で、Rethクライアントチームは、2024年末までにアップグレードをリリースしようとすることは「価値が少ない」と書いており、開発者は2025年初頭にアップグレードをリリースする準備をすべきだと述べました。EF Panda Opsチーム（EF開発者運営チームの一部）も通話前にPectraのタイムラインと範囲に関する意見を表明した文書を共有しました。彼らは、Pectraを2つのフォークに分けることを提案し、一つは今年アクティブにし、もう一つはMaxEB、EOF、そして可能なpeerDASを含み、来年初頭にアクティブにすることを提案しました。Jayanthiは、EF Panda Opsチームの意見が統一されていないが、彼自身はPectraの範囲を2つのフォークに分けるべきだと考えていると述べました。彼は、PectraアップグレードのエッジケースとEIPの相互作用はまだテストされていないと指摘しました。

EF Solidity開発者Alex Beregszasziは、EOFがPectraに含まれない場合、これらのコード変更はイーサリアムのアップグレードに永遠に含まれないことを懸念していると述べました。Geth開発者Marius van der WijdenとGuillaume Balletはこれに反対し、EOFの利点は十分に顕著であり、たとえ数回のフォークが遅れたとしても、その有用性は依然として存在すると考えています。

Beikoは、まずpeerDASとblobサイズの増加を優先的に処理する方法について合意し、その後にアップグレードの残りの範囲を決定することを提案しました。彼は、来週のAll Core Developers Consensus（ACDC）会議に参加する開発者がこのトピックについて集中して議論することを希望しています。彼は、開発者が次回のACDE会議でPectraの範囲を最終決定する準備を整えてほしいと考えています。

Portal Networkと歴史の期限切れ

最後に、MerriamはPortal NetworkチームがPectraと並行して歴史の期限切れバージョンをリリースするためにプロトコル開発者と協力する準備が整ったことを指摘しました。Portal Networkに関する詳細情報はこちらで見つけることができます。