Ethernet開発者会議の総括：カンクンのアップグレード、ハードフォーク、そしてプラハ

By Christine Kim VP of Research at Galaxy;Compiled by：Chin Jin Carbon Chain Value

イーサ開発者は、2024年1月4日のZoom for All Core Developers Execution (ACDE) Call #178に集まりました。ACDEコールは通常、イーサネット財団のプロトコル・リードであるティム・ベイコが主催し、イーサネット実行レイヤ(EL)の変更について議論・調整するための開発者向けミーティングを隔週で開催しています。今週のミーティングは、'Lightclient'というスクリーンネームの匿名のGeth EL開発者が主催しました。開発者たちは、Cancun/Deneb (Dencun)アップグレードのための次の3つのパブリックテストネットアクティベーションの日程を再確認した。彼らはまた、Dencunの次のハードフォークアップグレードであるPrague/Electraにおけるコード変更（EIP）の優先順位についても議論しました。

Dencunアップデート

連休中、Dencunアップグレードに関する特別なアップデートはありませんでした。12月21日の最後のACDE電話会議以来、クライアント・チームはGoerliテスト・ネットワークの新しいリリースに取り組んでいます。Prysmのためにアップグレードのテストが遅れたため、Gethの開発者であるMarius van der Wijden氏はPrysmクライアントチームに、新バージョンのカットの進捗について最新情報を提供するよう依頼しました。Prysmの開発者であるTerence Tsao氏は、PrysmチームがGoerliハードフォークの新バージョンを来週には準備することを確認しました。しかし、Goerli用のバージョンは「プレリリース」バージョンとなり、メインのEtherネットワークでの使用を推奨するPrysmのバージョンではないことを意味します。Goerliのハードフォーク後、Prysmチームは、ユーザーがメインネットで実行し、SepoliaまたはHoleskyテストネットでテストすることを推奨する、特定の変更と更新を加えた別のバージョンをリリースする予定です。

Tsao氏は、ACDE #177で議論されたように、PrysmチームはGoerliハードフォークのアクティブ化日である1月17日に満足していると述べた一方で、SepoliaとHoleskyハードフォークのアクティブ化日をGoerliハードフォークの後に設定することを推奨しました。ACDE #177以降、イーサネット財団のプロトコルサポート責任者であるTim Beiko氏は、Goerli、Sepolia、Holeskyの3つのイーサネット公開テストネットのフォーク時期を提案しています。

Goerli - 2024年1月17日 - エポック231680 - タイムスタンプ1705473120

Sepolia - 2024年1月30日 - 時代132608 - タイムスタンプ1706655072

Holesky - 2024年2月7日 - 時代29696 - タイムスタンプ 1707305664

LightclientはPrysm以外のクライアントチームに、Beikoが提案したGoerliハードフォークの起動時間に同意するかどうか尋ねました。通話に参加したクライアントチーム（Geth、Lodestar、Lighthouse、Teku、Besuを含む）はすべて、このタイミングが良いと感じており、遅くとも来週までにはGoerliノードオペレータ向けのバージョンをリリースできるだろうと確認しました。のリリースはPrysmのようなプレリリースになるかもしれません。

Dencun Timeline Divergence

Lightclientが提案したSepoliaとHoleskyのテストネットワークのアクティブ化時間について議論が行われました。議論を始める時間Potuz」（仮名）というスクリーンネームのPrysm開発者は、本ネットワークの前に最後の2つのテストネットワークをアップグレードする日付を設定することを保留することを提案した。「Goerliではうまくいかないかもしれないし、そこから戻るのは問題がある。エポックを修正することなく新しいバージョンを追加するのは簡単です。バージョンを削除してバグを修正するのは問題だ。それは数週間よりもはるかに長い時間がかかります」とポツズ氏は言う。

Lightclientは、クライアントチームはGoerliハードフォークの1週間後まで新バージョンをリリースする必要がないと強調した。Gethの開発者であるMarius van der Wijden氏は、SepoliaとHoleskyのテストネットの日付を設定することに害はないと述べた。

イーサネット財団のDevOpsエンジニアであるBarnabas Busa氏は、彼の意見では、Goerliのバージョンが正常に動作していることを確認した後にのみ、SepoliaとHoleskyのアップグレードの新バージョンをリリースする必要があるとZoomチャットルームに書いています。セポリアとホレスキーのバージョンスクリーンネーム「Sean」のLighthouse開発者は、開発者はSepoliaハードフォークの「暫定的な」日付を設定することができるが、1月30日までにGoerliの進捗状況を確認する必要があると述べている。

Potuz氏は、GoerliとSepoliaハードフォーク起動の間に1週間のテストを追加することを提案した。彼は、1週間のテストを追加することで、クライアントチームが次のテストネットアップグレードのために再び新しいバージョンをカットする必要がある前に、クライアントディストリビューションを数日間「染み込ませる」ことができると述べた。「2週間は近すぎる。それが私が指摘したいことです」。Potuz氏は、もしGoerliクライアントディストリビューションが完全に分析され、テストされていたならば、SepoliaとHoleskyハードフォーク活性化の間に3週間のターンアラウンドは必要なかったかもしれないと付け加えた。

Potuz氏の指摘は論争を巻き起こした。イーサネット財団のAnsgar Dietrichs氏は、アップグレードの最初のパブリックテストネットアクティベーションとアップグレードのメインネットアクティベーションの間の時間は、通常、開発者にとっての「カットオフタイム」であり、延長する必要はないと主張しました。しかし、Dietrichs氏はまた、テストネットのアップグレード間の時間を長くしたいという要望は、Dencunのアップグレードだけでなく、ハードフォークの文脈で開発者たちによってより真剣に議論されるべきであると指摘しました。

Lightclient氏はDietrichs氏の意見に同意し、もし10月の早い段階で話し合いが行われていれば、開発者はDencunのテストネットのスケジュールを延長することに寛容であっただろうと述べた。昨年秋にアップグレードを完了させたかったということも理由のひとつだと思います。

積極的なタイムラインにこだわる

コールで意見を交換した開発者によると、イーサネット財団のDevOpsエンジニアであるParithosh氏は、次のように述べています。Jayanthi 氏は、Sepolia ハードフォークのアップグレードを 1 週間ほど遅らせ、Goerli アップグレードに続く 1 月 25 日の ACDE コールで、Sepolia ハードフォークの日付を設定することを提案しました。Marius van der Wijden 氏は、テストネットのアップグレード起動の日付を再検討するために、ACDE コールにのみ依存することに反対しました。「私が本当に避けたいのは、日付を確認するためにまたAll Core Devsに電話をかけなければならないことだ。

Gethの開発者Guillaume Ballet氏は、すべての関係者をなだめるために、Sepoliaハードフォークの暫定日程を2つ作ることを提案した。Goerliハードフォークの結果が肯定的であれば、開発者は1組の日程にこだわることができ、Goerliハードフォークの結果が否定的であれば、開発者はもう1組の日程を使うことができる。しかし、LightclientとDietrichsの両氏は、開発者がSepoliaハードフォークの新しいスケジュールを設定する前に、Goerliのバグや問題の性質を評価する必要があるため、このアイデアに反対している。

ところで、イーサネット財団のテストチームのスクリーンネーム "Danceratopz "の偽名開発者は、開発者がGoerliテストネットワーク上のブロブ期限切れ問題の評価を終えるまで、Sepoliaのアップグレードを待ちたいのかどうか尋ねた。とは、約2週間後にイーサ状態からブロブデータが削除されることを指します。

LighthouseのSean氏とBesuチームのJustin Florentine氏は、メインネットでDencunをアクティブにする前に、3つのテストネットのうちの1つでブロブの有効期限を評価することに賛成しています。Florentine氏は、テスト・ネットワーク上でblobの有効期限を待つことは、Dencunのアップグレードに備えるレイヤ2ロールアップ・プロトコル・チームやアプリケーション開発者にとっても有益であると強調した。LighthouseのSean氏は、Goerliでblobの有効期限を監視する必要はないが、SepoliaとHoleskyのテスト期間を延長して、開発者とレイヤー2チームがSepoliaでblobのライフサイクル全体を確認できるようにする理由になるかもしれないと述べた。電話会議に参加した他の開発者たちは、ショーンの提案に明確には同意しなかった。

その代わりに、Lightclientは電話会議の開発者たちに、Beikoが提案した1月30日にSepoliaをアップグレードし、1週間後の2月7日にHoleskyをアップグレードするというスケジュールにこだわるかどうかを尋ねました。Lightclientは、開発者たちは当初のスケジュールに従うと言い、PotuzはZoomのチャットで、前者を1週間早くアップグレードするのではなく、2月7日にSepoliaとHoleskyのテストネットの両方をアップグレードしたいと書いた。通話後のDiscordメッセージで、LightclientはDencunのテストネットのスケジュールが今のところ変更されていないことを再確認しました。

Prague/Electra

次に、開発者たちは、Dencunの次のアップグレードにどのような優先順位を与えるべきかについて議論しました。Marius van der Wijdenは、開発者は他のEIPよりもPrague/ElectraのMerkleツリーアップグレードの完了に集中すべきだと述べました。ACDE #177で議論されたように、開発者はメルクルツリーの実装の詳細とハードフォークアップグレードのための準備について掘り下げるために、ACDE専用の電話会議を計画しています。

ヴァン・デル・ヴァイデン氏が言及した2つ目の注意点は、EL上のアップグレードをコンセンサスレイヤー（CL）から切り離す能力でした。ヴァン・デル・ヴァイデン氏は、EL上のメルクルツリーアップグレードよりも早く実装する必要があるかもしれない、CL上の「優先度の高い、超緊急の」EIPがいくつかあると述べました。実装だ。「私は、コンセンサスレイヤーの人々が、これらの（緊急の）変更をハードフォークする必要があるのか、ELの関与なしにできるのか、それともELの関与が必要で、いずれにせよ共同でハードフォークする必要があるのかを議論することが重要だと思います。最優先事項であり、その両方を念頭に置いて推進すべきだ」と述べた。

イーサネット財団の研究者であるAnsgar Dietrichs氏は、Zoomのチャットルームで、プラハ/エレクトラのアップグレードをメルクルツリーに集中させることに「強く反対する」と書いている。Nethermindのクライアント開発者であるLukasz Rozmej氏は、Dietrichs氏の意見に同意した。Rozmej氏は、「私の経験から、状態の再設計は非常に難しく、非常に長い時間がかかることがわかりました。Merkleツリーは非常に優れており、素晴らしい進歩を遂げていると思いますが、Merkleだけに集中すれば、次のハードフォークには少なくとも1年以上かかると思います。ですから、私の提案は、各チームがMerkleに取り組み、適切なリソース、作業量、頭脳、あなたがそれを呼びたいものは何でも、トピックに割り当てる一方で、おそらくいくつかの小さなハードフォークに集中することでしょう。"

Merkleに集中する

Prague/ElectraがMerkleに集中すべきか、Merkleよりも早くリリースされる小さなコード変更を優先すべきかについては、意見が分かれています。Ballet氏は、彼の意見では「マイナーフォークというものは存在しない」と強調し、開発者がMerkleを実装する前に長く待てば待つほど、Etherの状態更新を実装することが難しくなると述べた。/チームの能力を活用し、1年の間に最大の難題に対処できることを証明しなければならない。もしメルケルが、3月までにもっともっと困難が山積していることをチームに示すようなことがあれば、人々は再び疑問を呈し、『メルケルは退団だ』と言うかもしれない。しかし、メルケル以外のEIPについては、プラハ/エレクトルがメルケル以外に取り入れる可能性のある重要なEIPをいくつか挙げて、スタンチャク氏は次のように述べた。Andrew Ashikhmin氏は、BooのPrague/Electraフォークで小規模なEIPをリリースし、後続のフォークで使用するためにMerkleを同時に開発することに賛成しました。Balletは、プラハ/エレクトラのMerkleに焦点を当てるというStańczakの提案に賛成した。

CLのアップグレードに集中する

EL（実行層）とCL（コンセンサス層）のアップグレードを切り離す問題について、Potuz氏は、プラハ/エレクトラではEIP提案が1つしかないことに言及した。Electraには、CLへの変更のみを必要とするEIP提案が1つしかない。「唯一の変更点は、認証インデックス委員会の廃止です。他のすべての変更は、マックスEBのようなCLのみの変更に見えるものであっても、ELの他の変更に依存している。だから、純粋なCLフォークは起きないと思う。少なくとも、今年はないと思うし、来年もないと思う。純粋なCLのプロポーザルが十分でないからだ」とポッツは語った。

にもかかわらず、アンスガー・ディートリヒスは、主にCLを中心としたアップグレードで、ELのクライアントチームが簡単に実装できるような、ELにわずかな変更しか必要としないEIPもあると述べた。DASが実装のためにハードフォークされる必要があるかどうかについては、Dietrichs氏とLightclientの間で意見が分かれています。

EOFおよび他のEIPの後

スクリーンネーム「Rodiazet」の偽名開発者は、イーサネット財団のIpsilonチームで働いています。EOFはイーサネット・バーチャルマシン（EVM）を開発している。背景として、EOFはEVM Object Formatの略で、当初Cancun/Denebアップグレードに含めることが検討されていたEVMの改良のセットです。

開発者は、Merkleに加えて、EIP 5920 (PAYオペコード) やEIP 2537 (BLS12-381カーブ操作のプリコンパイル) など、多数の他のEIPを検討するよう提案しています。アップグレードのメタスレッドにあります。Cancun/Deneb会議の後、ほとんどの開発者はMerkleをある程度優先することに賛成していますが、2024年に実装がより速く、より簡単になる可能性のある小規模なEIPよりも、Prague/ElectraのためにMerkleをどの程度優先すべきかは不明です。Lightclientは、プラハ/エレクトラに何が入るかを最終決定するために、開発者が今週の電話会議で決定する必要はないと強調した。彼は、この話題を次回のACDEコールで続けることを提案しました。

その後、開発者たちは、プラハ/エレクトラのトピックで、まだ電話会議で議論されていないEIPについて、次のEIPを含む（ただし、これらに限定されない）

EIP-。7002: エグゼクティブ層のトリガー可能な退出

EIP-7549: 委員会インデックスを認証外に移動

EIP-3074: AUTHおよびAUTHCALLオペコード

EIP-6110: チェーンにおけるバリデータ預託の提供

EIP-6110.EIP-4444: クライアントでバインディング履歴データを実行する

EIP-6404: SSZトランザクションルート

上記のEIPに関する意見の詳細な概要については、YouTubeに投稿された通話の全録音をご覧ください。

EIP7587の正式化

最後に、EtherFoundationフェローのCarl Beekhuizen氏が、EIP7587に関する議論を再考しました。Beekhuizenは、EIPを将来のEthermindガバナンス・プロセスのための仕様を作成する情報提供的なEIPとして、どのように正式化するのがベストかを開発者に尋ねた。Lightclient は、Ethermind Magician のウェブサイトでこのトピックについてさらに議論し、次回の ACDE コールで必要に応じてこのトピックを再検討することを提案しています。