Defi 世界裡我們都知道智慧合約的程式碼安全性是非常重要的，這也關係到專案的成敗，因此在去年defi火熱之後，大量defi專案方紛紛都將自己的程式碼交給第三方審計機構，以確保專案不出現漏洞，當然一部分專案方也因此招攬使用者，審計機構在這次的牛市中賺得盆滿缽滿。
但是隨著行情日益分化，一些defi專案頻頻出現資產被駭客盜走的現象，而隨著近年行情的下調，這種情況愈演愈烈，遠的不說，在最近一兩月內，就接連發生多起規模龐大的defi專案被黑事件，它們分別是：
1、8月10號，o3swap資金被盜
2、8月4日，Sorbetto Fragola遭到攻擊，造成損失
3、8月2日，加密指數協議Levyathan遭到攻擊，造成損失
4、7月16日，THORChain遭受攻擊，造成損失
5、7月12日，anyswap遭到攻擊，私鑰被駭客推算出來，資產被盜，造成損失
6、7月3日，RAI Finance因ChainSwap合約漏洞，資產被盜，造成損失
令人觸目驚心的是這樣的攻擊和被黑事件幾乎每個月都會發生，DEFI儼然成為駭客的提款機。
那麼審計機構不是之前已經審計完成了麼，為什麼defi專案的漏洞問題還是有增無減？審計機構的報告到底有沒有意義成為很多人關注的話題。
審計報告一般都審計什麼
對於專案的第三方審計而言，很多人認為審計的作用就是將專案所有的程式碼都審計一遍，保證程式碼沒有漏洞。其實這種想法是錯誤的，第三方審計機構其實主要審計的是鏈上智慧合約的程式碼，對於不在區塊鏈上部署的程式碼比如網頁前端程式碼之類的是不進行審計的。
我們以靈蹤為例，在他們在某專案的審計報告裡明確指出，審計的檔案都是sol為字尾名的solidity智慧合約程式碼，而對於網頁前端部署程式碼是沒有進行審計的，也就是說，如果使用者因為網頁顯示問題而導致合約執行錯誤，這部分鍋並不由審計機構背。
換句話說，使用者在執行defi專案的合約時，需要在區塊瀏覽器上檢視自己的錢包是否和審計報告中規定的合約進行互動，如果有，那麼專案方是正常部署合約和網頁前端，如果沒有，那就說明專案方提交給審計機構的程式碼沒有問題，但是實際給使用者使用的是另一套有問題的程式碼，那麼這個時候就可以得出結論，專案方故意想要坑錢跑路。
當然我們前面也說到，區塊鏈上智慧合約的程式碼安全性可以透過審計機構審計，但是使用者使用前端的網頁程式碼沒有進行審計，因此從理論上來講，即使審計程式碼透過了，使用者在使用DEFI產品的時候仍然會有一定概率出現問題。
審計報告的缺陷
1、程式碼第三方審計的滯後性
對於區塊鏈專案程式碼尤其是智慧合約程式碼來說，其實審計是一個比較學習和完善的過程，區塊鏈專案大部分技術都是新興技術，而且創新性也比較高，因此對於審計機構來說，今天審計沒問題並不代表以後就一直沒有問題，只能說在當時的條件下，程式碼審計機構沒有發現之前已經被市場證實的漏洞出現在本次被審計的專案中。也就是說，審計報告有一定的滯後性。
比如去年大部分被攻擊的專案都是swap類專案，而最近一段時間裡出現問題的專案普遍是跨鏈類專案，比如o3、ploynetwork、THORChain和anyswap等，實際上，這在一定程度上來說，程式碼的創新性越高，其漏洞的可能性也越高，市場中審計機構也就會遇到各種各樣被駭客攻擊的案例，從而為以後審計程式碼提供參考。
2、審計機構參差不齊導致出現遺漏
不可否認的是本次牛市使得程式碼審計機構的工作任務出現大幅上升，也就是我們說的過飽和現象，而對於審計機構來說，人員數量和精力是一定的，因此一部分審計機構為了方便起見，對審計流程做了高度流程化，比如先看哪些，後看哪些，注意有沒有出現某些漏洞，而不是透過審計流程+同行評審等方式來進行，這樣的好處是能夠提高審計效率，使得審計機構能夠在短時間內完成大量專案的審計工作，而問題就是就會造成只看到會不會出現某些漏洞，而對於其他方向的漏洞沒有研究或者沒有考慮到，這樣一些名氣並不太好的審計機構出現這種問題的概率更大。
某專案的審計結果，基本都是按照模板來進行審計，沒有一定的靈活性
當然對於這種方式，一般有實力的defi專案方都會請兩到三個審計機構進行程式碼審計，最後公佈在專案官網上，以期待能夠提高知名度。目前多個審計機構進行程式碼審計確實能夠降低一部分程式碼漏洞的風險，但是仍然有大量DEFI專案並沒有這樣做，或者都選擇多個不知名審計機構進行審計，以給使用者一種多個機構審計完成，專案安全性高的錯覺。
投資者對審計報告的盲目崇拜
審計報告雖然對專案來說，有一定作用的，但是另外一點比較關鍵的是投資者對審計報告的崇拜，而不是認真研究審計報告，從而造成某種誤區。
我們以某defi專案為例：
一般審計結果會給出程式碼的風險等級，比如下圖：
這裡審計報告並沒有直接說該合約是否存在問題，而是以風險數量為標準，有的defi專案更簡單點直接會說明高風險和中風險的數量，故意忽略低風險，因為這裡低風險程式碼有時候是專案方自己設定的，比如：
審計機構在判定結果為所有風險皆為0的情況下，卻給出了增強建議，也就是一個合約檔案的某個引數可被修改，經過專案方的反饋之後，審計機構認為這種情況合理，到底是否正常，這一點有待商榷。
另外一點就是審計的過程其實是專案方改作業的過程，一般來說，專案方將程式碼提交給審計機構之後，審計機構在審計完成後對有問題的程式碼進行標識出來，然後專案方進行修改，審計機構對修改後的程式碼進行確認，這樣就完成了審計過程，比如o3的某個程式碼問題：
這裡會出現一個錯誤，而最終的結果是fixed
類似的情況還有很多，比如下圖
也就是說，專案方的漏洞被審計機構發現之後，專案方會按照要求進行修改，但是對於投資者而言，如果審計機構沒有發現的漏洞呢？專案方會進行反覆自查麼？這裡除了專案方自己，沒有人能知道。
結語
網上曾經有一個段子，說的是程式設計師甲擔心自己的程式碼出現bug，乙問能不能跑，甲反問是程式碼能跑還是人能跑，乙回答只要有一個能跑就行。這也在一定程度上說明對於快速搭建專案之下程式碼的質量堪憂，很多專案方其實並不是特別關心，程式碼能用和程式碼安全實際上是兩個事情。從去年牛市到現在，實際上有很多專案方都是抄襲的程式碼或買其他專案全套程式碼，修修改改之後就能直接執行，那麼這種氛圍之下，DEFI頻繁出現被盜的問題也就能夠得到很好的解釋了。
