執筆者: Christine Kim
編集者: Luccy、BlockBeats
編集者注: Ethereum All Core Developers Consensus Call (ACDC) は、Ethereum Consensus Layer (CL) の実装について話し合い、調整するために 2 週間ごとに開催されます。 ） 変化。これは 134 回目の ACDC 電話会議で、開発者は EIP 7549、EIP 7251、EIP 6110、EIP 7688 などの複数の主要 EIP の実装の詳細と技術的課題について議論しました。
さらに、開発者らは、ロールアップとそのデータ可用性要件をサポートするイーサリアム ネットワークの能力を大幅に向上させることが期待されるデータ可用性サンプリング テクノロジである PeerDAS の実装についても詳しく議論しました。会議中、アップグレードのために Pectra を 2 つのハード フォークに分割するという提案が行われ、アクティブ化時間と異なる EIP の相互依存性の問題が議論されました。
Galaxy Digital のリサーチ担当副社長 Christine Kim がこの会議の要点を詳細に記録し、BlockBeasts は原文を次のようにまとめました:
2024 年 5 月 30 日、イーサリアム開発者はオールコア開発者コンセンサスに参加するために Zoom に集まりました。 (ACDC) #134 会議に電話します。 ACDC コールは、イーサリアム財団の研究者アレックス・ストークスが主催する隔週の一連の会議で、開発者はイーサリアム コンセンサス レイヤー (CL、ビーコン チェーンとも呼ばれる) への変更について話し合い、調整します。今週は、開発者が Pectra Devnet 0 のリリース以降の経験と未解決の問題について話し合います。また、Pectra アップグレードの範囲を拡大して、peerDAS および SSZ コンテナ コードの変更を含めることの実現可能性についても議論しました。
Devnet 0 での Pectra のリリースを考慮して、クライアント チームは、ハード フォークのアクティブ化中に EIP 7549 の影響を受ける検証動作を変更しないことに同意しました。以前の ACDC 会議では、開発者は EIP 7549 の影響によりフォーク中に多数の無効な検証が発生しないようにするためのさまざまなオプションを検討しました。アップグレードのさらなる複雑化を避けるために、クライアント チームは、フォークの前後で検証動作を変更せずに、他の Pectra EIP と同じエポックで EIP 7549 をアクティブ化することにしました。
EIP 7251に関して、開発者はステーキングされたETHのマージを実行層(EL)からトリガーできるかどうかまだ迷っています。これは、Lido のようなステーキング プールにとって理想的な機能であり、ステークのマージがノード オペレーターに依存する必要がなく、代わりにスマート コントラクトを通じて実行できるようになります。ストークス氏は、クライアントがバリデーターステーキングマージを実装している状況を数週間以内に確認してから、EL操作にするかCL操作にするかを決定することを推奨しました。
その後、開発者は、EIP 6110 に基づくバリデーター デポジットの最終確認に関するいくつかの未回答の質問について話し合いました。 Teku 開発者の Mikhail Kalinin は、カンファレンスの前に GitHub コメントでこれらの問題に対処するための方向性をまとめました。 Lighthouse 開発者の「sean」は、エンジン API の「GetPayloadBodies」リクエストのバージョン管理について質問を提起しました。 Stokes 氏は、開発者に対し、GitHub 上でこの問題に対して作成されたプル リクエストにコメントを投稿することを推奨しました。
Nimbus 開発者 Etan Kissling は、EIP 7549 の実装に小さな変更を提案しました。 「これは一般化されたインデックスの安定性に関するものです。コンテナの中央に新しいフィールドを追加すると、後続のフィールドには新しいインデックスが割り当てられ、実行レベル (EL) で EIP 4788 に基づく証明が破られてしまいます。 …したがって、両方の問題を避けるために、新しいフィールドを最後に移動することをお勧めします。」と Kissling 氏は説明しました。この変更には異論はありませんでした。 Stokes 氏は開発者に対し、GitHub で Kissling のプル リクエストをチェックすることを推奨しています。
会議で提案された EIP 7549 へのもう 1 つの変更は、EL によってトリガーされるリクエストおよびその他のリクエストを EL ブロックへのアドオンとして設計することでした。この変更について、Kalinin 氏は次のように述べています。「私の意見では、これは非常に優れた設計ソリューションであり、EL を簡素化します。基本的に、実行層ブロックでの一般化されたリクエストの代替手段です。このトピックを取り上げることをお勧めします。」開発者が GitHub で提案を検討するためのより多くの時間を取れるように、次回の CL ミーティングで再度議論します。
まだ正式に Pectra アップグレードに含まれていない、または Pectra アップグレードから除外されていない、コンセンサス レイヤー (CL) に焦点を当てた EIP がいくつかあります。今週の会議では、開発者らは EIP 7688 と PeerDAS を Pectra に追加するかどうかについて議論しました。 EIP 7688 は、「StableContainer」SSZ データ構造の一部を採用して、EIP 7549 の構成証明の変更の前方互換性を確保します。背景の紹介として、SSZ は CL で使用されるデータ構造であり、開発者はそれを実行層 (EL) でも使用したいと考えています。 SSZ 移行の詳細については、以前の会議議事録を参照してください。 PeerDAS は、イーサリアム上でのデータ可用性サンプリングの実装であり、ロールアップとデータ可用性要件をサポートするネットワークの能力を大幅に強化することが期待されています。実際には、PeerDAS により、バリデーターがブロックにアタッチできる BLOB トランザクションの数が、ブロックあたり 3 から 64 以上に増加すると予想されます。
イーサリアム財団の開発者オペレーション エンジニアである Barnabas Busa 氏は、開発者が開発ネットワーク上で PeerDAS の初期イテレーションを開始したと述べました。 「多くのクライアントが多くの問題を発見したと思います。大幅な進歩があれば、いつでも新しい開発ネットワークを再開できます」とブサ氏は語った。 Stokes 氏は開発者に対し、アップグレードの遅延を引き起こすことなく PeerDAS を Pectra に追加する意思があるかどうかを尋ねました。
「Nishant」というニックネームの開発者は、Pectra で PeerDAS のアクティベーションを他の EIP のアクティベーションから分離するという提案を復活させました。これは実現可能ですが、「atd」というニックネームの別の開発者は、開発者が短期間にこれらのアップグレードを次々にアクティブ化することを計画している場合でも、ユーザーは依然としてソフトウェアを同時にアップグレードする必要があると強調しました。 atd 氏は次のように述べています。「別のアップグレードの 2 か月後にフォークを実行するのは少しクレイジーだと思います。クライアントをアップグレードするために全員を調整するつもりなら、2 か月後に全員にクライアントをアップグレードさせる必要はありません。そうすれば、全員がクライアントをアップグレードできるようになります。」 1 回のリリース サイクルでも十分ではありません。」
atd 氏は、彼の意見では、PeerDAS は、Pectra に含まれ議論されている EIP の中で最も「興味深い」コード変更であると付け加えました。 Stokes 氏は、たとえアップグレードに遅れが生じるとしても、Pectra に PeerDAS を含めたいと述べています。 Grandine クライアント開発者の Saulius Grigaitis は、PeerDAS を支持して Pectra から EIP 7549 と EIP 7688 を削除することを提案しました。これにより、EIP 7688 の実装の詳細についての議論が始まりました。開発者はコード変更について合意できず、この提案は次回の ACDC 会議で再検討される予定です。
PeerDAS のトピックに関して、開発者は Pectra を 2 つのハード フォークに分割するというアイデアを検討し続けています。イーサリアム財団の開発者オプションエンジニアのパリトシュ・ジャヤンティ氏は、開発者がペクトラを2つのアップグレードに分割する場合、将来のペクトラパート2でさらにEIPを追加しないように注意する必要があると警告した。 Jayanthi 氏は次のように述べています。「1 つ言及しておきたいのは、2 つのフォークに分割することを検討する場合、次のフォークでさらに新しい EIP を追加しないように細心の注意を払う必要があるということです。それができるかどうかはわかりません。もし私たちが 1 年か 1 年半前に何かに取り組んでいれば、私たちは常に新しいアイデアを思いつき、優先順位なども変化しているからです。」
2 つのアップグレード アイデア、Lighthouse 開発について引き続き議論します。著者「ショーン」は、PeerDAS と現在の Pectra EIP リストの間に多くの相互依存性があるとは予想していなかった、と述べました。したがって、この 2 つは個別に実行でき、開発者がその実装に自信を持ったら、後で簡単に統合できます。 Atd もこれに同意し、Pectra EIP、PeerDAS、および EIP 7688 を個別に開発およびテストした後、これらを統合しても大きなリスクはないと主張しました。
Busa 氏は、Pectra EIP と PeerDAS のテストを継続することを推奨していますが、開発およびテスト ネットワーク上で PeerDAS が Pectra EIP よりも 1 エポック遅くアクティブ化されるようにコードを変更します。同氏は、これがすでに Devnet 0 で Pectra EIP と PeerDAS のテストが行われている方法であると述べました。 「実際に変更する必要があるものは何もありません」とブサ氏は述べ、他の Pectra EIP の準備ができているときに PeerDAS の準備ができていない場合、開発者はアップグレードからそのコードの変更を削除できると付け加えました。これにより、PeerDAS のさまざまなアクティベーション エポックがクライアント チームの作業にどのような影響を与えるかについて、いくつかの疑問が生じます。最終的に、開発者は PeerDAS と Pectra EIP の開発を継続することに同意しましたが、その前提は、PeerDAS が開発ネットワークとテスト ネットワーク上の異なるエポックでアクティブ化されるということでした。
上記のように、開発者は、EIP 7688 が Pectra に含まれるかどうかについての議論は、次回の ACDC の呼びかけまで保留することに同意しました。
以上がイーサリアムコア開発者の最新ミーティングの概要: Pectra のアップグレードは 2 つのハードフォークに分割される可能性があるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
