TVL 前 10 的鏈中有 9 個支持 EVM 智能合約。
原文：How to Evaluate Forked EVMs for Security Risks（Coinbase）
作者： Ethen Pociask，Eric Meng，Nadir Akhtar，Gabriela Melendez Quan，Tom Ryan
編譯： Katie 辜，Odaily 星球日報譯者
為了加強對交易 ERC-20 和其他基於智能合約的資產的客戶的安全和託管保證，Coinbase 區塊鏈安全團隊調查了定義這些資產行為的程序層：以太坊虛擬機（EVM）。在評估修改自身網絡的 EVM 的項目時，Coinbase 的區塊鏈安全團隊會審查關鍵的 EVM 更改，以確定修改後的 EVM 是否能夠提供與原始 EVM 實施相同的安全和託管保證。
分叉 EVM 現狀
截至 2023 年 5 月，以太坊虛擬機（EVM）奪得最熱門智能合約執行平台 “榜一大哥” 頭銜。根據 DefiLlama 的數據，總鎖倉價值（TVL）排名前 10 位的鏈中有 9 個支持 EVM 智能合約。因此，深入了解 EVM 對於支持整個區塊鏈生態系統中的智能合約至關重要。
EVM 是一種虛擬機，用於在以太坊網絡上去中心化執行智能合約。許多兼容 EVM 的區塊鏈在其協議軟件中直接利用不同語言的熱門 Ethereum 執行客戶端的標準實施方案，如 go-ethereum（Golang）和 besu（Java）。
也就是說，分叉和修改 EVM 實際上在區塊鏈生態系統中非常常見，甚至在主要協議中也是如此。例如，為 Coinbase 的 Base L2 區塊鏈提供 “動力” 的 Optimism Bedrock Stack 使用了一個名為 op-geth 的 go-ethereum 執行客戶端的分叉版本，該版本運行的 EVM 與熱門的以太坊執行客戶端兼容。然而，這並不意味著以太坊上的 EVM 與 Optimism 上的 EVM 行為完全相同：op-geth EVM 在某些情況下的行為略有不同（即 DIFFICULTY 返回隨機值是由序列器確定的）。
雖然這聽起來很可怕，但對於 EVM 的採用來說，一般情況下是有益的。雖然標準 EVM 實施方案針對以太坊基礎協議進行了高度優化，但分叉的 EVM 通常會針對自己的新協議進行擴展。因此，合約在某些 EVM 兼容鏈上的執行方式可能與在以太坊上的執行方式不同，EVM 智能合約行為的安全假設在不同協議之間也可能存在很大差異。
分叉 EVM 安全框架
為此，Coinbase 開發了一個 Web3 安全框架，用於評估一些分叉 EVM 實施方案中的安全影響。我們稱之為 Coinbase 的分叉 EVM 框架，下面將對其進行詳細的解釋。
有了這個分叉 EVM 安全框架，Coinbase 能夠有效地：
- 了解我們的以太坊代幣框架的安全假設的無效性，使我們能夠安全地啟用新的 EVM 兼容區塊鏈，以便在我們的去中心化交易所支持 ERC-20/ERC-721 代幣；
- 為智能合約審計師提供關於分叉 EVM 的智能合約漏洞情況的分析，特別是跨網絡中的微小差異；
- 確保在 Coinbase 的 Base L2 區塊鏈上安全使用和執行 EVM 智能合約。
兼容 EVM 的區塊鏈的安全標準
為了解以太坊虛擬機中的安全風險是如何存在的，首先要知道標準 EVM 實施方案為我們提供了哪些保障。我們將標準 EVM 定義為以太坊執行規範中描述的以太坊驗證器執行客戶端一致使用的 EVM。到目前為止，最常用的客戶端是 go ethereum（即 geth）。
我們將安全性總結為兩個安全標準，它們代表了任何分叉 EVM 實施方案有資格獲得 Coinbase 支持的最低要求。
我們如何審計 EVM 實施方案的安全風險？
我們的分叉 EVM 框架在評估是否符合總體安全標準（即合約不變性和安全執行環境）時，主要關注以下審計要求。需要注意的是，以下風險成分並不是分叉 EVM 審計的全部範圍。
修改 EVM 操作碼的定義和編碼會導致合約執行方式的重大差異。例如，假設一些分叉的 EVM 實施（EVM'）將算術 ADD 操作碼定義邏輯（x 1 + x 2）改為減去兩個值（x 1 – x 2）。
結果，偏離的 EVM ' 在執行上與標準 EVM 不相等且不兼容。修改操作碼的後果可能是有益的行為，比如防止算術操作碼中的整數溢出和下溢，也可能是更危險的行為，比如導致本地資產無限鑄造的自毀行為。
EVM 使用預編譯合約來定義復雜的功能（如加密函數），使用更方便和性能更強的語言，如 Golang，而不是使用不太容易訪問的 EVM 字節碼。
從根本上說，這些是通過節點軟件中表示的預定鏈地址來訪問的編程功能。以太坊黃皮書（截至 2023 年 5 月）中定義了 9 個預編譯器，對這 9 個預編譯器所做的任何更改或引入新的預編譯器都需要進行審計。
讓我們再舉一個具體的例子——BNB 智能鏈漏洞。BNB 智能鏈使用 go-ethereum 的一個偏離的實施方案來運行節點。為此，引入了兩個新的預編譯合約（tmHeaderValidate，iavlMerkleProofValidate），利用第三方軟件（即 Cosmos SDK）來執行輕客戶端區塊驗證和 Merkle 證明驗證。問題是，Cosmos SDK 軟件在其 IAWL 樹表示法中有一個實施錯誤，允許加密無效的證明通過驗證。換句話說，任何人都可以憑空產生資金。攻擊者能夠利用嵌套在 iavlMerkleProofValidate 預編譯器中的這個實施漏洞，從幣安跨鏈橋中抽走數億美元。
這個利用漏洞的例子是為了展示預編譯器安全性的必要性，以及為偏離的 EVM 實施引入新的預編譯合約所帶來的潛在風險。
引入額外的預編譯器可能帶來的致命風險包括：
- 允許一方單方面修改任何已部署合約的狀態；
- 這包括所有存儲修改（插入、更新、刪除）；
- 使用不受信任、未經驗證或未經審計的第三方依賴項；
- 提供對不確定節點內值的訪問。
儘管將編譯器和 EVM 視為完全獨立的實體，但值得注意的是，Solidity 編譯器確實對前三個預編譯合約（ecrecover、sha 256 和&ripemd）的行為做出了嚴格的假設，這些合約通過 Solidity 語言中的本機語言關鍵字函數表示。在後台，Solidity 編譯器實際上將這些關鍵字處理成字節碼，字節碼執行合約間靜態調用操作。下圖進一步說明了這種合約間的溝通方式。
修改標準預編譯器會帶來的安全風險包括：
- 允許中心化的交易對手單方面修改任何已部署合約的狀態；
- 這包括所有存儲修改（插入、更新、刪除）；
- Solidity 編譯器預編譯位置假設不一致；
- 提供對不確定節點內值的訪問；
- 使用不受信任、未經驗證或未經審計的第三方依賴項。
修改 EVM 基本組成部分所帶來的關鍵風險包括：
- 不約束解釋器堆棧，使其無限大；
- 對內存模型進行大小修改或改變，可能導致非確定性的執行；
- 繞過訪問控制，允許任意的對手方單方面訪問所有鏈狀態；
- 使用不受信任、未經驗證或未經審計的第三方依賴關係。
為什麼要重視 EVM 安全性？
我們的目標是建立一個基於區塊鏈技術的開放金融系統，為此，我們鼓勵開發各種 EVM 實施方案。然而，為了讓兼容 EVM 的區塊鏈得到 Coinbase 的全面支持，它必須滿足標準 EVM 實施的基本要求。本文希望提高人們對偏離 EVM 相關風險的認識，並鼓勵資產發行人在偏離 EVM 時優先開發安全組件，提高整個 Web3 生態系統的安全意識。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
