近期 Curve Finance 遭遇 Vyper 編譯器漏洞事件，造成 DeFi 行業陷入一片混亂，另一方面也讓駭客有了新的攻擊切入點。（前情提要：突發！Curve穩定池遭「駭客攻擊」損失2676萬鎂、CRV重挫20% ）（背景補充：Curve遭駭逃難潮，讓搶跑機器人賺到1,227ETH，創史上最大MEV獎勵區塊 ）

隨著一場漏洞利用事件的發生，DeFi 行業陷入了一場混亂。Curve Finance，這個 DeFi 行業的巨頭，成為了嚴重「攻擊」的目標，諸如 alETH/msETH/pETH 的多個穩定幣池岌岌可危。據不完全統計，該漏洞利用事件已造成 Alchemix、JPEG’d、MetronomeDAO、deBridge、Ellipsis 和 CRV/ETH 池累計損失 5200 萬美元，整個市場的信心被嚴重撼動。

延伸閱讀：Curve遭駭持續更新》損失金額已破7千萬鎂，Alchemix、MetronomeDAO、JPEGd 回應…

Vyper 0.2.15、0.2.16 和 0.3.0 版本的重入鎖失效，Vyper 官方文件安裝介面推薦的也是一個錯誤的版本。其他使用 Vyper 編譯器的專案方也趕緊進行了自查，試圖確保自己不會成為下一個受害者。隨著漏洞利用事件的源頭被逐漸揭露，市場逐漸認識到，這次的危機並不僅意味著一次普通的駭客漏洞利用事件，更是展露出整個底層堆疊對整個 DeFi 行業潛在的巨大風險。

和以往相比，前段時間的駭客事件數量越來越少，這與市場的繁榮程度脫不開關係。DeFi summer 和 NFT summer 時期，每週都有新的十億美元協議推出，相比之下如今的市場十分萎縮。與此同時的，駭客們找到漏洞利用或者製造大筆的攻擊事件的市場機會也在逐漸萎縮，這意味著駭客需要更新的、未開發的切入口來探索。

回歸「第一性原理」的駭客們在更底層的編譯器上找到了一個完美的切入口，去饞食 DeFi 市場上巨大可口的「蛋糕」，更底層的編譯器成為了駭客們更「聰明」的選擇。就這次事件及其暴露出的相關問題，BlockBeats 採訪了智慧合約開發者 Box（@BoxMrChen ）和 BTX 研究員 Derek（@begas_btxcap ）。

Curve 事件是怎麼發生的？

Aave 及 Lens 的創辦人 Stani（@StaniKulechov ）在社交媒體發表了自己對事件的看法：

「這對 Curve 和 DeFi 來說是一個不幸的挫折。雖然 DeFi 是一個可以做出貢獻的開放空間，但要做到絕對正確是很困難的，而且風險很高。在 Curve 的案例中，他們在協議級別上做對了。」

Curve 遭遇的漏洞利用事件是最古老，也許是最常見的以太坊智慧合約攻擊形式之一，重入攻擊。重入攻擊允許攻擊者反覆呼叫智慧合約的某一函式，而不等該函式的前一個呼叫完成。這樣，他們就可以不斷利用漏洞提款，直至受害合約資金耗盡。

重入鎖與 CEI 原則

舉個簡單的例子來說明重入攻擊：一家銀行總共擁有 10 萬現金。但這家銀行有一個很大的漏洞，每當人們取錢時，銀行工作人員並不立即更新帳戶餘額，而是等到一天結束時才進行核對和更新。這時有人發現了這個漏洞，他在銀行開了一個帳戶，先存入 1000 元，然後取出 1000 元，過 5 分鐘再取出 1000 元。由於銀行沒有即時更新餘額，系統會在進行核對和更新前認為他帳戶還有 1000 元。通過反覆操作，最終該使用者取出了銀行裡全部的 10 萬美元現金。到這天結束時銀行才發現被利用了這個漏洞。

重入攻擊的複雜性在於它利用了合約之間相互呼叫的特性，以及合約自身的邏輯漏洞，通過故意觸發異常和回退功能來實現欺詐行為。攻擊者可以反覆利用合約的邏輯漏洞，竊取資金。防止重入攻擊的解決方案也很普遍，提前設定一段針對性的特殊程式碼內容進行防護，用這樣的保護機制來確保資金安全，這被稱為重入鎖。

Solidity 為智慧合約程式設計設定了一個「 CEI 原則 」（Check Effects Interactions），能很好地保護函式免受重入攻擊。CEI 原則的內容包括：

1. 函式元件的呼叫順序應該是：首先是檢查，其次是對狀態變數的影響，最後是與外部實體的互動。
2. 在與外部實體互動之前，應該先更新所有狀態變數。這被稱為「樂觀記帳」，即在互動真正發生之前就將影響寫入。
3. 檢查應在函式開始處進行，以確保呼叫實體有呼叫該函式的許可權。
4. 狀態變數應在任何外部呼叫之前更新，以防重入攻擊。
5. 即使是可信的外部實體，也應該遵循 CEI 模式，因為它們可能會將控制流轉移給惡意的第三方。

根據文件的說法，CEI 原則有助於限制合約的攻擊面，特別是防止重入攻擊。CEI 原則可以很容易地應用，主要就是按功能程式碼的順序，不需要改變任何邏輯。眾所周知的導致以太坊分叉的 The DAO 漏洞利用，也是無視「CEI 原則」，而被攻擊者實現了重入攻擊，造成了毀滅性後果。

但被攻擊的 Curve 池並沒有遵循這個 CEI 原則，原因是 Curve 採用的是 Vyper 編譯器。作為編譯器的 Vyper 程式碼漏洞，導致重入鎖失效，使得駭客的重入攻擊成功實現了。

大多數人都知道 Solidity，但 Solidity 並不是建立智慧合約的唯一語言，目前替代 Solidity 的流行方案就是 Vyper。雖然 Vyper 的功能和流行程度不如 Solidity，但對於熟悉 Python 的開發人員來說是理想的選擇，因為 Vyper 能將類 Python 的程式碼轉譯成以太坊智慧合約程式語言。

延伸閱讀：導致Curve被駭的Vyper：第二智能合約語言，出了什麼問題？

根據 github 的資訊顯示，Vyper 的 github 程式碼庫貢獻第一的開發者，也是 Curve 開發者。這也不難解釋 Curve 為什麼採用的是 Vyper 而不是 Solidity。

Vyper 重入鎖為什麼會失效？

那在這次攻擊事件裡，Vyper 的問題究竟出在哪裡？重入鎖為什麼會失效呢？是因為沒有進行測試嗎？BlockBeats 採訪了智慧合約開發者 Box826.eth（@BoxMrChen ），據他透露，Vyper 重入鎖是做過用例測試的。但失效的原因是，測試用例是結果導向，也就是測試用例也是錯的。

簡而言之，Vyper 重入鎖失效最大的原因在於，編寫測試用例的人是根據結果來編寫的測試用例，而沒有思考過為什麼 slot 會莫名其妙跳過 1。

在 Box 後續分享出來的這幾段 Vyper 程式碼中，可以明顯看出問題。當鎖名稱第二次出現的時候，storage_slot 的數量會被覆蓋，也就是說，在 ret 中，第一次獲取鎖的 slot 為 0，但是再次有函式使用鎖後，鎖的 slot 被加一。編譯後使用錯誤的 slot，導致重入鎖無法生效。

「預計錯誤的測試結果，當然驗證不出錯誤。舉個簡單的例子，現在我們在做計算題，1+1=2，但給定的標準答案錯了，說 1+1=3。而這時做題的同學答錯了，回答了 1+1=3，但卻和提前給定的標準答案相同，程式就自然沒辦法判定出測試結果出錯。」Box 在和 BlockBeats 的採訪中這麼說道。

懸了兩年的「達摩克利斯之劍」

在有所記錄的史上第一次重入攻擊事件中， WETH Attack 韋斯攻擊 的攻擊者，正是為了讓開發者重視重入攻擊而故意製造攻擊的白客，目的是使更多專案免受重入攻擊的可能性。在智慧合約的情境下，開發者應該採用不同的觸發機制，例如呼叫某個狀態改變函式來實現保護。這就要求開發人員在設計合約時充分考慮可能的攻擊場景，採取適當的預防措施。

為了深入瞭解 Vyper 編輯器，BlockBeats 採訪了 BTX 研究員 Derek（@begas_btxcap），他表示，對於熟悉 Python 的開發人員來說，Vyper 是比 Solidity 更理想的選擇，UI 介面更舒服，上手更快。但顯然，一些版本的 Vyper 編輯器程式碼並沒有經過可靠的第三方審計。甚至有的審計工作，可能是開發者自己完成的。

「傳統 IT 行業就不會發生這種事，因為一個新的語言出來後，會有無數的審計公司往死裡找你的漏洞。」

更不用說，能讓一個錯誤堂而皇之的存在兩年之久。

Vyper 貢獻者 fubuloubu 也表示：

編譯器並沒有像大家想像的那樣受到審查或審計。大多數編譯器都會進行重大且頻繁的更改，這使得稽核變得不利。即使有完整的程式碼庫稽核，在此之後新增的版本越多，它也會過時。稽核編譯器並不是一個很好的方式，因為稽核終端使用者使用該工具生成的最終產品（即原始 EVM 程式碼）更有意義。

所有這些都指向最後一個問題：激勵。也就是說沒有人有動力去尋找編譯器中的關鍵漏洞，尤其是舊版本。fubuloubu 此前提出過一個提案，提議將通過新增由使用者共同贊助的賞金計劃來幫助改進 Vyper，但沒有被通過。

駭客們正在回歸「第一性原理」

對協議和專案的開發人員而言，這是合約安全開發實踐的又一次鮮活案例。但最重要的是，Curve 事件給了我們所有人一個警示，底層編譯器的安全性問題被嚴重忽略了，回歸「第一性原理」的駭客們在更底層的編譯器上找到了一個完美的切入口。

事後，Aave 及 Lens 的創辦人 Stani（@StaniKulechov ）也在社交媒體釋出了長文表達自己的感想：

這次 Curve 被攻擊事件意味著，DeFi 風險一直涉及整個底層堆疊、程式語言、EVM 等。這警示了我們應更加謹慎和敏感，尤其是將來使用訂製的 EVM 和應用程式鏈時。

來自更底層的攻擊

對於編譯器的漏洞，僅通過對合約原始碼邏輯的審計，是很難發現的。僅僅是研究版本和版本之間的差異也是一個大工程。需要結合特定編譯器版本與特定的程式碼模式共同分析，才能確定智慧合約是否受編譯器漏洞的影響。

「目前只有兩個編譯器最佳，Vyper 的程式碼庫更小，更容易閱讀，對其歷史進行分析的更改也更少，這可能就是駭客從這裡下手的原因，Solidity 的程式碼庫要更大一些。」

fubuloubu 甚至懷疑國家支援的駭客可能參與這起 Curve 攻擊事件：

「找到該漏洞需要幾周到幾個月的時間，考慮到投入的資源，這也許是由一個小團體或團隊進行的。」

作為加密行業使用最廣泛的編譯語言，Solidity 的安全更是被使用者所牽掛，畢竟如果這次是 Solidity 編譯器出現了重入鎖失效的問題，那麼整個 DeFi 行業的歷史或許都要被改寫了。

根據 Solidity 開發團隊定期釋出的 安全預警 ，在多個不同版本的 Solidity 編譯器中也都曾存在過安全漏洞。

最近一次的編譯器錯誤記錄是 6 月 26 日，在調查與使用具有副作用的三元表示式的 abi.decode 作為型別引數相關的安全報告時，在 Solidity 編譯器的舊程式碼生成管道中發現了一個錯誤。舊程式碼生成器沒有評估複雜的表示式，如賦值、函式呼叫或條件，其 .selector 正在被訪問。這會導致此類表示式未執行的副作用，因此使用舊管道編譯的合約的行為可能不正確。

我們也可以看到 Solidity 的 Github 倉庫 中放置著一個檔案，上面列出了 Solidity 編譯器上一些已知的安全相關的 bug。該列表可以追溯到 0.3.0 版本，只在此版本之前存在的 bug 沒有被列入。這裡，還有另外一個 bugs_by_version.json 檔案。該檔案可用於查詢特定的某個編譯器版本會受哪些 bug 影響。

幸運的是，也正是因為 Solidity 語言的廣泛應用，以及以太坊基金會在背後的輔助，許多已存在的問題已經被專案和協議在部署的過程中被指出。因此 Solidity 比 Vyper 更快幾步完成了修改和完善，從這個角度看，這也是 Solidity 更規範和更安全的原因之一。

為了幫助 Solidity 開發者進行更好的測試，防止發生同樣的事。UnitasProtocol 共同創辦人 SunSec（@1nf0s3cpt）在 Curve 被攻擊事件後，釋出了一份 DeFiVulnLabs Solidity 安全測試指南，支援 47 種漏洞，其中包括漏洞描述、場景、防禦、漏洞程式碼、緩解措施以及如何測試。

如何儘可能避免底層攻擊？

在這起 Curve 事件上，Box 認為所有開發者得到的啟示是：不要貪圖追隨技術潮流選擇不成熟的方案；不要在不寫測試用例的情況下就認可自己的程式碼（Vyper 出問題的幾個版本上，甚至連測試用例都是錯誤的）；永遠不要自己批準自己的程式碼；有些財富，可能要數年才會被發現；不可升級是對自己的傲慢和對其他人的藐視。

通常開發人員也不會想到這裡面有什麼坑，隨手就選一個版本編譯，可能會忽略版本之間的區別所帶來的風險。即使是小版本升級也可能引入重大變化，這一點在開發去中心化應用程式時尤其重要。

這起 Curve 事件對開發者的警示有：使用較新版本的編譯器語言。保持最新的程式碼庫、應用程式和作業系統非常重要，同時也要全方位搭建自身的安全防禦機制。儘管新版本也可能引入新的安全問題，但已知的安全問題通常較舊版本要少。當然也要及時關注社群和官方的版本更新公告。瞭解每一個版本帶來的變化，按需更新自己的程式碼庫和執行環境。採取這些措施或許可以大大減少編譯器錯誤導致的安全事件。

此外，要完善程式碼的單元測試用例。大部分編譯器級別的錯誤會導致程式碼執行結果不一致，這很難僅通過程式碼 review 發現，但在測試中就可以暴露出來。提高程式碼覆蓋率有助於避免這類問題。以及要儘量避免使用內聯彙編、多維陣列編解碼等複雜語言特性，除非有明確需求。歷史上大多數 Solidity 語言漏洞都與這些高階功能相關。在沒有特殊需求的情況下，開發人員應該避免為了炫技而使用實驗性語言特性。

對協議層以及安全人員而言，在進行程式碼審計時，也不能忽視編譯器版本可能帶來的風險。可以預見的是，駭客們已然打開了新思路，在未來一段時間裡，更底層的漏洞被利用事件會越來越多。同時，作為更底層的基礎設施，底層堆疊、程式語言、EVM 等更需要被好好審計。未來審計公司的市場會越來越大，白客賞金的市場也會越來越大。Vyper 團隊也計劃在事情正式結束梳理後，開啟審查漏洞賞金的計劃。

當然我們也不用對底層基礎設施存在的風險過度恐慌。目前大多數編譯器 Bug 僅在特定程式碼模式下觸發，還需要根據專案情況具體評估實際影響。定期升級編譯器版本、充分的單元測試都能幫助預防風險。