EVMオブジェクトフォーマット（EFO）総合アップグレード分析

EOFの利点

EOFの価値を説明するのは難しいのですが、それはEOFが一枚岩ではないからです。より複雑になっている。

この記事の目的は、これらの利点を要約し、一文で説明することです:

利点:

1. 利点:

   1. EOFはオプコードのガス料金の変更を可能にします

   • ガス料金が変更された場合、従来のバイテックはガス料金を変更することができません。ガス価格が変更された場合、従来のバイトコードは異なる動作をするかもしれません。

   2. ガス観測可能性の削除

   • これは、ガス価格が変更された場合、従来のバイトコードは異なる動作をするかもしれません。align: left;">これは、CALL/DELEGATECALL/STATICCALLのガス制限と同様に、GASオペコードを削除することを意味します。

   3. L2がユースケースに基づいてガスを変更できるようにする

   • 例えば、zk L2ではハッシュ演算のコストが高い。

   • EIP-7667：ハッシュ関数のガスコストを増加させる。

   4. バイトコードのサイズを小さくすることで、ガス使用量を減らす

   • 初期のデータでは、コード/初期化コードのサイズとガス使用量が削減されています。

   • Uniwap-v3のデプロイメントでは、初期化コードとデプロイメントコードが6.5%削減されます。

   • UniswapV3Factoryのデプロイは約14%少ないガスを使用し、runTestの呼び出しは約9%少ないガスを使用します。

   • ENS DNSRegistrarのデプロイメントでは、初期化コードを～6%、デプロイメントコードを～1.5%削減します。

   • ENSのproveAndClaim:呼び出しは、ガスの使用を～10%削減します。

   5. バイトコード変換とスケーラビリティを可能にする

   • コード観測性を削除するということは、PC、CREATE/CREATE2、EXTCODEHASH、EXTCODESIZE、EXTCODECOPY、CODESIZE、CODECOPYオペコードを削除するということです。

   • コードが変更されると、レガシー契約は機能しなくなります。

   • これにより、将来verkleを導入する際に、EOFバイトコードに何らかの変更を加えることができるようになります。

   6. EOF有効化オペコード即時

   • EOFバイトコードを開く。align: left;">SWAPN、DUPN、EXCHANGEオペコードの可能性を開きます。

   • これにより、Solidity のスタック サイズに自由度が増し、Solidity の深すぎるスタック深度の問題が解決されます。

   7. 高価なジャンプターゲット解析の削除

   • Solidityのスタックサイズに自由度を与え、Solidityのスタック深度が深すぎるという問題を解決します。align: left;">Rethでは、解析はバイトコードと一緒に保存されますが、他のクライアントでは保存されません。コントラクトの実行前にジャンプターゲットの解析を削除することで、速度が向上します。

   • 解析の削除により、将来的にはバイトコードの最大サイズを増やすことができます。

   8. 静的解析がより簡単に

   • 静的解析がより簡単になりました。align: left;">サブルーチンにより、より構造化された制御フローが強制されるため、ファジーテストがより効率的になり、線形時間での静的解析が可能になります。

   • データとコードを分離することで、推論が容易になります。

   9. EOFバイトコードはより高速なバイトコードにコンパイルできる

   • EOF バイトコードはより高速なバイトコードにコンパイルできる。"text-align: left;">EOFバイトコードはマシンコードにコンパイルできます。

   10. EVMの将来性

   • EOFバイトコードはマシンコードにコンパイルできます。align: left;">バイトコードのバージョニングと構造は、その拡張性を可能にします。これは特にL2や標準化に役立ちます。

   • 例として、EIP-7701: Local Account Abstraction with EOFがあり、新しいヘッダーセクションが追加されています。

   11. アドレス空間の拡張

   • 新しいEXOFは、EOFによるローカルアカウントの抽象化です。: left;">新しいEXT*CALLオペコードは、アドレス・フィールドがゼロ入力であることを要求することで、将来のアドレス拡張に備えます。イーサネットがアドレス空間の拡張を決定したとき、EOFはすでにこれらの変更に備えていました。

   現在の EVM との統合

   開発者にとって重要な問題は、変更を実装するのに必要な労力、テストのコスト、およびこれらのオペコードを維持するコストです。.

   新しいオペコードはレガシーオペコードと衝突しませんし、EOF検証は非推奨のオペコードには触れません。

   EOFのエンコードとデコードはファジーテストが可能です。検証は新しく、Revmには約500行のコードがありますが、カバーすべきエッジケースがたくさんあり、実装全体にわたって正しくすることに集中する必要があります。

   EOFバイトコードのキャリアとして使用されるトランザクションの作成は、EOFCREATEに似ていますが、実行前にバリデーションが必要です。EXTDELEGATECALL (0xf9), EXTSTATICCALL (0xfb)

• 非推奨のCALLと同じ設計図を持ちますが、gas_limitとメモリ出力フィールドが削除されています。

• （非常に初期のフォークで）RETURNDATALOADが導入される前は、CALLオペコードのメモリ出力は、CALLオペコードを実行する前に設定されなければなりませんでした。これは、動的な出力を許可しませんでした。

2. EOFCREATEとRETURNCONTRACT

• EOFは新しいもので、特別な処理が必要です。

3. EXCHANGE（0xe8）、SWAPN（0xe7）、DUPN（0xe6）、DATACOPY（0xd3）、DATASIZE（0xd2）、DATALOADN(0xd1), DATALOAD (0xd0), RJUMP (0xe0), RJUMPI (0xe1), RJUMPV (0xe2), RETURNDATALOAD

• ロジックはシンプルで、そのほとんどは10～20行のコードで実装できます。カバーする必要のあるエッジケースは多くありません。

4. CALLF(0xe3)、RETF(0xe4)、JUMPF(0xe5)

• サブルーチン・スタックとスタック検証が必要で、コードの複雑さは約20～30行です。

• 開発者には約2～3ヶ月かかります。テストはすでに始まっています。現在、約2000の手書きの検証テストがあり、州のテスト作業が進行中です。

変更はEVMが中心なので、クライアントの残りの部分との統合は、クライアントのアーキテクチャとバイトコードが保存される場所に依存します。

EXTCODESIZEとEXTCODEHASHは、アカウントがEOFかどうかを知る必要があり、定義済みの値（0xEF00サイズとハッシュ）を返します。1つのアイデアは、任意のEXTCODEタイプのオペコードを呼び出すときにバイトコードのロードをスキップするために、一般的なアカウントテーブルにis_eofフラグを保存することです。

L2 への影響

大きな疑問は、なぜ L2 はこれらの変更を実装しないのでしょうか?イーサネットL1でのEVMの改善を止めるべきでしょうか？

現実には、L2は準備ができておらず、それだけでなく、これらの技術革新を統合するためのプラットフォームを持っていません。バイトコードのバージョン管理はL2が使用できるプラットフォームの構築に役立ち、コードの観測可能性の除去はスケーラビリティの問題を軽減するのに役立ち、ガスの変更はZK L2がガス爆弾のDDoSベクトルを排除するのに役立ちます（たとえば、zkのハッシュは非常に高価です）。

さらに重要なことは、EOFは単なるフォーマットではなく、それを使用するためには言語（Solidity/Vyper/Huff）のサポートとツールチェーンのサポートが必要だということです。それを使用するにはエコシステムが必要であり、このフォーマットはL2が革新するためのより多くの安定性を提供します。

デメリット：レガシーバイトコードがまだ存在する

これはよくある問題です。レガシー バイトコードは常に存在し、代替手段を提供しなければ、困ったことになります。バイトコードの代替フォーマットがあれば、将来、状態の有効期限が切れたときに、レガシーバイトコードを移行して削除することができます。

まとめ

EOFは次の光るものではありません。EVMの初期バージョンのレガシーな問題を修正するメンテナンスEIPであり、その問題を修正するには、それを壊す以外に方法はありません。EVMのさらなる発展と将来性のために必要なものだ。