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

原文タイトル：《Ethereum All Core Developers Execution Call #184 Writeup》
原文著者：Christine Kim
編訳：Luccy，BlockBeats

編者按：

イーサリアムの全コア開発者コンセンサス電話（ACDE）は、2週間ごとに開催され、主にイーサリアム実行層（EL）への変更について議論し調整します。今回はACDE第184回電話会議で、3月27日にブロックの欠落数が増加した原因や、Paradigmチームによるイーサリアムの状態と歴史的成長に関する新しい研究に焦点を当てました。

開発者たちは会議でBloxroute MEVリレーの問題や、Prague/Electraにおける2つの遡及的EIPについての議論を共有しました。また、EIP 7547（包含リスト）、EIP 5920（PAYオペコード）、EIP 7545（Verkle証明検証の事前コンパイル）の開発更新についても議論されました。

Galaxy Digitalの研究副社長Christine Kimは、今回の会議の要点を詳細に記録し、BlockBeatsが原文を編纂しました：

2024年3月28日、イーサリアムの開発者たちはZoomに集まり、All Core Developers Execution (ACDE) call #184会議に参加しました。ACDE電話会議は、イーサリアム財団のプロトコルサポート責任者Tim Beikoが主催する、2週間ごとに開催されるシリーズ会議で、開発者たちはイーサリアム実行層（EL）への変更について議論し調整します。

今週、開発者たちは3月27日にブロックの欠落数が増加した原因についての見解を共有しました。Prysmの開発者Terence Tsaoは、この増加がBloxroute MEVリレーの問題によって引き起こされたと述べ、Bloxrouteチームがこの問題に取り組んでいることを明らかにしました。開発者たちはまた、Paradigmチームによるイーサリアムの状態と歴史的成長に関する新しい研究の要点について議論しました。開発者たちは、Prague/ElectraにEIP 7610と7523という2つの遡及的イーサリアム改善提案（EIP）を含めることを承認しました。

最後に、彼らはEIP 7547（包含リスト）、EIP 5920（PAYオペコード）、EIP 7545（Verkle証明検証の事前コンパイル）など、他の候補EIPの開発更新を共有しました。

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

3月27日、欠落したブロックの数が増加しました。通常、イーサリアムでは30分ごとに2%から4%のブロックが欠落します。しかし、ネットワークが大量のBlobトランザクションを処理している間、この割合は数時間で14%を超えました。この期間中、Blobの価格は10倍以上に上昇しました。Tsaoは、BloxrouteチームがMEVリレーを停止した瞬間に欠落ブロックの問題が即座に解決されたと述べました。Bloxrouteリレーの問題の詳細は不明ですが、Bloxrouteチームは修正プログラムを研究しており、数日以内にその修正プログラムと問題の完全な事後分析を共有する予定です。

「したがって、昨日欠落したブロックは、クライアントがこのタイプの作業負荷を処理できなかったわけではありません。基本的に、すべての欠落ブロックはBloxrouteの問題によって引き起こされたものです。しかし、昨日のトラフィックの下で何が起こるかという基本的な問題は依然として存在します。私は、クライアントがブロックを取り込む速度が以前よりも遅くなる可能性があると疑っていますが、これは私が確固たる証拠を持っていないことです。これは観察が必要です」とTsaoは述べました。欠落ブロックイベントに対処するために、Lighthouseクライアントチームはノードの性能と安定性を向上させるための「ホットフィックス」バージョンをリリースしました。また、調査はまだ進行中ですが、BloxrouteのCEO Uri KlarmanはXで、これらの問題はBloxrouteリレーとは無関係であり、イーサリアム上でのBlobの一般的な伝播方法に関連していると考えていると述べました。

イーサリアム財団の開発者運営エンジニアParithosh Jayanthiは、このイベントが開発者にクライアントのブレーカ条件を再評価させるかどうかを尋ねました。これらの条件は、自動的に検証者ノードがローカルブロック生成に戻ることを引き起こします。ほとんどのクライアントでは、ブレーカ条件のデフォルト値は連続して5つのスロットを欠落させるイベントです。Tsaoは、あまりにも簡単にトリガーされるブレーカ条件は、複雑なMEV行為者が利用できる潜在的な攻撃媒体であると指摘しました。

Prysmの開発者「Potuz」は、彼の見解では、このイベントはリレーにおけるクライアントの多様性の欠如と、リレーとプロトコル開発者間のコミュニケーションの欠如を浮き彫りにしていると述べました。「TerenceはこのBlobについて1週間以上話していましたが、誰もそれに気づいていませんでした。一旦それが爆発すると、正しいリレーが実際に彼らのログを確認するために数回電話をかけるだけで済みます。これは受け入れられません」とPotuzは述べました。

一部の開発者は、次回のネットワーク違反報告時に書面での投稿を作成し、イーサリアムエコシステムの認知度を高めることを提案しました。欠落ブロックイベントについてさらに議論するために、イーサリアム財団の研究者Alex Stokesは、開発者に次回のMEV-Boostコミュニティ電話会議に参加するよう促しました。

状態と歴史的成長データ分析

ParadigmのデータサイエンティストエンジニアStorm Slivkoffは、イーサリアムの状態と歴史的成長について新たな分析を行いました。彼の発見によれば、状態の成長はイーサリアムのスケーラビリティの主要なボトルネックではありません。「私たちは、既存の消費者向けハードウェアが現在の国家成長率を長期間維持できることを発見しました。おそらく数十年です。ここで私が話しているのはストレージ容量とメモリ容量だけです。これは、このフレームワーク内での読み取りまたは書き込みを主張するものではありません。」彼の見解では、イーサリアムの「静かな殺人者」は歴史的成長です。

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

Slivkoffは、開発者に次回のイーサリアムアップグレードPrague/Electraで歴史的成長を解決するEIPを加速することを真剣に考慮するよう提案しました。例えば、EIP 4444とEIP 7623です。彼はまた、イーサリアム上の他のスケーリングボトルネックを分析し、これらの方法をロールアップのスケーリングボトルネックの分析に適用するためのさらなる分析が行われると述べました。Slivkoffは、すべてのデータがオープンソースとして公開され、フィードバックを歓迎すると述べました。

Slivkoffの発表の後、開発者たちは短期的に歴史的成長を解決するさまざまな方法について議論しました。ACDE #180で議論されたように、開発者たちは強力な代替ネットワークを構築しており、一定期間の歴史データ（例えば、合併アップグレード前の歴史データ）を保持し、データがイーサリアムノードを介してアクセスできない場合でも、ユーザーがこれらのデータにアクセスできるようにしています。歴史の期限とサービス歴史データの代替オプションについてのさらなる議論では、Gethの開発者「Lightclient」が、開発者にイーサリアム研究Discordチャンネルで「歴史の期限」というタイトルのサブチャンネルテーマで対話を続けるよう提案しました。

遡及的EIP 7610と7523

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

EIP 2537、BLS事前コンパイル

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

EIP 7547、包含リスト

ACDC #130で議論されたように、開発者たちはEIP 7547をPrague/Electraアップグレードに含めることを強く検討しています。今週、イーサリアム財団の研究者Mike Neuderは、アカウント抽象化と前方互換性を持たせるためにEIP 7547をどのように修正するかについての最新情報を共有しました。アカウント抽象化は、ユーザーが制御するアカウントである外部アカウント（EOA）に対して、イーサリアム上でより大きな柔軟性とプログラマビリティを導入することを目的とした継続的な取り組みです。Neuderは、EIP 7547とアカウント抽象化EIPとの互換性の問題を解決するための3つの異なるアプローチを提案しました。これらの解決策について、Neuderは「これは確かに包摂的デザインの複雑性のように感じますが、私はこれらの3つの選択肢が実際に機能すると思いますし、この問題を解決するための魔法の解決策があるとは思いません。私たちはこの問題を解決するためのより良いデザインを見つけることはないと思います」と述べました。

Beikoは、限られた時間内で、別のグループ会議で包含リストデザインについての議論を続けることを提案しました。

Prague/Electraの他の候補EIP

次に、開発者たちはPrague/Electraアップグレードの他の候補EIPリストを確認しました。それらには以下が含まれます：

EIP 5920（PAYオペコード）：イーサリアム財団の研究者Sam Wilsonは、このオペコードのテスト作業が始まったことを指摘しました。

EIP 7609（TLOAD/TSTOREの基本コストを引き下げる）：Vyperコンパイラの貢献者Charles Cooperは、EVM内でTLOADとTSTOREオペコードの価格をより安くすべきだという彼の見解を再確認しました。

EIP 2935と7545（状態とVerkle証明検証の事前コンパイルで歴史的ブロックハッシュ値を保存）：Gethの開発者Guillaume Balletは、これら2つの提案をコード変更として提案し、Verkle実装に将来的な利益をもたらすと同時に、より広範なイーサリアムエコシステムに対して今後のVerkleアップグレードを思い出させるのに役立つと述べました。

イーサリアムオブジェクトフォーマット（EOF）：BesuクライアントのメンテナーDanno Ferrinは、EOF EIPが複数のクライアントチームによって実装されており、それらのために参照テストが作成されていると述べました。彼は、開発者にEOF準備マトリックスを参照して、より詳細な更新を得るよう求めました。

EIP 7212とEIP 3074（secp256r1曲線サポートとAUTH/AUTHCALLオペコードの事前コンパイル）：Besuの開発者Matt Nelsonは、L2ロールアップが実装しているこれら2つのEIPに焦点を当てました。彼は、イーサリアムとロールアップ間の互換性を促進するために、これら2つのEIPはPragueで採用されるべきだと強調しました。

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

EIP 6493（SSZトランザクション署名スキーム）：Protolambdaは、イーサリアムデータの検証の安全性と効率を向上させるためにSSZに関連するコード変更を支持すると述べました。

開発者たちは、このリストの中でどのEIPをPragueに優先的に適用すべきかを議論する時間がありませんでした。Beikoは、2週間後の次回ACDE電話会議の開始時に、時間が確保され、このリストを再確認すると述べました。「今後数週間で、今日提起されたすべての問題をより深く掘り下げ、決定を下すことに取り組むべきだと思います。これは、私たちが前進したいのであれば、2週間後にまだ完全に明確でないか指定されていないものは、このフォークに入らない可能性があることを意味します」とBeikoは述べました。