元のタイトル: 「イーサリアムの全コア開発者コンセンサスコール#139の書き込み」
原作者：クリスティーン・キム
オリジナルコンピレーション：Ladyfinger、BlockBeats
編集者注:
All Core Ethereum Developers Consensus Call (ACDC) は、ビーコン チェーンとしても知られるイーサリアム コンセンサス レイヤー (CL) への変更の議論と調整に焦点を当てた隔週の一連の会議です。イーサリアム財団（EF）の研究者アレックス・ストークス氏が主催した第139回ACDCコールでは、Pectra Devnet 2の修正、Devnet 3の準備、PeerDAS実装の進捗状況、イーサリアムノードの分布に関する新データなどが取り上げられた。
会議中、開発者は Pectra Devnet 2 の安定性と既存の問題を確認し、次期 Devnet 3 への準備について議論し、PeerDAS 実装の進捗状況について徹底的な議論を行いました。さらに、イーサリアムのデータシリアル化方式の潜在的な変更をサポートするために、前方互換性のあるデータ構造を導入することを目的とした EIP 7688 の提案も、出席者の間で広範な議論を引き起こしました。 Galaxy Digital の研究担当副社長である Christine Kim はこの会議を詳細に記録し、BlockBeats は原文を次のように編集しました。
2024年8月8日、イーサリアム開発者はZoom経由で第139回コア開発者コンセンサスカンファレンスコール（ACDC）を開催した。 ACDC の電話会議は、開発者がビーコン チェーンとしても知られるイーサリアム コンセンサス レイヤー (CL) への変更について話し合い、調整する隔週の一連の会議です。今週の電話会議は、イーサリアム財団（EF）の研究者アレックス・ストークスが主催します。開発者は、Pectra Devnet 2 の修正、Devnet 3 の準備、PeerDAS 実装の進捗状況、および Ethereum ノードの分散に関する新しいデータについて話し合います。
Pectra 更新
Stokes は、EF 研究者の Hsiao Wei Wang が、Pectra コンセンサス レイヤー (CL) 仕様の公式更新バージョン alpha.4 をリリースする予定であると発表しました。このバージョンには、以前のバージョンに対する多くの改善が含まれており、近い将来リリースされる予定です。
Pectra Devnet 2 の話題に関して、EF 開発者オペレーション エンジニアの Barnabas Busa 氏は、ネットワークは安定しており、ネットワーク参加率は 85% に達していると述べました。実行層 (EL) クライアント (主に EthereumJS と Erigon) には、解決する必要のある小さな問題がまだいくつかあります。ほとんどの CL クライアントは Devnet 2 で安定しています。ただし、Busa 氏は、Prysm クライアントに関するさらなる調査が必要な小さな問題について言及しました。 EF DevOps エンジニアの Parithosh Jayanthi 氏は、クライアント チームは Lighthouse、Teku、Besu ノード間の問題を調査することも求められていると付け加えました。
その後、開発者は、devnet 起動時の通信プロセスを改善する方法について話し合いました。 Prysm 開発者の Kasey Kirkham は、Zoom チャット中に Devnet 2 の起動時間についての知識が不足していると指摘しました。 Devnet 3 のリリース情報がすべてのクライアント チームに正確に伝達されるようにするために、開発者は、Pectra のテストの進捗状況を更新するための毎週の定例会議を設定することにしました。正確な時間はまだ決定されていませんが、これらの会議は、Dencun のアップグレード前のテスト電話と同様に、毎週月曜日に開催される予定です。 Jayanthi 氏は、これらの会議は 15 ～ 30 分間の短く効率的なものとし、Pectra 関連の開発ネット テストの更新について議論することに重点を置き、PeerDAS や EOF 開発ネットなどのトピックを取り上げることを提案しました。
Pectra Devnet 3 について議論する際、開発者は Devnet 2 と同じ EIP 構成を引き続き使用すると繰り返しました。さらに、Devnet 3 には新しく設計された EIP 7702 が初めて統合され、チームは Pectra コア EIP との互換性を確保するために綿密なテストを実施します。 Lodestar チームの Gajinder Singh 氏は、MaxEB 提案の問題である EIP 7251 が Devnet 2 で発見されたと述べました。これはデバッグされましたが、解決策を検証するには次の Pectra Devnet でさらに詳細なテストがまだ必要です。
ACDE#193で説明されているように、CL クライアントが EL BLOB トランザクション メモリ プールから BLOB を取得できるようにする新しいエンジン API 仕様があります。このメソッドは「getBlobsV1」と呼ばれます。悪用を避けるために、Teku 開発者の Enrico del Fante は CL 仕様にいくつかの明確化を提案しました。 Stokes 氏は、開発者がこれらの明確化を検討し、Pectra Devnet 3 でこのアプローチの使用をテストする計画を立てることを推奨しました。
開発者は、複雑なプロトコルの廃止について議論しました。 Mplex は、単一の通信リンクを介したマルチストリーム送信のために CL クライアントによって使用されるプロトコルでしたが、その保守者によって非推奨になりました。クライアント チームは、yamux などの新しいストリーム再利用テクノロジへの移行を計画しています。 Lodestar の Phil Ngo 氏は、yamux の統合とテストが完了し、クライアントの運用コストが増加するため、2 つのプロトコルを長期的に維持するよりも、新しいプロトコルに直接移行することを選択していると発表しました。 Nimbus の Etan Kissling 氏も、彼のチームが yamux をテストしていることを明らかにしました。開発者は、プロトコル移行に関する他の CL クライアント チームの進捗状況を引き続き監視し、今後数か月以内にマルチプレックスから新しいマルチプレクサへの移行戦略を再評価する予定であることに同意しました。
Etan Kissling は、Pectra スレッドで EIP 7688 に関するディスカッションを発表しました。これは、スマート コントラクト開発者がイーサリアム実行層 (EL) のデータ シリアル化メソッドで RLP から移行できるようにする、前方互換性のあるデータ構造を導入する提案です。 SSZに到着。 Pectra のアップグレード自体は SSZ を完全には実装しませんが、データ変更に関して Pectra EIP の前方互換性を確保するために EIP 7688 が提案されています。
Alex Stokes 氏は、Pectra アップグレードに EIP 7688 を含めることには慎重で、アップグレードはすでにかなり大規模になっていると述べています。 Parithosh Jayanthi 氏はカンファレンス中に、EIP 7688 ができるだけ早く Devnet 5 でテストされる可能性があると述べました。 Lodestar、Prysm、Teku、Lighthouseなどのチームの代表者がこの提案への支持を表明した。 Stokes と Beiko は、既存の Pectra EIP がすべて定常状態に達するまでは、新しい EIP を Pectra に追加しないようにすることを推奨しています。キスリング氏は提案を受け入れ、この問題を再検討するのに最適な時期はいつになるかを尋ねた。具体的な回答は得られませんでしたが、チームは Pectra Devnet 5 の発売前に EIP 7688 を再評価する必要があることに概ね同意しました。
PeerDAS の更新
Prysm クライアント チームの代表者は、会議で PeerDAS 実装に関する最新の進捗状況を報告し、「ブロブサイドカー」エンジン API リクエストの必要性についての議論を引き起こしました。 Alex Stokes 氏は、次回の PeerDAS グループ会議では、PeerDAS がエンジン API に対して行う必要がある調整について徹底的に議論する必要があると提案しました。同氏はまた、EFの研究者が、アップグレードプロセスの複雑さを軽減することを目的として、PeerDASからサンプリングメカニズムを削除することを提案する正式仕様の草案を作成したことにも言及した。しかし、最近の PeerDAS グループ会議では、この動きにより将来的にハードフォークによるサンプリングの再導入がより困難になる可能性があると参加者が懸念を表明しました。さらに、Pectra でのブロブ ガス制限の安全な増加に対するサンプリング メカニズムの削除の影響は不明です。実行層 (EL) とコンセンサス層 (CL) の BLOB ガス制限を分離する提案である EIP 7742 が、今週の電話会議で再び取り上げられました。ストークス氏は、EIPを更新し、次回のCLコールにEIPが含まれる可能性や、Pectraのブロブガス制限調整に関連するトピックについて話し合う予定であると述べた。
研究の最新情報
今週の電話会議で、開発者は 3 つの研究トピックに焦点を当てました。まず、EIP 7251 に基づいてステーキングされた ETH 残高をマージする際にバリデーターが遭遇する可能性のあるエッジケースを調査します。 Etan Kissling 氏は、マージ中にバリデーターの残高が長期間更新されない可能性があり、その場合、プロトコルが同期委員会の責任を誤って割り当てる可能性があると示唆しました。これに対し、Alex Stokes 氏は、この問題はプロトコルによるバリデーター終了の処理に似ていると答え、既存のマージ設計を変更せずに、このエッジケースをコンセンサス層 (CL) 仕様に文書化することを提案しました。
その後、開発者はイーサリアム ネットワーク層への変更、特に「クイック ENR エントリ」の導入について議論しました。 Quic は Quick UDP Internet Connection の略で、ノードがデータを送受信するのに役立ちます。 Stokes 氏は、quic ENR エントリに対する具体的な変更をさらに詳細に説明するために、GitHub でプル リクエスト (PR) を作成することを提案しました。
最後に、ProbeLab は、イーサリアム ネットワーク上のノード動作の進行中の分析を共有しました。レポートによると、現在イーサリアム ネットワーク上では 8,335 のノードが実行されており、そのうちの 42% が Lighthouse クライアントを使用しています。米国で運用されているノードは全体の 36% を占め、ノードの約半分はデータセンターに導入されています。 Prysm 開発者の「Potuz」は、データセンターでホストされている Lighthouse ノードの数が自己ホスト型ノードの数を超えているという事実に興味を示しました。 Stokes 氏は、これは Lighthouse クライアントの主なユーザー ベースに機関やプロのノード オペレーターが含まれているためではないかと推測しています。
会議の終わりに、ポトゥズ氏はチームに対し、実行ペイロード構造の微調整に関して提出した PR を見直すよう促した。この提案は、前回の ACDC の呼びかけで初めて提起されました。 Potuz 氏は、迅速な意思決定の重要性を強調し、これらの変更は概念的にはシンプルで理解しやすいものの、コンセンサス レイヤー (CL) 仕様に統合するのは困難な場合があると指摘しました。同氏は開発者に対し、できるだけ早くこれに取り組み始めるようアドバイスしている。
「オリジナルリンク」
