執筆者：クリスティン・キムコンピレーション:Luccy、BlockBeats編者によると、イーサリアムのすべてのコア開発者のコンセンサス電話（ACDC）は2週間ごとに開催され、イーサリアムのコンセンサスレイヤー（CL）の変更についての議論と調整が主な目的です。今回はACDCの第135回電話会議で、この会議では、Pectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize（SSZ）イーサリアム改善提案（EIP）のテストネットワークの準備に焦点を当てました。開発者たちは、ソフトウェアパッケージのメンテナンス、EIPを含むプロセスと新しいイーサリアムのコンセンサスレイヤのアップグレードについて詳しく議論しました。さらに、会議ではElectra仕様の実装の進捗状況、PeerDASネットワークの変更がイーサリアムノードのデータ処理と検証に与える影響、およびblob gas制限の追加に関する複雑な技術的問題についても触れられました。ギャラクシーデジタルの研究副社長クリスティン・キムは、この会議の要点を詳しく記録しています。BlockBeastsは以下のように翻訳しました:2024年6月13日、イーサリアムの開発者たちはZoomで開催されたAll Core Developers Consensus (ACDC)Call #135に出席しました。ACDC電話会議は、イーサリアム財団の研究者であるAlex Stokesが主催する、2週間ごとに開催されるシリーズの会議で、開発者はイーサリアムのコンセンサスレイヤー（CL、またはビーコンチェーンとも呼ばれます）の変更について議論と調整を行います。今週、開発者たちはPectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize（SSZ）イーサリアム改善提案（EIPs）用の3番目の専用テストネットの準備について議論しました。### お知らせ開発者たちは2つのアナウンスメントで会議を始めました。イーサリアム財団のDevOpsエンジニアであるParithosh Jayanthi氏は、ethPandaOpsチームがイーサリアム財団のDevOps作業を担当するエンジニアチームであることを示し、ethereum-package Kurtosisモジュールのメンテナンスと開発を引き継ぐことを発表しました。このパッケージは、開発者がイーサリアムのテストネットワークや関連ツール（Grafanaデータダッシュボードを含む）を起動するために使用していたものです。KurtosisチームからethPandaOpsチームへの移行に伴い、一部のリンクがKurtosisチームではなく、ethPandaOpsチームが管理するGitHubリポジトリにリダイレクトされる可能性があります。Jayanthi氏は、ユーザーにソフトウェアリンクの更新と、ethPandaOpsチームからの新バージョンの発表に注目するよう提案しています。第2の公告は、イーサリアム財団のプロトコルサポートディレクター、Tim Beiko氏によって発表されました。Beiko氏は、段階的にEIPをイーサリアムのアップグレードに取り込むための新しいプロセスの導入に努めていると述べています。彼は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）によってトリガーされる検証者の統合にはいくつかの未解決の問題があると述べました。Stokesは、会議の後でELトリガーの検証者の統合の状態をフォローアップすることに記録しました。最新のElectra規格の実装進捗について、会議でのほとんどのConsensus Layer（CL）クライアントチームは、v1.5.0-alpha.3が確定した後1〜2週間で新バージョンをテストする準備ができると述べています。開発者たちは、数週間後に次のPectra開発ネットワークPectra Devnet 1のスケジュールを再度検討することに同意しました。### ピアダス次に、開発者たちはPeerDASの実装進捗について議論しました。PeerDASはイーサリアムのネットワーク改善であり、ノードがブロブトランザクションを通じて大量の任意のデータを処理し、ユーザーの検証能力を強化します。Stokesは前回のACDC会議での決定を振り返り、開発者たちは他のPectra EIPと並行してPeerDASを開発し、開発ネットワークでPeerDASを単独でアクティブ化するアクティブ化サイクルを実現することを決定しました。Lodestarの開発者、Gajinder Singh氏は、最近のPeerDASのグループミーティングの議論に基づいて、開発者はDenebのアップグレードを基に、他のPectra EIPとは別の開発ネットワーク上でPeerDASをアクティブ化する予定です。Tekuの開発者、Enrico Del Fante氏は、PeerDASを構築する際に、以前のEthereumのアップグレードであるDenebで確立された安定したコード規格に基づくことが、Pectraのコード規格の変更に比べて容易だと述べています。Jayanthi氏は、PeerDASの実装と他のPectra EIPの実装を統合するのは、特にエラーの原因を特定しようとする際に、テストプロセスで複雑な問題を引き起こす可能性があるため、現時点では賛成していません。彼は、これら2つの作業フローを分けて実施し、両者の実装がより安定した後で統合することを提案しています。Stokes氏は同意し、PeerDASと他のPectra EIPの実装を約1ヶ月後に再び議論することができると述べました。PeerDAS Devnet 1の起動に関するトピックについて、クライアントチームはテストネットの起動がいつ準備できるかについて明確な見積もりはありません。会議での個人の見積もりは、おおよそ2週間から1ヶ月の間です。Stokesは数週間後に、クライアントチームがPeerDASの実装により多くの時間を持つときに、開発ネットワークのスケジュールを再検討することを提案しました。その後、Beikoは、PeerDASがイーサリアムのコアプロトコルの変更ではなくネットワークの改善であるにもかかわらず、コード変更をPectraのアップグレードの元EIPに含めたいと述べました。元EIP文書は、イーサリアムのアップグレードに含まれるすべてのコアプロトコルの変更が記載されている公共文書です。Beikoによると、PeerDASはPectraの中で「最大の特徴」であり、ハードフォークのアクティベーションは必要なくとも、開発者がPectraメインネットのアクティベーションに備えていることを示すために文書に含めるべきだと述べました。これに異論はありません。### ブロブ gas 制限の向上PeerDASは、ノードがイーサリアムのピアネットワークレイヤーを介してデータを処理および伝送する方法を変えました。ユーザー、特にLayer-2ロールアップの利益を得るために、開発者は現在のブロックごとの6つのブロブの制限をより高い閾値に引き上げる必要があります。これにより、より高いブロブ（任意のデータ）のスループットが可能になります。ブロブの制限を変更するには、イーサリアムのコアプロトコルを変更する必要があります。これについては、開発者が今週の会議で議論しているように、プロトコルスタックの定数値を単純に調整するよりも複雑なエンジニアリング作業が必要になる可能性があります。Stokesは、blob gasの制限を変更する際に、実行層（EL）と共識層（CL）の依存関係を切り離すことを提案しました。現在、blob gasの制限を変更するたびにELとCLのプロトコルを変更する必要があります。Stokesは、これらの依存関係を解消するいくつかの方法を提案し、開発者がELからハードコーディングされたblob gasの制限を安全に削除し、完全にCLによって決定できるようにしました。イーサリアム財団（EF）の研究者であるDankrad Feist氏は、ELとCLの依存関係の問題に加えて、blob gasの制限を変更することがブロックのgas計算にどのような連鎖反応をもたらすかも重要だと指摘しています。Feist氏は次のように述べています。「最善の方法は計算方法を変えることです。gas価格の計算がELで行われるのは間違いかもしれません。それはCLで行うべきですが、現在それを変更するのはより難しいです。……これは簡単なことではありません。」開発者たちは、blob gas の制限とブロック内の gas 計算の調整に関する最良の方法を引き続き検討することに同意しました。開発者たちはまた、Pectra で PeerDAS をアクティブにする際に blob gas の制限が増加するかどうかについても引き続き議論することに同意しました。これらの変更を一緒に実施するべきか、段階的に複数のハードフォークで実施すべきかについては意見が分かれています。Jayanthiは、これらの変更を組み合わせることは「リスクがある」決定であると述べ、開発者はPeerDASがメインネットでアクティブになる前にその具体的な機能を把握することはできません。イーサリアム財団（EF）のDevOpsエンジニアであるBarnabas Busaは、Pectraのハードフォークの範囲がすでに非常に大きいため、追加のコード変更は不要だと補足しています。Busaは、「重要なのは、私たちにはすでに多くのEIPがあるということで、ますます多くのコンテンツを追加し続けると、終わりが来ないと思います。ですので、どこかで線を引かなければなりません。それが私たちのゴールです。私は将来1年半のテスト期間内にPeerDASをリリースしてblobの数を増やすことは不可能だと考えています。」と述べています。一位「Francesco」的スクリーン名を持つ開発者は、ネットワークの変化が blob の数の増加を伴わない場合、PeerDAS を削除して「Pectra のリスクを低減」できると提案しました。Francesco は尋ねます：「blob の数が増えない場合、Pectra の PeerDAS にはどのような利点があるのでしょうか？」テストPeerDASの困難をさらに説明するために、Jayanthiは、テストがイーサリアムのEIP 4844にblobを導入することで、実際のblobのメインネット上での挙動や影響を完全にシミュレートしていないことを指摘しました。Jayanthiは、「問題はテストネットワークが非常に困難であることです。私たちは4844に関連する多くの素晴らしいテストを行いましたが、blobはメインネット上での挙動がテスト中の挙動と完全に一致しているわけではありません。私たちは弱いノードに問題が発生することを確かに見ています。時間的な課題が発生することを確かに見ています。これが、開発ネットワークでPeerDASとblobの数を増やしても正常に動作する理想的な状況をシミュレートできても、これがメインネットにとって実質的な意味を持たないため、私が一歩ずつ進むべきだと考える主な理由でもあります。」と述べています。EF 研究員 Ansgar Dietrichs は、blob 数の増加と PeerDAS の関連付けを間違いだとコメントしました。なぜなら、PeerDAS は開発者に blob 数の値を選択することを要求しているだけであるからです。開発者はイーサリアムメインネットと同じ数字を選択することができますが、PeerDAS がどの数字を使用すべきかについては決定しなければなりません。同じ数字を選択する唯一の理由は、開発者が PeerDAS の複雑さを増加させ、エラーが発生した場合に現行の Deneb 仕様での blob 伝搬メカニズムにロールバックできるようにするためです。Dietrichs は、テストの複雑さに関する懸念が彼の Pectra を二つのハードフォークでアクティブにするべきだという見解をさらに強化したと述べ、ただし、これは PeerDAS が blob 数の変更とは別になるべきだという意味ではありません。### SSZアップデートKisslingは、SSZに関連する3つのEIPの進捗状況を共有しました。これらのEIPの実装作業は、Teku、Grandine、Lighthouseを含む複数のクライアントで展開されています。彼は、開発者がこれらのSSZ EIPの開発ネットワークのスケジュールについて議論を始め、次のACDCミーティングでPectraアップグレードの範囲に含めることができるかもしれないと述べました。### F-スターの命名Ethereum Magiciansでの記事で、Electraの次のEthereumコンセンサスレイヤー（CL）のアップグレードの名前について議論されています。開発者はPragueの後のExecution Layer（EL）のアップグレードの名前を決定しました：Osaka。CLのアップグレードの候補の名前は、Fulu、Felis、Formosa、Funiです。これらの名前は、Beacon Chainの6回目のネットワーク全体のアップグレードに適用される、主に恒星の命名規則に従っています。Stokesは、開発者にこのトピックに関する意見をMagiciansの記事に投稿するように依頼します。
イーサリアムコア開発者の最新の会議の概要:PeerDASをアクティブ化し、ブロブガス制限を引き上げます
執筆者：クリスティン・キム
コンピレーション:Luccy、BlockBeats
編者によると、イーサリアムのすべてのコア開発者のコンセンサス電話（ACDC）は2週間ごとに開催され、イーサリアムのコンセンサスレイヤー（CL）の変更についての議論と調整が主な目的です。今回はACDCの第135回電話会議で、この会議では、Pectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize（SSZ）イーサリアム改善提案（EIP）のテストネットワークの準備に焦点を当てました。
開発者たちは、ソフトウェアパッケージのメンテナンス、EIPを含むプロセスと新しいイーサリアムのコンセンサスレイヤのアップグレードについて詳しく議論しました。さらに、会議ではElectra仕様の実装の進捗状況、PeerDASネットワークの変更がイーサリアムノードのデータ処理と検証に与える影響、およびblob gas制限の追加に関する複雑な技術的問題についても触れられました。
ギャラクシーデジタルの研究副社長クリスティン・キムは、この会議の要点を詳しく記録しています。BlockBeastsは以下のように翻訳しました:
2024年6月13日、イーサリアムの開発者たちはZoomで開催されたAll Core Developers Consensus (ACDC)Call #135に出席しました。ACDC電話会議は、イーサリアム財団の研究者であるAlex Stokesが主催する、2週間ごとに開催されるシリーズの会議で、開発者はイーサリアムのコンセンサスレイヤー（CL、またはビーコンチェーンとも呼ばれます）の変更について議論と調整を行います。今週、開発者たちはPectra Devnet 1、PeerDAS Devnet 1、およびSimple Serialize（SSZ）イーサリアム改善提案（EIPs）用の3番目の専用テストネットの準備について議論しました。
お知らせ
開発者たちは2つのアナウンスメントで会議を始めました。イーサリアム財団のDevOpsエンジニアであるParithosh Jayanthi氏は、ethPandaOpsチームがイーサリアム財団のDevOps作業を担当するエンジニアチームであることを示し、ethereum-package Kurtosisモジュールのメンテナンスと開発を引き継ぐことを発表しました。このパッケージは、開発者がイーサリアムのテストネットワークや関連ツール（Grafanaデータダッシュボードを含む）を起動するために使用していたものです。KurtosisチームからethPandaOpsチームへの移行に伴い、一部のリンクがKurtosisチームではなく、ethPandaOpsチームが管理するGitHubリポジトリにリダイレクトされる可能性があります。Jayanthi氏は、ユーザーにソフトウェアリンクの更新と、ethPandaOpsチームからの新バージョンの発表に注目するよう提案しています。
第2の公告は、イーサリアム財団のプロトコルサポートディレクター、Tim Beiko氏によって発表されました。Beiko氏は、段階的にEIPをイーサリアムのアップグレードに取り込むための新しいプロセスの導入に努めていると述べています。彼は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）によってトリガーされる検証者の統合にはいくつかの未解決の問題があると述べました。Stokesは、会議の後でELトリガーの検証者の統合の状態をフォローアップすることに記録しました。
最新のElectra規格の実装進捗について、会議でのほとんどのConsensus Layer（CL）クライアントチームは、v1.5.0-alpha.3が確定した後1〜2週間で新バージョンをテストする準備ができると述べています。開発者たちは、数週間後に次のPectra開発ネットワークPectra Devnet 1のスケジュールを再度検討することに同意しました。
ピアダス
次に、開発者たちはPeerDASの実装進捗について議論しました。PeerDASはイーサリアムのネットワーク改善であり、ノードがブロブトランザクションを通じて大量の任意のデータを処理し、ユーザーの検証能力を強化します。Stokesは前回のACDC会議での決定を振り返り、開発者たちは他のPectra EIPと並行してPeerDASを開発し、開発ネットワークでPeerDASを単独でアクティブ化するアクティブ化サイクルを実現することを決定しました。
Lodestarの開発者、Gajinder Singh氏は、最近のPeerDASのグループミーティングの議論に基づいて、開発者はDenebのアップグレードを基に、他のPectra EIPとは別の開発ネットワーク上でPeerDASをアクティブ化する予定です。Tekuの開発者、Enrico Del Fante氏は、PeerDASを構築する際に、以前のEthereumのアップグレードであるDenebで確立された安定したコード規格に基づくことが、Pectraのコード規格の変更に比べて容易だと述べています。Jayanthi氏は、PeerDASの実装と他のPectra EIPの実装を統合するのは、特にエラーの原因を特定しようとする際に、テストプロセスで複雑な問題を引き起こす可能性があるため、現時点では賛成していません。彼は、これら2つの作業フローを分けて実施し、両者の実装がより安定した後で統合することを提案しています。Stokes氏は同意し、PeerDASと他のPectra EIPの実装を約1ヶ月後に再び議論することができると述べました。
PeerDAS Devnet 1の起動に関するトピックについて、クライアントチームはテストネットの起動がいつ準備できるかについて明確な見積もりはありません。会議での個人の見積もりは、おおよそ2週間から1ヶ月の間です。Stokesは数週間後に、クライアントチームがPeerDASの実装により多くの時間を持つときに、開発ネットワークのスケジュールを再検討することを提案しました。
その後、Beikoは、PeerDASがイーサリアムのコアプロトコルの変更ではなくネットワークの改善であるにもかかわらず、コード変更をPectraのアップグレードの元EIPに含めたいと述べました。元EIP文書は、イーサリアムのアップグレードに含まれるすべてのコアプロトコルの変更が記載されている公共文書です。Beikoによると、PeerDASはPectraの中で「最大の特徴」であり、ハードフォークのアクティベーションは必要なくとも、開発者がPectraメインネットのアクティベーションに備えていることを示すために文書に含めるべきだと述べました。これに異論はありません。
ブロブ gas 制限の向上
PeerDASは、ノードがイーサリアムのピアネットワークレイヤーを介してデータを処理および伝送する方法を変えました。ユーザー、特にLayer-2ロールアップの利益を得るために、開発者は現在のブロックごとの6つのブロブの制限をより高い閾値に引き上げる必要があります。これにより、より高いブロブ（任意のデータ）のスループットが可能になります。ブロブの制限を変更するには、イーサリアムのコアプロトコルを変更する必要があります。これについては、開発者が今週の会議で議論しているように、プロトコルスタックの定数値を単純に調整するよりも複雑なエンジニアリング作業が必要になる可能性があります。
Stokesは、blob gasの制限を変更する際に、実行層（EL）と共識層（CL）の依存関係を切り離すことを提案しました。現在、blob gasの制限を変更するたびにELとCLのプロトコルを変更する必要があります。Stokesは、これらの依存関係を解消するいくつかの方法を提案し、開発者がELからハードコーディングされたblob gasの制限を安全に削除し、完全にCLによって決定できるようにしました。イーサリアム財団（EF）の研究者であるDankrad Feist氏は、ELとCLの依存関係の問題に加えて、blob gasの制限を変更することがブロックのgas計算にどのような連鎖反応をもたらすかも重要だと指摘しています。Feist氏は次のように述べています。「最善の方法は計算方法を変えることです。gas価格の計算がELで行われるのは間違いかもしれません。それはCLで行うべきですが、現在それを変更するのはより難しいです。……これは簡単なことではありません。」
開発者たちは、blob gas の制限とブロック内の gas 計算の調整に関する最良の方法を引き続き検討することに同意しました。開発者たちはまた、Pectra で PeerDAS をアクティブにする際に blob gas の制限が増加するかどうかについても引き続き議論することに同意しました。これらの変更を一緒に実施するべきか、段階的に複数のハードフォークで実施すべきかについては意見が分かれています。
Jayanthiは、これらの変更を組み合わせることは「リスクがある」決定であると述べ、開発者はPeerDASがメインネットでアクティブになる前にその具体的な機能を把握することはできません。イーサリアム財団（EF）のDevOpsエンジニアであるBarnabas Busaは、Pectraのハードフォークの範囲がすでに非常に大きいため、追加のコード変更は不要だと補足しています。Busaは、「重要なのは、私たちにはすでに多くのEIPがあるということで、ますます多くのコンテンツを追加し続けると、終わりが来ないと思います。ですので、どこかで線を引かなければなりません。それが私たちのゴールです。私は将来1年半のテスト期間内にPeerDASをリリースしてblobの数を増やすことは不可能だと考えています。」と述べています。
一位「Francesco」的スクリーン名を持つ開発者は、ネットワークの変化が blob の数の増加を伴わない場合、PeerDAS を削除して「Pectra のリスクを低減」できると提案しました。Francesco は尋ねます：「blob の数が増えない場合、Pectra の PeerDAS にはどのような利点があるのでしょうか？」
テストPeerDASの困難をさらに説明するために、Jayanthiは、テストがイーサリアムのEIP 4844にblobを導入することで、実際のblobのメインネット上での挙動や影響を完全にシミュレートしていないことを指摘しました。Jayanthiは、「問題はテストネットワークが非常に困難であることです。私たちは4844に関連する多くの素晴らしいテストを行いましたが、blobはメインネット上での挙動がテスト中の挙動と完全に一致しているわけではありません。私たちは弱いノードに問題が発生することを確かに見ています。時間的な課題が発生することを確かに見ています。これが、開発ネットワークでPeerDASとblobの数を増やしても正常に動作する理想的な状況をシミュレートできても、これがメインネットにとって実質的な意味を持たないため、私が一歩ずつ進むべきだと考える主な理由でもあります。」と述べています。
EF 研究員 Ansgar Dietrichs は、blob 数の増加と PeerDAS の関連付けを間違いだとコメントしました。なぜなら、PeerDAS は開発者に blob 数の値を選択することを要求しているだけであるからです。開発者はイーサリアムメインネットと同じ数字を選択することができますが、PeerDAS がどの数字を使用すべきかについては決定しなければなりません。同じ数字を選択する唯一の理由は、開発者が PeerDAS の複雑さを増加させ、エラーが発生した場合に現行の Deneb 仕様での blob 伝搬メカニズムにロールバックできるようにするためです。Dietrichs は、テストの複雑さに関する懸念が彼の Pectra を二つのハードフォークでアクティブにするべきだという見解をさらに強化したと述べ、ただし、これは PeerDAS が blob 数の変更とは別になるべきだという意味ではありません。
SSZアップデート
Kisslingは、SSZに関連する3つのEIPの進捗状況を共有しました。これらのEIPの実装作業は、Teku、Grandine、Lighthouseを含む複数のクライアントで展開されています。彼は、開発者がこれらのSSZ EIPの開発ネットワークのスケジュールについて議論を始め、次のACDCミーティングでPectraアップグレードの範囲に含めることができるかもしれないと述べました。
F-スターの命名
Ethereum Magiciansでの記事で、Electraの次のEthereumコンセンサスレイヤー（CL）のアップグレードの名前について議論されています。開発者はPragueの後のExecution Layer（EL）のアップグレードの名前を決定しました：Osaka。CLのアップグレードの候補の名前は、Fulu、Felis、Formosa、Funiです。これらの名前は、Beacon Chainの6回目のネットワーク全体のアップグレードに適用される、主に恒星の命名規則に従っています。Stokesは、開発者にこのトピックに関する意見をMagiciansの記事に投稿するように依頼します。