著者：Christine Kim、Galaxy、編集者：Wu Baht、Golden Finance
2024 年 9 月 12 日、イーサリアム プロトコルの開発者は、第 196 回 All-Core Developer Execution (ACDE) 電話会議のために Zoom を介して仮想的に集まりました。今週の電話会議は、イーサリアム財団（EF）のプロトコルサポート責任者であるティム・ベイコ氏が主催した。 ACDE Conference Call は、開発者が Ethereum Execution Layer (EL) への変更について話し合い、調整する隔週のカンファレンス シリーズです。
ACDE#196では、開発者は Pectra Devnet 3 リリースの最新アップデートを共有し、将来の開発ネットワークに実装されるさまざまな Pectra コードの変更について議論しました。彼らは、おそらく来年 2 月までに、Devnet 3 のコード変更をより速いタイムラインでリリースできるように、アップグレードを 2 つの部分に分割することについて真剣に議論しています。開発者は、次回の ACD 会議でこれについて最終決定を下すことに同意しました。最後に、「pk910」という名前の EF 開発者オペレーション エンジニアが、イーサリアムのパブリック テストネット GitHub リポジトリをクリーンアップし、使いやすくするために再構築した自身の作業に関する最新情報を共有しました。
ペクトラ デヴネット 3
EF DevOps エンジニアの Parithosh Jayanthi が Pectra Devnet 3 のリリースについて説明します。開発ネットワークは 9 月 11 日水曜日に開始されます。これには、EIP 7251 でのバリデーターのマージに関する修正と、EIP 7702 の仕様の更新が含まれています。これまでの Devnet 3 でのテストによると、EIP 7251 と EIP 7702 は両方とも期待どおりに動作しているようです。 Jayanthi 氏は、Nethermind クライアントと EthereumJS クライアントでいくつかの問題が発見され、2 つのクライアント チームがそれらを解決するために懸命に取り組んでいることを指摘しました。 Jayanthi 氏は、EIP 7702 が Devnet 3 で稼働するので、ウォレット開発者に実装をテストさせ、その使用に関するフィードバックを提供するのが良い考えだと付け加えました。テストネット ETH をリクエストするためのフォーセットを含む、Pectra Devnet 3 に関するすべての情報は、この Web サイトで見つけることができます。
ペクトラ仕様の更新
Geth 開発者の Felix Lange は、Pectra の EL トリガー リクエストのコーディングの変更を提案しました。背景として、Pectra は EL 上のスマート コントラクトがバリデーターの引き出しと CL 上のマージを開始できるようにします。前回の ACD 通話中に、ランゲ氏は、EL クライアントがこれらのリクエストを解析するために必要な作業量を削減するための推奨事項を共有しました。先週の電話以来、ランゲ氏は自身の推奨事項と、次の 4 つの EIP のコーディングを更新するために EL クライアント チームが行う必要がある作業を正式にまとめました。
EIP 7685、汎用実行層リクエスト。
EIP 7002、EL は引き出しをトリガーできます。
EIP 6110、オンチェーンサプライバリデーターデポジット。
EIP 7251、最大有効残高を増やします。
開発者はおおむねランゲ氏の提案に同意している。しかし、「ダスティン」と名乗るニンバス開発者は、この提案は「無意味に柔軟」であり、EL シリアル化フォーマットへの将来の変更に対して上位互換性がないと考えています。同氏はまた、EL クライアントからのリクエストの順序と、EL が無効なリクエストを CL に送信したときの CL クライアントの動作を明確に規制するには、追加の仕様が必要であることも強調しました。 Lange 氏は、リクエストの順序を指定するためにエンジン API にテキストを追加することに同意しました。また、CL クライアントが EL クライアントからの無効なリクエストを検出したときの CL クライアントの動作について、より詳細な考慮が必要であるという点でも、Dustin 氏に同意しています。
イーサリアム財団の研究者ピーター・ミラー氏は、現在の仕様に基づく CL クライアントの論理的動作に基づいて、CL クライアントは正しい方法で順序付けされていない EL からのブロックを拒否する必要があると指摘しました。さらに、EL によって CL に共有されるリストに無効なリクエストがある場合、CL はリスト内のすべての有効なリクエストを単純に処理し、無効なリクエストを無視する必要があります。 Dustin 氏も Miller 氏の意見に同意し、開発者が適切なドキュメントでこの動作を指定することを推奨しています。ベイコ氏は、開発者はランゲ氏の提案の問題点の修正に取り組み、次回のACDコールまでに完成させるべきだと述べた。
その後、Erigon 開発者の Andrew Ashkhmin 氏は、EOA アカウント コードを設定する EIP 7702 へのアップデートを提案しました。同氏は、EIP で指定されている有効性チェックが古い EIP で指定されているものと矛盾していると指摘しました。 Geth 開発者の Matt Garnett (別名「Lightclient」) は、一貫性の問題に対処し、EIP 7702 の有効性チェックを簡素化する代替手段があると述べています。開発者のほとんどは、Lightclient 提案を最終決定し、それを Pectra Devnet 4 に追加することに賛成しています。
Pectra に関連する次の議論は、EIP 2537 に基づく BLS プリコンパイルの価格設定についてです。 Geth 開発者の Jared Wasinger 氏は、ベンチマーク分析に基づくと、BLS プリコンパイルのコストは現在言われているコストの 2 倍になるはずだと述べました。現在、コストはマルチスレッド実行に基づいており、他のプリコンパイル済み実行の価格設定の標準ではありません。したがって、Wasinger 氏は、シングルスレッド実行を使用した分析に基づいて、EIP 2537 での操作の割引テーブルを変更することを推奨しました。 Nethermind チームは、他のクライアント チームが独自の EIP ベンチマーク分析を簡単に実行できるツールを開発中であると報告しています。 Beiko 氏は、チームが BLS プリコンパイルに関する独自のベンチマークを実施し、今後 2 週間以内にこれらの操作の価格を再設定するアイデアを見つけることを提案しました。
ペクトラ EIP サプリメント
その後、開発者は Pectra アップグレード用に新しい EIP を追加することについて議論を開始しました。ディスカッションの開始時に、Beiko 氏は次のように警告しました。「Pectra にはすでに多数の EIP があります。電話会議の前に開発者によって共有された見解によると、これはすでに EIP ボリュームの点でこれまでで最大のフォークです。」明らかに、EIP 7742 (EL と CL 間のブロブ数の分離) は、アップグレードに含めることがまだ検討されている EIP のリストの中で最も議論の余地のないものです。
EF 研究者の Alex Stokes は、Pectra を 2 つの小さなハードフォークに分割するというアイデアを再び浮上させました。 「これが非常に大きなフォークであることには誰もが同意すると思います。したがって、これを 2 つに分割するのが自然なことです。一般的に、フォークが小さいほどリスクが低くなります。特に、Pectra には現在、多くのクロスレイヤー EIP があり、それは本当に重要です」テスト、セキュリティ、レビューの負担が増大します」とストークス氏は語った。以前の電話でもこのアイデアを提起したジャヤンティ氏は、今でもこのアイデアを支持していると述べた。 「主な理由は、現在、多くの EIP があり、スタックの多くの層に触れる傾向があり、追加するほど、すべての変更の全体像を把握するのが 1 人では困難になるためだと思います。現在の負荷の下でも」とジャヤンティ氏は語った。
現在の Pectra EIP を 2 つのブランチに分割する方法について、Stokes 氏は、開発ネットワーク上で現在実行されているすべての EIP を使用して Pectra の最初の部分をリリースし、次に PeerDAS、EOF、およびその他のいくつかの追加 EIP を使用して Pectra の 2 番目の部分をリリースすることを提案しました。ペクトラ。開発者はこれにより、来年 2 月までに Pectra の最初の部分をリリースできると確信しています。 「6月にまだ前半しかリリースしていなかったら、このフォークは失敗だったと思います」とEFの研究者アンスガー・ディートリヒス氏はZoomチャットで語った。
Beiko 氏はフォークというアイデアを支持していますが、開発ネットから EIP を削除することには警告しています。これは、顧客チームの作業が増え、メインネットのアクティベーションに向けたコード変更の準備のタイムラインが短縮されるのではなく、延長される可能性があるためです。独立系イーサリアム プロトコル開発者の Danno Ferrin 氏は、Devnet 3 で EIP をできるだけ早く完了してメインネットをアクティブ化し、Devnet 4 または 5 から並行して作業を開始して PeerDAS と EOF を Pectra EIP に再配置することを推奨しました。実際、Pectra 以降のアップグレードでは、Devnet 4 または 5 が Devnet 0 になるため、開発者はこれにどのような名前を付けるか迷っています。
以前の電話会議で、開発者はアップグレードに Pectra Fusaka にちなんだ名前を付けることに同意しましたが、アップグレードを Verkle 移行用に保留することにも同意しました。その点に関して、Ferrin 氏は開発者に対し、コード変更がメインネットのアクティベーションに向けた準備が整っていると確信するまではアップグレードを予約しないようにアドバイスしました。これは、Verkle 移行の取り組みを主導し、Verkle への移行は「ずっと前に」準備ができていたと主張してきた Geth 開発者の Guillaume Ballet 氏の激怒を引き起こしました。緊張を和らげるために Pectra を 2 つに分割する目的は、最終的には Pectra のコード変更をより速いタイムラインでリリースすることを試みることであり、それがその後の Verkle 移行への道を切り開くのに役立つだろうと Beiko 氏は述べた。
ただし、Pectra アップグレードの 2 番目の部分は、より多くの EIP が追加されるにつれて規模が大きくなり、現在の Pectra EIP リストが同時にリリースされるよりもリリースに時間がかかる可能性があるというリスクがあります。 Nethermind 開発者の Ben Adams は、アップグレードが 2 つの部分に分割された場合に Pectra のテスト プロセスがどのように機能するか疑問を呈しました。この決定により、イーサリアムの次回の即時アップグレードの範囲が完全に変わることを考慮して、ベイコ氏は開発者に対し、このアイデアを検討するのに1週間かかるよう推奨した。同氏は開発者に対し、来週木曜日の全コア開発者コンセンサスコールでこの件について最終決定を下す準備をするよう求めた。
ネットワーク構成構造の調整
最後になりましたが、EF DevOps エンジニア「pk910」は、イーサリアムのパブリック テストネット GitHub リポジトリをクリーンアップし、使いやすいように再構築するという自身の作業に関する最新情報を共有しました。同氏はアカウントチームに対し、イーサリアムメインネットとテストネットのノード構成を確認し、不足している情報があれば対応するリポジトリに追加するよう依頼した。
