10月12日、イーサリアム開発者はZoom電話会議に集まりました。イーサリアム財団のプロトコルサポート責任者ティム・ベイコ氏が主催したこの会議では、開発者らがイーサリアム実行層（EL）への変更について話し合い、調整する場となった。最新の会議では、Dencun のテストと EVM オブジェクト フォーマットの開発が中心でした。
10 月 12 日、イーサリアム開発者は All Core Developers Execution (ACDE) Call #172 ミーティングのために Zoom に集まりました。 ACDE 電話会議は、イーサリアム財団のプロトコル サポート責任者であるティム ベイコが主催する隔週の一連の会議であり、開発者はイーサリアム実行層 (EL) への変更について話し合い、調整します。今週、開発者は次のトピックの進捗状況に焦点を当てています。
カンクン/デネブ (デンクン) テスト
Ethereum Virtual Machine (EVM) オブジェクト形式の開発。
デンクンテスト
イーサリアム財団の DevOps エンジニアである Barnabas Busa 氏は、9 月 29 日にリリースされた Devnet #9 に関する最新情報を最近共有しました。
Devnet #9 の参加率は現在 93% です。これは、バリデーターの 93% がネットワーク コンセンサスに積極的に参加していることを意味します。
実行されていないバリデーターの 7% は、主に Geth (EL)/Teku (CL) バリデーター ノードで構成されています。
Erigon (EL)/Prysm (CL) クライアントの組み合わせや EthereumJS (EL) クライアントにも問題があります。
Flashbots チームは、Devnet #9 で MEV-Boost リレーとビルダーをテストしています。ブサ氏は、Devnet #9 でより多くの MEV インフラストラクチャをテストできるように、他のリレー オペレーターやビルダー オペレーターに連絡するよう勧めています。
BLOB トランザクションは MEV-Boost ビルダーではテストされていません。この場合、BLOB はビルダーによって破棄されましたが、開発者には、これが BLOB が実際に無効であるためなのか、最低基本料金要件を満たしていないためなのか、それとも他の理由で破棄されたのかはまだわかりません。
Busa 氏とイーサリアム財団の同僚である Parithosh Jayanthi 氏は、次の Devnet #10 に関する最新情報を共有しました。
Devnet #10 は今週は準備が整っていませんが、来週には準備が整う予定です。
Devnet #10 では、開発者は EIP 4844 KZG セレモニーで信頼できる設定ファイルをテストすることを計画しています。
Devnet #10 には、330,000 人のアクティブなバリデーターを含む大規模なバリデーター ベースがあります。開発ネットワークが立ち上げられたばかりの時期は、バリデーターの入出金が大量に流入するため、ネットワーク立ち上げ後 1 ～ 2 日以内に、バリデーターの入出金制限が 5 回から 4 回に削減されることが予想されます。メインネットの実際の最大イングレス チャーン制限は 8 ですが、開発者は Devnet #10 で EIP 7514 をテストするために制限 4 を採用します。
ブサ氏は、開発者がデンクンのテストプロセス中にいくつかの重要な問題を解決中であることを強調した。開発チームは、これらの問題が適切に解決されるまで Devnet #10 を起動しない予定であり、これが Goerli などのパブリック Ethereum テストネットでアップグレードがアクティブ化される前の Dencun の最後の Devnet となる可能性があります。 Jayanthi 氏は、Zoom チャット ボックスで Devnet #10 を起動する前に開発者が対処する必要がある主要な問題について概説しました。
EIP 4844 KZG セレモニーの信頼できる設定ファイルを更新する
BLOB トランザクションの視覚化の向上
MEV パイプラインの改善
ネットワークの安定性の向上
EIP 4844 KZG セレモニーの信頼できる設定ファイルを更新する
BLOB トランザクションの視覚化の向上
MEV パイプラインの改善
ネットワークの安定性の向上
通話中、Jayanthi 氏は顧客チームに、BLOB トランザクションの可視性を高めるために Beacon API のサポートを追加するよう勧めました。 Beiko 氏は、開発者が Devnet #10 の立ち上げ後に Goerli テスト ネットワークをアップグレードする意思があるかどうかを尋ねました。 Busa 氏は、後続のアップグレード テスト手順を決定する前に、Devnet #10 のパフォーマンスを観察することをお勧めします。
さらに、Jayanthi氏は、Devnet #10の立ち上げ後の一定期間、開発者はDencunのアップグレードをさらにテストするための公開テストネットワークのテスト作業と同時に、イーサリアムメインネットのシャドウフォークを実施する可能性があることを認めた。ただし、Jayanthi 氏は、Dencun のテスト中に発見されたバグのほとんどがピアツーピア ネットワーク レベルであったため、シャドウ フォークの有用性は限定される可能性があると指摘しました。
Geth (EL) 開発者の Marius van der Wijden 氏は、同僚の Péter Szilágyi 氏が Devnet #9 で自身のノードを実行することに成功し、BLOB スパムに関連する深刻な問題を発見したと述べました。
ノードのクラッシュを防ぐために、Szilágyi 氏は開発ネットワーク上で確認された BLOB の数を制限するトランザクション ハンドラーを実装したと報告されています。 Van der Wijden 氏は、CL チームに対し、EIP 4844 の 3/6 最大 BLOB ターゲット/制限を再検討し、EL チームにノード帯域幅要件と BLOB スパムへの対処方法を深く検討させるよう推奨しました。
これらの問題についてさらに議論するために、Beiko は開発者に対し、10 月 16 日に開催される Dencun 相互運用性テストの電話会議に参加することを奨励しています。
EVMオブジェクトフォーマットの開発
次に、開発者は EVM オブジェクト フォーマット (EOF) の最新の開発について話し合いました。 EOF は、スマート コントラクト コードの実行に使用される Ethereum ベースの仮想マシンである EVM への変更に焦点を当てた EIP のセットです。 EOFの提唱者の1人であるDanno Ferrin氏は、過去数カ月にわたるEOFの取り組みを総括してまとめた。
プレゼンテーションの冒頭で、Ferrin 氏は、EOF がカンクン/デネブ (プラハ/エレクトラと呼ばれる) に続くアップグレードにおける大幅なコード変更になると予想していることを強調しました。 Ferrin 氏によると、現在 4 つの主要なチームが EOF に取り組んでいます。
Team Ipsilon: イーサリアム財団から資金提供を受け、EVM の改善に重点を置いた開発チーム
EL クライアント チーム: Geth、Besu、Nethermind など
高級言語コンパイラ チーム: Solidity や Vyper など
スマート コントラクト開発者: たとえば、SSTORE2 オペコードの支持者。
一般に、さまざまなチームが EOF の開発に貢献し、イーサリアム ネットワークの技術進歩を共同で推進しています。
EOF の主な目的は、EVM コード用の新しいコンテナ形式を作成することです。このコンテナ形式はコードとデータを明確に分離しますが、現在の形式では不可能です。また、新しいオペコードの導入が可能になり、スマート コントラクト開発者がアプリケーションをより効率的に設計できるようになり、コードのセキュリティが強化されます。 EOF では、既存の形式を維持しながら、EVM コード用の新しいコンテナ形式を作成する必要があります。
EVM に関するこれらの変更の実装とテストを容易にするために、Ferrin 氏は、開発者が新しい EOF EVM コードを使用するスマート コントラクトと、使用しない古いスマート コントラクト間の依存関係を減らす方法を詳しく説明しました。クライアント チームは EVM の 2 つのバージョンを維持する必要がありますが、Ferrin 氏は、新しいバージョンの方が現在の EVM よりも更新しやすいと考えています。同氏はまた、時間の経過とともに、EOFを採用するスマートコントラクト開発者が増えるにつれ、現在のEVMは徐々に時代遅れになる可能性があるとも述べた。
Ferrin 氏がスピーチで言及した EOF 関連の EIP には次のものがあります。
EIP 3540: EVM コードの新しいコンテナ形式。
EIP 4200: 静的ジャンプを導入する 3 つの新しい EVM ジャンプ命令。
EIP 4750: 2 つの新しいオペコードにより、動的ジャンプの必要性がなくなり、動的ジャンプが無効になります。
EIP 3540: EVM コードの新しいコンテナ形式。
EIP 4200: 静的ジャンプを導入する 3 つの新しい EVM ジャンプ命令。
EIP 4750: 2 つの新しいオペコードにより、動的ジャンプの必要性がなくなり、動的ジャンプが無効になります。
EIP 663: 2 つの新しい命令により、スタック深さ 256 (16 ではなく) へのアクセスが可能になります。
EIP 7480: EOF コンテナーのデータ部分の読み取りを可能にする 4 つの新しい命令。
EIP 7069: ガスの使用量とコスト関連のセマンティクスを簡素化するための 3 つの新しい呼び出し命令。
EIP 5450: 契約実行中の EOF 形式のスマート コントラクトの検証を導入します。
EIP 3670: コントラクト作成時に EOF 形式のスマート コントラクトの検証を導入します。
EOF オペコードへの変更の完全なリストを確認するには、Ferrin のプレゼンテーションの次の表を参照してください。
EOF オペコード変更の概要。出典: ダンノ・フェーリング
EOF テストの進捗状況に関して、Ferrin 氏は、EOF 仕様がまだ最終決定されていないため、クライアントがまだアップグレードを実装していない理由であると説明しました。ただし、EOF の焦点は EVM に対して実行される変更のみにあるため、EOF のテストは非常に「スタンドアロン」で比較的簡単になると同氏は予想しています。 「ネットワークの相互作用や、異なる CL/EL の組み合わせとのペアリングについて心配する必要はありません。テストできるので、同じレベルの開発ネットワークとテスト ネットワークは必要ないと思います」と同氏は語った。 Ferrin 氏は次のように付け加えました。「私たちは明確なリファレンス テストを作成します。また、私たちが持つ大きな利点の 1 つは、私たちが行っている差動 EVM テストです。」
講演の最後に、Ferrin 氏は、EOF を Prague/Electra アップグレードにおける主要なコード変更として見たいという希望を繰り返しました。同氏はまた、Dencun のアップグレード完了後 3 ～ 6 か月以内に、メインネット上で EOF に向けた一連のコード変更をテストして実行することが可能であるとも述べました。 EOF の最新の仕様は、ここで見つけることができます。これらの仕様に関する未解決の質問は、Ipsilon チームによってここにまとめられています。 EOF 仕様の一部はまだ改良する必要があります。通話に参加する開発者は、Ethereum Research and Development Discord の「#EVM」チャンネルで EOF の最新の開発と仕様についての意見を共有することが奨励されています。
EVM オブジェクト形式の議論
Ferrin 氏のプレゼンテーションは、開発者の間で広範な議論を引き起こしました。電話会議中、EOF に関する開発者の主な懸念は次のとおりでした。
タイムライン: Tim Beiko を含む数名の開発者は、Dencun アップグレード後の EOF 実装までの 3 ～ 6 か月というタイムラインに難色を示しました。
緊急性: 開発者は、別の大きなコード変更で Verkle を Bragg/Electra に組み込むことを検討しています。 8月初旬、イーサリアム財団の開発者Guillaume Ballet氏がVerkleの最新の進捗状況を共有した。今週の電話会議でバレエ氏は、VerkleはEOFよりもイーサリアムの緊急アップグレードであるため、優先されるべきであると強調した。 Ballet氏はまた、EOFの複雑さを軽減し、コード変更の数を減らすことができ、その実装がVerkle社のスケジュールに影響を与えないようにすることができるのであれば、アップグレードを支持すると述べた。
利点: Van der Wijden 氏と Nethermind (EL) 開発者の Lukasz Rozmej 氏などは、EOF の即時的な利点とアップグレードの複雑さの間のトレードオフに疑問を抱いています。 EVMに対するこのような大きな変更に対する強い需要がないことへの懸念について、フェリン氏は、EVMはイーサリアムの元の開発チームによって「週末にかけて」書かれたものであり、EVMを確実に維持するために多くの改善を行うことができると述べたレイヤー 1 ブロックチェーンの新しい代替Sui などの競合他社との競争力を強化します。 「これは安全上のリスクではありません」とフェリン氏は述べた。 「それはむしろ実存的な取引です。」
複雑さとリスクの増大: Van der Wijden 氏は、EOF がプロトコルの複雑さとリスクを増大させる可能性があることを強調しました。 EVM の両方のバージョンを保守し、将来のハード フォーク時にそれらの相互依存関係が確実に考慮されるようにするため、顧客チームの負担は増大します。 Wijden 氏は、レイヤー 2 チームは EVM と EOF の保守作業を並行してクライアント チームに「押し付け」るべきではなく、独自のプロトコルで EVM の改善を実装することに重点を置くべきだと考えています。
下位互換性: EOF のもう 1 つの大きな問題は、レガシー スマート コントラクトに下位互換性の問題が発生する可能性があることです。 EOF は、EOF コンテナーを使用しない従来のスマート コントラクトを継続的にサポートできるように設計されています。しかし、Ferrin 氏やイーサリアム財団の研究者 Ansgar Dietrichs 氏などの開発者は、時間の経過とともに古いスマート コントラクト機能が段階的に廃止され、EOF に特化してアップグレードされる可能性があると示唆しています。
EVM ガバナンス: Dietrichs 氏は、EVM ガバナンスに対する EOF の影響についても懸念を表明しました。イーサリアムは、レイヤー 2 と呼ばれる代替ネットワークでのスマート コントラクトの実行をサポートするために常に進化しています。将来、ほとんどのユーザーアクティビティとスマートコントラクトの実行がオフチェーンで行われ、イーサリアムが主にデータ可用性レイヤーとして使用されると仮定すると、EVM への変更はイーサリアムメインネットではなくレイヤー 2 プロトコルにとって最も重要になるはずです。 Dietrichs 氏は、拡大するレイヤー 2 エコシステムで EVM に変更を加える方法を開発者が慎重に検討し、話し合うことを推奨しています。
Ferrinらは、早ければ2021年にEOF研究に取り組み始めた。今年初め、EOF は多段階のロードマップを理由に上海ハードフォークによって拒否されました。 EOF 支持者は、EOF 関連のすべての変更を 1 回の大規模アップグレードで導入するアップグレードの更新設計を作成することで、この問題に対処しました。ただし、このアップグレードの複雑さは、今週の電話会議で提起された EOF に関する主な懸念事項の 1 つでした。 Van der Wijden氏は、今回開発者はEOFに関する決定を遅らせ続けるのではなく、EOFをイーサリアムに実装すべきかどうかを慎重に検討する必要があると強調した。
「Ipsilon チームと Danno がこの問題に多くの時間を費やしたことは知っていますが、これほど時間が経ってもおそらく提供できないだろうと言うのはかなり厳しいですが、『見てみましょう』と言うほうが悪いと思います」 「それから我々はそれが2年も遅れて、『ああ、結局出荷するつもりはない』と言いました。それで、Devconnectについて決定を下すべきだと思います」とファン・デル・ワイデン氏は述べ、さらに付け加えた。それが私たちがやりたいことであるなら、私たちはそれをやるつもりです。同様の技術的な課題がない限り、これは私たちがやりたくないことであると言うなら、私たちはそれをやるつもりです。これまでの大変な努力を考えると、そんなことは起こらないと思いますが、全員が明確な決断を下すのはチームにとって当然のことです。」
Rozmej 氏は、開発者は、EOF と Verkle に加えて、歴史的なチェーン データの増加という増大する問題に対処するために、おそらく EIP 4444 などのコード変更を再考する必要があると付け加えました。 Rozmej 氏によると、これまでのチェーン データの増加率は月あたり 20 GB です。 Beiko 氏は、開発者は Devconnect 上で EOF、Verkle、Prague/Electra について引き続き議論すべきであることに同意しました。 Beiko 氏はまた、10 月 18 日水曜日は、これらのチーム間のコラボレーションを促進するために、EVM のようなレイヤー 2 プロトコルの開催に専念することを強調しました。同日には EOF 実装者向けの電話会議も開催されます。最後に、Beiko 氏は、Devconnect で L2Beat が主催する専用の Layer2 Day イベントについて言及しました。
全てのコメント