如何評估「分叉版EVM」的安全風險？

TVL 前10 的鏈中有9 個支持EVM 智能合約。

原文標題：《How to uate Forked EVMs for Security Risks》

摘文：Ethan Pociask、Eric Meng、Nadir Akhtar、Gabriela Melendez Quan、Tom Ryan

編譯：Katie 辜

為了加強對交易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操作碼定義邏輯（x1 + x2）改為減去兩個值（x1 - x2）。

結果，偏離的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、sha256和&ripemd）的行為做出了嚴格的假設，這些合約通過Solidity語言中的本機語言關鍵字函數表示。在後台，Solidity編譯器實際上將這些關鍵字處理成字節碼，字節碼執行合約間靜態調用操作。下圖進一步說明了這種合約間的溝通方式。

修改標準預編譯器會帶來的安全風險包括：

• 允許中心化的交易對手單方面修改任何已部署合約的狀態；
• 這包括所有存儲修改（插入、更新、刪除）；
• Solidity編譯器預編譯位置假設不一致；
• 提供對不確定節點內值的訪問；
• 使用不受信任、未經驗證或未經審計的第三方依賴項。

修改EVM基本組成部分所帶來的關鍵風險包括：

• 不約束解釋器堆棧，使其無限大；
• 對內存模型進行大小修改或改變，可能導致非確定性的執行；
• 繞過訪問控制，允許任意的對手方單方面訪問所有鏈狀態；
• 使用不受信任、未經驗證或未經審計的第三方依賴關係。

為什麼要重視EVM安全性？

我們的目標是建立一個基於區塊鏈技術的開放金融系統，為此，我們鼓勵開發各種EVM實施方案。然而，為了讓兼容EVM的區塊鏈得到Coinbase的全面支持，它必須滿足標準EVM實施的基本要求。本文希望提高人們對偏離EVM相關風險的認識，並鼓勵資產發行人在偏離EVM時優先開發安全組件，提高整個Web3 生態系統的安全意識。