イーサリアムコア開発者最新会議の要約：Pectraアップグレードは2つのハードフォークに分かれる可能性があります。

著者：Christine Kim

翻訳：Luccy，BlockBeats

編者按：イーサリアムのすべてのコア開発者のコンセンサス電話（ACDC）は、2週間ごとに開催され、主にイーサリアムのコンセンサス層（CL）への変更について議論し調整します。今回はACDC第134回電話会議で、開発者たちはEIP 7549、EIP 7251、EIP 6110、EIP 7688など、複数の重要なEIPの実装の詳細と技術的課題について議論しました。

さらに、開発者たちはPeerDASの実装についても深く議論しました。このデータ可用性サンプリング技術は、イーサリアムネットワークがロールアップとそのデータ可用性のニーズをサポートする能力を大幅に向上させると予想されています。会議では、Pectraを2つのハードフォークに分けてアップグレードする提案が出され、異なるEIPのアクティベーションタイミングと相互依存関係の問題についても議論されました。

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

2024年5月30日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Consensus (ACDC) call #134会議に参加しました。ACDC電話会議は、イーサリアム財団の研究員Alex Stokesが主催する、2週間ごとに開催されるシリーズ会議で、開発者たちはイーサリアムのコンセンサス層（CL、別名ビーコーチェーン）への変更について議論し調整します。今週、開発者たちはPectra Devnet 0の立ち上げ後の経験と未解決の問題について議論しました。また、Pectraのアップグレードの範囲をpeerDASとSSZコンテナのコード変更を含むように拡大することの実現可能性についても議論しました。

Devnet 0の振り返り

PectraのDevnet 0での立ち上げ状況に基づき、クライアントチームはハードフォークのアクティベーション中にEIP 7549の影響を受けた検証行動を変更しないことに同意しました。以前のACDC会議では、開発者たちはハードフォーク中にEIP 7549の影響が大量の無効な検証を引き起こさないようにするためのさまざまなオプションを検討しました。アップグレードをさらに複雑にしないために、クライアントチームは他のPectra EIPと同じエポックでEIP 7549をアクティベートし、フォーク前後で検証行動を変更しないことを決定しました。

EIP 7251について、開発者たちは実行層（EL）からステーキングETHのマージをトリガーすることを許可すべきかどうかまだ確信が持てませんでした。これはLidoのようなステーキングプールにとって理想的な機能であり、ステーキングのマージがノードオペレーターに依存せず、スマートコントラクトを通じて実現できるようになります。Stokesは数週間後にクライアントの実装の検証者ステーキングマージの進捗を確認し、それらがEL操作であるべきかCL操作であるべきかを決定することを提案しました。

その後、開発者たちはEIP 6110に基づく検証者の預金の最終確認に関するいくつかの未解決の問題について議論しました。Tekuの開発者Mikhail Kalininは、会議前のGitHubのコメントでこれらの問題の解決方向をまとめました。Lighthouseの開発者「sean」は、Engine APIの「GetPayloadBodies」リクエストのバージョン管理に関する問題を提起しました。Stokesは、開発者たちがこの問題に関してGitHubで作成されたプルリクエストに意見を述べることを提案しました。

EIP 7549の変更

Nimbusの開発者Etan Kisslingは、EIP 7549の実装に小さな変更を提案しました。「これは一般化インデックスの安定性の問題に関するものです。コンテナの中間に新しいフィールドを追加すると、後続のフィールドに新しいインデックスが割り当てられ、EIP 4788に基づく実行層（EL）の証明が破損し、誤解を招く可能性があります。……したがって、新しいフィールドを末尾に移動して、これらの2つの問題を回避することを提案します。」Kisslingは説明しました。この変更に対して異議を唱える人はいませんでした。Stokesは、開発者がGitHubでKisslingが提案したプルリクエストを確認することを提案しました。

EIP 7549に対するもう一つの変更は、会議中に提案されたもので、リクエストやELによってトリガーされた他のリクエストをELブロックの追加プログラムとして設計することです。この変更について、Kalininは「私の見解では、これは非常に良い設計案であり、ELを簡素化します……そして、これは基本的に実行層ブロック内の一般化リクエストの代替案です。」と述べました。Stokesは、次回のCL会議でこのトピックを再度議論することを提案し、開発者がGitHub上のこの提案をより多くの時間をかけてレビューできるようにしました。

Pectraの範囲に関する議論

コンセンサス層（CL）に焦点を当てたEIPのいくつかは、Pectraのアップグレードに正式に含まれていないか、除外されています。今週の会議では、開発者たちはPectraにEIP 7688とPeerDASを追加するかどうかを議論しました。EIP 7688は「StableContainer」SSZデータ構造の一部を採用しており、EIP 7549による証明の変更が前方互換性を持つことを保証します。背景として、SSZはCLで使用されるデータ構造であり、開発者は実行層（EL）でも使用することを望んでいます。SSZの変化に関する詳細は、以前の会議記録を参照してください。PeerDASはイーサリアム上のデータ可用性サンプリングの実装であり、ネットワークがロールアップとそのデータ可用性のニーズをサポートする能力を大幅に強化すると予想されています。実際の運用では、PeerDASは検証者がブロックに追加できるblobトランザクションの数を各ブロック3つから64以上に増加させると予想されています。

イーサリアム財団の開発者オペレーションエンジニアBarnabas Busaは、開発者たちが開発ネットワーク上でPeerDASの初期バージョンを立ち上げたと述べました。「多くのクライアントが多くの問題を発見していると思います。実質的な進展があれば、いつでも新しい開発ネットワークを再起動できます。」とBusaは言いました。Stokesは、開発者たちがアップグレードの遅延を引き起こす可能性がある場合にPeerDASをPectraに追加することを望んでいるかどうかを尋ねました。

「Nishant」というニックネームの開発者は、PeerDASのアクティベーションをPectraの他のEIPのアクティベーションから分ける提案を再度行いました。これは実現可能ですが、「atd」というニックネームの別の開発者は、開発者が短期間でこれらのアップグレードを順次アクティベートする計画がある場合、ユーザーはソフトウェアを同時にアップグレードする必要があると強調しました。atdは「私は、別のアップグレードの2ヶ月後にフォークするのは少し狂っていると思います。すべての人にクライアントをアップグレードさせるために調整する必要がある場合、2ヶ月後に再度すべての人にクライアントをアップグレードさせたくありません。その場合、1つのリリースサイクルさえも足りません。」と言いました。

atdは、彼の見解では、PeerDASはPectraに含まれ、議論されるEIPの中で最も「興味深い」コード変更であると付け加えました。Stokesは、たとえこれがアップグレードの遅延を引き起こすとしても、PeerDASをPectraに含めたいと述べました。Grandineクライアントの開発者Saulius Grigaitisは、PeerDASをサポートするためにEIP 7549とEIP 7688をPectraから削除することを提案しました。これにより、EIP 7688の実装の詳細についての議論が引き起こされました。開発者たちはコード変更について合意に至らず、次回のACDC会議でこの提案を再度議論することになりました。

PeerDASに関するトピックについて、開発者たちはPectraを2つのハードフォークに分けるアイデアを引き続き検討しました。イーサリアム財団の開発者オプションエンジニアParithosh Jayanthiは、開発者がPectraを2つのアップグレードに分ける場合、将来のPectraの第2部に新しいEIPを追加しないように注意する必要があると警告しました。Jayanthiは「私が言いたいのは、2つのフォークに分けることを考える場合、次のフォークに新しいEIPを追加しないように非常に注意しなければならないということです。私たちがそれを実現できるかどうかはわかりません。私たちが1年または1年半前に何かを約束できるなら、私たちは常に新しいアイデアを提案し、優先順位が変わっているからです。」と言いました。

2つのアップグレードのアイデアを引き続き議論する中で、Lighthouseの開発者「sean」は、PeerDASと現在のPectra EIPリストの間に多くの相互依存関係があるとは思わないと述べました。したがって、これらは別々に行うことができ、開発者がそれらの実装に自信を持つようになったときに簡単に統合できると考えました。atdはこの見解に同意し、これらの内容を別々に開発およびテストした後、Pectra EIP、PeerDAS、およびEIP 7688を統合することには大きなリスクがないと考えました。

Busaは、Pectra EIPとPeerDASのテストを続けることを提案しましたが、コード変更をPeerDASが開発ネットワークとテストネットワークでPectra EIPよりも1エポック遅れてアクティベートされるように設計しました。彼は、これはすでにDevnet 0でPectra EIPとPeerDASのテストを行う方法であると指摘しました。Busaは「実際には何も変更する必要はありません」と述べ、PeerDASが他のPectra EIPが準備できたときにまだ準備ができていない場合、開発者はそのコード変更をアップグレードから削除できると付け加えました。これにより、PeerDASの異なるアクティベーションエポックがクライアントチームの作業にどのように影響するかについていくつかの疑問が生じました。最終的に、開発者たちはPeerDASとPectra EIPの開発を続けることに同意しましたが、前提としてPeerDASが開発ネットワークとテストネットワークで異なるエポックでアクティベートされることが求められました。

前述のように、開発者たちはEIP 7688をPectraに含めるかどうかの議論を次回のACDC電話会議に持ち越すことに同意しました。