原題: "Ethereum All Core Developers Consensus Call #132 Writeup"
原著者: Christine Kim
原編集: Luccy、BlockBeats
編集者注:
イーサリアム全コア開発者コンセンサスコール (ACDC) は、イーサリアムコンセンサスレイヤー (CL) への変更について話し合い、調整するために 2 週間ごとに開催されます。これは 132 回目となる ACDC カンファレンスコールで、開発者は最初の 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 カンファレンスコールは、イーサリアム財団の研究者アレックス・ストークスが主催する隔週シリーズで、開発者らがイーサリアムコンセンサスレイヤー(CL)の変更について話し合い、調整します。今週、開発者は、Pectra Devnet 0 としても知られる最初の Pectra Developer Test Network の準備に関する最新情報を共有しました。彼らは、Pectra Devnet 0 仕様に関する未解決の問題について議論し、ネットワーク パブリッシングとデータ可用性サンプリングに関連する 2 つの未完了の研究プロジェクトについて簡単に強調しました。
イーサリアム財団開発者は、Pectra Devnet 0 の初期 CL 仕様とテスト ベクターをリリースしました。ただし、これらの仕様に関しては未解決の問題がいくつかあり、最初の devnet の立ち上げまでに解決されるかどうかはわかりません。 Stokes 氏は、問題の 1 つが EIP 7251 (MAX_EFFECTIVE_BALANCE の増加) に関連していることを強調しました。開発者は、実行層 (EL) でトリガー可能なアクションとしてバリデーター ステーク ETH を組み込むことに傾いているようです。ただし、現時点では、マージは初期の Electra 仕様で CL 操作として定義されています。 「ビーコンチェーンに必要な処理ロジックのほとんどはソースに関係なく同じなので、これは良いことです」とストークス氏は言います。
開発者が電話会議で議論したもう 1 つの未解決の問題は、EIP 7549 (Moving Committee Indexing Beyond Proof) に関連しています。 EIP は、バリデーター証明の集約方法とブロックのフォーマット方法を変更します。 Pectra がアクティブ化されると、アップグレード前のプルーフは、オンチェーンで送信された新しいプルーフと互換性がなくなることが要約されます。ストークス氏は電話会議の前に、GitHub の問題で考えられる 2 つの解決策を強調しました。彼はこう書きました:
· 前回の Deneb 時代に両方の形式をブロードキャストしていたクライアントは、切り取られるメッセージを生成しないように注意していました。
· Electra 以前の証明用の追加フィールドでブロックを拡張し、Electra の最初のエポックでは Deneb スタイルのみを許可します。
Deneb は、イーサリアム上でアクティブ化された最新のハード フォークのアップグレードを組み合わせた名前です。 Electra は、イーサリアム上の次の即時ハードフォークのための CL アップグレードの名前です。
開発者は電話会議中に両方のオプションについて話し合いました。最終的に、彼らは今のところ Electra 仕様を変更せず、これらの不足している証明が開発ネット上のネットワーク セキュリティにどのような影響を与えるかを確認することにしました。
Electra 関連の通話で開発者によって議論された 3 番目の未解決の問題は、ユニバーサル EL リクエストを作成するアップグレードでの新しい EIP の追加でした。 Geth 開発者によって提案された EIP「Lightclient」は、EL から CL に更新メッセージを送信するプロセスを簡素化します。スマート コントラクト ベースのステーキング ソリューションの台頭により、イーサリアム上でアクティブ化される EIP が大量に流入しており、CL ではなく EL から直接さまざまなバリデーター操作をトリガーする Pectra の提案が行われています。 Lightclient 提案は、「コントラクトによってトリガーされるリクエスト」を EL から CL に伝播するための共通フレームワークを作成します。この EIP が Pectra の設計方法、特に EIP 6110 と EIP 7002 の実装を変えることを考慮して、Lightclient 氏は、顧客チームが彼の提案についてできるだけ早くフィードバックを提供してくれることを期待していると強調しました。開発者らは、Lightclient の EIP を今週末までに完成させ、4 月 22 日月曜日までに仕様を構築して共有できるようにすることに同意しました。
その後、開発者たちは、Teku 開発者の Mikhail Kalinin によって提起された EIP 7549 および EIP 7251 に関連する他の 2 つの未解決の問題について話し合いました。 1 つ目はバリデータ委員会のインデックス タイプの変更に関するもので、後者はバリデータ デポジット データの処理の変更を提案しています。ストークス氏は開発者に対し、今後数週間でさらなる議論に向けて両方の提案をより詳細に検討するよう奨励した。
最後に、開発者によって議論された Electra 仕様に関連する最後の未解決の問題は、BLOB 数の増加です。イーサリアム財団の開発者オペレーションエンジニアであるパリソシュ・ジャヤンティ氏は、Dencunのアップグレード後にBLOBアクティビティの分析を実施し、この分析に基づいてElectraのアップグレードに含めるBLOB数の1回限りの増加を推奨したいと述べた。イーサリアム財団の研究者アンスガー・ディートリヒス氏は、ブロブ数の段階的な増加を有効にする提案も行っており、これはエレクトラを組み込むというジャヤンティ氏の提案と並行して検討されるべきであると強調した。
今週の ACD 電話会議で、開発者は 2 つの研究プロジェクトについて簡単に話し合いました。 1 つ目は、イーサリアム財団の研究者であるアンダース・エロウソン氏による新しい研究論文で、イーサリアムの発行ポリシーの変更を検討し実装するための新しいモデルを提案しています。投稿全文はここで読むことができます。ストークス氏は通話中に開発者に対し、投稿をレビューするよう奨励した。
Lighthouse 開発者 Adrian Manning が提案した 2 番目の研究プロジェクトは、サブネットの証明に関するものです。マニング氏が GitHub で述べたように、「この PR では、『ネットワーク シャーディング』の概念が導入されています。これは、ノード ID を数値 (ネットワーク シャーディング) としてマークする抽象的な概念にすぎません。その後、このネットワーク シャーディング (数値) を使用してトピックを割り当てることができます」マニング氏は、イーサリアムのデータ可用性サンプリング ソリューションである PeerDAS の開発を開始できるよう、提案に関する最終的な意見を求めています。
Nethermind 開発者の Lukasz Rozmej 氏は、EIP 7547 が Electra アップグレードに含めることが承認されているかどうかを尋ね、「Grandine」と呼ばれる Ethereum CL クライアントを構築している開発者は次のような疑問を提起したと繰り返しました。現在進行中の PeerDAS 研究を踏まえたイーサリアムのフォーク選択ルール。 Grigaitis は開発者に対し、PeerDAS ワーキング グループにアイデアを提供するよう求めました。
以上がEthereum ACDC 最新の会議議事録: Electra Devnet 0 の進捗状況とその他の技術的問題の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。