這些智慧合約漏洞，可能會影響你的賬戶安全！

摘要：區塊鏈聯盟鏈智慧合約形式化驗證揭秘，解釋了我們為什麼要對區塊鏈上的智慧合約進行形式化驗證，以及形式化驗證的分類和業界針對每種分類所推出的形式化驗證工具，最後作者描述了一下目前形式化驗證的種種方法所面臨的問題及對於這個領域技術發展的展望。

本文分享自華為雲社群《》，作者：麥冬爸 。

什麼是形式化驗證？

維基百科對形式化驗證的解釋是這樣的：在計算機硬體（特別是積體電路）和軟體系統的設計過程中，形式化驗證的含義是根據某個或某些形式化規範或屬性，使用數學的方法證明其正確性或非正確性。傳統上在硬體設計領域比較常用。主要原因就是硬體設計週期長，成本高，一旦生產出來就很難改動了。例如一個 CPU 設計如果已經出晶片了，那麼出了問題就是大事。形式驗證可以分為三大類：抽象解釋（Abstract Interpretation）、形式模型檢查（Formal Model Checking，也被稱作特性檢查）和定理證明（Theory Prover）。

區塊鏈智慧合約為什麼需要形式化驗證？

在區塊鏈系統中可以程式設計且自動執行的程式被稱為智慧合約。智慧合約最早在以太坊區塊鏈平臺上應用，如Solidity就是一種智慧合約程式語言，以使傳統應用程式開發人員能夠編寫智慧合約。初期會Solidity語言的全球只有幾百人，後來隨著以太坊與區塊鏈的火熱，參與Solidity智慧合約的人才開始逐漸增加，但是跟整個IT市場的從業人群比起來，會編寫智慧合約的人還是太少，大量的IT從業者要想開發智慧合約只能去學習Solidity。為了讓更多的 IT從業者可以參與智慧合約的編寫與業務規則的實現，智慧合約平臺在原有Solidity的基礎上擴充套件了對更多主流語言，甚至高階語言的支援，這樣可以讓多普通It從業人員也有了可以進行智慧合約編寫的可能性，大量熟悉Java、Go、Php等技術程式設計的開發人員都可以參與智慧合約的開發。

然而，由於區塊鏈交易是不可變的，智慧合約程式碼中的錯誤會產生毀滅性的後果，破壞了對底層區塊鏈技術的信任。例如，臭名昭著的TheDAO漏洞導致價值近6000萬美元的以太損失，奇偶校驗錢包漏洞導致價值1.69億美元的以太永遠被鎖定。解決這些事件的唯一補救辦法是硬分叉區塊鏈，並將其中一個分叉恢復到事件發生前的狀態。然而，這種補救辦法本身是毀滅性的，因為它摧毀了區塊鏈的核心價值，如不可變性和分散信任。但是智慧合約的編寫目的是為了行業應用，一旦應用到實際中必須考慮智慧合約的安全性，智慧合約要達到機器可信，就必須首先排除掉因人為因素而造成的智慧合約破壞情形。智慧合約形式化驗證提供了一種可以證明的安全檢驗機制，透過形式化語言把合約中的概念、判斷、推理轉化成智慧合約模型，可以消除自然語言的歧義性、不通用性，進而採用形式化工具對智慧合約建模、分析和驗證，進行一致性測試，最後自動生成驗證過的合約程式碼，形成智慧合約生產的可信全生命週期。可以把市場上已經出現的安全風險進行排查與審計，經過審計後的智慧合約程式碼自然安全性就得到增強，同時智慧合約形式化驗證也是目前對智慧合約進行安全保證最可靠的措施。行業應用區塊鏈與智慧合約，就需要進行智慧合約 的形式化驗證，消除安全隱患。

智慧合約形式化驗證方法分類

業界通常對智慧合約進行形式化驗證都有一些通用的方法，大體上分為下面幾種通用的方法，每種方法都有一些工具和框架進行支撐。

1. 定理證明

定理證明是一種利用演繹推理在符號邏輯中提供證明的形式化方法．在這種方法中，證明的每個步驟都 會引入一個公理或一個前提，並提供一個陳述，使用謂詞邏輯將其進行推導，最終得到想要驗證的結果．在證明系統滿足關鍵期望的過程中，一般使用定理證明器來做輔助驗證工作，因為這需要將手工證明的過程變成一系列能夠在計算機上執行的符號演算，且可以對正確性進行檢查。

其優勢是這個方式是使用數學的方法，透過公理或前提進行推導，保證驗證的嚴謹性。其不足是在做數學驗證前需要將不同型別的原始碼轉換為相關框架的驗證程式碼，而目前沒有很好地辦法保證在原始碼與驗證程式碼之間的轉換一致性，實現成本高，自動化水平低，正確性也是很難保證的。在區塊鏈智慧合約領域一般對於有高隱私性，安全性，功能性，語義一致性等強烈的需求會透過這種法法來保證。

那業界在定理證明還是實現了很多工具和框架支撐這一能力，基本有下面的一些工具：

Solidity* and EVM*，該框架使用函式式語言F*分析驗證了 Solidity智慧合約執行時的正確性，F*是一種函數語言程式設計語言，用於形式化驗證程式的正確性。

Corral是 Boogie語言的分析工具．預設情況下，Corral會進行有界搜尋，直到遞迴深度和固定數量到達一定限度為止，Boogie是一種中間驗證語言，旨在構建其他語言的驗證程式的中間層。

Coq是一個互動式定理證明助手，它提供了一種形式化的語言來編寫數學定義，可執行 演算法和定理

Isabelle/HOL是一個基於高階邏輯的通用互動式定理證明器.

Raziel是一個程式設計框架，用於驗證智慧合約的多方計算的安全問題，為智慧合約的隱私 性提供保障.

2. 符號執行

符號執行（英語：symbolic execution）是一種電腦科學領域的程式分析技術，透過採用抽象的符號代替精確值作為程式輸入變數，得出每個路徑抽象的輸出結果。 這一技術在硬體、底層程式測試中有一定的應用，能夠有效的發現程式中的漏洞。這種方式的優點是以符號值作為輸入，藉助相應工具，可得到具體測試用例，具有很高的程式碼覆蓋率。那這種方式本質上屬於測試，不能１００％證明智慧合約是沒有問題的，因為基於測試是很難以100%覆蓋所有的場景，一般在做合約的安全性，功能性驗證會推薦使用這種方式。

基於符號執行的業界的一些比較有名的架構如下：

• SASC，這個工具被用來發現潛在的邏輯風險，它是一種靜態分析的工具，且可以生成呼叫關係的拓撲圖。
• MAIAN，這個工具被用來查詢漏洞，被設計成利用符號分析和具體驗證器來跟蹤智慧合約中的屬性。
• Securify，這個工具被用來進行安全漏洞分析，它是一個專門針對以太坊智慧合約的工具。
• Mythril，這個工具被用來進行程式碼安全分析，是一個針對以太坊的智慧合約的符號執行的工具。
• Verx是一個可以自動驗證以太坊智慧合約功能性的驗證器，以太坊相關的問題可以透過上面三個工具組合使用來提高覆蓋面。
• Oyente，這個工具被用來檢測合約程式碼潛在的安全漏洞，是一個基於符號執行技術的測試工具。

3. 模型檢測

模型檢測(model checking)，是一種重要的自動驗證和分析技術，由Clarke和Emerson以及Quelle和Sifakis提出，主要透過顯式狀態搜尋或隱式不動點計算來驗證有窮狀態併發系統的模態/命題性質。其基本思想是檢驗一個結構是否滿足一個公式要比證明公式在所有結構下均被滿足容易得多，進而面向併發系統創立了在有窮狀態模型上檢驗公式可滿足性的驗證新形式，這種方法也被用於驗證智慧合約的正確性。

它的優點是可以使用市面上現有的模型檢測工具，並且支援自動化驗證，減少人為參與。但是其無法保證所使用的模型檢測工具的完備性與正確性，合約複雜度過高會導致狀態空間爆炸，進而導致無法完成驗證能力。一般情況下需要保證合約的安全性，功能性會使用這種方式。

業界也有不少這種型別的工具和架構如下：

• NuSMV，這個工具被用於用於工業設計的驗證，具有極高的可靠性，且被設計成模型檢查的開放架構。它是SMV工具的重新實現和擴充套件，而SMV是第一個基於BDD的模型檢查器。
• BIP， 這個框架包含一整套支援建模、模型轉換、模擬、驗證和程式碼生成的工具集，還支援層次化結構, 被設計成為一個通用的系統級形式化建模框架。
• Prism，這個工具只針對表現出隨機或機率行為的系統，被設計成一個機率模型檢查器，對機率行為進行形式化建模和分析。
• SMC，這個工具被設計成模型檢測器，用於檢查在不同公平性假設下併發程式的安全性和活性。

4. 形式化建模

可以透過準確的數學語句和模型元件去定義不同元件的關係，消除系統中存在的二義性，這種設計系統的技術就是形式化建模。基於這種方式的系統的模擬結果是可以復現的，不會存在偶發性事件。這種方法的優點就是使用精確的數學語句或模型元件來設計系統，從而保證其模擬結果可被複現。但是此方法大多使用市面上已有的建模框架，其框架的完備性與正確性無法保證。基於智慧合約的隱私性，安全性和功能性可以使用這種方法來檢驗。Hydra，就是基於形式化建模的一個框架，該框架鼓勵開發者和使用者誠實地披露智慧合約中的錯誤和漏洞，它的設計是基於漏洞賞金的模式和NNVP程式設計。

5. 有限狀態機

有限狀態機是一種用來進行物件行為建模的工具，其作用主要是描述物件在它的生命週期內所經歷的狀態序列，以及如何響應來自外界的各種事件。智慧合約的執行也可以看作從一個狀態到下一個狀態的變遷。

這個方法的優點是思維導向簡單，將智慧合約抽象轉換為狀態機的形式，易於操作，且具有圖形介面。但是狀態定義的好壞，對智慧合約的驗證難易程度有很強相關性，合約複雜度過高也會導致狀態空間爆炸。對智慧合約的安全性，語義一致性校驗一般會使用這種方式。

業界一般的工具介紹如下：

• Contract Larva, 這個工具可以驗證智慧合約執行時的安全狀況，它目前只支援以太坊的 Solidity。
• VeriSol，這個工具支援對智慧合約語義的一致性進行形式化檢測，具體原理是使用訪問控制策略檢查狀態機工作流。
• FSolidM，這個工具可以自動生成以太坊智慧合約程式碼，並且帶有圖形畫介面，介面上支援將智慧合約設計為有限狀態機的形式並進行驗證。
• SPIN，這個工具可以檢測一個有限狀態系統是否滿足PLTL公式以及其他一些性質，包括是否有迴圈或可達性，它是一種顯式模型檢測工具。

6. 著色Petri網

Petri網是 ２０世紀 ６０年代由 Carl Adam Petri發 明的，適合於描述非同步的、併發的系統模型。所謂的著色Petri網就是在原有Petri網的基礎上加入了顏色集和模型宣告等元素，藉此可以表達更復雜的型別資訊。這種方式的優點是基於已有的Petri網模型，進行形式化驗證，具有良好的語義描述且具有圖形介面。但是當智慧合約邏輯較為複雜時，可能會導致可達圖生成難度增加，狀態空間爆炸等一系列問題。對於智慧合約的安全性，功能性驗證可以選擇此種方式。

當前技術應用的問題與展望

智慧合約的形式化驗證雖然已經有了一些成果和進展，但是這個領域還只是剛剛開始，離發展完備還有很大的距離，在商用過程中可能還存有下列問題：

• 易用性問題，形式化驗證通常需要具備專業知識的人員參與除錯，通常參與編寫智慧合約的人無法掌握這種技術來檢驗合約的正確性，需要花費大量金錢找專業人士花很長時間來完成檢測。自動化的對智慧合約進行形式化驗證也存在相關侷限性，一般情況下自動化程度越高的方法和框架，驗證智慧合約的性質越侷限。那將自動化形式化驗證方法擴大其普世性，並且支援非專業人士使用是急需解決的一個問題，從而才能立於形式化智慧合約方法的廣泛應用。
• 執行驗證的計算機的時間和記憶體的問題，形式化驗證透過探索儘可能多的執行狀態來發現錯誤和安全問題的可能性。在這種情況下，計算機執行時記憶體的上限和執行時間成為複雜程式和協議的基本限制。商用場景中對於使用者無法實施檢測出結果，需要長時間的等待和分析也會影響相關體驗。
• 正確性問題，當我們使用形式化驗證工具時，我們將程式碼、安全目標和操作環境透過工具在不同模型之間轉換，將高階語言轉換為形式化驗證工具支援的語言。工具的執行結果決定了形式化的準確性。但是，我們沒有一個好的工具檢查語言轉換或者模型轉換的準確性，缺乏對原始碼和目標語言的語義一致性需要進行嚴格的證明。對於任意的形式化系統，我們需要透過檢視人類的形式化程式碼來檢查正確性，因此這就限制了形式化驗證的一般適用性。
• 信任性問題，當前形式化驗證智慧合約的方法不斷增加，如何評判這種方式的準確度，其驗證的必要性，驗證合約的效率，都要靠開發人員憑藉其經驗，這種方式是不是和不用形式化驗證的測試沒有區別。而且當解決問題的成本超過問題本身時，我們也會質疑解決該問題是否有意義。

我們相信，隨著智慧合約應用的法律化、區塊鏈技術的發展，形式化驗證方法在智慧合約的全生命週期過程中，將會起到越來越重要的作用，得到更普遍的應用。華為區塊鏈服務基於上面的問題以及現有方式出發也打造了自己的形式化驗證工具，給出了其證明內容的正確性和必要性，並且提高其驗證效率，也是為業界使用自動化形式化驗證方式給出一條探索和思考的路徑。

1. Luu, L.; Chu, D.H.; Olickel, H.; Saxena, P.; Hobor, A. Making smart contracts smarter. In Proceedings of the ACM SIGSAC Conf. Comput. Commun. Securit, New York, NY, USA, 24–28 October 2016; pp. 254–269.

2. Atzei, N.; Bartoletti, M.; Cimoli, T. A Survey of Attacks on Ethereum Smart Contracts (SoK). In Proceedings of the Int. Conf. Princ. Secur. Trust, Uppsala, Sweden, 22–29 April 2017; pp. 164–186. 3. The DAO Attacked: Code Issue Leads to $60 Million Ether Theft. Available online: . com/dao-attacked-code-issue-leads-60-million-ether-theft/ (accessed on 17 June 2017).

3. Liu, J.; Liu, Z.T. A Survey on Security Verification of Blockchain Smart Contracts. IEEE Access 2019, 7, 77894–77904. [CrossRef]

4. 王璞巍，楊航天，孟佶，等．面向合同的智慧合約的形式化定義及參考實現［Ｊ］．軟體學報，２０１９，３０（９）：２６０８－２６１９．

5. 胡凱，白曉敏，等．智慧合約的形式化驗證方法［Ｊ］．資訊保安研究，２０１６，２（１２）：１０８０－１０８９．