イーサリアムコア開発者最新会議の要約：EIP 3074の実装準備、ロールアップロードマップ

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

原文作者：Christine Kim

原文编译：Frost，BlockBeats

編者按：

イーサリアムのすべてのコア開発者のコンセンサス電話（ACDE）は、2週間ごとに開催され、主にイーサリアムの実行層（EL）への変更について議論し、調整します。今回はACDEの第186回電話会議で、開発者たちはPectra Devnet 0とEIP 3074の実施準備について議論しました。彼らは、各クライアントチームがPectra Devnet 0の準備においてどのような進展を遂げているかを詳しく説明し、EIP 3074の仕様に関する修正提案や関連するテストの進捗についても議論しました。

また、この記事では、Pectraアップグレードに含まれる可能性のある他のコード変更についての議論や、イーサリアムのEIPプロセスの変更がL2/RIPプロセスにどのように影響を与えるかについても言及されています。Galaxy Digitalの研究副社長Christine Kimがこの会議の要点を詳細に記録し、BlockBeatsが原文を以下のように編纂しました：

2024年4月25日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Execution (ACDE) call #186会議に参加しました。ACDE電話会議は、イーサリアム財団のプロトコルサポート責任者Tim Beikoが主催する、2週間ごとに開催される一連の会議です。開発者たちはこの会議で、Pectra Devnet 0とEIP 3074の実施準備について議論しました。彼らはまた、Pectraアップグレードにどの他のEIPを含めるべきか、そしてイーサリアムの「Rollup中心のロードマップ」を考慮したガバナンスの変革について広く考察しました。

Pectra Devnet 0 最新進展

Beikoは電話会議で、クライアントチームにPectra Devnet 0の最新進展を共有するよう求めました。NethermindチームのMarek Moraczyńskiは、NethermindがすべてのPectra EIPを実装し、テスト作業を行っていると述べました。BesuチームのJustin Florentineは、BesuがPectra EIPを実装しており、Devnet 0のリリースに向けて準備を進めていると述べました。ErigonチームのAndrew Ashikhminは、「ErigonがDevnet 0のEIPの全セットに対して準備が整っているかは不明です。一部の理由として、これらのEIPの仕様がまだ変化しており、Erigonクライアントが新しいメジャーバージョンErigon 3に移行中であり、チームのリソースと時間を占有しています。Erigon 3とPectra EIPは最終的に確定し、一緒にErigonクライアントに組み込まれます。」と述べました。Gethチームの「Lightclient」は、GethがDevnet 0の準備が整うまで「数日」かかると述べました。Ethereum JSチームのGajinder Singhは、Ethereum JSもDevnet 0に「準備が整う」と述べました。

EIP -7685

LightclientはEIP 7685を統合し、ELによってトリガーされたリクエストをコンセンサス層（CL）に保存するための一般的なフレームワークを作成し、EIP 6110および7002への影響を示しました。Beikoは、開発者がDevnet 0のリリースにこのEIPを追加し、Pectra EIPを継続的に改善すべきだと述べました。

テストに関して、EFテストチームのMario Vegaは、EIP 6110と2537のテストが完了し、EIP 7002とEIP 2935のテストが今週または来週に完了する予定であると述べました。EIP 3074のテストはDevnet 0の準備が整っていません。EF研究者Antonio Sansoは、EIP 2537の仕様が更新され、GitHubリポジトリに新しいテストベクトルが追加されたと述べ、皆にGitHubを確認するように勧めました。EF研究者Hsiao Wei Wangは、CL仕様のテストベクトルにエラーが存在することを指摘し、そのエラーはすぐに修正され、新しいバージョンがリリースされました。

EIP -3074 の更新

今週のACDEでは、EIP 3074仕様に対するいくつかの変更提案がありました。Ahmad Mazen Bitarは、EIP 3074の動作を変更し、AUTH CALLの前にDELEGATECALLを行えるようにすることで、EIPのユースケースを拡大することを提案しました。ブロックチェーンウォレットオペレーティングシステムZeroDevの創設者兼CEOであるDerek Jiangは、必要に応じてAUTHメッセージと他の変更をグローバルに取り消すための「noncemanager」を作成することを提案しました。電話会議に参加した一部の開発者は、EIP 3074の変更を遅らせるべきだと考えました。なぜなら、それは実装の難易度を大幅に増加させるからです。

Beikoは、開発者がEIP 3074の提案された変更について別のグループ会議で議論することを提案しました。彼は、PectraにEIP 3074を実装するために十分な時間を確保するために、開発者は「今後1、2ヶ月のうちに」最終仕様を決定するように努めるべきだと指摘しました。LightclientはEIP 3074のグループ会議を組織することに同意しました。Devnet 0に関して、Beikoはクライアントチームが変更を加えずにEIP 3074を実装すべきだと確認しました。たとえ開発者が将来のdevnetでEIPを異なる方法で実装することを決定したり、アップグレードから完全に削除したりする可能性があってもです。

EIP 3074の実装の詳細に加えて、開発者たちはEIPが十分なコミュニティの支持を得ているかどうかについても真剣に議論しました。「Siri」という表示名の開発者は電話会議で懸念を示し、「EIP 3074は原則的にひどく、私たちが完全なアカウント抽象を実現する速度を遅くする」と述べました。Beikoは、イーサリアムの魔法使いやACD通話の議論に基づいて、クライアントチームはEIP 3074を支持しているようであり、アカウント抽象（AA）に関連する他の提案ではないと応じました。Beikoは、「これは短期的に最も合意のある提案のようで、実際に次のフォークでEOAの状態を改善できる」と述べました。これに対し、Siriはクライアントチームが孤立してこの決定を下すべきではないと考えました。「私たちは他の利害関係者の意見を聞くべきです」とSiriは述べ、「私たちは論争のあるハードフォークの領域に移行したくありません。……他の利害関係者の見解と彼らがこの提案をどう考えているかを理解することが最善だと思います。」

BeikoとSiriはまた、ACD通話の外でEIPのためにより広範な合意をどのように築くべきかについて議論しました。ChiangはまずEIP 3074のグループ会議を開催し、EIPの技術仕様について深く議論した後、Pectraアップグレードに残すべきかどうかを決定することを提案しました。EF研究者Ansgar Dietrichsは「私たちは、十分な進展がなければEIP 3074は撤回されることを理解すべきです」と述べました。

イーサリアムの共同創設者Vitalik Buterinは、「今後数年でユーザーのアカウント機能が変わる予定であり、特に外部所有アカウント（EOA）においてです。アカウント抽象に関連するEIP、例えばEIP 3074などを有効にする必要があります。」と付け加えました。

その他 Pectra 提案

開発者たちは、Pectraアップグレードに含めるべき他のコード変更について引き続き議論しました。Geth開発者のMarius van der Wijdenは、これはEOFのような複雑なEIPがPectraに入るかどうかに依存すべきだと述べました。「もしEOFを含めるなら、フォークが飽和することになります。EOFを含めないなら、もっと多くの内容を含めることができるかもしれません」とvan der Wijdenは述べました。

Siriは、安全性の監査を受けていないEIP 3074をPectraに含めることに懸念を示しました。Beikoは、この議論をEIP 3074の仕様が最終決定されるまで保留することを提案しました。

Bitarは、PectraにEIP 7212を追加することを望んでいると述べました。EIP 7212は、secp256 r1楕円曲線で署名検証を実行する新しいプリコンパイルを作成します。これは、ユーザーの生体認証をサポートするハードウェアデバイスと一緒に使用できます。Bitarは、生体認証を使用してイーサリアムの取引に署名することがユーザー体験の大きな改善になると述べました。Ashikhminもこの提案に賛成しました。Dietrichsは、これは「Rollup改善提案」（RIP）プロセスを通じてLayer-2 Rollupsによって承認された唯一の提案であると指摘しました。

他の開発者であるDietrichs、van der Wijden、Moraczyńskiは、通話データのコストを増加させ、最大ブロックサイズを制限するEIP 7623を支持する意向を示しました。Beikoは、EIP 7623とEIP 7212を「考慮に入れる」またはCFIとしてPectraにマークし、Devnet 0の立ち上げ後にクライアントチームの帯域幅を再評価してこれら2つの改善提案をサポートすることを提案しました。

ELのシリアル化方法をSSZに更新することに関連するEIPバンドルについて、van der Wijdenは、これらがPectraに運ばれるのが難しすぎることを懸念しました。GethチームのGuillaume Balletの同僚もこの評価に同意しました。Buterinは、「少なくとも取引の受領書のシリアル化方法を更新することは、イーサリアム自体を超えた「重要な価値」を持つでしょう。なぜなら、それはイーサリアム上に構築された第2層Rollupの追加のセキュリティ監査コストを排除するからです。」と発言しました。SSZ関連のEIPの主要な支持者であるNimbusチームのEtan Kisslingは電話会議に出席していませんでしたが、彼はGitHubにこれらのコード変更がなぜ重要であり、Pectraに含めるべきかを説明する詳細な説明を書きました。

開発者たちはまた、EOFについて再度議論しました。独立したイーサリアムプロトコル開発者Danno Ferrinは、EOFチームがコード変更に対するEL仕様のテストを行っていると述べました。EVMOneとRethは、EOFの実装を完了したと報告されている2つのELクライアントチームです。Ferrinは、Gethチームが実装において「良好な進展」を遂げていると述べました。Ferrinは、BalletがSolidityチームの「Daniel」と協力してEOFとVerkleの互換性に関する懸念を解決していると付け加えました。

Balletは、彼がDanielやDietrichsなどの他の開発者との対話に基づいて、EOFの範囲を狭めることが目的に反しない方法で行うのは難しいと述べました。また、開発者が将来的に別のEOFに類似したコード変更を実装するための作業を増やすことになるとも述べました。

「Charles C」というスクリーン名の開発者は、EOFを小規模または大規模なEOFアップグレードの間で選択するのではなく、Blobトランザクション用のメカニズムなどを通じてEOFを簡単に反復的に実装する方法を探すことを提案しました。Dietrichsはチャットで、PectraのEOFの複雑性を下げる場合、クライアントチームがそれに対してより大きな関心を持つかどうかを尋ねました。Ipsilonチームは、EOFの中で最も高い複雑性を引き起こすコード変更（例えば「TX create」）がすでに解決されていることを指摘しました。「EOF create」などの機能を削除する特定の要求は、全体のEOFの複雑性を大幅に減少させることはないと述べました。背景として、IpsilonはEFが資金提供するEVM研究開発チームの名称です。Beikoは、開発者が繰り返し行われるEOFグループ討論でEOFの実装について議論を続けることを提案しました。

ACD / EIP と L2 / RIP

ACDE #186の議論の最後のテーマとして、開発者たちは新しいRIPプロセスがイーサリアムEIPプロセスに与える変更について議論しました。Dietrichsは、開発者がRollup調整、RollCall、RIPプロセスの会議シリーズを開始してから6ヶ月が経過したと指摘しました。これらのプロセスがイーサリアムEIPプロセスにどのように、またはどのように影響を与えるべきかについては、いくつかの未解決の問題が残っています。Dietrichsは、L2で進行中の研究問題の1つは、Rollupにとってイーサリアム仮想マシン（EVM）の長期的な同等性が望ましいかどうかであると述べました。彼はまた、L2で実施された変更が最終的にイーサリアム第1層のプロトコル決定にどの程度影響を与えるかという未解決の問題があると付け加えました。

Geth開発者のPéter Szilágyiは、L2で提供される特定の機能がL1で提供するのに適していない可能性があり、場合によってはL2で提供される機能に従っても、L2間で異なる場合があるため、イーサリアムプロトコル開発者に混乱をもたらす可能性があると述べました。EF研究者のCarl Beekhuizenは、RollCallsとRIPプロセスはイーサリアムプロトコル開発者がL2で機能を公開する必要がないが、Rollupsとイーサリアム開発者間のコミュニケーションを改善する必要があると指摘しました。そうすることで、Szilágyiが説明したような混乱を避けることができます。Van der Wijdenは、プロトコル開発者がL2で実施された変更をサポートするために時間を費やすことに懸念を示しましたが、これらの変更は最終的に時代遅れまたは不必要になる可能性があるため、L2自体がシャットダウンまたは使用を停止することがあります。

これらの懸念に対して、Dietrichsは「人々はLayer 2が実験を行い、より大胆になると考えてきたと思います。実際には、彼らのほとんどはそうしないことを決定し、少なくとも最初はそうするかもしれませんが、時間が経つにつれてほとんどの人がそれをやめてしまいました。したがって、彼らは実際には主に第一層の仕様に従っています。少なくともRollup中心のロードマップを考慮する限り、あるいは私たちがこれがエコシステムの発展に最適な方法だと考える限り、私たちはLayer 2に明確な指導とコミュニケーションを提供する必要があります。ここでの最良の進行方法として。」と述べました。