ホームページ > ウェブ3.0 > イーサリアムコア開発者の最新会議の概要: Dencun アップグレードの最終進捗状況と Pectra アップグレード範囲の議論

イーサリアムコア開発者の最新会議の概要: Dencun アップグレードの最終進捗状況と Pectra アップグレード範囲の議論

WBOY
リリース: 2024-03-09 13:13:11
転載
1383 人が閲覧しました

以太坊核心开发者最新会议摘要:Dencun升级最终进展及Pectra 升级范围讨论

編集者: Luccy、BlockBeats

イーサリアム コア開発者コンセンサス コール (ACDC) は、イーサリアム コンセンサス レイヤー (CL) 調整の変更について話し合い、調整するために定期的に開催されます。 。最新のACDCコールは129回目で、開発者らはDencunアップグレードの準備に関する最新の進捗状況を共有し、次期イーサリアムアップグレードであるPectraの範囲とEIPについて議論した。

Galaxy Digital のリサーチ担当副社長 Christine Kim は、この会議の要点を詳細に記録し、BlockBeasts は原文を次のようにまとめました:

2024 年 3 月 7 日、イーサリアム開発者は Zoom に集まりました。 All Core Developers Consensus (ACDC) コール #129 ミーティングに参加するには。 ACDC コールは、イーサリアム財団の研究者ダニー・ライアンが主催する隔週の一連の会議であり、開発者はイーサリアム コンセンサス レイヤー (CL) への変更について話し合い、調整します。今週、開発者は、3 月 13 日水曜日にメインネットでアクティブ化される予定の Dencun アップグレードの準備に関する最終更新情報を共有しました。彼らはまた、次期イーサリアムのアップグレードである Pectra の範囲や、CL クライアント間のブロック値の標準化などのいくつかの研究トピックについても議論しました。

デネブ

ライアン氏は、電話会議の冒頭で、Dencun のアップグレードが 1 週間以内にイーサリアム上で公開されることを全員に思い出させ、また、多くのアメリカ人にとって、それがこの問題の始まりになるだろうとも述べました。すべての ACD 電話会議とアップグレードは DST を遵守せずに協定世界時 (UTC) に基づいてスケジュールされているため、米国外の開発者と電話参加者はそれに応じてスケジュールを調整する必要があります。

電話会議中に、一部のクライアント チームは、Dencun のアップグレードに合わせて、数日以内にソフトウェアの更新バージョンをリリースする予定であることを明らかにしました。 Prysm、Lighthouse、Teku の各チームは今週末までに新しいバージョンをリリースする予定です。これらの更新されたバージョンは必須のアップグレードではありませんが、イーサリアム財団のティム・ベイコ氏はZoom会議中に、Dencunと互換性のあるすべてのバージョンを要約したブログ投稿は更新しないと述べました。

Flashbots チームの Chris Hager が、MEV-Boost ソフトウェアの準備状況に関する最新情報を共有しました。 Hager 氏は、先週リリースされた MEV-Boost バージョン 1.7 が安定しており、バリデーター ノードのオペレーターが使用できることを確認しました。 Deneb用のFlashbotsビルダーソフトウェアはまだ開発中で、今週中には完成して統合される予定だという。バリデーターのアップグレードの準備状況に関して、Hager 氏は、Dencun のアップグレードに対応するために MEV-Boost ソフトウェアをアップデートしているバリデーターが十分にいないと思われることに懸念を表明しました。データを再確認した後、Hager 氏は、Flashbots リレーに接続されているバリデーターの約 50% が最新の MEV-Boost バージョン v1.7 を使用していると述べました。

Beiko氏はさらに、彼の情報源MetrikaとEthernetsがイーサリアムノードの約半数がDencunにアップグレードする準備ができていることを示していると指摘した。同氏はまた、すべてのイーサリアムノードだけでなく、バ​​リデーターノードのアップグレードの準備状況を追跡できるデータツールへの期待も表明した。

Electra

Ethereum 開発者は、Pectra のアップグレードに関連する 4 つのコード変更について話し合いました。

EIP 7459

1 つ目は Ethereum Improvement Proposal (EIP) 7549 です。これにより、CL クライアントはブロック (構成証明とも呼ばれる) の投票をより効率的に集約できるようになります。開発者は、EIP 7549 を Pectra に組み込むという以前の推奨事項に同意しています。 Teku開発者のMikhail Kalinin氏は、EIP 7549がイーサリアムにどのように実装されるかについてさらなる分析を共有し、コード変更の結果として導入される可能性のあるいくつかのトレードオフまたは「マイナスの影響」を示唆しました。 Ryan は、さらなるフィードバックとレビューのために、CL 仕様に対する提案された変更を GitHub 上で直接要約するよう Kalinin に提案しました。

Prysm 開発者の Terence Tsao 氏は、Kalinin 氏が提案した EIP 7549 の実装には同意するが、この EIP に必要な Beacon API の変更についてはさらなるドキュメントと仕様を推奨すると述べました。 「現在、同じスロットに 10 個のアグリゲーターがある場合、10 個の証明書に署名する必要がありますが、この変更により、メッセージを 1 つ送信するだけで済みます。そのため、ビーコン API にいくつかの変更が必要になる可能性があります」と Tsao 氏は述べ、Dao 氏は付け加えた, 「この問題を解決するには、ビーコン API バリデーターの統合を変更する方法について、この部分でさらに検討する必要があるかもしれません。」 背景として、ビーコン API は、ノードがネットワークにクエリを実行し、ネットワークのステータスに関する情報を取得できるようにする CL の仕様です。ネットワーク。

発行額の削減

次に、EF 研究者のアンスガー・ディートリヒス氏が、ネットワーク発行額を減らすことでステーキング報酬を削減するという提案について簡単な最新情報を共有しました。同氏は、前回のACDC電話会議でこの提案が提示されて以来、「コミュニティからさまざまなフィードバック」があったと述べた。同氏は、この提案は、メインネットが10月にハードフォークすることを前提として、6月か7月までに土壇場でのElectraアップグレードに組み込むことができる小さなコード変更になるだろうと繰り返し述べた。しかしディートリヒス氏は、協議は「進行中」である、つまり決定を下す前にこのアイデアについてさらに議論する必要があるとも述べた。

EIP 7547

3 番目に、EF 研究者の Mike Neuder は、さらなる議論のためのリストを含む EIP 7547 を提示しました。同氏は、EIP設計の「正確な特徴」について議論するための2回目の分科会が有益であり、来週金曜日、3月15日の開催を検討していると述べた。同氏はまた、EIPには「Inclusion List」と呼ばれる専用のDiscordチャンネルがあり、提案について詳しく知りたい人や質問したい人は利用すべきだとも述べた。ツァオ氏はまた、2月16日の最初の対象リスト分科会以降、提案の仕様はほぼ具体化されたと述べた。 「仕様はおそらく約 75% 完成していると思います」と Tsao 氏は述べ、実行 API や正直なバリデータ周りの仕様の変更など、仕様には改善が必要なコンポーネントが他にもいくつかあると付け加えました。

EIP 7251

最後に、Lighthouse 開発者の Mark Mackey は、最大有効残高 (maxEB) を増加させる EIP 7251 のサポートを表明しました。 「Lighthouse でほぼプロトタイプを作成しました。仕様に関してはまだやるべき作業がいくつかありますが、実際には大した作業ではないようです。バリデータ セットのサイズを考慮すると、ちょっとした時限爆弾のようなものです」 「私たちはTuneの提案をリリースすることを提案しました。リリースの変更は常に物議を醸すため、コミュニティがそれを受け入れる保証はありません。コミュニティがそれを気に入らない場合、私たちが実際にできる唯一のことはmaxEBです」とマッキー氏は言いました。 Ryan 氏は、maxEB を Electra に組み込むことへの主な抵抗は、Prysm チームとの以前の通話で表明されたように、コード変更の複雑さによるものであると述べました。 Prysmチームの匿名開発者「ポツズ」は、Zoom会議のチャットで、彼のチームはEIPを再度検討し、提案の複雑さを再評価すると述べた。ライアン氏はアカウントチームに対し、EIP 7547と7251に関して「確固たる決定」を下すため、2週間後の次回のACDCコールに向けて準備するよう求めた。

キー マネージャー API 標準化

EF 開発者運用 (DevOps) エンジニアの Barnabas Busa 氏は、すべての CL クライアントはバリデーター キーを生成する方法が若干異なるようで、バリデーター キーは暗号化キーであると説明しました。バリデーターの操作と取り消しに必要なキー。 「キー マネージャー API」と呼ばれる API があり、バリデーター ノードのオペレーターによるキー管理やバリデーターへの参加および終了を支援します。 Busa 氏は、この API の戻り値に関してはクライアント間の微妙な違いが API エンドポイントのテストを困難にしていると説明しました。彼はまた、彼のチームがハイブリッドバリデーターの基本的なテストを開始したことにも言及しました。これは、バリデーターノードオペレーターがビーコンノードにバリデータークライアントとは異なるクライアントを使用することを意味します。ビーコン ノードは、CL 状態を維持するクライアントですが、コンセンサスに参加するためにバリデーターが必要とするキー ペアは管理しません。バリデータ クライアントは、キー ペアを利用してブロックを生成し、チェーン上の証明に署名するクライアントです。 Ryan は、Busa がキー マネージャー API を標準化するための提案を含むドキュメントまたはプル リクエストを開始することを提案しました。通話中の開発者は、ハイブリッド バリデーターがすべての CL クライアントの組み合わせで動作することを確認するためのさらなるテストもサポートします。

ブロック値ビーコン API の標準化

スクリーン名が「Dustin」である Nimbus 開発者も、ビーコン API エンドポイント「productBlockV3」および「getBlockRewards」の CL 標準化について懸念を表明しました。 Dustin 氏は、Beacon API の一部の領域は明確に定義されておらず、クライアント間で「普遍的に実装されていない」と説明しました。具体的には、ブロック値を返すエンドポイントに関しては、提案されたブロックの前後のバリデーターバランスの変化を少なくとも計算に含める必要があります。ただし、この仕様では、別のバリデーターのアクションによるバリデーターの残高の変更に対するクライアントが報酬とペナルティを含めるべきかどうかについては詳しく説明されていません。これらには、例えば、委員会の同時任務の賞または罰則、提案者または認証者の自己減額、および内部告発者の表彰が含まれます。 Ryan は、Beacon API に命令を追加する必要があることに同意します。しかし、Prysm チームの Radosław Kapka 氏や Potuz 氏など、会議に参加した他の開発者はあまり自信がありませんでした。 Potuz 氏は、これらのエンドポイントを使用している人の数が少なく、独自のツールを使用してさまざまな CL クライアントからのブロック値を正規化できる人が少ないことに懸念を表明しました。 「消費者が制限されているのに、なぜこれをサポートすることに同意するのかさえ理解できません。これらの市場に注目して、自分たちの代わりにこれらのエンドポイントを使用して実際にこの作品を人々に送信できるかどうかを確認してみたいと思います。」とポトゥズ氏は述べました。

Nimbus 開発者の Jacek Sieka 氏は、この見解に反論し、「productBlockV3」エンドポイントの存在により、開発者はクライアント間の不一致を解決するか、エンドポイントを非推奨にして「V4」を使用する必要があると述べました。さらに、Sieka 氏は「このエンドポイントは非常に基本的な機能にすぎないと思います。複数のブロック ソースがあり、それらを比較する必要がある未来を想像するのであれば、これは理にかなっています。とても簡単なことです。」と Ryan 氏が Dustin Create 氏に提案をアドバイスしました。 V3 と「getBlockRewards」エンドポイントを標準化するため、提案が作成されたら、アカウント チームはサポートを継続するかどうかを再検討します。

残り

Potuz は、さらなる開発者のフィードバックと議論のために 2 つのプロジェクトにフラグを立てました。 1 つ目は、EL と CL の間の通信を指定するエンジン API で現在指定されていない、遅延ブロックの実行層 (EL) クライアントの動作に関するものです。 「これをエンジン API で指定できれば、後のブロックを再編成する際に容易になるでしょう」と Potuz 氏は言います。ポトゥズ氏がフラグを立てた 2 番目の項目は、イーサリアム上で信頼できるリレーの必要性を排除するアップグレードである Proposer Builder Separation (ePBS) ペイロード アップグレードの分析に関するものでした。 Potuz 氏は、分析およびその他の ePBS 設計の制限に関する追加のフィードバックを要求しました。

最後に、Ethereum Cat Herder グループの Pooja Ranjan 氏は、Women in the Ethereum Protocol (WiEP) と呼ばれる新しい作業グループの設立を発表しました。 WiEP は、より多くの女性イーサリアム プロトコル開発者を奨励し、育成することに特化したイーサリアム財団の新しい組織です。ランジャン氏は、同グループが3月8日に数人の女性イーサリアムプロトコル貢献者と議論する1時間のウェビナーを主催すると述べた。

ライアンはその後、4月1日から3か月の休暇を取ると述べた。同氏が不在の間は、EFフェローのアレックス・ストークス氏がACDC招集の司会を務める。

以上がイーサリアムコア開発者の最新会議の概要: Dencun アップグレードの最終進捗状況と Pectra アップグレード範囲の議論の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

関連ラベル:
ソース:panewslab.com
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート