イーサリアムコア開発者最新ミーティング要約：Electra仕様の変更は当面見送り、汎用ELリクエストの作成を検討
TechFlow厳選深潮セレクト
イーサリアムコア開発者最新ミーティング要約：Electra仕様の変更は当面見送り、汎用ELリクエストの作成を検討
Electra是以太坊下一次即时硬分叉的CL升级名称。
Web3業界の深掘り報道に専念し潮流を洞察翻訳：Luccy、BlockBeats
編集者注：イーサリアムの全コア開発者による合意電話会議（ACDC）は隔週で開催され、主にイーサリアムコンセンサス層（CL）の変更について議論・調整しています。今回はACDC第132回目の電話会議であり、開発者たちは最初のPectra開発者テストネット（Pectra Devnet 0）に関する最新情報を共有し、仕様に関する未解決問題について議論したほか、ネットワークリリースおよびデータ可用性サンプリングに関連する研究プロジェクトにも言及しました。取り上げられた課題には、Electraにおける未解決問題、Electra関連の懸案事項、および研究面での未解決問題が含まれます。
Electraにおける未解決問題に関しては、EIP 7251およびEIP 7549の影響、そして汎用ELリクエストを作成する新しいEIPの追加が焦点となりました。Electra関連の懸案事項としては、検証者委員会インデックスの型の変更や、検証者の預入データ処理の変更などが議論されました。Galaxy DigitalのリサーチバイスプレジデントであるChristine Kimが今回の会議の要点を詳細に記録しており、以下にその原文をBlockBeastsが翻訳して紹介します。
2024年3月21日、イーサリアム開発者たちはZoom上でAll Core Developers Consensus（ACDC）#132会議に参加しました。ACDC電話会議は隔週で行われるシリーズ会議であり、今週の会議はイーサリアム財団のリサーチャーであるAlex Stokes氏が司会を務め、開発者たちはイーサリアムコンセンサス層（CL）の変更について協議・調整を行いました。今週は、開発者たちが最初のPectra開発者テストネット（いわゆるPectra Devnet 0）の準備状況について最新情報を共有しました。また、Pectra Devnet 0の仕様に関するオープンな課題についても議論し、ネットワークリリースとデータ可用性サンプリングに関連する2つの未完了の研究プロジェクトにも簡単に触れました。
Electraにおける未解決問題
イーサリアム財団の開発者はすでにPectra Devnet 0の初期CL仕様およびテストベクトルを公開しています。しかし、これらの仕様にはいくつかの未解決の問題があり、最初のdevnet起動時に解決されるかどうかは不透明です。Stokes氏は、そのうちの一つとしてEIP 7251（MAX_EFFECTIVE_BALANCEの増加）への対応を強調しました。開発者の間では、検証者のETHステーキングを実行層（EL）によってトリガー可能な操作とする方向性が支持されています。ただし現時点では、この統合操作は初期Electra仕様内でCL操作として定義されています。「これは良いことです。なぜなら、信標チェーンが必要とするほとんどの処理ロジックは、その発生源に関わらず同じだからです」とStokes氏は述べました。
電話会議で開発者が議論した別の未解決問題は、EIP 7549（証明の外側に委員会インデックスを移動）に関するものです。このEIPは、検証者が署名を行う際の集約方法やブロックフォーマットの方式を変更します。Pectraが有効化されたとき、アップグレード前の証明を集約したものと、チェーン上で新たに提出される証明とは互換性がなくなります。Stokes氏は会議前のGitHub上の問題提起において、2つの可能なかな解決策を提示しました。彼は次のように記述しています。
-
クライアントが直前のDeneb時代に両方のフォーマットをブロードキャストするが、スラッシング可能なメッセージを生成しないように注意すること。
-
前Electra証明に対応するブロックを追加フィールド付きで拡張し、Electra初回エポック期間中はDenebスタイルのみを許可すること。
Denebは、イーサリアム上で活性化された最新のハードフォークの組み合わせアップグレードの名称です。一方、Electraは次の直近のハードフォークとして予定されているCLアップグレードの名称です。
開発者たちは会議の中でこれら2つの選択肢について議論しました。最終的に、当面はElectra仕様を変更せず、これらの失われた証明がdevnet上のネットワークセキュリティにどのように影響するかを見守ることで一致しました。
電話会議で開発者が議論したElectra関連の3つ目の未解決問題は、アップグレードに新たなEIPを追加することで、これにより汎用的なELリクエストが作成されることです。Geth開発者の「Lightclient」氏が提案したこのEIPは、ELからCLへメッセージを更新するプロセスを簡素化します。スマートコントラクトベースのステーキングソリューションの台頭に伴い、ELから直接、CLではなく各種検証者操作をトリガーすることをPectraに提案するEIPが多数提出されています。Lightclient氏の提案は、「コントラクトトリガーリクエスト」をELからCLへ伝播させるための汎用フレームワークを構築するものです。このEIPは特にEIP 6110およびEIP 7002の実装に影響を与えるため、Pectraの設計自体を変更する可能性があるとして、Lightclient氏はクライアントチームが早期にフィードバックを提供することを強く希望しています。開発者たちは、4月22日（月）までに仕様を構築・共有できるよう、今週末までにLightclient氏のEIPを試行し確定するよう同意しました。
その後、Teku開発者のMikhail Kalinin氏が提起した、EIP 7549およびEIP 7251に関連する追加の2つの未解決問題についても議論が行われました。1つ目は検証者委員会インデックスの型に関する変更であり、もう1つは検証者の預入データ処理の変更に関するものです。Stokes氏は、開発者に対してこれらの2つの提案をより詳細に検討し、今後数週間以内にさらに議論を進めるよう促しました。
最後に、Electra仕様に関連する最終的な未解決問題として、blobのカウント数の増加が議論されました。イーサリアム財団の運用エンジニアであるParithosh Jayanthi氏は、Dencunアップグレード後のblob活動を分析し、その結果に基づいてElectraアップグレードに含まれる一時的なblobカウントの増加を提案したいと述べました。また、イーサリアム財団のリサーチャーAnsgar Dietrichs氏は、blobカウントを段階的に増加させる提案を行い、Jayanthi氏の提案と並行して検討すべきだと強調しました。
研究分野の未解決問題
今週のACD電話会議では、2つの研究プロジェクトについて簡単に議論が行われました。1つ目は、イーサリアム財団のリサーチャーAnders Elowsson氏による新規研究論文で、イーサリアムの発行政策の変更を考え、実施するための新しいモデルを提示しています。全文はこちらで読むことができます。Stokes氏は会議中に、開発者に対してこの投稿を確認するよう勧めました。
2つ目の研究プロジェクトは、Lighthouse開発者のAdrian Manning氏が提起したもので、証明サブネットに関するものです。Manning氏がGitHub上で述べているように、「このPRは『ネットワークシャーディング』という概念を導入します。これは単なる抽象概念であり、ノードIDをある数値（ネットワークシャード）としてタグ付けするものです。その後、このネットワークシャード（数値）を使って、ノードが長期的に購読すべきトピックを割り当てることができます。」Manning氏は、自身の提案に対する最終的な意見を求め、その上でチームがイーサリアムのデータ可用性サンプリングソリューションであるPeerDASの研究を開始できるようにしたいとしています。データ可用性サンプリングの詳細については、このGalaxy Researchレポートをご覧ください。
Nethermindの開発者Lukasz Rozmej氏は、EIP 7547（含むリスト）がElectraアップグレードに採用されることが承認されたかどうかを質問しました。開発者たちは、EIP 7547はまだ採用が承認されていないと再確認しました。
「Grandine」というイーサリアムCLクライアントを開発しているSaulius Grigaitis氏は、現在進行中のPeerDAS研究を踏まえて、イーサリアムのフォーク選択ルールについて疑問を呈しました。Grigaitis氏は、開発者たちにPeerDASワーキンググループにアイデアを寄せてほしいと要請しました。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@galaxyhq
