原題：「Ethereum All Core Developers Execution Call #187 Writeup」原著者：Christine Kim原コンパイラ：Luccy、BlockBeats

編集者注: All Core Ethereum Developers Consensus Call (ACDE) は、Ethereum Execution Layer (EL) への変更について話し合い、調整するために 2 週間ごとに開催されます。これは ACDE の 187 回目の電話会議で、開発者は Pectra Devnet 0 の準備、EIP 3074 の実装の更新、および実行層のシリアル化メソッドを MPT から SSZ に変換する緊急性について議論しました。 Pectra Devnet 0 の準備に加えて、開発者は新しい EIP 提案、既存の EIP の議論と分析、スマート コントラクトとトランザクションへの影響分析についても議論しました。その中で、EIP 7702 に関する議論は参加者から広く注目を集め、この提案は EIP 3074 に代わる潜在的なソリューションとみなされました。 Galaxy Digital のリサーチ担当副社長である Christine Kim は、この会議の要点を詳細に記録し、原文を次のようにまとめました。

2024 年 5 月 9 日、イーサリアム開発者は All Core Developers Execution (ACDE) コール #187 ミーティングに参加するために Zoom に集まりました。 ACDE 電話会議は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコが主催する隔週の一連の会議であり、開発者はイーサリアム実行層 (EL) への変更について話し合い、調整します。今週、開発者は、Pectra Devnet 0 の準備、EIP 3074 実装の更新、EL のシリアル化メソッドを MPT から SSZ に変換する緊急性について話し合いました。

Pectra Devnet-0 アップデート

イーサリアム財団の開発者運用エンジニアである Barnabas Busa 氏は、彼のチームが最初の Pectra 開発者中心のテスト ネットワークのクライアント構成をテストしており、5 月 13 日月曜日までに Pectra Devnet 0 の安定した構成を確保するために取り組むと述べました。 Pectra Devnet 0 準備状況トラッカーによると、Geth、Nethermind、および EthereumJS クライアント チームが Pectra コード仕様を完全に実装しました。

電話会議で、Besu 開発者の Justine Florentine 氏は、すべての Pectra EIP が Besu に実装されているが、彼のチームはまだコードのデバッグに懸命に取り組んでいると述べました。 Erigon の開発者 Andrew Ashkhmin 氏は、彼のチームが EL がトリガー可能な撤回である EIP 7002 を除くすべての EIP の開発に着手していると述べました。 Reth チームは Zoom チャットに実装トラッカーへのリンクを投稿し、Erigon チームと同様に EIP 7002 に関する作業がまだ保留中であることを示しました。

CL クライアント側では、Grandine 開発者の Saulius Grigaitis 氏は、すべての EIP が実装されているが、彼のチームは EL クライアントで実行中にいくつかのバグに遭遇したと述べました。 Lighthouse チームの代表者は、Pectra Devnet 0 の完全な実装の準備がほぼ完了していると述べ、エンジン API の仕様を更新する必要があると述べました。 Teku 開発者の Mikhail Kalinin 氏は、エンジン API 仕様にこれらの更新を追加することに取り組んでいると述べました。

EF テスト チームの Mario Vegas 氏は、開発者が EIP 3074、AUTH および AUTHCALL オペコード、およびその他のいくつかの EIP のテスト ケースの追加に取り組んでいると述べました。

EIP-3074 アップデート

開発者は EIP 3074 を Pectra Devnet 0 仕様に残すことに同意しましたが、これに代わる代替 EIP、EIP 7702 が議論されています。 Geth 開発者の「Lightclient」は、EIP 3074 に関する最新の分科会セッションを要約しました。参加者は、ユーザー コントロール アカウントのプログラマビリティの向上に関連して、Pectra アップグレードでどの変更を優先するかを議論しました。 Lightclient によると、完全なネイティブ アカウントの抽象化がイーサリアムに実装されるまでにはまだ数年かかることに参加者全員が同意しています。ただし、これが外部所有アカウント (EOA) 機能への変更を優先することを意味するのか、それとも EOA をスマート コントラクト ウォレットに移行することを意味するのかについては意見が分かれています。このACDE電話会議の前日、5月8日、イーサリアム共同創設者のヴィタリック・ブテリン氏は、イーサリアムが単一トランザクション中にスマートコントラクトウォレットのように動作するEOAをサポートする新しいトランザクションタイプをサポートできるようにする新しいEIP、EIP 7702を提案した。 Lightclient氏によると、EIP 3074の分科会セッションの参加者は概してEIP 7702について肯定的だったという。しかし、同氏は後に、EIP 7702に関して解決すべき重要な詳細がまだ残っていると付け加えた。たとえば、EIP 7702 トランザクションを取り消す方法や、そのようなトランザクションのガスコストを調整する方法の詳細は依然として不明です。

EIP 7702 が受け入れられ、Pectra アップグレードに含まれる場合、EIP 7702 は EIP 3074 と同様の結果を達成しますが、イーサリアム上で新しいオペコードを作成せず、静的分析の安定性が向上するため、EIP 3074 を置き換えることが検討されます。新しい EOA の動作について説明します。 EFの研究者アンスガー・ディートリヒス氏はZoomチャットで、EIP 7702をPectraに含めることを検討し、EIP 3074を7702に置き換えるかどうかの正式な決定は約2～4週間以内に行われると提案した。電話会議での EIP 7702 に関する開発者の議論から、この提案が実装の準備ができているとみなされる前にさらなる作業が必要であることは明らかでした。 Nethermind 開発者の Ahmad Mazen Bitar 氏は、EIP 3074 用にすでに行われた作業が 7702 の実装に再利用される可能性は低いと指摘しました。 Beiko 氏は、開発者は引き続き Devnet 0 向け EIP 3074 の実装を進め、後で Devnet-1 仕様を再検討する必要があることを確認しました。

EIP-7685、SSZ、および EIP-6110

次に、開発者らは、Nimbus 開発者 Etan Kissling が EIP 7685 に関して提起したいくつかの懸念事項、つまり一般的な実行層リクエストについて話し合いました。今週の電話会議の議題に基づく GitHub のコメントの中で、Kissling 氏は、Universal Execution Layer リクエスト用に提案されている設計が必要かどうか、またマージ アップグレード以来開発者が苦労してきた SSZ への切り替えにこの機会をうまく活用できないかと尋ねました。実行層で更新されることが予想されるシリアル化形式。会議に参加しているエグゼクティブ クライアント チームのほとんどは、EIP 7685 を Pectra に維持することをサポートしており、クライアントの楽観的な同期など、運用に EIP を含めることに障害がある場合は、設計を再検討してください。

SSZ への移行の話題に関して、Kissling 氏は、共通実行層リクエストの新しい設計形式は従来のシリアル化形式である MPT および RLP に基づいているため、開発者が SSZ に移行する際には更新する必要があると説明しました。同氏は、開発者が新しい MPT/RLP データ構造を作成し続ける場合、SSZ への移行を遅らせても開発者の作業が増えるだけであると指摘しました。ただし、SSZ 安定コンテナである EIP 7495 を Pectra に組み込むことに対するエグゼクティブ クライアント チームからの強力なサポートはありません。 「ダスティン」という名前の開発者は、Zoom チャットで、SSZ への移行を遅らせる決定は「狂気」であり、SSZ ライブラリが EL で適切に動作しないという問題は「深刻な問題」であると書いた。

EIP 6110、オンチェーンサプライバリデーターデポジットに関して、キスリング氏はデポジットの順序について疑問を提起しました。カリーニン氏は、この問題は「重大な懸念事項」であり、主要な利害関係者らと協力してさらに深く調査することに同意した。

EOF更新

EIP 6110、オンチェーンサプライバリデーターデポジットに関して、キスリング氏はデポジットの順序について疑問を提起しました。カリーニン氏は、この問題は「重大な懸念」であり、主要な利害関係者らと協力してさらに深く調査することに同意した。

EOF更新

独立系イーサリアム プロトコル開発者の Danno Ferrin 氏と EF Solidity の研究責任者 Alex Beregszaszi 氏が、EOF 実装の取り組みに関する最新情報を共有しました。文脈的に説明すると、EOF は、開発者が Pectra アップグレードに組み込むことを検討しているイーサリアム仮想マシン (EVM) を改善するための一連のコード変更です。 EOF のメタ EIP が完成しました。開発者はまた、EOF でのトランザクション作成プロセスを簡素化し、EOF のクライアント実装に取り​​組んでいます。

EIP-7623 アップデート

電話会議で「ウィリアム・モリス」というスクリーンネームで名乗った開発者は、EIP 7623の通話データストレージのガスコストの変化について懸念を表明した。同氏は、この変更により、一部のユーザーが取引を統合することでより低い料金で取引できるようになり、それによってガス割引の二次市場の創設が促進され、レイヤー2ロールアップ（L2）や他の参加者がより安価にネットワーク取引に移行できるようになると説明した。の上。同氏は、これらの問題に対処するために、固定料金で通話データのコストを追加する代替 EIP、EIP 7703 を推奨しました。

ブテリン氏は、モリスの懸念はもっともだが、そのような市場に参加することを選択するユーザーの数は非常に限られているため、EIP 7623の結果として通話データの流通市場が実際に創設される可能性は高くないと述べた。 Buterin 氏は、EIP 7623 の影響を受ける主なプレーヤーは、第 2 層の開発チーム Starkware と Inscription Creator であると指摘しました。同氏は、セカンダリコールデータ市場の対応可能な市場の合計は小さいものの、開発者がブロブガス制限を引き上げることができるため、コールデータを介して最大ブロックサイズの制限を増やすことの利点は非常に大きく、それによってイーサリアムのL2サポート能力が拡大すると付け加えた。 。 Vitalik氏はまた、Morris氏が示唆したように、通話データのコストが一律に増加すると、L2やその他の利害関係者に現在のEIPよりも厳しい影響を与えるだろうとも述べた。 Buterin 氏は、通話に先立ってブログ投稿で BLOB のガス価格に関するさらなる考えを共有しました。

EIP 7623 の共著者である Toni Wahrstätter 氏も Buterin 氏に同意し、実際的な観点から見ると、ほとんどの L2 は通話データの二次市場を生み出すことはないと考えていると述べました。 「実際的な観点から見ると、これはあまり実現可能ではありません。特に、このような市場では参加者間での信頼と高度な調整が必要であることを考えると、L2 としてデータを L1 に公開したいと考えているのに、それができないと想像してください。どのアドレスがデータを公開するのか、データが最終的にどこに送信されるのかはわかりません。実際的な観点からは、インデックスなどをカスタマイズする必要があります。」と Wahrstätter 氏は言います。

Reth 開発者の Georgios Konstantopoulos 氏は、EIP 7623 が Pectra に含まれている場合、開発者はブロブガスの制限を増やす可能性を検討しているかどうかを尋ねました。 EIP 7623に伴うブロブガス制限の増加がなければ、EIPは「問題の多くは解決しない」とコンスタントプロス氏は述べた。 EFの研究者Dankrad Feist氏は、イーサリアムの最大ブロックサイズが変わらない点までブロブガス制限を引き上げることを提案しました。これは、コールデータコストの増加によって解放されたスペースがブロブ（バイナリラージオブジェクト）で満たされることを意味します。 EF の研究者 Ansgar Dietrichs 氏は、この EIP は BLOB ガス制限の増加と組み合わせると役立つだけでなく、最大数のトランザクションと BLOB を含むブロックによってネットワークが影響を受けないようにすることができるため、セキュリティの観点からも有用であると述べています。そして不安定。

スマートコントラクトと取引に対するEIP 7623の影響を分析するという質問に関して、ヴァールシュテッター氏は、自身が提案した提案はユーザーの98％に影響を与えないと述べた。 Beiko 氏はまた、EF 開発者オペレーション エンジニアの Parithosh Jayanthi 氏が、EIP 7623 を考慮してブロブガス制限の引き上げの詳細についてより深い分析を行っている可能性があることにも言及しました。

EIP 7609 の新しい代替品

電話会議中、スクリーンネーム「Charles C」の開発者は、スマートコントラクトにおける再入攻撃を防ぐための新しい EIP を提案しました。 Charles 氏は、この提案はスマート コントラクトを保護するために 2 つの新しいオペコードを作成し、Pectra の TLOAD/TSTORE の基本コストを削減することを目的として以前に提出した EIP 7609 と呼ばれる提案に代わるものであると述べました。 Charles 氏は、EIP 7609 が Pectra に含めることが検討されなかった理由はわからないが、費用対効果の高い方法でのリエントランシーの防止について開発者からのフィードバックをまだ集めていると述べた。同氏は、OpenZeppelin の Reentrancy Guard や TLOAD/TSTORE オペコードなどの現在のソリューションは、分散アプリケーション開発者がデフォルトで使用するにはコストが高すぎると指摘しました。 Beiko 氏は、開発者が Ethereum Magicians フォーラムでこの新しい EIP について Charles 氏にフィードバックを提供することを推奨しました。