イーサリアム開発者会議の振り返り：カニオンアップグレード、ハードフォーク、プラハ
TechFlow厳選深潮セレクト
イーサリアム開発者会議の振り返り：カニオンアップグレード、ハードフォーク、プラハ
会議では、Dencun の次のハードフォークアップグレードであるプラハ／エレクトラにおけるコード変更の優先順位についても議論された。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Christine Kim、Galaxy リサーチ副社長
翻訳：秦晋、碳链价值
2024年1月4日、イーサリアム開発者たちはZoomによるAll Core Developers Execution（ACDE）Call #178に集まりました。ACDEミーティングは通常、イーサリアム財団のプロトコル担当であるTim Beiko氏が主催し、イーサリアムの実行レイヤー（EL）における変更について開発者が議論・調整を行う隔週の会議です。今週の会議は、「Lightclient」という匿名のGeth EL開発者によって主宰されました。開発者たちは、キャンクン／デネブ（Dencun）アップグレードにおける今後の3つのパブリックテストネットのアクティベーション日程を再確認しました。また、Dencunの次のハードフォークアップグレードであるプラハ／エレクトラ（Prague/Electra）において、どのコード変更（EIP）を優先すべきかについても議論しました。
Dencunのアップデート
休暇期間中、Dencunアップグレードに関する具体的な更新はありませんでした。前回のACDE #177以降、クライアントチームはGoerliテストネット向けの新バージョンの準備を進めてきました。Prysmの問題により以前アップグレードのテストが遅延していたため、Geth開発者のMarius van der Wijden氏は、Prysmクライアントチームに対して新バージョンのリリース状況の最新情報を求めました。Prysm開発者のTerence Tsao氏は、Prysmチームが来週中にGoerliハードフォーク用の新バージョンを準備できると確認しました。ただし、Goerli向けのこのバージョンは「プレリリース」バージョンであり、メインネットでの使用を推奨するものではないと説明しました。Goerliハードフォーク後に、特定の変更や更新を含んだ正式版がリリースされ、そのバージョンがメインネットおよびSepoliaやHoleskyテストネットでの使用を推奨される予定です。
Tsao氏は、ACDE #177で議論された通り、Goerliのハードフォークアクティベーション日を2024年1月17日とすることに満足していると述べましたが、Goerliのハードフォーク後までSepoliaおよびHoleskyのアクティベーション日を確定しないよう提案しました。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ノードオペレータ向けのバージョンをリリースできる見通しだと述べました。Lighthouseクライアントチームは、現在クライアントのネットワーク機能の一部をテスト中であるため、彼らのリリースもPrysm同様にプレリリース版となる可能性があると指摘しました。
Dencunのタイムラインにおける意見の相違
その後、LightclientはSepoliaおよびHoleskyテストネットのアクティベーション日程案について議論を進めました。「Potuz」というハンドルネームのPrysm開発者（仮名）は、本番ネットワーク前の最後の2つのテストネットのアップグレード日を現時点で決定しないことを提案しました。「Goerliで何か問題が起きた場合、修正が難しいので、今の段階で日程を約束するのは避けたほうがよい。新しいエポックを持つ正しいバージョンを追加するのは簡単だが、バージョンを削除してバグを修正するのは非常に困難だ。これは数週間以上かかるかもしれない」とPotuz氏は述べました。
Lightclientは、クライアントチームがGoerliのハードフォークから1週間後であれば新バージョンをリリースできるため、1月24日以降にGoerliで問題が発覚しない限り、新バージョンを撤回する必要はないとしています。Geth開発者のMarius van der Wijden氏は、SepoliaおよびHoleskyのアップグレード日を設定しても害がないと考えており、「Goerliで問題が起きたら、いつでも日程を変更できる」と述べました。
イーサリアム財団のDevOpsエンジニアBarnabas Busa氏はZoomチャットで、「Goerliのバージョンが正常に動作することが確認されてから、SepoliaおよびHoleskyのアップグレード用に新バージョンをリリースする必要がある」と述べました。別の「Sean」というハンドルネームのLighthouse開発者はこれに同意し、「Sepoliaのハードフォークには『暫定』の日程を設定してもよいが、1月30日まではまずGoerliの状況を観察すべきだ」と述べました。
Potuz氏は、GoerliとSepoliaのハードフォークアクティベーションの間に1週間のテスト期間を設けることを提案し、分析期間を3週間から2週間に短縮することを示唆しました。彼は、「クライアントのリリースを数日間『浸す（soak）』ことで、次のテストネットアップグレードのために再び新バージョンを切り直す必要性を減らせる」と述べました。「2週間は近すぎる。それが私が指摘したい点だ」と補足しました。また、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の電話会議を開いて日程を確認しなければならないのは避けたい。『よし、Sepoliaを始められる』というだけのために会議を開き、その後2週間待たなければならないのは嫌だ」と述べました。
合意形成のため、Geth開発者のGuillaume Ballet氏は、Sepoliaのハードフォークについて2セットの暫定日程を設定する案を提案しました。Goerliの結果が良好であれば一方の日程を採用し、問題があれば他方を使うというものです。しかし、Lightclient氏とDietrichs氏はともにこのアイデアに反対し、Sepoliaの新たなスケジュールを設定する前に、まずGoerli上で発生したバグや問題の性質を評価する必要があると指摘しました。
ちなみに、イーサリアム財団テストチームの「Danceratopz」というハンドルネームの開発者は、Goerliテストネット上のblobデータの有効期限切れの評価を待ってからSepoliaをアップグレードするべきかどうかを尋ねました。ここで言うblobの有効期限切れとは、約2週間後にイーサリアムのステートからblobデータが削除されることを指します。
LighthouseのSean氏とBesuチームのJustin Florentine氏はいずれも、Dencunの本番ネットワークアクティベーション前に、3つのテストネットのいずれかでblobの有効期限切れを評価すべきだと支持しました。Florentine氏は、テストネット上でblobの有効期限を待つことは、第2層Rollupプロトコルチームやアプリ開発者にとってもDencunへの準備を進める上で有益だと強調しました。LighthouseのSean氏は、Goerliでblobの有効期限切れを観察することは必須ではないが、SepoliaとHoleskyの間のテスト期間を延長する理由になり得ると述べ、開発者やLayer2チームがSepolia上でblobのライフサイクル全体を体験できるようにすべきだと提案しました。しかし、他の開発者たちはこの提案に対して明確な同意を示しませんでした。
代わりに、Lightclientは会議中に、Beiko氏が提案したスケジュール（Sepoliaを1月30日、Holeskyを2月7日）に従うことにするか尋ねました。特に異論がなかったため、開発者たちは当初のスケジュールを維持することで合意しました。Potuz氏はZoomチャットで、Sepoliaを1週間早くアップグレードするのではなく、2月7日に両テストネットを同時にアップグレードしたいと述べました。会議後のDiscordでのメッセージで、LightclientはDencunのテストネットスケジュールが当面変更されないことを改めて確認しました。
Prague/Electra
次に、開発者たちはDencunの次のアップグレード（Prague/Electra）で優先すべきEIPについて議論しました。Marius van der Wijden氏は、他のEIPよりも、Prague/Electraにおけるメルクリツリーのアップグレードに集中すべきだと述べました。彼はこの考えを補足し、まずメルクリツリーの準備状況について言及しました。ACDE #177で議論されたように、開発者たちはメルクリツリーの実装詳細とハードフォーク準備状況について深く議論するための特別なACDE会議を開く予定です。
van der Wijden氏が挙げた2つ目のポイントは、EL上のアップグレードとコンセンサスレイヤー（CL）のアップグレードを分離できるかどうかです。彼は、CL上には「高優先度かつ極めて緊急」なEIPがあり、ELのメルクリツリーのアップグレードよりも迅速に実施が必要な可能性があると指摘しました。「重要なのは、コンセンサスレイヤーのメンバーが、これらの[緊急]変更について単独でハードフォークを行う必要があるのか、ELなしで可能なのか、あるいはELとの連携が必要なのかどうかを検討することです。それによっては、小さなハードフォークを受け入れることもできます」とvan der Wijden氏は述べました。「したがって、メルクリツリーは絶対に最優先であり、これら2点を踏まえて推進すべきです。」
イーサリアム財団の研究者Ansgar Dietrichs氏はZoomチャットで、メルクリツリーに重点を置くことに「強く反対」すると述べました。その複雑なコード変更を考えると、アップグレードが2025年まで遅れる可能性があるためです。Nethermindクライアント開発者のLukasz Rozmej氏もDietrichs氏の意見に賛同しました。「私の経験上、ステートの再設計は非常に難しく、非常に長い時間がかかる」とRozmej氏は述べ、「メルクリツリー自体は非常に良いもので、大きな進展があるとは思いますが、もし次回のハードフォークでメルクリツリーにのみ注力すれば、少なくとも1年以上、あるいはそれ以上かかるでしょう。そのため、私はむしろいくつかの小さなハードフォークに焦点を当てつつ、各チームがメルクリツリーの開発に適切なリソース、作業量、知力を割り当て続けることを提案します」と述べました。
メルクリツリーに集中
Prague/Electraがメルクリツリーに集中すべきか、それともメルクリツリーよりも早く実装可能な小規模なコード変更を優先すべきかについて、開発者の意見は分かれました。Ballet氏は、「小さなフォークなど存在しない」との立場を示し、メルクリツリーの実装を遅らせれば遅らせるほど、イーサリアムステートの更新はますます困難になると強調しました。Nethermindクライアントの開発者Tomasz K. Stańczak氏は、野心的なアプローチを提唱し、Prague/Electraに含まれるEIPの数を増やすことを提案しました。「チームの能力を活かし、今年こそ最大の課題に立ち向かえることを証明しよう。もし3月までにメルクリツリーの実装で困難が積み重なれば、『メルクリツリーは延期』と言い直すこともできる。しかし、その際には他の一連の優れたEIPを含めたまま進めることができるだろう」とStańczak氏は述べました。彼が挙げた例には、ステーキング、リステーキング、アカウント抽象化に関連するEIPが含まれます。
Stańczak氏の発言に対し、Lightclient氏は、あるEIP（メルクリツリー）が「18〜24ヶ月かかるプロジェクト」である以上、EIPセットをコミットした後で再度何を含めるかを議論するのは難しいだろうと答えました。Erigonクライアントの開発者Andrew Ashikhmin氏は、Prague/Electraで小規模なEIPをリリースしつつ、メルクリツリーの開発を並行して進め、その後のフォークで導入する方針を支持しました。Ballet氏はStańczak氏の提案に賛成し、Prague/Electraでメルクリツリーの開発に注力する一方で、重大な問題が判明した場合にはアップグレードから除外する案を支持しました。
CLアップグレードに注目
EL（実行レイヤー）とCL（コンセンサスレイヤー）のアップグレード分離について、Potuz氏は、Prague/ElectraではCLの変更のみを必要とするEIPが1つしかないとの見解を示しました。「唯一の変更は認証インデックス委員会の廃止であり、他の変更、たとえCLのみに関係しているように見えるもの（例：Max EB）でさえ、EL側の他の変更に依存している。したがって、純粋なCLフォークは起こらないだろう。少なくとも今年も来年もない。純粋なCLの提案が十分に存在しないのだ」とPotuz氏は述べました。
それでもAnsgar Dietrichs氏は、CL中心のアップグレードでありながらELへのわずかな変更だけで済むEIPもあると指摘しました。このようなEIPでも、ELとCLのハードフォーク協調は必要です。Dietrichs氏は続けて、CL側で最も重要なコード変更はEIP-4844に続くデータ可用性サンプリング（DAS）だと考えていると述べました。Dietrichs氏とLightclient氏の間では、DASの実装にハードフォークが必要かどうかについて若干の見解の相違がありました。
EOFおよびその他のEIPに注目
「Rodiazet」というハンドルネームの匿名開発者は、イーサリアム財団のIpsilonチームに所属し、イーサリアム仮想マシン（EVM）の研究に取り組んでいます。ここでいうEOFはEVM Object Formatの略で、当初Cancun/Denebアップグレードに組み込まれる予定だったEVMの改善群です。
メルクリツリー以外にも、開発者たちはEIP-5920（PAYオペコード）やEIP-2537（BLS12-381曲線演算のプリコンパイル）などの他のEIPも候補として挙げました。Prague/Electraの候補EIPの完全なリストは、Ethereum Magiciansウェブサイトのアップグレードメタスレッドで確認できます。多くの開発者がCancun/Denebの後にメルクリツリーをある程度優先することに賛成していますが、2024年により早く簡単に実装可能な小規模EIPと比べて、どこまでメルクリツリーを優先すべきかはまだ明確ではありません。Lightclient氏は、今週の電話会議でPrague/Electraの内容について最終決定する必要はないと強調し、今後のACDE会議でこのテーマを継続して議論することを提案しました。
その後、開発者たちは会議中に議論されなかったPrague/Electraの候補EIPについて簡単に触れました。これには以下のようなEIPが含まれます。
-
EIP-7002：実行レイヤーによるトリガー可能な退出
-
EIP-7549：認証外への委員会インデックスの移動
-
EIP-3074：AUTHおよびAUTHCALLオペコード
-
EIP-6110：チェーン上でのバリデーター預け入れ
-
EIP-6913：SETCODE命令
-
EIP-7377：移行トランザクション
-
EIP-4444：実行クライアントにおける履歴データのバインド
-
EIP-6404：SSZトランザクションルート
-
EIP-6465：SSZ抽出ルート
-
EIP-6466：SSZレシートルート
-
EIP-7212：secp256r1曲線サポートのプリコンパイル
上記EIPに関する詳細な見解の概要については、YouTubeで公開されている会議録画をご覧ください。
EIP-7587の正式化
最後に、イーサリアム財団の研究者Carl Beekhuizen氏は、第2層プロトコルが利用するプリコンパイルアドレスを確保するEIP-7587についての議論を再提起しました。Beekhuizen氏は、このEIPをどのように情報的EIPとして正式化し、今後のイーサリアムガバナンスプロセスの規範とすべきか、開発者の意見を求めました。Nethermindの開発者Ahmad Bitar氏は、EIPプロセスのガイドラインを示すEIP-1ファイルにこのEIPを組み込むことを提案しました。Lightclient氏は、Ethereum Magiciansサイトでさらなる議論を行い、必要に応じて次回のACDE会議で再議論することを提案しました。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@galaxyhq
