原題: "Ethereum All Core Developers Consensus Call #135 Writeup"
編集者注: Ethereum All Core Developers Consensus Call (ACDC) は、主にコンセンサスの議論と調整を目的として、2 週間ごとに開催されます。イーサリアム上でコンセンサス層（CL）を変更します。これは 135 回目の ACDC カンファレンスコールであり、主に Pectra Devnet 1、PeerDAS Devnet 1、および Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP) のテスト ネットワークの準備に焦点を当てています。
開発者は、ソフトウェアパッケージのメンテナンス、EIPの組み込みプロセス、およびイーサリアムコンセンサスレイヤーのアップグレードの新しいラウンドの名前について徹底的に議論しました。さらに、セッションでは、Electra 仕様に基づく実装の進捗状況、Ethereum ノードがデータを処理および検証する方法に対する PeerDAS ネットワークの変更の影響、BLOB ガス制限の増加を巡る複雑なエンジニアリングの問題についても触れられました。
Galaxy Digital のリサーチ担当副社長 Christine Kim がこの会議の要点を詳細に記録し、BlockBeasts は原文を次のようにまとめました:
2024 年 6 月 13 日、イーサリアム開発者はオールコア開発者コンセンサスに参加するために Zoom に集まりました。 (ACDC) #135 会議に電話します。 ACDC コールは、イーサリアム財団の研究者アレックス・ストークスが主催する隔週シリーズで、開発者がイーサリアム コンセンサス レイヤー (CL、ビーコン チェーンとも呼ばれる) への変更について話し合い、調整します。今週、開発者らは、Pectra Devnet 1、PeerDAS Devnet 1、および Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP) の 3 番目の専用テスト ネットワークの準備について話し合いました。
開発者は 2 つの発表でミーティングを開始しました。イーサリアム財団 DevOps エンジニアのパリトシュ ジャヤンティ氏は、イーサリアム パッケージ Kurtosis モジュールのメンテナンスと開発は、イーサリアム財団 DevOps (EF DevOps) で働くエンジニアのグループである ethPandaOps チームが引き継ぐと述べました。このパッケージは、開発者が過去にイーサリアム テスト ネットワークや、さまざまなクライアント実装を監視およびテストするための Grafana データ ダッシュボードなどの関連ツールを起動するために使用されてきました。 Kurtosis 技術チームから ethPandaOps チームへのこのパッケージの移行は、一部のリンクが Kurtosis チームではなく ethPandaOps チームによって管理される GitHub リポジトリにリダイレクトされるため、ユーザーに影響を与える可能性があります。 Jayanthi 氏はユーザーに対し、ソフトウェア リンクを更新し、ethPandaOps チームからの新しいリリースに注目するようアドバイスしています。
2 番目の発表は、イーサリアム財団のプロトコル サポート責任者である Tim Beiko によって行われました。ベイコ氏は、段階的にイーサリアムのアップグレードにEIPを含める新しいプロセスの導入に取り組んでいると述べた。彼は、「含める予定」、「含める予定」、および「含める予定」というラベルを定義する EIP 草案を作成しました。同氏は、開発者がこのドキュメントを確認してフィードバックを提供してくれることを望んでいます。同氏は、次回のACD会議までに文書を完成させたいと考えていた。
次期 Electra メジャーバージョン v1.5.0-alpha.3 のコード仕様がほぼ完成しました。開発者は、コンセンサス仕様 GitHub リポジトリのプル リクエスト (PR) #3768 を次のバージョンにマージすることに同意しました。このプルリクエストは、Nimbus 開発者の Etan Kissling によって作成されました。彼は、データのシリアル化の問題を避けるために、「committee_bits」フィールドをデータの途中ではなく「Attestation」の末尾に追加する必要があると指摘しました。 PR #3768 に加えて、Stokes 氏は、Electra 仕様の次のメジャー バージョンがリリースされる前に解決する必要がある未解決の問題が他にもあるかどうかを尋ねました。 Jayanthi 氏は Zoom チャットで、実行層 (EL) を通じてトリガーされるバリデーターの統合にはいくつかの未解決の問題があると述べました。ストークス氏は、会議後、EL によって引き起こされるバリデーター統合の状況をフォローアップすることをメモしました。
最新の Electra 仕様の実装の進捗状況に関して、会議に参加したコンセンサス層 (CL) クライアント チームのほとんどは、v1.5.0-alpha から 1 ～ 2 週間以内に新しいバージョンをテストできる状態にできると述べました。 .3が確定しました。開発者らは、次の Pectra 開発ネットワークである Pectra Devnet 1 のタイミングを数週間以内に再検討することに同意しました。
次に、開発者は PeerDAS の実装の進捗状況について話し合いました。 PeerDAS は Ethereum に対するネットワークの改良であり、BLOB トランザクションを介してユーザーによって送信された大量の任意のデータを処理および検証するノードの能力を強化します。 Stokes 氏は、開発ネットワーク上で PeerDAS の個別のアクティベーション サイクルをアクティブにすることで、開発者が他の Pectra EIP と並行して PeerDAS を開発するという前回の ACDC 会議での決定を思い出しました。
Lodestar 開発者の Gajinder Singh 氏は、PeerDAS に関する最近の分科会セッションでの議論に基づいて、開発者は Deneb アップグレードに加えて、他の Pectra EIP とは別の開発ネットワーク上で PeerDAS をアクティブ化すると述べました。 Teku開発者のEnrico Del Fante氏は、開発者にとっては、常に変化するPectraのコード仕様ではなく、以前のイーサリアムアップグレードのDenebですでに確立された安定したコード仕様に基づいてPeerDASを構築する方が簡単だと述べた。 Jayanthi 氏は、現在 PeerDAS 実装を他の Pectra EIP 実装とマージすると、テスト中に、特にエラーの原因を特定しようとするときに複雑さが発生する可能性があることに同意しました。同氏は、2 つのワークフローを分離しておき、実装がより安定したら統合することを提案しました。 Stokes氏もこれに同意し、開発者は約1カ月以内にPeerDASと他のPectra EIP実装のマージを再検討できると述べた。
PeerDAS Devnet 1 の立ち上げに関しては、クライアント チームはテストネットの立ち上げ準備がいつ整うかについて明確な見積もりを持っていません。セッションでの個別の見積もりは、およそ 2 週間から 1 か月の範囲でした。 Stokes 氏は、クライアント チームが PeerDAS 実装に取り組む時間がより多く取れる数週間以内に、ネットワーク開発のスケジュールを再検討することを提案しました。
Beiko 氏は、PeerDAS はイーサリアムコアプロトコルの変更ではなくネットワークの改良であるが、それでもコードの変更が Pectra アップグレードのメタ EIP に含まれることを望んでいると述べました。メタ EIP 文書は、イーサリアムのアップグレードに含まれるすべてのコア プロトコルの変更をリストした公開文書です。 Beiko 氏は、PeerDAS は Pectra の「最大の機能」であり、ハード フォークのアクティベーションは必要ありませんが、開発者が Pectra メインネットのアクティベーションに間に合うよう真剣に準備していることを示すために、ドキュメントに含める必要があると指摘しました。これには異論はありません。
PeerDAS は、ノードが Ethereum ピアツーピア ネットワーク層を通じてデータを処理および伝播する方法を変更します。ユーザー、特にレイヤー 2 ロールアップがこれらの変更の恩恵を受けるには、開発者はブロックあたり 6 BLOB という現在の制限をより高いしきい値に増やす必要があります。これにより、BLOB (任意のデータ) のスループットが向上します。 BLOB 制限を変更するには、イーサリアム コア プロトコルの変更が必要になります。開発者らが今週のカンファレンスで議論したように、これには、プロトコル スタック内の定数値を単に調整するだけではなく、より複雑なエンジニアリング作業が必要になる可能性があります。
Stokes 氏は、BLOB ガス制限を変更する際に、実行層 (EL) とコンセンサス層 (CL) の間の依存関係を切り離すことを提案しました。現在、ブロブ ガス制限を変更するには、EL および CL プロトコルを変更する必要があります。 Stokes 氏は、これらの依存関係を解消し、開発者がハードコードされた BLOB ガス制限を EL から安全に削除し、完全に CL に任せられるようにする方法を提案しました。イーサリアム財団（EF）の研究者ダンクラッド・ファイスト氏は、ELとCLの間の依存関係の問題に加えて、ブロブのガス制限を変更することによるブロックのガス計算への波及効果も重要であると指摘した。ファイスト氏は、「最善の方法は計算方法を変更することだ。ガス価格の計算がELで行われるのはおそらくバグだろう。それはCLにあるはずだが、今変更するのはより難しい。…簡単ではない」と語った。 "
開発者は、BLOB のガス制限とブロック内のガス計算を変更するための最良の方法を調査し続けることに同意しました。開発者はまた、Pectra で PeerDAS をアクティブ化すると、ブロブ ガス制限の増加が伴うかどうかについて議論を続けることに同意しました。開発者は、変更をまとめてロールアウトするか、複数のハード フォークにまたがって段階的に実装するかについて意見が分かれています。
Jayanthi 氏は、PeerDAS がメインネットでアクティブ化されるまで開発者は PeerDAS がどのように動作するか分からないため、これらの変更を組み込むことは「危険な」決定であると述べました。 Ethereum Foundation (EF) DevOps エンジニアの Barnabas Busa 氏は、Pectra ハード フォークの範囲はすでに非常に大きく、追加のコード変更は必要ないと付け加えました。 「重要なのは、私たちはすでに多くのEIPを持っており、さらに追加し続けているように感じますが、終わりはありません」とブサ氏は語った。今後 1 年半のテスト中に PeerDAS をリリースして BLOB の数を増やすことは不可能です。「
スクリーン名「Francesco」の開発者は、ネットワークの変更が BLOB の数の増加を伴わない場合、 PeerDAS は「Pectra のリスクを軽減する」ために削除できます。 Francesco 氏は、「BLOB の数が増えない場合、Pectra の PeerDAS の利点は何でしょうか?」と尋ねました。PeerDAS のテストの難しさをさらに説明するために、Jayanthi 氏は、イーサリアムに BLOB を導入した EIP 4844 のテストでは BLOB が完全にはシミュレートされていないと指摘しました。イーサリアムメインネットの実際のパフォーマンスと影響について。 Jayanthi 氏は次のように述べています。「問題は、ネットワークをテストするのが非常に難しいことです。4844 に関連する優れたテストは数多くありましたが、BLOB はテストで確認したものとまったく同じには動作しませんでした。質問: タイミングの問題などが発生するため、PeerDAS が動作する完璧な状況をシミュレートできても、BLOB の数が増加しても実際的な影響はありません。つまり、これが、一度にすべてを行うのではなく、段階的に行うべきだと私が考える主な理由です。」
EF 研究者の Ansgar Dietrichs 氏は、PeerDAS だけでもすでに開発者が BLOB の数の値を選択する必要があるため、BLOB の数の増加を PeerDAS と関連付けることは間違いであるとコメントしました。開発者はイーサリアムメインネットと同じ番号を選択できますが、PeerDAS がどの番号を使用するかを決定する必要があります。同じ番号を選択する唯一の理由は、開発者がエラー発生時に現在の Deneb 仕様の BLOB 伝播メカニズムにフォールバックできるようにするために PeerDAS の複雑さを高めたことです。 Dietrichs 氏は、テストの複雑さへの懸念により、Pectra は 1 つではなく 2 つのハード フォークでアクティブ化されるべきだという彼の見解をさらに強めていますが、だからといって PeerDAS を BLOB 数の変更から切り離すべきだと考えているわけではないと付け加えました。
Kissling は、3 つの SSZ 関連 EIP に関する進捗状況の最新情報を共有しました。これらの EIP の実装は、Teku、Grandine、Lighthouse などの複数のクライアントですでに進行中であると同氏は述べました。開発者らはこれらのSSZ EIPの開発ネットワークスケジュールについて議論を開始し、次回のACDC会議でPectraアップグレードの対象に含める可能性があると同氏は述べた。
Ethereum Magicians に、Electra の後の次の Ethereum Consensus Layer (CL) アップグレードの名前について議論する投稿があります。開発者は、エグゼクティブ レイヤー (EL) アップグレードの名前を、Prague: OSAKA にちなんで決定しました。 CL アップグレードの候補名は、Fulu、Felis、Formosa、Funi です。これらの名前はすべて、「F」で始まるメジャー スター命名規則に従っており、ビーコン チェーンの 6 番目のネットワーク全体のアップグレードに適しています。ストークス氏は電話会議に参加した開発者に対し、マジシャンズ スレッドのトピックについて検討するよう求めました。
以上がイーサリアムコア開発者の最新ミーティングの概要: PeerDAS のアクティブ化、BLOB ガス制限の増加の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
