イーサリアムコア開発者の最新会議の概要: メインネットのステータスと成長データの分析、プラハのアップグレード提案

原題:「Ethereum All Core Developers Execution Call #184 Writeup」
原著者: Christine Kim
編集者: Luccy、BlockBeats

編集者注:

イーサリアム コミュニティでは、オール コア開発者コンセンサス コール (ACDE) が 2 週間ごとに開催され、イーサリアム実行層 (EL) の改善について議論および交渉されます。これは ACDE の 184 回目の電話会議であり、このカンファレンスでは、3 月 27 日に誤ったブロックの数が増加した理由と、イーサリアムの状況と歴史的成長に関するパラダイム チームの新しい研究に焦点が当てられます。

開発者はカンファレンスで、Bloxroute MEV リレーの問題とプラハ/エレクトラでの 2 つの遡及 EIP に関するディスカッションを共有しました。さらに、EIP 7547 (包含リスト)、EIP 5920 (PAY オペコード)、および EIP 7545 (Verkle Proof Verification Precompilation) の開発更新についても議論されました。

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

2024 年 3 月 28 日、イーサリアム開発コミュニティは招集されました。 All Core Developers Execution (ACDE) コール #184 の Zoom ミーティング。ACDE コールは隔週の一連のミーティングで、イーサリアムの開発に関連する決定が議論され、調整されます。イーサリアム財団がサポートするメインコーディネーターのティム ベイコ氏が、この会議を率いました。イーサリアム改善提案 (EIP) に対する提案された変更についての議論と合意形成に参加した開発者。

今週、開発者は、3 月 27 日の不正確なブロック数の増加の原因についての洞察を共有しました。 Prysm開発者のテレンス・ツァオ氏は、この上昇はBloxrouteチームが取り組んでいるBloxroute MEVリレーの問題が原因だと述べた。開発者らはまた、イーサリアムの状態と歴史的成長に関してパラダイムチームが実施した新しい研究からの重要な点についても議論しました。開発者は、プラハ/エレクトラにおける 2 つの遡及的なイーサリアム改善提案 (EIP)、EIP 7610 および 7523 を含めることを承認しました。

最後に、EIP 7547 (包含リスト)、EIP 5920 (PAY オペコード)、EIP 7545 (Verkle Proof Verification Precompilation) など、他の候補 EIP に関する開発最新情報を共有しました。

メインネット欠落ブロック イベント

3 月 27 日、欠落ブロックの数が増加しました。通常、イーサリアムでは 30 分ごとに 2% ～ 4% のブロックが失われます。ただし、ネットワークで大量の BLOB トランザクションが発生する期間中は、この割合は数時間以内に 14% 以上に上昇します。この期間中、BLOB の価格は 10 倍以上に上昇しました。ツァオ氏は、Bloxroute チームが MEV リレーを停止すると、ブロック欠落の問題はすぐに解決されたと述べました。 Bloxroute リレーの問題の原因の詳細は不明ですが、Bloxroute チームは修正に取り組んでおり、数日以内に問題の完全な事後分析とともに修正を共有する予定です。

「つまり、昨日のブロックの欠落は、お客様がこの種のワークロードを処理できないと言っているわけではありません。基本的にブロックの欠落はすべて Bloxroute の問題によって引き起こされているからです。しかし、基本的な問題がまだ残っています。それは、昨日はどうなるのかということです。 「トラフィックの影響で、顧客がブロックをインポートするのが以前より遅くなっているのではないかと思いますが、それについては決定的な証拠がありません。まだわかりません」とツァオ氏は述べた。チームは、ノードのパフォーマンスと安定性を向上させるために「ホットフィックス」バージョンをリリースしました。さらに、調査は進行中であるが、ブロックルートのCEO、ウリ・クラルマン氏は次のように述べた。

イーサリアム財団の開発者オペレーションエンジニアであるパリトシュ・ジャヤンティ氏は、このインシデントにより、開発者はバリデーターノードを自動的にローカルブロックプロダクションにフォールバックさせるクライアントサーキットブレーカーの条件を再評価する必要があるかどうかを尋ねました。ほとんどのクライアントでは、サーキット ブレーカー条件のデフォルト値は、連続して 5 つのスロットが欠落するイベントです。 Tsao 氏は、サーキット ブレーカーの条件があまりにも簡単にトリガーされると、高度な MEV 攻撃者が悪用できる潜在的な攻撃ベクトルになると指摘しました。

Prysm 開発者の "Potuz" 氏は、この事件はリレーにおけるクライアントの多様性の実装の欠如と、リレーとプロトコルの開発者間のコミュニケーションの欠如を浮き彫りにしていると述べました。 「テレンスはこれらのブロブについて一週間以上話し続けましたが、誰も気づきませんでした。そして、一度爆発すると、適切な中継器に実際にログを確認させるには数回電話するだけで済みます。これは容認できません。」とポルトゥッツィ氏は説明します。 ##

一部の開発者は、イーサリアム エコシステムの可視性を高めるために、次回ネットワーク違反を報告するときに書面による投稿を作成することを提案しています。ブロック欠落事件についてさらに議論するために、イーサリアム財団の研究者アレックス・ストークス氏は開発者に対し、次回の MEV-Boost コミュニティコールに参加するよう勧めました。

ステータスと歴史的成長データの分析

Paradigm のデータ サイエンティスト エンジニアである Storm Slivkoff は、イーサリアムのステータスと歴史的成長の新しい分析を実施しました。彼の調査結果によると、状態の成長はイーサリアムのスケーラビリティにおける主なボトルネックではありません。 「私たちは、既存の消費者向けハードウェアが、長期間、おそらく数十年にわたり、現在の国家成長率を維持できることを発見しました。ここでは、ストレージ容量とメモリ容量についてのみ話していることに注意してください。これは、読み取りまたは書き込みが宣言されるべきであると言っているわけではありません」この枠組み。彼の見解では、イーサリアムの「サイレントキラー」は歴史的な成長です。

パラダイム研究チームは書面による分析で次のように説明しました:「状態とは、新しいイーサリアム ブロックを構築して検証するために必要なデータ セットです。状態は、コントラクト バイトコード、コントラクト ストレージ、アカウント残高、およびアカウントのノンス構成で構成されます。」履歴は、ノードを生成から最新のブロックに同期するために必要なデータのセットです。履歴はブロックとトランザクションで構成されています。状態と履歴は重複しないデータのセットです。歴史はイーサリアムよりも大幅に速く成長しているとスリブコフ氏は付け加えました。歴史的な成長率に影響を与えるユースケースは、イーサリアムにブリッジする必要があるロールアップやその他のタイプのプロトコルです。

Slivkoff 氏は、開発者に対し、次のイーサリアム アップグレードで歴史的な成長率の解決を加速することを真剣に検討することを推奨しました。同氏はまた、イーサリアム上の他のスケーリングボトルネックを分析するためにさらなる分析が行われ、これらの手法はチームの研究の次のステップとしてロールアップのスケーリングボトルネックの分析に適用される予定であると述べた。

Slivkoff 氏のプレゼンテーションに続き、開発者らは短期的に歴史的成長に対処するためのさまざまな方法について議論しました。ACDE #180 で議論されたように、開発者は強力な代替ネットワークを構築しています。マージ アップグレード前など、一定期間にわたる履歴データは、イーサリアム ノード経由でデータにアクセスできない場合でも、ユーザーは引き続きアクセスできます。履歴の有効期限とサービスについては、履歴データの代替手段についての詳細な議論については、Geth 開発者「Lightclient」を参照してください。 」は、開発者がイーサリアム研究開発 Discord チャネルの「履歴の有効期限」というタイトルのサブチャネル トピックで会話を続けることを推奨しています。

振り返り EIPIP7610 および 7523

開発者は、EIP 7610 および 7523 を実装することに同意します。これらは、イーサリアム プロトコルにルールを追加する遡及 EIP であり、ネットワークの最初から遡って適用して、チェーン上の特定の種類の動作をさらに制限できます。これらの EIP の利点は、イーサリアムのテスト ケースを簡素化し、空のアカウントを作成するというエッジ ケースなど、さまざまなエッジ ケースの範囲を制限することです。遡及適用された 2 つの EIP には、EIPIP2681 と 3607 が含まれます。開発者は、プラハ/エレクトラで 2 つの追加の遡及 EIP をアクティブ化することに同意しました。これらの EIP がどのようなアクションを制御するかについての背景情報については、ここで以前の通話記録を参照してください。

EIP 2537、BLS プリコンパイル済み

Geth 顧客チームは、EIP 2537 BLS 曲線操作のガスコストを見積もるためのいくつかのベンチマークを完了しました。これらの新しいビジネスは、Prague/Electra のアップグレードで有効化され、開発者は現在、これらのビジネスの価格を検討中です。レスチームの代表者は、彼のチームは、これらの運用のガスコストの決定を支援するために、BLS曲線運用の追加のベンチマークも完了すると述べた。

EIP 7547、包含リスト

ACDC #130 で説明したように、開発者は Prague/Electra アップグレードに EIP 7547 を含めることを強く検討しています。今週、イーサリアム財団の研究者マイク・ニューダー氏は、EIP 7547 を変更してアカウント抽象化と上位互換性を持たせる方法に関する最新情報を共有しました。アカウントの抽象化は、イーサリアム上のユーザーが管理するアカウントである外部アカウント (EOA) に、より優れた柔軟性とプログラム可能性を導入するための継続的な取り組みです。 Neuder は、EIP 7547 とアカウント抽象化 EIP の間の互換性の問題を解決する 3 つの異なる方法を提案しました。これらの解決策についてノイダー氏は、「確かにインクルーシブデザインは複雑だと感じるが、これら 3 つの選択肢は効果があると思うし、この問題を解決する特効薬はないと思う。私はそうは思わない」と語った。これらの問題に対処する、より良い設計を見つけてください。

Beiko は、期間限定で別の分科会セッションでリストの設計を組み込むことについて引き続き議論することを提案します。

プラハのその他の候補 EIP /Electra

次に、開発者は、プラハ/エレクトラ アップグレード用の他の候補 EIP のリストを検討しました。それらには、次のものが含まれます:

EIP 5920 (PAY オペコード): イーサリアム財団の研究者であるサム ウィルソン氏は、次のように指摘しました。この操作 コードのテストが開始されました。

EIP 7609 (TLOAD/TSTORE の基本コストの削減): Vyper コンパイラーの貢献者 Charles Cooper は、TLOAD および TSTORE オペコードは EVM でより安価に価格設定されるべきであるという自身の見解を繰り返し述べています。 ##

EIP 2935 および 7545 (履歴ブロック ハッシュの状態保存と Verkle 証明検証プリコンパイル): Geth 開発者 Guillaume Ballet は、これら 2 つの提案を、Verkle 実装に将来のメリットをもたらすコード変更として提起しました。より広範なイーサリアム エコシステムに今後の Verkle アップグレードを思い出させます。

イーサリアム オブジェクト フォーマット (EOF): Besu クライアント メンテナーの Danno Ferrin 氏は、EOF EIP は複数のクライアント チームによって実装されており、それらのチーム向けにリファレンス テストが作成されていると述べました。同氏は開発者に対し、より詳細なアップデートについてはEOF Readiness Matrixを参照するよう求めた。

EIP 7212 および EIP 3074 (secp256r1 曲線のサポートと AUTH/AUTHCALL オペコードのプリコンパイル): Besu 開発者の Matt Nelson は、L2 ロールアップに実装されているこれら 2 つの EIP を強調しています。同氏は、イーサリアムとロールアップ間の互換性を促進するために、これら 2 つの EIP がプラハで採用されるべきであると強調しました。

EIP 7664 (アクセス キー オペコード): OPLabs 開発者「Protolambda」は、アクセス リストを活用して AUTH/AUTHCALL オペコードの機能を強化する EIP 3074 の代替案を提案しました。

EIP 6493 (SSZ トランザクション署名スキーム): Protolambda は、イーサリアム データの検証のセキュリティと効率を向上させるための SSZ 関連のコード変更のサポートも表明しました。

開発者には、このリストのどの EIP をプラハで優先すべきかについて議論する時間がありませんでした。ベイコ氏は、2週間後の次回のACDE電話会議の開始時にリストを再度検討する時間が妨げられるだろうと述べた。 「今後数週間で、今日提起されたすべての問題をより深く検討し、決定を下すことに取り組む必要がある。それは、前進したい場合は、完全に解明されていない点や未解決の点が2週間以内に解決されることを意味すると思う」この分岐点には何も入ってはいけないと指定されています」とベイコさんは言いました。

以上がイーサリアムコア開発者の最新会議の概要: メインネットのステータスと成長データの分析、プラハのアップグレード提案の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。