作者：Jaleel，BlockBeats
隨著一場漏洞利用事件的發生，DeFi 行業陷入了一場混亂。 Curve Finance，這個DeFi 行業的巨頭，成為了嚴重「攻擊」的目標，諸如alETH/msETH/pETH 的多個穩定幣池岌岌可危。據不完全統計，該漏洞利用事件已造成Alchemix、JPEG’d、MetronomeDAO、deBridge、Ellipsis 和CRV/ETH 池累計損失5200 萬美元，整個市場的信心被嚴重撼動。
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 的代碼轉譯成以太坊智能合約編程語言。
根據github 的信息顯示，Vyper 的github 代碼庫貢獻第一的開發者，也是Curve 開發者。這也不難解釋Curve 為什麼採用的是Vyper 而不是Solidity。
Vyper 重入鎖為什麼會失效？
那在這次攻擊事件裡，Vyper 的問題究竟出在哪裡？重入鎖為什麼會失效呢？是因為沒有進行測試嗎？ BlockBeats 採訪了智能合約開發者Box 826.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（@ 1 nf 0 s 3 cpt）在Curve 被攻擊事件後，發布了一份DeFiVulnLabs Solidity 安全測試指南，支持47 種漏洞，其中包括漏洞描述、場景、防禦、漏洞代碼、緩解措施以及如何測試。
如何盡可能避免底層攻擊？
在這起Curve 事件上，Box 認為所有開發者得到的啟示是：不要貪圖追隨技術潮流選擇不成熟的方案；不要在不寫測試用例的情況下就認可自己的代碼（Vyper 出問題的幾個版本上，甚至連測試用例都是錯誤的）；永遠不要自己批准自己的代碼；有些財富，可能要數年才會被發現；不可升級是對自己的傲慢和對其他人的藐視。
通常開發人員也不會想到這裡面有什麼坑，隨手就選一個版本編譯，可能會忽略版本之間的區別所帶來的風險。即使是小版本升級也可能引入重大變化，這一點在開發去中心化應用程序時尤其重要。
這起Curve 事件對開發者的警示有：使用較新版本的編譯器語言。保持最新的代碼庫、應用程序和操作系統非常重要，同時也要全方位搭建自身的安全防禦機制。儘管新版本也可能引入新的安全問題，但已知的安全問題通常較舊版本要少。當然也要及時關注社區和官方的版本更新公告。了解每一個版本帶來的變化，按需更新自己的代碼庫和運行環境。採取這些措施或許可以大大減少編譯器錯誤導致的安全事件。
此外，要完善代碼的單元測試用例。大部分編譯器級別的錯誤會導致代碼執行結果不一致, 這很難僅通過代碼review 發現, 但在測試中就可以暴露出來。提高代碼覆蓋率有助於避免這類問題。以及要盡量避免使用內聯彙編、多維數組編解碼等複雜語言特性，除非有明確需求。歷史上大多數Solidity 語言漏洞都與這些高級功能相關。在沒有特殊需求的情況下，開發人員應該避免為了炫技而使用實驗性語言特性。
對協議層以及安全人員而言，在進行代碼審計時，也不能忽視編譯器版本可能帶來的風險。可以預見的是，黑客們已然打開了新思路，在未來一段時間裡，更底層的漏洞被利用事件會越來越多。同時，作為更底層的基礎設施，底層堆棧、編程語言、EVM 等更需要被好好審計。未來審計公司的市場會越來越大，白客賞金的市場也會越來越大。 Vyper 團隊也計劃在事情正式結束梳理後，開啟審查漏洞賞金的計劃。
當然我們也不用對底層基礎設施存在的風險過度恐慌。目前大多數編譯器Bug 僅在特定代碼模式下觸發，還需要根據項目情況具體評估實際影響。定期升級編譯器版本、充分的單元測試都能幫助預防風險。