jakiro
作者： Dragan Rakita， Paradigm 翻譯：善歐巴，比特鏈視界
EOF（EVM 對象格式）
EOF（EVM Object Format）是一組旨在改進EVM的小型EIP。它引入了一種新的字節碼格式，為EVM的未來做好準備。
EOF的優勢
EOF的價值難以解釋，因為它不是單一的東西，並且由於多次在分叉中被推遲以及多年的開發和研究、不同版本的演變，使得解釋變得更加複雜。
本文的目的是總結這些優勢並用一句話解釋它們：
優勢：
-
EOF允許操作碼的Gas定價變化
-
如果燃氣定價變化，傳統字節碼可能會表現不同。
-
移除燃氣可觀測性
-
這意味著移除GAS操作碼，以及CALL/DELEGATECALL/STATICCALL中的燃氣限制。
-
允許L2根據其用例改變燃氣
-
例如，zk L2中哈希操作的高成本。
-
EIP-7667：提高哈希函數的燃氣成本。
-
減少字節碼大小，降低燃氣使用
-
早期數據表明代碼/初始化代碼大小和燃氣使用量的減少：
-
Uniswap-v3部署減少6.5%的初始化代碼和部署代碼。
-
部署UniswapV3Factory使用約14%更少的燃氣，調用runTest使用約9%更少的燃氣。
-
ENS DNSRegistrar部署減少約6%的初始化代碼和約1.5%的部署代碼。
-
ENS調用proveAndClaim：使用約10%更少的燃氣。
-
允許字節碼轉換和可升級性
-
移除代碼可觀測性意味著移除PC, CREATE/CREATE2, EXTCODEHASH, EXTCODESIZE, EXTCODECOPY, CODESIZE和CODECOPY操作碼。
-
如果代碼更改，傳統合約將無法運行。
-
這將允許我們在未來引入verkle時對EOF字節碼進行任何形式的修改。
-
EOF啟用操作碼立即數
-
打開SWAPN, DUPN和EXCHANGE操作碼的可能性。
-
這為Solidity在棧大小上提供了更多自由，解決了Solidity中的棧深度過深問題。
-
移除昂貴的跳轉目標分析
-
在Reth中，分析結果與字節碼一起保存，但其他客戶端不一樣。移除在合約執行前的跳轉目標分析提高了速度。
-
隨著分析的移除，未來我們可以增加最大字節碼大小。
-
靜態分析變得更容易
-
子程序強制更結構化的控制流，這使模糊測試更有效，並且可以實現線性時間的靜態分析。
-
數據和代碼分離，更容易推理。
-
EOF字節碼可以編譯成更快的字節碼
-
EOF字節碼可以編譯成機器碼。
-
未來證明EVM
-
字節碼的版本和結構允許其可擴展性。這對L2和標準化尤其有用。
-
一個例子是EIP-7701：帶有EOF的本地帳戶抽象，增加了新的頭部部分。
-
地址空間擴展
-
新的EXT*CALL操作碼通過要求地址欄位填充零，為未來的地址擴展做好了準備。當以太坊決定擴展地址空間時，EOF已經為這些變化做好了準備。
與當前EVM的集成
對於開發人員來說，一個重要的問題是實施變化所需的努力、測試成本和維護這些操作碼的成本。
新的操作碼不會與傳統操作碼衝突，EOF的驗證不會觸及已棄用的操作碼。
EOF的編碼和解碼可以進行模糊測試。驗證是一個新事物，在Revm中大約有500行代碼，但有很多邊緣情況需要覆蓋，並需要集中精力在各個實現中做到正確。
創建交易用作EOF字節碼的載體，類似於EOFCREATE但在執行前需要驗證。
大多數操作碼非常簡單：
-
EXTCALL (0xf8), EXTDELEGATECALL (0xf9), EXTSTATICCALL (0xfb)
-
具有與已棄用的CALL相同的藍圖，但移除了gas_limit和內存輸出欄位。
-
在RETURNDATALOAD引入之前（在一個很早的分叉中），CALL操作碼的內存輸出必須在執行CALL操作碼之前設置。這不允許動態輸出。
-
EOFCREATE和RETURNCONTRACT
-
是EOF的新內容，需要特殊處理。
-
EXCHANGE (0xe8), SWAPN (0xe7), DUPN (0xe6), DATACOPY (0xd3), DATASIZE (0xd2), DATALOADN (0xd1), DATALOAD (0xd0), RJUMP (0xe0), RJUMPI (0xe1), RJUMPV (0xe2), RETURNDATALOAD
-
邏輯簡單，大多數只需10-20行代碼實現。沒有很多需要覆蓋的邊緣情況。
-
CALLF (0xe3), RETF (0xe4), 和 JUMPF (0xe5)
-
需要子程序棧和棧驗證，複雜度大約需要20-30行代碼。
-
需要一個開發人員約2-3個月的時間。測試工作已經開始。目前大約有2000個手寫的驗證測試，狀態測試工作也在進行中。
變化集中在EVM中，因此與客戶端其餘部分的集成取決於客戶端的架構以及保存字節碼的位置。
EXTCODESIZE和EXTCODEHASH需要知道帳戶是否為EOF，並返回預定義的值（0xEF00的大小和哈希），這可能會略微改變客戶端的集成方式。一個想法是將is_eof標誌保存在普通帳戶表中，以在調用任何EXTCODE類型的操作碼時跳過字節碼的加載。
對L2的影響
最大的問題是為什麼L2不實施這些變化？我們是否應該在以太坊L1上停止EVM改進？
現實情況是，L2還沒有準備好，不僅如此，它們也沒有一個平臺來幫助整合這些創新。字節碼版本控制有助於構建L2可以使用的平臺，代碼可觀測性的移除有助於緩解可升級性問題，燃氣變化幫助ZK L2消除燃氣炸彈的DDoS向量（例如，zk中的哈希值非常昂貴）。
更重要的是，EOF不僅僅是一種格式，它還需要語言（Solidity/Vyper/Huff）的支持，並需要工具鏈的支持才能使用。它需要一個生態系統來使用它，這種格式為L2提供了更多的穩定性，以便在其上進行創新。
缺點：傳統字節碼仍然存在
這是一個常見問題。傳統字節碼將永遠存在，如果我們不提供替代方案，我們將陷入困境。有了替代格式的字節碼，未來我們可以在狀態過期發生時過渡並移除傳統字節碼。
總結
EOF不是下一個耀眼的東西，它是修復初始EVM版本遺留問題的維護EIP，除了破壞它，沒有其他方法可以解決這些問題。它對於EVM的進一步發展和未來證明是必要的。
