原題: "Ethereum All Core Developers Execution Call #184 Writeup" 原著者: Christine Kim 原編集: Luccy、BlockBeats 編集者注: Ethereum All Core Developers Consensus Call (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 電話会議は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコが主催する隔週の一連の会議であり、開発者はイーサリアム実行層 (EL) への変更について話し合い、調整します。

今週、開発者たちは、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 の問題によって引き起こされているからです。しかし、昨日のトラフィックで何が起こったのかという根本的な疑問がまだ残っているのではないかと思います」 「顧客がブロックをインポートするのが以前より遅くなっている可能性があるが、それについては決定的な証拠がないので、まだ分からない」とツァオ氏は語った。ブロック欠落事件に対応して、Lighthouse クライアントチームは「ホットフィックス」をリリースした。ノードのパフォーマンスと安定性を向上させるバージョン。さらに、調査はまだ進行中であるが、ブロックルートのCEO、ウリ・クラルマン氏は次のように述べた。

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

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

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

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

ステータスおよび過去の成長データの分析

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

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

Slivkoff 氏は、開発者に対し、次の Ethereum アップグレードである Prague/Electra で、EIP 4444 や EIP 7623 など、歴史的に増加している EIP の解決を加速することを真剣に検討することを推奨しました。同氏はまた、イーサリアム上の他のスケーリングボトルネックを分析するためにさらなる分析が行われ、チームの研究の次のステップとして、これらの手法がロールアップのスケーリングボトルネックの分析に適用される予定であると述べた。すべてのデータはオープンソースで公開され、フィードバックを歓迎するとスリヴコフ氏は述べた。

Slivkoff のプレゼンテーションに続いて、開発者は歴史的な成長に短期的に対処するためのさまざまな方法について議論しました。 ACDE #180で説明したように、開発者は、マージ アップグレード前などの一定期間にわたる履歴データに、イーサリアム ノード経由でデータにアクセスできない場合でもユーザーがアクセスできる強力な代替ネットワークを構築しています。履歴の有効期限と履歴データを提供するための代替オプションに関するさらなる議論のために、Geth 開発者の「Lightclient」は、開発者がイーサリアム R&D 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 候補者

次に、開発者は、Prague/Electra アップグレード用の他の候補 EIP のリストを参照しました。それらには次のものが含まれます。

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

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

EIP 2935 および 7545 (履歴ブロック ハッシュを状態に保持し、Verkle 証明検証プリコンパイルを行う): Geth 開発者 Guillaume Ballet は、Verkle 実装に将来のメリットをもたらすコード変更としてこれら 2 つの提案を提案しました。今後の 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週間以内に解決されることを意味すると思う」この分岐点には何も入ってはいけないと指定されています」とベイコさんは言った。