從最近幾個月融資趨勢和市場反應來看，一級市場資本目前對注重安全信息時效性、風險覆蓋度、技術偏輕量級的安全監測、防火牆領域有濃厚的興趣
作者： Ray Xiao, Sally Gu, IOSG Ventures
封面： Photo by Shubham's Web3 on Unsplash
本文為 IOSG 原創內容，僅做行業學習交流之用，不構成任何投資參考。如需引用，請註明來源，轉載請聯繫 IOSG 團隊獲取授權及轉載須知。
前言：
在 9 月底 Paradigm 官宣完成了區塊鏈安全項目 Blowfish 的領投又一次引起了大家對智能合約安全分析領域的廣泛關注。但其實 Paradigm 團隊在此之前就已經在智能合約安全測試方向做了很多實踐，在今年 3 月 Paradigm CTO Georgios 公佈了他們開發的 Foundry 智能合約測試套件（Runtime Verification 團隊也是重要的貢獻者），如今區塊鏈安全分析也在朝著更細緻的分工方向發展。
從最近幾個月融資趨勢和市場反應來看，一級市場資本目前對注重安全信息時效性、風險覆蓋度、技術偏輕量級的安全監測、防火牆領域有濃厚的興趣（這和以往大部分資本投入在審計領域大有不同）。
根據 CertiK 和 SlowMist 的相關報告，僅 2022 年第一季度和第二季度因安全攻擊問題 crypto 資產損失就高達 20 億美元。在第二季度單閃電貸攻擊就導致了總計 3 億美元的資產損失。而本月更是成為了有史以來黑客活動最大的一個月，兩週內僅針對 DeFi 協議的攻擊已超過 12 次，被盜金額超 7 億美元。
如果我們把鏈上智能合約從開發>> 部署至區塊鍊網絡>> 運行看成是一個完整生命週期的話，針對智能合約的安全分析分為：針對合約部署前（在區塊鍊網絡正式上線運行前）的分析、合約部署後的分析，這大致涵蓋了：測試、審計、監測三大類目，每個類目下面又有各種類型的分析方式和相應的工具（如下圖）。PS：智能合約的審計覆蓋面會從合約部署前到部署後（合約升級審計）
1. 智能合約部署前的安全分析：測試+審計
1.1 測試（Testing）
合約測試是開發者和審計者需要花費最多精力的工作，這與傳統開發者不同。因為區塊鏈不可篡改的特性，一旦智能合約部署到 EVM 虛擬機上就難以變更，因此安全分析、彌補安全漏洞的工作大部分花費在 “事前分析”——對智能合約部署前的安全測試。
在接受正式審計前，合約開發者/審計者需要對合約的代碼進行一些基礎性的測試，初期測試的覆蓋率越高越能避免一些簡單的 bug 進入正式審計階段（一般一份智能合約達到 85%-90% 的代碼被測試覆蓋是合理水平；針對核心模塊的覆蓋率需要在 95% 以上）。
常見的基礎性的測試有單元測試（聚焦於單個函數的測試）和集成測試（確保各部分代碼組合起來也能正常運行）。這個階段常用的工具有 Hardhat、Truffle test framework 等，常見的測試內容包括：狀態檢查、事件觸發、交易重置、函數計算、完全功能測試。
1.2 審計 Auditing
“測試可以有效地發現程序存在的缺陷，但是它卻無法證明程序不存在缺陷。” —— Edsger Wybe Dijkstra（計算機科學家、1972 年圖靈獎獲得者）
根據 Ethereum 官方文檔的定義，審計是對智能合約每一行源代碼的細節評估，攻擊者的思維方式來繪製智能合約中可能的攻擊向量，以發現可能的故障點、安全漏洞和不良的開發實踐。審計階段大致包含：靜態分析、動態分析（模糊測試 Fuzzing test、符號執行 symbolic execution）、人工分析、形式化驗證。正如上圖所說的 Dijkstra，單靠測試無法完全相信程序沒有故障，審計、形式化驗證更多的是想更加靠近程序不存在缺陷這一目標。
金錢成本
根據智能合約安全公司 Hacken 的數據，智能合約審計服務的行業的平均成本在 5000 美元到 30000 美元之間（中小型項目）。對於大型項目，成本有時可以達到 50 萬美元甚至更高。智能合約審計的成本直接取決於代碼複雜性和商定的工作範圍。影響價格的其他因素包括緊急程度、智能合約的大小（有多少行代碼）、完成流程所需的工程小時數、與項目相關的文檔的可用性等因素。
時間成本
初始審計平均需要 2 到 14 天，這也具體取決於項目的複雜性、智能合約規模和緊迫性。對於大型項目或協議，初始審核可能需要長達 1 個月的時間。初始審核完成後，客戶會收到有關要引入哪些修改的建議。
人力成本
根據 IOSG 在區塊鏈形式化驗證領域的領投項目 Runtime Verification 的反饋，審計的人力成本取決於協議的複雜性。對於大部分擁有資深行業經驗和學術經驗的頭部安全審計公司來說，理解 crypto 客戶項目的商業邏輯和 token economics 基本沒有太大難度，一般兩個專業的工程師大概花費 1~2 個星期就可以完成初始步驟。
但是接下來的部分會取決於客戶的具體需求。有的客戶只需要對被審計項目的基本業務邏輯進行人工審計（查看他們的代碼並手動審查它是否符合所需的業務邏輯），這是最便宜的服務。有的客戶希望對業務邏輯和 token economics 進行建模然後手工進行數學證明以確保某些重要結果成立，例如安全性、活性、一致性等。有些大客戶像 MakerDAO、以太坊基金會等則希望更進一步，對代碼進行形式化驗證 (Formal Verification)。
這里關於形式化驗證再多說一句，形式化驗證是用數學方法去驗證程序的正確性——程序的實現與程序員的意圖相符，最終證明項目的系統是 Bug Free 的。或者換句話說，形式化驗證像是一種更全面的 “testing”，它理論上會包含所有可能的輸入和狀態，這是 testing 無法做到的（如下圖例子所示轉賬合約中有 overflow bug，如果用 testing 需要測試者輸入一個極大的值才能找出，但是形式化驗證者會通過 “total amount of the token = sum of the balance of all addresses” 的數學邏輯來找出 overflow bug）
從實際規模化運用來說，形式化驗證相對傳統的測試方案在規模化運用上相對較慢。大部分的 crypto 項目來說，完成智能合約審計之後就已經足夠，從成本投入和潛在效益來說對小型項目來說還不是必需品 (或者說證明程序是 bug-free 的代價還比較高），核心原因是形式化驗證需要專業的形式化人才參與，因為對項目代碼創建形式化規範（formal specification) 是非常複雜的事情，需要涵蓋合約代碼的屬性，並定義合約在不同情況下的行為方式，這些需要專業的人才參與。（感興趣的讀者詳見我們之前寫的《為什麼我們領投 Runtime Verification》https://mp.weixin.qq.com/s/VWVgn4k9k0XqbM-O7-TVXg）
智能合約審計當下仍然是一個 labour intensive 的行業，並且對人才的技術要求較高。目前雖然市面上有十幾款比較流行的審計工具（大多由主流安全審計公司或者學術研究人員開發)，但是這些審計工具開發的目的是發現比較普遍的漏洞比如：transaction order dependency, random number, timestamp, callstack depth, Reentrancy, dangerous delegate call 等等）。因此，僅僅依賴這些工具去完成審計工作比較困難，可能會錯過許多和業務邏輯相關的漏洞。通常審核智能合約需要使用自動化工具+手動代碼審查相結合的方式，並且根據客戶的智能合約業務邏輯、Token 模型的不同需要 case by case 的人工審查。
智能合約安全分析和審計往往是在驗證程序的正確性，也就是程序的實現與程序員的意圖相符。因為程序的 bug，其實都是由程序的實現與程序員的意圖之間有區別導致的。我們之前在分享我們投資 Runtime Verification 一文中提及的形式語義學的其實就是能讓開發者的開發意圖（即 “語義”）和實現（即編程語言的 “語法”）精確相符的語言框架，從而減少 bug 的出現。
在智能合約安全審計領域目前雖然市面上工具也不少，且大多開源，但是拿來真正做到成功商業化的寥寥無幾，這其中根本原因我們後面也會分析，總之目前還是依賴於安全服務提供商自己的自動化工具+人工閱讀每一行代碼或建模，基本無法通過直接賣自動化審計工具拿到規模化商業收入。
PS: 根據我們最近領投的 Hexens 反饋，初期對於一些靜態分析的測試 Slither 和 MythX 是他們常用的開源工具，雖然結果並不能讓他們非常滿意。對於更高級別的測試，他們主要用 fuzzers 如 Echidna、Forge+built in fuzzer
2. 智能合約部署後的安全分析——監測（Monitoring）
目前 10 種最常見的區塊鍊網絡安全攻擊裡 Scam 出現頻率最高，且給用戶直接造成資產損失最高。根據 Peckshield 的數據，在 2021 年 crypto 因為各類 scams 造成的鏈上經濟損失達 120 億美金，比黑客直接攻擊造成的損失要高 6.7 倍。
常見的 scam 攻擊：
- 網絡釣魚（常見的網絡釣魚技巧是發送電子郵件/網站要求用戶重置密碼/恢復他們的帳戶。一旦用戶登錄這些虛假網站，他們就會竊取私鑰）案例：Alice 登錄某交易所後鏈接 MetaMask 錢包，收到彈窗提示錢包故障，需要助記詞恢復，恢復後錢包內資產被全部盜走。
- 冒名/冒充（自稱是某些 dapps/機構的員工或代表的人可能會通過電子郵件、電話或社交媒體聯繫用戶。他們將通過發送虛假的免費鑄幣/空投網站從用戶那裡竊取資金。或者通過冒充行為來操縱受害者以提取資金或敏感數據）案例：烏克蘭政府接受加密貨幣捐贈並宣布空投 NFT，冒名者偽裝成烏克蘭政府發出假 token 空投進行詐騙。
- Discord 管理身份劫持（攻擊者通過控制受到社區信任的管理員的機器人發布虛假公告，詐騙鏈接，或欺騙受害者放棄他們的加密貨幣或 NFT）案例：黑客通過控制藍籌 NFT 如 Bored Ape Yacht Club 等 discord 官方服務器，批量對成員發送錯誤鏈接，用戶點擊後資產會被不可逆地盜取
- BGP 劫持（通過謊稱擁有實際上並不能控制的 IP 前綴，並將之添加到互聯網 BGP 路由器中的路由表進行，攻擊者可以實現對該 IP 地址流量的劫持，在這種情況下用戶一旦嘗試登錄就會被重新導向至攻擊者設好的陷阱地址）案例：Celer 遭受 BGP 劫持攻擊，波及 32 名用戶和 23.5 萬美元的損失（2022.08）
- 代碼後門&陷阱（攻擊者通過隱藏在正常程序中的一段具有特殊功能的惡意代碼，如具備破壞和刪除文件、發送密碼、記錄鍵盤和 DDoS 攻擊等特殊功能的後門程序以竊取用戶個人信息）案例：Bob 在某網站 mint 了一個 NFT，兩天后發現不翼而飛。因為攻擊者在 NFT 代碼植入了某些特徵，可以授權他人進行 NFT 交易或可以破壞他人的 NFT，無法掛單等。
- 前端惡意代碼(攻擊者會將惡意代碼植入交易所等網站的前端，如用戶瀏覽器的標籤管理系統，從而通過這串惡意代碼生成錯誤的批准，允許用戶資產被轉移至攻擊者的地址) 案例：KyberSwap 因為黑客安插的前端惡意損失 256 萬美金（2022.09）
常見的工具：
相比於智能合約安全審計，提供 monitor&firewall 服務涉及的業務內容更為龐雜和細密。
Focus 在合約部署前以及合約部署後升級的智能合約代碼安全審計，往往通過各類型的測試（靜態分析、動態分析）輸入一系列的值來看合約的輸出值及狀態是否正常運行。比如針對一個常見的鏈上轉賬邏輯（如下圖），常見的測試人員會做：transfer zero ether, transfer all the ether, transfer slightly more than all the ether, transfer the largest possible amount of ether, transfer an account's value to itself 等事情來看合約是否可以如能做到程序員預期該做的事情和實現的結果。
Focus 在事中安全分析的 monitor/firewall 服務，要處理的問題更繁雜。並且目前看下來這類項目提供的安全服務更注重廣度（涵蓋盡可能多的有問題的鏈上資產合約、最新的涉嫌詐騙行為的地址合約釣魚網址等等），它們相對比合約審計的安全服務更輕量級。涉及許多跟檢查代碼正確性之外的安全風險，比如各類詐騙、釣魚相關的攻擊。而監測這些漏洞除了需要依賴合約解析能力之外，還需要不斷更新可疑地址、可疑合約邏輯、可疑資產清單等數據的風險數據庫。
通過我們和最近行業內從業人員的交流，發現不同的 Monitor 服務定位其實也各有不同，比如 GoPlus 更加註重提供數據 API 服務給項目方甚至是一些注重前端的防火牆；Harpie、Blowfish 更注重提供前端服務，當用戶執行一個交易行為、或者完成一次授權之前模擬這個交易以發現問題阻止用戶有安全風險的交易；Tenderly 則更注重開發者的需求，為智能合約開發者提供運行監測等服務。當然目前這個領域還比較新，儘管像 Opensea 這樣的大型交易平台已經和一些項目進行實質的商業合作，但是我們認為未來商業化的路徑還是不太明晰同時會遇到的同業競爭會不小（因為相較於代碼審計技術上的門檻會低一些）。
3. 智能合約安全分析工具的商業發展機遇和挑戰
1）目前來看行業內的許多人認為 monitoring&firewall 跟 security auditing 之間的商業邊界還較為模糊（現在看都屬於 2B 的服務，客戶大部分是各類 crypto 項目方），理論上來說由在區塊鏈安全領域深耕多年的專業安全審計公司直接提供 monitoring service，甚至開拓 B2C, 2C 化的終端用戶直接收益的產品更符合商業發展邏輯。但是由於 monitoring 賽道剛剛起步，收費模式和盈利模型尚不明確（目前看到是 2B 抽取服務費或者項目的交易手續費分成），如果市場回暖安全審計市場會仍然處於供> 需，訂單做不完的狀態可能無暇顧及這個新興市場，這個時間窗口會是給新出現的專門做 monitor/firewall 的公司一個很好的機會。
2）智能合約審計的自動化工具目前市面上已經有很多，常見的有十幾種大多開源。這個方向通過賣工具來收費的商業模式尚未跑通，核心原因是：1）黑客和安全防御者的博弈關係是 an arms race and the attack is always a moving target，魔高一尺道高一丈。安全工具一旦推出，黑客就會嘗試繞過它，開發出新的攻擊形式。所以安全工具只能不斷迭代更新將攻擊門檻提高；2) 大部分工具使用門檻不低，會使用專業安全分析工具產品的人少，因此限制了市場規模 (雖然 Runtime Verification 有在推給普通開發者使用的 Firefly, ConsenSys Dilligence 也有 MythX); 3) 安全分析工具只能覆蓋主流的漏洞，而根據協議業務邏輯的經濟模型的不同客戶主觀更希望審計團隊人工提供定制化的服務。
團隊主觀也希望一個受市場 authorized 的審計公司提供較深度定制化審計服務並且蓋戳。因此，提供 monitoring service 會是專業安全團隊切入可規模化產品的一個很好的機會點。
3）為 defi 項目方，DAO 或個人服務的 insurance 業務可能會成為下一片藍海。考慮到目前市場對於黑客直接盜取私鑰等攻擊方法並沒有良好的防範或解決方案，以風險規避和資產保障為目的的保險業務很可能在未來會受到更多的青睞。當然考慮到加密資產本身的複雜性和合規方面的多重不確定性，underwriter 往往會承受更大的風險，因而在解決這一問題之前，insurance 產業的發展可預見的，仍然將面臨一定的瓶頸。期待隨著整體加密資產體量的上升和更多傳統機構用戶的進入，insurance 業務能在下一個週期來臨之前能夠實現更多製度性的完善。
Reference:
https://www.paradigm.xyz/2022/03/foundry-02
https://ethereum.org/en/developers/docs/smart-contracts/testing/
https://docs.openzeppelin.com/learn/writing-automated-tests
https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d
感謝：Xinshu Dong, Runtime Verification team, Hexens team 對此文的幫助和意見
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。文章內的信息僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
