イーサリアムコア開発者最新会議の要約：PectraアップグレードにEOFとEIP-7702を追加

原文タイトル：《Ethereum All Core Developers Execution Call #189 Writeup》
著者：Christine Kim
編纂：Luccy，BlockBeats

編者按：
イーサリアムの全コア開発者実行電話（ACDE）は、2週間ごとに開催され、主にイーサリアム実行層（EL）への変更について議論し、調整を行います。今回はACDE第189回電話会議で、開発者たちはPectraアップグレードにおけるいくつかの重要な議題について議論しました。これには、EOFやEIP 7702を含む変更、Pectraの範囲の改善、Verkle移行の準備などが含まれます。

会議では、EOFや他のPectra EIPsをどのようにパッケージ化し、これらのコード変更をどのようにテストするかについても議論されました。また、イーサリアムネットワークのアップグレードプロセスを改善することを目的としたいくつかの提案も紹介されました。これには、ACD電話会議の議題の議論頻度の調整や新しいEIPラベル提案が含まれます。EIP 4444とPortal Networkの統合進捗についても言及されました。

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

2024年6月6日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Execution (ACDE) call #189会議に参加しました。ACDE電話会議は、イーサリアム財団プロトコルサポート責任者Tim Beikoが主催する、2週間ごとに開催される一連の会議で、開発者たちはイーサリアム実行層（EL）への変更について議論し、調整を行います。今週、開発者たちはEOFとEIP 7702をPectraアップグレードに含めることに合意しました。これらのコード変更によるマルチクライアントテストのアップグレード遅延を避けるために、開発者たちは後の開発ネットワークでEOFを有効にし、他のEIPとは異なる有効化サイクルで有効にする可能性があることに合意しました。これは、開発者がPeerDASをテストするのと同様です。また、OsakaアップグレードでEIP 158を無効にしてVerkleの準備をする方法や、Portal Networkとの統合を通じてEIP 4444の次のステップを実施する方法についても議論されました。最後に、BeikoとEF開発者運営（DevOps）チームは、ガバナンスプロセスとイーサリアムアップグレードのコミュニケーションチャネルの最新情報を共有しました。

Pectraの範囲

今週のACD会議の前に、各ELクライアントチームとEF DevOpsチームは、Pectraの範囲についての見解を共有しました。

• Besuの見解
• EthJSの見解
• Nethermindの見解
• Rethの見解
• EthPandaOpsの見解

会議前に共有された見解によると、明らかにほとんどのクライアントチームはPectraにEOFを含めることを支持しています。唯一強くEOFに反対しているクライアントチームはGethです。Gethの開発者Guillaume Balletは、「私たちが待てば待つほど、Verkle変換に必要な時間が長くなることを心配しています。EOFは本当にそんなに緊急ですか？私はそうは思いません。プラハでEOFをリリースすることについてのいくつかの議論を読みました。読むほど、EOFが必要であることを証明するものは何もないことに気づきました。」と述べました。これに対して、数人の開発者が反対意見を述べました。

「Kamil Sliwak」という名前の開発者は、イーサリアムスマートコントラクトプログラミング言語Solidityのコンパイラと相互作用するユーザーの観点から、EOFは「大きな改善」になるだろうと述べました。Rethの開発者Dragan Rakitaは、EOFがVerkle変換を著しく遅延させるという考えは不誠実だと補足しました。「私たちが話しているのは、10%から20%の変換時間の延長です。EOFは状態を増加させず、追加の3ヶ月で追加の部分フォークをリリースすることはVerkleを著しく遅延させることはありません。」とRakitaは言いました。EOFが何であり、どのようにイーサリアム仮想マシン（EVM）を改善するかについての詳細は、ポッドキャスト《無限のジャングル》のこのエピソードをお聞きください。

Beikoは、開発者にEOFを他のPectraのEIPとバンドルすることを好むか、それともPectraのEIPを2つのハードフォークに分けることを好むかを尋ねました。Erigonの開発者Andrew Ashikhminは、開発者はすべてのPectraのEIPを一緒にリリースするか、Verkle変換後までEOFを延期するべきだと考えていると述べました。「私が最も望まないのは、PectraとVerkleの間でEOFをリリースするためのフォークを行うことです。なぜなら、私はGuillaumeの意見に同意し、状態が増加していると思うからです。私はVerkleがEOFよりも重要だと思います。だから私にとっては、これは最悪の結果です。」とAshikhminは言いました。Beikoは、EOFを含むすべてのPectraのEIPを1つのクライアントバージョンでリリースすることを提案しました。しかし、テストの目的のために、開発者は開発ネットワークを使用してこれらのコード変更を段階的に実施することを検討すべきだと述べました。「開発ネットワークをマルチクライアントテストの優先事項として使用し、EOFが長期間遅延することがわかれば、それを分けることを決定できます。」とBeikoは言いました。

EOFをPectraに組み込む方法についてのこれらの議論の中で、Gethの開発者はZoomチャットと会議全体でEOFをアップグレードに含めるべきかどうかの疑問を表明し続けました。GethチームのEOFに対する継続的な議論に対処するために、Rethの開発者George Konstantinopoulosは、「直接やりましょう。対話の流れは少し混乱しています。私たちはVerkle変換を数日延長することを気にしません。データは状態が減少していることを示しているので、これは混乱を招く議論ですし、あなたにはこれが良い機能であることを教えてくれるアプリケーションがたくさんあります。ほとんどの人が支持を表明しているのに、なぜ私たちはそれを行わないことを考慮する必要があるのか、これは非常に混乱しています。」と述べました。

Beikoはこの意見に同意し、EOFはPectraに含めるべきだと再確認しましたが、開発ネットワークで段階的にテストする必要があると述べました。これは、クライアントチームがDevnet 0で実装されたEIPをDevnet 1でテストすることを意味します。その後、将来の開発ネットワークでEOFを追加してテストします。この戦略は、クライアントチームが同じタイムラインでPectraの一部のEIPのリリースに集中し、マルチクライアント開発ネットワークでの進捗を続けることを保証します。イーサリアム財団（EF）DevOpsエンジニアのMario Vegaは、EOFの実行層（EL）仕様テストが2ヶ月以内に準備できると予想しています。EF DevOpsエンジニアのParithosh Jayanthiは、EOFはPectraの他の実行層（EL）EIPと分けてテストできると述べました。しかし、彼はPectraのコンセンサス層（CL）EIP間の相互依存性や、これらのコード変更をテストすることの複雑さを懸念しています。

Vyperコンパイラの開発者Charles Cooperは、彼の見解では、EOFは彼が提案したコード変更ほど緊急ではないと述べました。これらの変更は、再入攻撃を防ぐ保護を安価で普遍的にすることを目的としています。BeikoはCooperに、EOFに対する広範な合意が明確である一方で、クライアントチームが再入攻撃に関連する変更など、より多くのコード変更を追加するための十分なエネルギーを持っているかどうかは不明であると指摘しました。「私たちがEOFを進めるなら、他のことを行うためのエネルギーはほとんどないことは明らかです。これはこれまでで最大のフォークになるでしょう。」とBeikoは言いました。

EOFを含めることに加えて、開発者たちはEIP 7702をEIP 3074の代替案として含めることに合意しました。開発者たちは依然としてEIP 7702の仕様についての小規模なグループ会議を行っています。BeikoはEIP 7702にEOFと同様のアプローチを採用することを提案しました。「私はそれをフォークに含めますが、仕様にあまり満足していない場合は、Devnet 1または2の一部として含めず、次の1ヶ月で本当に仕様を整理して、現在提案されているものよりも良い取り消しメカニズムを持つようにします。後であまり大きくないEIPを追加します。」とBeikoは言いました。Gethの開発者「Lightclient」は、クライアントチームが準備ができているなら、EIP 7702をできるだけ早く実施すべきだと述べました。誰も次の緊急のPectra開発ネットワークDevnet 1にEIP 7702を含めることに反対していません。

Pectra仕様

その後、Tekuの開発者Mikhail Kalininは、既存のPectra EIP仕様のいくつかの更新を共有しました。最初の提案は、実行層（EL）ブロック内で直接処理するのではなく、サイドカー機構を介してコンセンサス層（CL）リクエストを処理することです。Prysmの開発者「Potuz」は、この戦略が将来のコード変更に必要な論理、すなわち明確な提案者ビルダー分離（ePBS）を破壊することを指摘しました。「信号ブロックは、ペイロードが既に存在することに依存すべきではありません。したがって、引き出しや預け入れのいずれであっても、信号ブロックがペイロード内の内容に依存することは望ましくありません。なぜなら、これがePBSのプロセスを破壊するからです。」とPotuzは言いました。この問題のため、Kalininは彼の提案を撤回し、GitHub上のプルリクエストを閉じることに同意しました。

Kalininは、PectraのELとエンジンAPI仕様に関する他の変更のいくつかを共有しました。その中の1つは、EIP 7251の下でELトリガー合併を有効にし、MAXEFFECTIVEBalanceを増加させることです。Beikoは、開発者が次回のACD電話会議の前にこれらの変更をレビューすることを提案しました。そうすれば、Devnet 1でのテスト前に完了し、準備が整うことができます。

Verkle準備

Verkle移行に関する彼の作業に基づいて、BalletはEIP 158が廃止されたオペコードSELFDESTRUCTに類似した問題を引き起こすことを示しました。移行後にネットワーク上の複雑な状況を避けるために、BalletはPectraアップグレードでEIP 158を無効にすることを提案しました。しかし、彼はPectraにおけるEIP 7702の実施が微調整された場合、EIP 158の無効化が遅れる可能性があり、Verkle移行と同時に行われる可能性があると指摘しました。BeikoはGuillaumeにEIP 158の無効化提案を起草するよう提案しました。

歴史の期限

PectraとVerkleに加えて、イーサリアムプロトコルの開発者たちはEIP 4444、歴史の期限にも取り組んでいます。EIP 4444の計画と要約文書に記載されているように、このコード変更を行う理由は「ブロックの歴史がノードの大量のスペースを占有し、一度そのブロックが完了すると、限られた非コンセンサスの重要なユースケースにのみ必要だからです。」文書はさらに説明しています。「ブロックの歴史はもはやフルノードによって永久に保存されません。しばらくすると、それはノードから削除され、それを必要とするエンティティは他の場所から照会する必要があります。」Portal Networkは、ノードがイーサリアムの歴史データを照会するための代替の分散型ネットワークです。

Merriamは、彼のチームがELクライアントチームにPortal Networkとの統合サポートを提供する意向を再確認しました。彼は、サポートがなければ、統合には約6ヶ月の開発時間がかかると述べました。しかし、指導と密接な協力を通じて、彼は今後2ヶ月以内にEIP 4444で有意義な進展を遂げることができると楽観的に考えています。Jayanthiは、Portal Network仕様がセキュリティ監査を受けたかどうかを尋ねました。Merriamは、受けていないと答えました。イーサリアム財団の研究者Ansgar Dietrichsは、クライアントチームがネットワークとどのようにインターフェースを取るかを自分で決定できるかどうかを尋ねました。これには、既存のクライアントに統合をバンドルすること、新しいクライアントを構築すること、または統合をまったく行わないことが含まれます。Merriamは、この決定がクライアントチームによって行われることを確認しました。

Merriamは、電話会議中のELクライアントチームにEIP 4444に関する進捗と意図について尋ねました。Nethermindの開発者Ł ukasz Rozmejは、「全体的に見て、これは優先事項です。私たちは昨日、Portalチームと会議を開きました。問題は、優先事項が多すぎることです。すべてのことを正しくバランスを取るのが難しいことがあります。したがって、ハードフォークと比較して、それほど緊急ではない優先事項ですが、Nethermindは取り組みを開始し、優先的に扱います。」と述べました。Besuの開発者Matt Nelsonも同様の見解を示しました。Gethの開発者Guillaume Balletは、彼のチームがPortal Networkの統合についてまだ議論していないと述べました。

ACDプロセスの改善

ACDプロセスの改善に続いて、Beikoはイーサリアムネットワークのアップグレードプロセスを改善するいくつかの提案を共有しました。彼はまず、ACD電話会議でクライアントチームがまだ詳細にレビューしていないトピックの議論頻度を減らすことを提案しました。Beikoは、開発者が専門的な議論を行う前に、ACD電話会議でこれらのトピックをレビューのためにマークし、その後、必要に応じて次回のACD電話会議でこれらのトピックについてより詳細に議論することを提案しました。

Beikoが提案した2つ目の提案は、ハードフォークに含めることを検討しているイーサリアム改善提案（EIP）に通常付加される「考慮含める」（CFI）ステータスに関するものです。このステータスは、歴史的にどのEIPがハードフォークに含まれる可能性が高いかを効果的に示していませんでした。Beikoは、開発者がどのEIPがハードフォークに含まれる可能性が高いか、どのEIPが含まれないかをよりよく区別できるようにするために、「提案含める」（PFI）という別のラベルを作成することを提案しました。

イーサリアム財団の研究者Ansgar Dietrichsは、ZoomチャットでEIPに新しいラベルを作成することは「間違った方向」であり、CFIラベルが「完全に無用」になるだけだと書きました。Beikoは、開発者がGitHubやEthMagiciansでネットワークアップグレードプロセスの改善に関する問題を引き続き議論できると述べました。

さらに、イーサリアム財団のDevOpsエンジニアMario Vegaは、テストに関連する更新のために新しいDiscordサブチャンネルを作成したいと述べました。Vegaは、現在イーサリアム開発Discord内でテストリリース情報が複数のチャンネルに分散していると述べました。しかし、彼はこの新しいフォーラムがクライアントチームがイーサリアム財団DevOpsチームからテスト更新を取得するための「ワンストップ」リファレンスになることを望んでいます。彼はクライアントチームにこの件についてフィードバックを求めました。

最後に、Beikoは開発者に、次の数日間に2回の小規模会議が予定されていることを思い出させました。1回はePBSに関するもので、6月7日に開催され、もう1回はPeerDASに関するもので、6月11日に開催されます。