本文來自 Coinbase，原文作者：Ethen Pociask&Eric Meng&Nadir Akhtar&Gabriela Melendez Quan&Tom Ryan，由 Odaily 星球日報譯者 Katie 辜編譯。
為了加強對交易ERC-20和其他基于智能合約的資產(chǎn)的客戶的安全和托管保證，Coinbase區(qū)塊鏈安全團隊調(diào)查了定義這些資產(chǎn)行為的程序?qū)樱?a href=http://www.weishizb.com.cn/szb/eth/ target=_blank class=infotextkey>以太坊虛擬機（EVM）。在評估修改自身網(wǎng)絡(luò)的EVM的項目時，Coinbase的區(qū)塊鏈安全團隊會審查關(guān)鍵的EVM更改，以確定修改后的EVM是否能夠提供與原始EVM實施相同的安全和托管保證。
分叉EVM現(xiàn)狀
截至2023年5月，以太坊虛擬機（EVM）奪得最熱門智能合約執(zhí)行平臺“榜一大哥”頭銜。根據(jù)DefiLlama的數(shù)據(jù)，總鎖倉價值（TVL）排名前10位的鏈中有9個支持EVM智能合約。因此，深入了解EVM對于支持整個區(qū)塊鏈生態(tài)系統(tǒng)中的智能合約至關(guān)重要。
EVM是一種虛擬機，用于在以太坊網(wǎng)絡(luò)上去中心化執(zhí)行智能合約。許多兼容EVM的區(qū)塊鏈在其協(xié)議軟件中直接利用不同語言的熱門Ethereum執(zhí)行客戶端的標準實施方案，如go-ethereum（Golang）和besu（Java）。
也就是說，分叉和修改EVM實際上在區(qū)塊鏈生態(tài)系統(tǒng)中非常常見，甚至在主要協(xié)議中也是如此。例如，為Coinbase的Base L2 區(qū)塊鏈提供“動力”的Optimism Bedrock Stack使用了一個名為op-geth的go-ethereum執(zhí)行客戶端的分叉版本，該版本運行的EVM與熱門的以太坊執(zhí)行客戶端兼容。然而，這并不意味著以太坊上的EVM與Optimism上的EVM行為完全相同：op-geth EVM在某些情況下的行為略有不同（即DIFFICULTY返回隨機值是由序列器確定的）。
雖然這聽起來很可怕，但對于EVM的采用來說，一般情況下是有益的。雖然標準EVM實施方案針對以太坊基礎(chǔ)協(xié)議進行了高度優(yōu)化，但分叉的EVM通常會針對自己的新協(xié)議進行擴展。因此，合約在某些EVM兼容鏈上的執(zhí)行方式可能與在以太坊上的執(zhí)行方式不同，EVM智能合約行為的安全假設(shè)在不同協(xié)議之間也可能存在很大差異。
分叉EVM安全框架
為此，Coinbase開發(fā)了一個Web3安全框架，用于評估一些分叉EVM實施方案中的安全影響。我們稱之為Coinbase的分叉EVM框架，下面將對其進行詳細的解釋。
有了這個分叉EVM安全框架，Coinbase能夠有效地：
-
了解我們的以太坊代幣框架的安全假設(shè)的無效性，使我們能夠安全地啟用新的EVM兼容區(qū)塊鏈，以便在我們的去中心化交易所支持ERC-20/ERC-721代幣；
-
為智能合約審計師提供關(guān)于分叉EVM的智能合約漏洞情況的分析，特別是跨網(wǎng)絡(luò)中的微小差異；
-
確保在Coinbase的Base L2區(qū)塊鏈上安全使用和執(zhí)行EVM智能合約。
兼容EVM的區(qū)塊鏈的安全標準
為了解以太坊虛擬機中的安全風險是如何存在的，首先要知道標準EVM實施方案為我們提供了哪些保障。我們將標準EVM定義為以太坊執(zhí)行規(guī)范中描述的以太坊驗證器執(zhí)行客戶端一致使用的EVM。到目前為止，最常用的客戶端是go ethereum（即geth）。
我們將安全性總結(jié)為兩個安全標準，它們代表了任何分叉EVM實施方案有資格獲得Coinbase支持的最低要求。
我們?nèi)绾螌徲婨VM實施方案的安全風險？
我們的分叉EVM框架在評估是否符合總體安全標準（即合約不變性和安全執(zhí)行環(huán)境）時，主要關(guān)注以下審計要求。需要注意的是，以下風險成分并不是分叉EVM審計的全部范圍。
修改EVM操作碼的定義和編碼會導(dǎo)致合約執(zhí)行方式的重大差異。例如，假設(shè)一些分叉的EVM實施（EVM'）將算術(shù)ADD操作碼定義邏輯（x1 x2）改為減去兩個值（x1 – x2）。
結(jié)果，偏離的EVM '在執(zhí)行上與標準EVM不相等且不兼容。修改操作碼的后果可能是有益的行為，比如防止算術(shù)操作碼中的整數(shù)溢出和下溢，也可能是更危險的行為，比如導(dǎo)致本地資產(chǎn)無限鑄造的自毀行為。
EVM使用預(yù)編譯合約來定義復(fù)雜的功能（如加密函數(shù)），使用更方便和性能更強的語言，如Golang，而不是使用不太容易訪問的EVM字節(jié)碼。
從根本上說，這些是通過節(jié)點軟件中表示的預(yù)定鏈地址來訪問的編程功能。以太坊黃皮書（截至2023年5月）中定義了9個預(yù)編譯器，對這9個預(yù)編譯器所做的任何更改或引入新的預(yù)編譯器都需要進行審計。
讓我們再舉一個具體的例子——BNB智能鏈漏洞。BNB智能鏈使用go-ethereum的一個偏離的實施方案來運行節(jié)點。為此，引入了兩個新的預(yù)編譯合約（tmHeaderValidate，iavlMerkleProofValidate），利用第三方軟件（即Cosmos SDK）來執(zhí)行輕客戶端區(qū)塊驗證和Merkle證明驗證。問題是，Cosmos SDK軟件在其IAWL樹表示法中有一個實施錯誤，允許加密無效的證明通過驗證。換句話說，任何人都可以憑空產(chǎn)生資金。攻擊者能夠利用嵌套在iavlMerkleProofValidate預(yù)編譯器中的這個實施漏洞，從幣安跨鏈橋中抽走數(shù)億美元。
這個利用漏洞的例子是為了展示預(yù)編譯器安全性的必要性，以及為偏離的EVM實施引入新的預(yù)編譯合約所帶來的潛在風險。
引入額外的預(yù)編譯器可能帶來的致命風險包括：
-
允許一方單方面修改任何已部署合約的狀態(tài)；
-
這包括所有存儲修改（插入、更新、刪除）；
-
使用不受信任、未經(jīng)驗證或未經(jīng)審計的第三方依賴項；
-
提供對不確定節(jié)點內(nèi)值的訪問。
盡管將編譯器和EVM視為完全獨立的實體，但值得注意的是，Solidity編譯器確實對前三個預(yù)編譯合約（ecrecover、sha256和&ripemd）的行為做出了嚴格的假設(shè)，這些合約通過Solidity語言中的本機語言關(guān)鍵字函數(shù)表示。在后臺，Solidity編譯器實際上將這些關(guān)鍵字處理成字節(jié)碼，字節(jié)碼執(zhí)行合約間靜態(tài)調(diào)用操作。下圖進一步說明了這種合約間的溝通方式。
修改標準預(yù)編譯器會帶來的安全風險包括：
-
允許中心化的交易對手單方面修改任何已部署合約的狀態(tài)；
-
這包括所有存儲修改（插入、更新、刪除）；
-
Solidity編譯器預(yù)編譯位置假設(shè)不一致；
-
提供對不確定節(jié)點內(nèi)值的訪問；
-
使用不受信任、未經(jīng)驗證或未經(jīng)審計的第三方依賴項。
修改EVM基本組成部分所帶來的關(guān)鍵風險包括：
-
不約束解釋器堆棧，使其無限大；
-
對內(nèi)存模型進行大小修改或改變，可能導(dǎo)致非確定性的執(zhí)行；
-
繞過訪問控制，允許任意的對手方單方面訪問所有鏈狀態(tài)；
-
使用不受信任、未經(jīng)驗證或未經(jīng)審計的第三方依賴關(guān)系。
為什么要重視EVM安全性？
我們的目標是建立一個基于區(qū)塊鏈技術(shù)的開放金融系統(tǒng)，為此，我們鼓勵開發(fā)各種EVM實施方案。然而，為了讓兼容EVM的區(qū)塊鏈得到Coinbase的全面支持，它必須滿足標準EVM實施的基本要求。本文希望提高人們對偏離EVM相關(guān)風險的認識，并鼓勵資產(chǎn)發(fā)行人在偏離EVM時優(yōu)先開發(fā)安全組件，提高整個 Web3 生態(tài)系統(tǒng)的安全意識。
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
