原題: "Ethereum All Core Developers Execution Call #189 Writeup" 原著者: Christine Kim 原編集: Luccy、BlockBeats 編集者注: Ethereum All Core Developers Execution Call (ACDE) は、主に議論と調整のために 2 週間ごとに開催されます。イーサリアム実行層 (EL)。これは ACDE の 189 回目の電話会議で、開発者は EOF や EIP 7702 を含む変更、Pectra スコープの改善、Verkle 移行の準備など、Pectra アップグレードのいくつかの重要な問題について議論しました。この会議では、EOF およびその他の Pectra EIP がどのようにパッケージ化されるか、およびこれらのコード変更がどのようにテストされるかについても議論されました。さらに、ACD 電話会議のトピックディスカッションの頻度の調整や新しい EIP ラベルの提案など、イーサリアム ネットワークのアップグレード プロセスを改善するためのいくつかの提案が導入されました。 EIP 4444とポータルネットワークの統合の進捗状況についても言及されています。 Galaxy Digital のリサーチ担当副社長である Christine Kim は、この会議の要点を詳細に記録し、原文を次のようにまとめました。

2024 年 6 月 6 日、イーサリアム開発者は All Core Developers Execution (ACDE) コール #189 ミーティングに参加するために Zoom に集まりました。 ACDE 電話会議は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコが主催する隔週の一連の会議であり、開発者はイーサリアム実行層 (EL) への変更について話し合い、調整します。今週、開発者は Pectra アップグレードに EOF と EIP 7702 を含めることに同意しました。これらのコード変更によるマルチクライアント テストのアップグレードの遅延を回避するために、開発者は、開発者がPeerDAS のテストを計画しているのと同じように、開発後のネットワーク上で、おそらく他の EIP とは異なるアクティベーション サイクルで EOF をアクティベートすることに同意しました。また、Verkle に備えて大阪アップグレードで EIP 158 を廃止する方法と、ポータル ネットワークとの統合による EIP 4444 実装の次のステップについても議論しました。最後に、Beiko と EF Developer Operations (DevOps) チームは、イーサリアムのアップグレードを計画するためのガバナンス プロセスとコミュニケーション チャネルに関する最新情報を共有しました。

ペクトラの範囲

今週の ACD ミーティングに先立ち、さまざまな EL クライアント チームと EF DevOps チームが Pectra の範囲についての考えを共有しました。

会議前に共有された意見に基づくと、クライアント チームの大多数が Pectra に EOF を含めることを支持していることは明らかです。 EOF に強く反対している唯一のクライアント チームは Geth です。 Geth 開発者の Guillaume Ballet 氏は次のように述べています。「待てば待つほど Verkle の移行に時間がかかるのではないかと心配しています。EOF は本当にそんなに急務なのでしょうか? 私はそうは思いません。EOF のリリースに関する議論をいくつか読みました。プラハ 「読めば読むほど、EOF が本当に必要であることを証明するものは何もないことが分かりました。」 何人かの開発者が異議を唱えました。

「Kamil Sliwak」という名前の開発者は、Ethereum スマート コントラクト プログラミング言語 Solidity のコンパイラーを操作するユーザーの観点から、EOF は「大幅な改善」になると述べました。 Reth開発者のドラガン・ラキタ氏は、EOFがVerkleへの移行を大幅に遅らせると考えるのは不誠実であると付け加えた。 「移行時間の10％から20％の増加について話しています。EOFは状態を増加させません、そして追加の部分フォークをリリースするための追加の3か月はVerkleを大幅に遅らせることはありません」とラキタ氏は述べた。 EOF とは何か、また EOF によってイーサリアム仮想マシン (EVM) がどのように改善されるかについて詳しくは、 Infinite Jungleポッドキャストのこのエピソードを聞いてください。

Beiko 氏は、EOF を他の Pectra の EIP とバンドルするか、Pectra の EIP を 2 つのハード フォークに分割するかを開発者に尋ねました。 Erigon の開発者 Andrew Ashkhmin 氏は、開発者はすべての Pectra の EIP をまとめてリリースするか、Verkle 移行後まで EOF を延期するべきだと考えていると述べた。 「私が望んでいないのは、ペクトラとヴァークルの分裂がEOFを解除することだ。国家が成長しているという意見には私も同意するので、ヴァークルはEOFよりも重要だと思う。したがって、私の意見では、これは考えられる最悪の結果だ。 」とアシクミンは言った。 Beiko 氏は、EOF を含むすべての Pectra の EIP を 1 つのクライアント バージョンでリリースすることを推奨しています。ただし、テスト目的の場合、開発者は開発ネットワークを使用してこれらのコード変更を段階的に実装することを検討する必要があると同氏は述べた。 「マルチクライアント テストの観点から優先順位を付ける方法として開発ネットワークを使用し、EOF によって物事が長期間遅れることがわかった場合は、分割することを決定できます」と Beiko 氏は述べています。

EOF を Pectra に組み込む方法に関するこうした議論のさなか、Geth 開発者は、Zoom チャットや会議中、EOF をアップグレードに含めるべきかどうかについて疑問を表明し続けました。 EOF をめぐる Geth チームの継続的な議論に応えて、Reth 開発者の George Konstantinopoulos 氏は次のように述べています。 「ステータスが低下しているということは、これは紛らわしい議論であり、多くのアプリがそれが良い機能だと主張しているのに、ほとんどの人がそれをサポートしているのに、なぜそれをやらないことを検討する必要があるのでしょうか？」

Beiko 氏はこれに同意し、EOF は Pectra に含めるべきだが、開発ネットワークで段階的にテストする必要がある、つまりクライアント チームは Devnet 0 に既に実装されている Devnet 1 EIP でテストする必要があると繰り返し述べました。次に、将来の開発ネットワークで、テスト用に EOF を追加します。この戦略により、クライアント チームは同じタイムラインで Pectra の EIP の一部をリリースすることに集中し、マルチクライアント開発ネットワークでの進歩を続けることができます。イーサリアム財団（EF）の DevOps エンジニアであるマリオ・ベガ氏は、EOF の実行層（EL）仕様テストが 2 か月以内に準備できると予想していると述べました。 EF DevOps エンジニアの Parithosh Jayanthi 氏は、EOF は Pectra の他の実行層 (EL) EIP とは別にテストできると述べました。しかし、彼は、Pectra のコンセンサス レイヤー (CL) EIP 間の相互依存性と、これらのコード変更のテストの複雑さを懸念しています。

Vyperコンパイラ開発者のCharles Cooper氏は、彼の見解では、再入攻撃に対する保護を安価かつ一般的なものにするために提案したコード変更ほどEOFは緊急ではないと述べた。 Beiko 氏は Cooper 氏に、EOF に関する広範なコンセンサスは明らかだが、クライアント チームに、リエントラント攻撃に関連するコード変更など、コード変更をさらに追加するだけの十分なエネルギーがあるかどうかは不明であると指摘しました。 「EOFを進めれば、他のことを行うためのエネルギーはほとんど残されていないことは明らかだと思います。これはすでにこれまでで最大の分岐点となるでしょう」とベイコ氏は語った。

EOF を含めることに加えて、開発者は EIP 3074 の代替として EIP 7702 についても合意しました。開発者は現在も別のグループ会議で EIP 7702 仕様について議論しています。 Beiko は、EIP 7702 の EOF に対しても同様のアプローチを推奨しています。 「フォークに含めるつもりですが、仕様に満足できない場合は、それを Devnet 1 または 2 の一部にせず、次の 1 か月をかけて仕様を徹底的に整理し、より良い取り消しを実現します」現在提案されているものよりも大きなメカニズムが追加される予定です」とベイコ氏は語った。 Geth 開発者の「Lightclient」は、クライアントチームの準備ができたら、できるだけ早く EIP 7702 を実装する必要があると述べました。次の緊急 Pectra 開発ネットワークである Devnet 1 に EIP 7702 を含めることに異論はありません。

ペクトラ仕様

その後、Teku 開発者の Mikhail Kalinin が、既存の Pectra EIP 仕様に対するいくつかの更新を共有しました。 1 つ目は、実行層 (EL) ブロックで直接ではなく、サイドカー メカニズムを通じてコン​​センサス層 (CL) リクエストのトリガーを処理するという提案です。 Prysm 開発者の「Potuz」は、この戦略は将来のコード変更に必要なロジック、つまりプロポーザーとビルダーの明確な分離 (ePBS) を壊すことになると指摘しました。 「ビーコン ブロックは、すでにそこに存在するペイロードに依存すべきではありません。したがって、出金であろうと入金であろうと、ビーコン ブロックがペイロードの内容に依存することは望ましくありません。ePBS の流れが中断されてしまうからです。」とポトゥズ氏は述べています。言った。この問題のため、Kalinin は提案を撤回し、GitHub 上のプル リクエストを閉じることに同意しました。

Kalinin 氏は、Pectra の EL およびエンジン API 仕様に対する他のいくつかの変更点を共有しました。その 1 つは、EIP 7251 で EL トリガーによるマージを有効にし、MAX_EFFECTIVE_Balance を増加させることです。 Beiko は、開発者が次の ACD コールの前にこれらの変更を確認して、変更を最終化し、Devnet 1 でテストできるようにすることを推奨しています。

バークルの準備

Barlet 氏は、Verkle 移行に関する研究に基づいて、EIP 158 は非推奨のオペコード SELFDESTRUCT と同様の問題を引き起こすだろうと述べました。移行後のネットワークの複雑化を回避するために、Ballet では Pectra のアップグレードで EIP 158 を無効にすることをお勧めします。ただし、EIP 7702 の実装が Pectra で微調整される場合、EIP 158 の廃止が遅れ、Verkle 移行と一致する可能性があると同氏は指摘しました。ベイコはギョームに EIP 158 を非アクティブ化するための提案の草案を書き始めるよう提案した。

履歴の有効期限が切れました

Pectra と Verkle に加えて、イーサリアム プロトコルの開発者も歴史的な有効期限である EIP 4444 に取り組んでいます。 EIP 4444 の計画と概要文書に記載されているように、このコード変更の理由は、「ブロック履歴はノード上で多くのスペースを占有し、ブロックが完了すると、限られた非合意の場合にのみ必要になる」というものです。重要なユースケース。」文書は続けて、「ブロック履歴は完全なノードによって永続的に保存されなくなり、一定期間が経過するとノードから削除され、必要なエンティティはブロック履歴をクエリする必要があります。ポータル ネットワークは、イーサリアムの履歴データをクエリするためにノードによって使用される、代替の分散型ネットワークです。

Merriam 氏は、ポータル ネットワークとの統合サポートを EL アカウント チームに提供するというチームの意欲を繰り返しました。同氏によると、何の支援もなければ、統合の進展には約6カ月かかるだろうという。しかし、指導と緊密な協力があれば、今後 2 か月以内に EIP 4444 に関して有意義な進歩を遂げることができると彼は楽観的です。 Jayanthi は、ポータル ネットワーク仕様のセキュリティ監査が行われたかどうかを尋ねました。メリアムはノーと答えた。イーサリアム財団の研究者アンスガー・ディートリヒス氏は、既存のクライアントとの統合をバンドルするか、新しいクライアントを構築するか、統合をまったく行わないかなど、ネットワークとのインターフェース方法を顧客チームが自分たちで決定できるかどうかを尋ねた。メリアムは、この決定がクライアント チームの裁量によるものであることを認めています。

メリアム氏は電話会議でELアカウントチームにEIP 4444に関する進捗状況と意図について尋ねた。 Nethermind の開発者 Łukasz Rozmej 氏は次のように述べています。「全体として、これは優先事項です。私たちは昨日ポータル チームとミーティングを行いました。問題は、優先事項が多すぎることです。そのため、優先事項はそれほど緊急ではありません。」たとえば、ハードフォークですが、Nethermind がそれに取り組むでしょうし、私たちはそれを優先します」と Besu 開発者のマット ネルソン氏は同じように感じていると述べました。 Geth 開発者の Guillaume Ballet 氏は、彼のチームは Portal Network の統合について議論していないと述べた。

ACDプロセスの改善

ACD プロセスの改善 次に、Beiko 氏は、イーサリアム ネットワークのアップグレード プロセスを改善するためのいくつかの提案を共有しました。同氏はまず、アカウントチームがまだ詳細に検討していないトピックについて、ACD 通話でのディスカッションの頻度を減らすことを推奨しました。 Beiko 氏は、開発者が専門的な議論に参加できるようにする前に、ACD コールでこれらのトピックにレビュー用のフラグを立て、必要に応じて後続の ACD コールでさらに詳細に議論することを推奨しています。

Beiko が行った 2 番目の提案には、通常、ハードフォークへの組み込みが検討されているイーサリアム改善提案 (EIP) に付随する「組み込み検討」 (CFI) ステータスが含まれます。このステータスはこれまで、どの EIP がハード フォークに含まれる可能性が高いかを示す有用な指標ではありませんでした。 Beiko 氏は、開発者がどの EIP がハード フォークに含まれる可能性が高く、どの EIP が含まれないかをよりよく区別できるように、「Pending for Inclusion」(PFI) という別のラベルを作成することを提案しました。

イーサリアム財団の研究者、アンスガー・ディートリヒス氏はZoomチャットで、EIPの新しいラベルを作成することは「間違った方向」であり、CFIラベルが「完全に役に立たなくなる」だけだと書いた。 Beiko氏は、開発者はGitHubとEthMagiciansでネットワークアップグレードプロセスの改善について引き続き議論できると述べた。

さらに、イーサリアム財団のDevOpsエンジニアであるマリオ・ベガ氏は、テスト関連のアップデートのために新しいDiscordサブチャンネルを作成したいと述べた。ベガ氏は、現在イーサリアムの研究開発ディスコードでは、テストリリース情報が複数のチャネルに散在していると述べた。しかし、同氏は、新しいフォーラムが、顧客チームがイーサリアム財団のDevOpsチームからテストアップデートを入手するための「ワンストップ」のリファレンスとなることを望んでいる。彼はアカウント チームにこれに関するフィードバックを提供するよう依頼しました。

最後に、Beiko 氏は開発者に対し、今後数日間に 2 つのグループ ミーティングが予定されており、1 つは ePBS で 6 月 7 日に開催され、もう 1 つは PeerDAS で 6 月 11 日に開催されることを思い出させました。