イーサネットACDE会議：来年のDevnet3でコード変更が発表されるかもしれない

Pectra Devnet 3

EF Developer Operations EngineerのParithosh Jayanthi氏は、Pectra Devnet 3のリリースについて発表しました。このDevnetは9月11日（水）にリリースされました。EIP 7251のバリデータマージの修正と、EIP 7702の仕様の更新が含まれています。jayanthi氏は、NethermindクライアントとEthereumJSクライアントにいくつかの問題が見つかっており、両クライアントチームが解決に向けて取り組んでいることを指摘した。jayanthi氏は、EIP 7702はDevnet 3のリリースに含まれているため、EIP 7702を本番稼動させるのが最善であると付け加えた。Devnet 3が稼動したら、ウォレット開発者に実装をテストしてもらい、その使用感についてフィードバックしてもらうのがベストだろう。テストネットETHを要求するためのタップを含む、Pectra Devnet 3に関するすべての情報は、このサイトで見つけることができます。

Pectra Specification Update

Geth 開発者の Felix Lange は、Pectra における EL トリガーリクエストのエンコーディングの変更を提案しました。背景として、PectraはEL上のスマートコントラクトがCL上でバリデータの引き出しとマージを開始することを可能にします。前回のACDカンファレンスコールで、Lange氏はELクライアントがこれらのリクエストを解析するのに必要な作業量を削減する提案を共有した。先週の電話会議以来、ランゲは、次の4つのEIPのコーディングを更新するためにELクライアント・チームが行うべき作業と、彼の推奨を正式に決定しました:

EIP

EIP7002、EL Triggerable Withdrawal、

EIP6110、Chain Provisioning Validator Deposit、

EIP7251、最大有効残高の増加。

開発者たちは概ねランゲの提案に同意した。しかし、"Dustin "というスクリーンネームで呼ばれているニンバスの開発者は、この提案は「無意味な柔軟性」であり、将来的なELシリアライゼーションフォーマットの変更に対応するものではないと考えています。彼はまた、ELクライアントからのリクエストの順序と、ELがCLに無効なリクエストを送信したときのCLクライアントの動作を明示的に規制する追加仕様の必要性を強調しました。 Langeは、リクエストの順序を指定するためにEngine APIにテキストを追加することに同意しました。彼はまた、CLクライアントがELクライアントからの無効なリクエストを検出したときのCLクライアントの動作について、より深く検討する必要があることにDustinと同意しました。

イーサネット財団の研究者であるPeter Miller氏は、現在の仕様におけるCLクライアントの論理的な動作に基づき、CLクライアントは正しい順序でないELからのブロックを拒否すべきだと指摘しました。DustinはMillerの意見に同意し、開発者にこの動作を適切な文書に明記するよう提案した。Beiko氏は、開発者はLange氏の提案にある問題の解決に取り組み、次のACDコールが行われるまでに終わらせるべきだと述べた。

その後、エリゴン開発者の Andrew Ashikhmin 氏は、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 で運用されているディスカウントテーブルを変更することを推奨した。 Beiko氏は、今後2週間以内に、BLSのプリコンパイルのベンチマーキングを行い、これらのオペレーションを再プライシングするためのアイデアを出すようチームに提案しました。

Pectra EIPの追加

その後、開発者たちはPectraのアップグレードのために新しいEIPを追加するというトピックについて議論を始めました。ディスカッションの冒頭で、Beiko氏は「ペクトラにはすでに多数のEIPがあります。"EIPの数という点では、すでにこれまでで最大のフォークです。"」と警告しました。通話に先立ち開発者によって共有された見解に基づき、Beiko氏は、EIP 7742 (ELとCL間のブロブカウント分離)が、アップグレードに含めるかどうかまだ検討されているEIPのリストの中で、最も議論の余地が少ないことは明らかだと述べました。

EFの研究者であるAlex Stokes氏は、Pectraを2つの小さなハードフォークに分割するというアイデアを再び提起しました。「これが非常に大きなフォークであることは、誰もが認めるところだと思います。だから、2つに分割するのが自然だ。通常、小さなフォークの方がリスクは少ない。特に、ペクトラには多くのクロスレイヤーEIPがあり、テスト、セキュリティ、レビューの負担が大きくなっています」とストークス氏は語った。以前の電話会議でもこのアイデアを提案したジャヤンティ氏は、今でもこのアイデアを支持していると語った。「主な理由は、現在多くのEIPがあり、スタックの多くのレイヤーに触れる傾向があり、追加すればするほど、現在の負荷の下でも、一人の人間がすべての変更をグローバルに把握することが難しくなるからだと思います」とJayanthi氏は語った。

現在のPectra EIPを2つのブランチに分割する方法について、ストーク氏は、Pectraの最初の部分をリリースするために現在開発ネットワーク上で動作しているすべてのEIPを使用し、PeerDAS、EOF、および他のいくつかの追加EIPを使用してPectraの2番目の部分をリリースすることを提案しています。開発者たちは、こうすることで来年2月までにペクトラの最初の部分をリリースできると確信している。「もし我々がまだ6月に前半部分をリリースするだけなら、このフォークは失敗に終わると思う」とEFの研究者であるAnsgar DietrichsはZoomチャットで語った。

Beiko氏はフォークのアイデアには賛成だが、EIPを開発者ネットから削除することには反対だと警告している。独立系のイーサネットプロトコル開発者であるDanno Ferrin氏は、メインネットをアクティブにするために、できるだけ早くDevnet 3上でEIPを改良し、その後Devnet 4または5からPeerDASとEOFをPectra EIPに移す作業を並行して行うことを提案しています。実際、Pectraの後のアップグレードでは、Devnet 4または5はDevnet 0になり、開発者たちはどのような名前になるのか不明です。

以前の電話会議では、開発者たちはペクトラ・フサカにちなんでアップグレードに名前をつけることに合意しましたが、このアップグレードをヴァークル移行のために予約することにも合意しました。この点についてFerrin氏は、コードの変更がメインネットの活性化に使えると確信できるまで、アップグレードを事前に予約しないよう開発者たちに助言しました。これは、Verkle移行の取り組みを主導し、Verkle移行の準備は「ずっと前にできていた」と主張するGeth開発者ギョーム・バレ氏の怒りを買った。緊張を和らげるために、Beiko氏は、Pectraを2つに分割する目的は、最終的にはPectraのコード変更をより早いスケジュールでリリースすることで、その後のVerkle移行の道を切り開くためであると述べた。

しかしながら、ペクトラのアップグレードの第二部分は、より多くの EIP が追加されるにつれて大きくなり、したがって、現在のペクトラ EIP のリストが同時にリリースされた場合よりもリリースに時間がかかるというリスクがあります。Nethermindの開発者であるBen Adamsは、アップグレードが2つの部分に分割された場合、Pectraのテストプロセスはどのように機能するのだろうかと疑問を投げかけました。そのような決定が Ether の次の即時アップグレードの範囲を完全に変えてしまうことを考慮し、Beiko 氏は開発者たちにこのアイデアを検討するために 1 週間かかることを提案しました。彼は開発者たちに、来週の木曜日に行われる全コア開発者のコンセンサス・コールで、この問題について最終的な決定を下す準備をするよう求めた。

ネットワーク構成構造の調整

最後になりましたが、EFのDevOpsエンジニアである "pk910 "は、EtherNetパブリックテストネットワークのGitHubリポジトリをクリーンアップし、使いやすくするために再構築する作業の最新情報を共有しました。彼はクライアント・チームに対し、メインのイーサネット・ネットワークとテスト・ネットワークの両方のノード構成をチェックし、不足している情報があれば適切なリポジトリに追加するよう依頼しました。