智能合約安全綜述

孟博，劉加兵，劉琴，王瀟瀟，鄭旭睿，王德軍

智能合約安全綜述

孟博，劉加兵，劉琴，王瀟瀟，鄭旭睿，王德軍

（中南民族大學計算機科學學院，湖北 武漢 430074）

區塊鏈為構建社會價值傳遞和信任機制提供了一種新的技術。區塊鏈的快速發展促進了智能合約與人工智能、大數據、物聯網等技術的深入融合，其安全性受到重點關注。近幾年，區塊鏈與智能合約安全研究取得了較大進展，基于區塊鏈智能合約，對智能合約的運行機制、鏈上安全和鏈外安全的最新相關研究成果進行歸類、分析、比較、總結和討論，并展望了智能合約安全性的研究方向和趨勢。

區塊鏈；智能合約；鏈上安全；鏈外安全；安全性分析

1 引言

區塊鏈應用了密碼學、分布式存儲、共識機制、智能合約等技術，建立了一種新型的可量化的信任和激勵體系，大大提升了透明度，減少了信任風險，降低了成本，提高了效率，將改變整個社會價值傳遞的方式和信任機制，因而被認為是顛覆性的核心技術。區塊鏈技術的發展為智能合約提供了可信的執行環境，允許在不依賴第三方的情況下進行可信、可追蹤且不可逆的合約交易。智能合約作為區塊鏈的重要組成部分，旨在以信息化方式傳播、驗證和執行合同的談判或者履行計算機協議[1]。智能合約最早在1995年由SZABO提出[2]，起初被定義為一套以數字形式定義的承諾，包括合約參與方在智能合約上執行承諾協議，其設計初衷是希望將智能合約內置到物理實體中來創造靈活可控的智能資產。隨著區塊鏈的進一步發展，應用在區塊鏈上的智能合約被重新定義：智能合約是由事件驅動的、具有狀態的、運行在一個可復制和共享的賬本上且能夠保管賬本上資產的程序。智能合約的普及和大規模的應用，必須滿足安全性、一致性、完整性、原子性等屬性，其中，安全性是一個非常關鍵的屬性。

智能合約安全分為鏈上安全和鏈外安全，其中，鏈上安全重點關注智能合約架構設計安全和代碼安全等，鏈外安全重點關注智能合約與鏈外數據交互時的安全（在本文，跨鏈數據被統稱作鏈外數據）。雖然文獻[3-7]對區塊鏈的發展狀況做了介紹和討論，但是較少關注智能合約安全方面的研究成果，因而有必要對智能合約安全性研究成果進行總結、分析和討論。本文首先介紹和分析了主流的Ethereum、Hyperledger Fabric和EOS平臺上的智能合約運行機制，進而對智能合約鏈上安全和鏈外安全的相關研究成果進行歸類、分析、比較、總結和討論，并對未來智能合約的發展及其安全性的研究方向進行了展望。

2 智能合約運行機制

智能合約是區塊鏈的核心構成要素（合約層），對區塊鏈技術的應用和普及具有重要意義。一方面，智能合約是區塊鏈的激活器，不僅為靜態的底層區塊鏈數據提供了靈活可編程機制和算法，而且為構建基于區塊鏈 2.0 和 3.0 的應用奠定了基礎；另一方面，智能合約的自動化和可編程特性使封裝分布式區塊鏈系統中各節點的復雜行為得以實現，這促進了區塊鏈技術在各類分布式系統中的應用。

智能合約是運行在可復制的共享區塊鏈數據賬本上的計算機程序，通過交易轉賬到特定的合約地址以觸發智能合約，接受、存儲和發送數據，以及控制和管理鏈上智能資產。智能合約由事件驅動，具有狀態和區塊鏈數據的一般特征，如分布式記錄、存儲和驗證，不可篡改和不可偽造等。智能合約運行機制[8]如圖1所示。

通常情況下，智能合約經各方認可后，首先以程序代碼的形式附著在未經驗證的區塊上，然后，經P2P網絡傳播和節點驗證后添加到區塊鏈上的特定區塊中。智能合約封裝了預定義的若干狀態和轉換規則、觸發合約執行的情景（如到達特定時間或發生特定事件等）及相應的響應規則。區塊鏈可實時監控智能合約的狀態，并在核查數據源、確認滿足特定觸發條件后激活并執行合約。目前，主流的3個智能合約平臺有Ethereum、Hyperledger Fabric和EOS。對包含圖靈完備智能合約的Ethereum、針對機構用戶進行多方授權交易的Hyperledger Fabric，以及面向高性能互聯網應用的EOS的主要特點[9-10]進行分析，如表1所示。

Figure 1 Operating mechanism of smart contract

Ethereum秉持開放的理念，采用公有鏈形式。區塊鏈系統中每一個節點都可讀取、任何節點都能發送交易（transaction）且交易能夠獲得有效確認，任何節點都能參與其中的共識過程，這導致采取公有鏈形式的Ethereum智能合約平臺在一定程度上性能較低。EOS雖然同樣采取公有鏈形式，但是EOS依賴已經在壓力測試中展現出每秒1萬至10萬筆交易處理能力的石墨烯技術，且EOS使用并行化拓展網絡，因而EOS的吞吐量在Ethereum的基礎上有了很大提升。但公有鏈也有積極意義：規則可信，規則公開透明可預見，保護用戶免受開發者的影響；訪問門檻低，成為系統節點的任何用戶都可以訪問，而在聯盟鏈中，節點需要得到許可搭建應用。Hyperledger Fabric采取了聯盟鏈的形式，只有獲得特定許可的節點才能接入網絡，也只有特定的節點才能從事記賬參與共識算法，為交易處理的低延遲和吞吐量大幅增長提供了可能。下面分別對Ethereum、Hyperledger Fabric和EOS智能合約運行機制進行分析和討論。

2.1 Ethereum智能合約

Ethereum智能合約是區塊鏈2.0中的智能合約的典型代表之一。Ethereum智能合約存在兩種賬戶：外部賬戶和合約賬戶。外部賬戶既可以通過創建和使用其私人密鑰簽署一項交易，也可以向其他外部賬戶或合約賬戶發送消息。兩個外部賬戶之間的消息只是一種價值轉移，但從一個外部賬戶到合約賬戶的消息會激活合約的代碼，使它能夠執行各種操作（如轉移代幣、寫入內存、生成代幣、執行計算、創建合約等）。與外部賬戶不同，合約賬戶不能自行啟動新的交易。相反，合約賬戶只能根據它們收到的其他交易（從外部賬戶或從其他合約賬戶）進行交易。因而，在Ethereum區塊鏈上發生的任何操作都是由外部控制賬戶的交易引起的。Ethereum智能合約運行機制[11-12]如圖2所示。

交易是連接外部世界與以太坊內部狀態的橋梁。交易（包括調用和合約創建）總是由外部賬戶啟動并提交給區塊鏈的，不同賬戶之間發生的交易使Ethereum智能合約從一個狀態轉移到另一個狀態。首先，外部賬戶（或者Ethereum-Wallet）將編譯好的智能合約通過RPC接口部署到Geth節點上。然后，當外部賬戶發起交易時，外部賬戶通過RPC接口將要寫入區塊中的信息發送到Geth節點（即區塊鏈節點），Geth節點會將數據發送到本地虛擬機（EVM）中進行運算，得到運算結果后進行相互驗證（區塊鏈共識），驗證成功的結果將寫入區塊鏈中。

2.2 Hyperledger Fabric智能合約

Hyperledger Fabric智能合約被稱為Chaincode（鏈上代碼）。它有6個狀態，分別是Install、Instantiate、Invocable、Upgrade、Deinstantiate和Uninstall。Install表示鏈上代碼部署到區塊鏈上。Instantiate表示智能合約進行初始化。Invocable表示經過初始化后的智能合約進入被調用的狀態。聯盟鏈跨多家企業、地區，合約很難保持一致的版本，因而每個合約都有版本號，Upgrade表示版本升級。Deinstantiate和Uninstall對應智能合約離鏈。6個狀態之間的關系是Install→Instantiate→Invocable→Upgrade→Deinstantiate→Uninstall。Hyperledger Fabric中智能合約運行機制[13-14]如圖3所示。

表1 3個智能合約平臺分析

圖2 Ethereum智能合約運行機制

Figure 2 Operating mechanism of Ethereum smart contract

Hyperledger Fabric智能合約運行機制包含如下7個步驟。

1) 應用程序或者命令行通過RPC請求向背書節點發起鏈上代碼的調用請求，背書節點再轉發給鏈上代碼執行，應用程序不能直接與鏈上代碼通信。調用之前，應用程序將編寫和編譯完的智能合約打包上傳、部署到背書節點。

2) 背書節點檢查對應的鏈上代碼是否啟動。檢查的方法是查看本地維護的映射表中是否有指定的鏈上代碼名稱和版本的記錄。如果沒有相關的記錄，則通過Docker的API發起創建或者啟動容器的命令。

3) Docker服務器根據API的命令啟動鏈上代碼容器，并建立和背書節點的RPC接口。如果背書節點接收到請求以后檢查鏈碼容器已經啟動，則直接跳過第2)步和第3)步。

4) 通過鏈上代碼和背書節點建立的RPC連接，轉發應用程序調用的請求，鏈上代碼在執行過程中和背書節點有多次的數據交互。

5) 鏈上代碼執行完以后，調用背書節點的ESCC對模擬執行的結果進行背書。

6) ESCC對模擬執行進行簽名，返回背書結果。

圖3 Hyperledger Fabric智能合約運行機制

Figure 3 Operating mechanism of Hyperledger Fabric smart contract

7) 背書節點返回包含背書節點的背書結果給應用程序，不再轉發給其他背書節點。

如果涉及交易，在整個交易流程中，鏈上代碼只參與業務邏輯模擬執行的過程，后續的交易排序和驗證分別由排序服務和記賬節點完成。應用程序自由選擇背書節點發起請求，只要最終生成的交易滿足背書策略即可。

2.3 EOS智能合約

EOS智能合約由一系列Action組成。每個Action代表一項合約條款，實現該條款中的具體規則。在智能合約部署階段，編譯好的智能合約代碼通過客戶端（Cleos）發送到服務器，由服務器部署在區塊鏈上，隨后其他用戶調用、執行該智能合約。在智能合約調用階段，由客戶端通過Cleos命令發送Action請求給服務器。每個服務器都有一個Action處理函數集合副本，當客戶端發起Action請求后，服務器根據Action請求信息，在區塊鏈上找到對應的智能合約代碼，并將代碼加載到內存中，然后執行。服務器會在本地運行Action處理函數，并相互校驗結果，最后將執行結果返回給客戶端。EOS智能合約運行機制[15-16]如圖4所示。

EOS智能合約運行機制包含如下4個步驟。

1) Cleos將編寫好的智能合約代碼上傳到區塊鏈上。

2)客戶端請求部署智能合約，解析智能合約名稱和Action名稱。

3) Cleos請求調用智能合約，服務器根據Action請求信息在Action處理函數集合副本中找到相對應的智能合約代碼，并將其加載到內存中執行。

4)服務器在本地執行Action處理函數并相互校驗結果后，將執行得到的結果返回給客戶端。

Cleos將一組Action封裝成Transaction數據包發送給服務器。一個Transaction代表一個事務，一個Transaction中包含一個或多個Action。為保證事務的原子性，事務內的Action要么全部執行，要么都不執行。

3 智能合約鏈上安全

智能合約鏈上安全主要關注智能合約及其與區塊鏈內部要素交互過程中的安全性，如智能合約架構設計安全、代碼安全、運行安全等。下面從智能合約鏈上代碼的架構設計安全（主要開發框架、設計模式）、代碼安全（代碼自身安全性）以及安全性分析3個方面進行總結歸納。

3.1 架構設計安全

智能合約架構設計安全分為開發框架安全和設計模式安全。智能合約在開發過程中采用安全的開發框架[17-20]以及設計模式[21]，使其可以按序、安全、可驗證地實施特定的流程，為智能合約正確性和安全性提供支持和保障，防止受到拒絕服務攻擊、重入攻擊等，并且可以獲得代碼可重用性和可擴充性，縮短開發周期，提高開發質量。

圖4 EOS智能合約運行機制

Figure 4 Operating mechanism of EOS smart contract

針對開發框架安全，2018年，Kalra等[17]設計和實現了一種基于抽象解釋和符號執行的智能合約自動形式化驗證框架——Zeus。Zeus首先將高級語言編寫的智能合約作為輸入，并由用戶生成模板的正確性和公平性標準。將合約和策略規范轉化為低級中間表示形式，編碼執行語義正確解釋合約的行為。然后，對中間表示形式進行靜態分析，確定需要由斷言驗證的地方。最后，將斷言驗證后的中間表示形式提供給驗證引擎，確保智能合約的安全性。同年，Sánchez等[18]提出Raziel框架，將安全多方計算和攜帶證明的代碼相結合，實現了智能合約的隱私性、正確性和可驗證性。Raziel提供一個編程框架，用來開發實現具有隱私性的智能合約并且進行形式化驗證隱私性，分別通過安全多方計算和攜帶證明的代碼來實現和驗證隱私性。但是，此方法既增加了智能合約代碼量，又增加了計算和存儲方面的開銷，從而對整體性能和可伸縮性產生影響。同年，Dargaye等[19]提出基于Coq實現的Cyberlogic信任管理框架。此框架不僅可以根據自然語言生成形式化語言規則并驗證法律合約，而且可以將法律合約轉化為智能合約Solidity代碼。面向交易，2016年，Kosba等[20]提出Hawk——一種分布式的智能合約系統框架。Hawk中的編譯器使用加密原語（如零知識證明）將私有智能合約編譯為區塊鏈和用戶之間安全的加密協議，進而實現交易隱私性。

基于開發設計模式安全，2018年，W?hrer等[21]首先介紹了Ethereum和Solidity及其相關安全性，然后提出了檢查效果交互（CEI，checks-effect-interaction）、緊急停止（emergency stop）、減速帶（speed bump）、速率限制（rate limit）、互斥（mutex）和余額限制（balance limit）6種設計模式，可以處理開發智能合約過程中的典型安全問題和漏洞。檢查效果交互模式通過一定的代碼順序，在最后一步調用外部智能合約，阻止外部智能合約發動重復調用攻擊，解決惡意代碼劫持控制流的漏洞。緊急停止模式將緊急停止功能集成到智能合約代碼中，由認證方觸發以禁用某些敏感功能。減速帶模式通過延長執行敏感任務的智能合約的完成時間，解決短時間內某項任務請求執行頻率過高的問題。速率限制模式通過降低智能合約一段時間內的執行速率，緩解任務請求繁忙狀況，實現智能合約正常運行。互斥模式利用互斥死鎖阻止外部調用重新輸入調用方函數，防止重入攻擊。余額限制模式通過限制智能合約中風險資金的最高金額，降低智能合約受到攻擊后造成的金融風險。

3.2 代碼安全

智能合約代碼安全是智能合約安全的核心組成部分。智能合約代碼安全主要涉及類型安全、漏洞挖掘、語言安全、代碼靜態分析和法律合約與代碼一致性。下面從漏洞挖掘、語言安全和法律合約與代碼一致性3個方面進行總結歸納。

在漏洞挖掘方面，2019年，付夢琳等[22]對區塊鏈領域的知名開源軟件Dogecoin、Ripple、Litecoin、Dash、Ethereum-Wallet等，通過掃描工具和人工審計，在代碼層面發現高危安全漏洞 746 個，中危漏洞3 497 個。同年，Natoli等[23]引入區塊鏈異常（the blockchain anomaly）概念。區塊鏈異常不能中止提交的交易，可能出現Gas雙花等漏洞，對智能合約使用者造成嚴重后果。2017年，Atzei等[24]首先介紹了Ethereum平臺及Solidity語言的安全漏洞，進而將這些漏洞分為3個級別：Solidity、EVM和blockchain。Solidity級別的漏洞主要涵蓋調用不明確（call to unkown）、沒有足夠的Gas發送（gasless send）、異常障礙（exception disorder）、類型轉換（type cast）、重入攻擊（reentrancy）和保密（keeping secret）；EVM級別的漏洞主要包括immutable等類型的Bug、傳輸過程中網絡數據丟失（ether lost in transfer）和堆棧容量限制（stack size limit）等；Blockchain級別的漏洞主要涉及不可預測的狀態（unpredictable state）、產生隨機性（generating randomness）和時間限制（time constraint）。

在語言安全方面，2018年，Tonelli等[25]研究了12 000多個部署在Ethereum上的智能合約，介紹了智能合約語言Solidity開發合約時代碼的4種典型特征：合約聲明、地址聲明和映射、所有者數據管理和實現塊鏈地址之間的合約和交易的特定代碼的函數。基于以太坊，2018年，Grishchenko等[26]提出了Ethereum智能合約典型安全屬性的語義特征。智能合約的典型安全屬性主要包含調用完整性（call integrity）、原子性（atomicity）、可變賬戶狀態的獨立性（independence of mutable account state）以及交易環境獨立性（independence of transaction environment）。智能合約調用完整性可以防止重入攻擊和調用不明確等Bug；當智能合約不滿足原子性時，將出現不可預知異常（mishandled exceptions）等類型的Bug；當智能合約不滿足可變賬戶狀態的獨立性時，將出現交易順序依賴（transaction order dependency）和不可預測狀態等類型的Bug；當智能合約不滿足交易環境獨立性時，將出現時間戳依賴（timestamp dependency）、時間限制（time constraints）和產生隨機性等類型的Bug。

在法律合約與代碼一致性方面，2016年，Frantz等[27]首先使用Adico語言建模自然語言描述的制度規則、法規和法律條文的語義；然后，將其轉換成Solidity語言代碼。同年，Clack等[28]提出智能合約模板的概念，將智能合約定義為可自動執行的協議。智能合約模板包含法律條款和參數，其中，每個參數包含一個標識符、一個類型和一個可選的值。通過制定的法律條款和參數來實例化模板產生李嘉圖合約三元組[29]，然后生成智能合約代碼。2017年，周學峰等[30]提出對代碼規則進行法律控制，從而適用數字虛擬社會，主要存在兩種法律控制方法：一種方法是直接對代碼規則的設計提出要求，確保在數字虛擬社會中運行的規則與現實世界中適用的法律規則一致；另一種方法是不對代碼規則本身進行直接規制，而是通過對程序及其相關機構或主體進行規制，從而實現對代碼規則間接規制。

3.3 安全性分析

當前的智能合約研究處于初級階段，應用比較簡單，甚至是不夠智能的，智能合約還面臨可信和安全問題。已經開發好的智能合約也有可能會出現意想不到的錯誤，因而有必要對智能合約進行驗證和分析。對智能合約鏈上安全性進行分析可以從攜帶證明的智能合約、開發軟件驗證工具、形式化證明和零知識證明4方面進行研究。

在代碼中添加證明。1997年，Necula等[31]提出通過由不受信任的代碼生產者產生的攜帶證明的代碼（PCC，proof-carrying code），主機驗證代碼與已定義的安全策略的一致性，不需要使用加密技術和咨詢外部代理。基于Necula的工作，2018年，Thomas等[32]提出攜帶證明的智能合約（PCSC，proof-carrying smart contract）。PCSC將智能合約的形式化正確性證明存儲在鏈上，從而驗證者可以檢查智能合約的正確性。但PCSC會占用鏈上存儲空間，增加計算開銷。

開發軟件驗證工具。2016年，Luu等[33]開發了Oyente軟件工具。Oyente可以檢測智能合約EVM字節碼中的安全漏洞，但功能上具有局限性。同年，Bhargavan等[34]提出了一個分析和形式化驗證智能合約的框架，介紹了基于語言的驗證方法來驗證智能合約，提出了兩種基于F*語言的原型工具Solidity*、EVM*。Solidity*將Solidity語言編譯為F*語言，以此來驗證功能正確性和檢測運行期間的Bug；EVM*將EVM字節碼解碼成更簡潔的F*語言，以此來分析低級屬性，如完成調用或交易所需要的Gas范圍。但是這兩個工具不支持Solidity許多語法特征。

形式化建模與驗證。2018年，Bai等[35]使用Promela建模語言和形式化驗證工具（SPIN）驗證智能購物合約（SSC，smart shopping contract）的資金安全性和交易狀態可達性。由于SSC是有限狀態模型，通過對SSC建模和驗證，SPIN隨機生成合約的狀態，進而驗證SSC執行結果與商務購物合約預期結果的一致性。

零知識證明。2018年，Sánchez等[18]使用零知識證明使代碼使用者驗證代碼證明的正確性，無須泄露證據本身和智能合約代碼的實際信息。Zcash[36]是首個使用零知識證明的區塊鏈“加密貨幣”項目，目前最大的智能合約平臺Ethereum也在2017年的“拜占庭”分叉過程中引入了使用同態加密的零知識證明技術（zk-SNARK，zero knowledge succinct non-interactive arguments of knowledge）來保證智能合約交易雙方和交易金額的匿名性。

4 智能合約鏈外安全

當前區塊鏈的存儲空間有限，不能滿足所有鏈外數據存儲在鏈上的要求。一般情況下，將部分關鍵數據和計算結果存儲在鏈上，非關鍵數據和數據計算放在鏈外[37]，從而降低鏈上數據存儲量。智能合約和鏈外數據交互過程中的安全與智能合約的快速發展關系密切，因為智能合約需要訪問跨鏈數據和鏈外數據。智能合約與鏈外數據交互過程中的安全主要涉及鏈外數據的可信性[38-40]、不可否認性等安全屬性。

由于智能合約訪問鏈外數據異常復雜，目前主流的智能合約都不支持直接訪問鏈外數據，主要有兩種解決思路：Oracle[41]和RealityKeys[42]。其中，應用較為廣泛的是Oracle。Oracle是第三方服務，其主要任務是使智能合約訪問來自其他區塊鏈或者萬維網的數據，供智能合約使用。Oracle代理機制[43]如圖5所示。

圖5 Oracle代理機制

Figure 5 Proxy mechanism of Oracle

2018年，Xu等[44]根據使用類型將Oracle分為5類：軟件Oracle、硬件Oracle、入境Oracle、出境Oracle和基于共識的Oracle。軟件Oracle提取所需要的網絡信息并將其提供給智能合約，同時提供網絡信息的真實性證明；硬件Oracle可以提供通過傳感器數據的加密證據和防篡改機制，使設備在遭受破壞時無法操作，從而直接獲取來自物理世界的信息。硬件Oracle最大的挑戰是在不犧牲數據安全性的條件下傳遞數據；入境Oracle將外部世界的數據提供給智能合約；出境Oracle將智能合約數據發送到外部世界；只使用一個數據來源是不安全和不可靠的，因而為了避免出現被操縱現象，需要提供進一步的安全性，基于共識的Oracle通過使用不同的Oracle組合提供共識機制，保障數據的可信性和安全性。

2017年，Eberhardt等[45]提出了5種可行的鏈外模式（可單獨使用也可組合使用），目的在于將計算和數據放在鏈外，共有5種模式，分別是挑戰響應模式（challenge response pattern）、鏈外簽名模式（off-chain signatures pattern）、可尋址內容存儲模式（content-addressable storage pattern）、委托計算模式（delegated computation pattern）、低合約足跡模式（low contract footprint pattern）。挑戰響應模式在客戶端檢查區塊鏈智能合約狀態是否是Final態，客戶端可以在達到Final態時通知智能合約，這樣只需將計算結果存放在鏈上，而計算在鏈外進行。挑戰響應模式增加了鏈上交易的總量，同時需要各參與方配合。鏈外簽名模式由兩個參與者在鏈外對請求改變狀態的消息進行簽名，發送到智能合約后，智能合約驗證簽名，之后智能合約更新狀態。鏈外簽名模式無須引入系統信任，可以減輕系統負載，并且一旦發現惡意參與者，可以拒絕簽名并凍結資金。可尋址內容存儲模式將鏈外數據脫機存儲在內容可尋址存儲系統中，并將其引用存儲在智能合約中。使用智能合約的客戶端可以檢索引用，并在此基礎上檢索數據。然后，通過計算數據本身的地址，將其與存儲在智能合約中的引用進行比較，從而驗證數據的正確性。可尋址內容存儲模式可以降低鏈上存儲量，但是引入了第三方，因而其安全性依賴于第三方。委托計算模式將計算外包給不可信的鏈外第三方，生成執行計算的證據，在鏈上驗證執行計算的證明。委托計算模式提高了區塊鏈的吞吐量，但是需要簡單易用的鏈上驗證工具。低合約足跡模式減少鏈上交易的數量和規模。本地節點先執行條件檢查，只有在滿足條件的情況下才觸發鏈上檢查，從而最小化寫入和存儲信息。

本文主要從基于硬件Oracle、基于軟件Oracle和基于共識Oracle這3個方面來分析智能合約鏈外安全。

4.1 基于硬件Oracle

在硬件Oracle方面，獲取鏈外數據通常采用將硬件作為可信任的第三方中介來實現鏈外數據傳輸的方案。但此方案引入了第三方硬件，對硬件安全性和可靠性要求比較高。Zhang等[46]和Alder等[47]分別通過離鏈基礎設施（Core）以及適配器（Adapter）和可信硬件（Relay）作為中介來進行鏈外數據傳輸。

2016年，Zhang等[46]提出了一個面向以太坊的智能合約數據認證系統——TC（town crier）。TC作為智能合約和Web站點之間的橋梁，通過結合區塊鏈前端與Inter可信硬件SGX后端，將經過源身份驗證的鏈外數據提供給智能合約。TC包含4個部分：TC智能合約、用戶User智能合約、Enclave和中繼器Relay。TC智能合約部署在區塊鏈上，Enclave和中繼器Relay駐留在TC服務器上。TC智能合約為User智能合約提供一個API。Enclave只能通過Relay進行網絡連接訪問數據。Relay可以提供給Enclave 3個鏈外數據源：區塊鏈（主要是以太坊系統）、客戶端和Web數據。TC的工作流程分為5步：第1步，用戶提交User智能合約，通過User智能合約向TC智能合約發送獲取鏈外數據請求；第2步，TC智能合約將請求發送到Relay，通過Relay將請求進一步轉發到SGXEnclave；第3步，Enclave通過Relay查詢鏈外數據源并獲取鏈外數據；第4步，Enclave將獲得的數據轉化為基于數據報的區塊鏈數字簽名消息，并通過Relay發送給TC智能合約；第5步，TC智能合約把數據發送給User智能合約。TC系統的數據容易進行解析，但是，它要求Relay是一個受信任的第三方，因為它不受SGX的完整性保護。

2018年，Adler[47]給出面向Ethereum的Chainlink解決方案，使智能合約可以利用新創建的ChainlinkOracle與Off-chain系統進行安全通信。Chainlink應用分散的離鏈Oracle將鏈外數據導入鏈上智能合約。Chainlink解決方案包含4個部分：鏈上用戶User智能合約、ChainlinkOracle智能合約、離鏈基礎設施和適配器。Chainlink解決方案的工作流程分為6步：第1步，User智能合約向ChainlinkOracle智能合約發出鏈上請求，請求獲取鏈外數據，請求信息包含Oracle版本、所需資源數和其他重要屬性；第2步，ChainlinkOracle智能合約記錄這個事件并將此請求發送給Chainlink節點上的Core；第3步，Chainlink節點上的Core接收到請求后為Adapter配置路由；第4步，配置完路由后，Adapter執行獲取鏈外數據的請求，獲得鏈外數據并將數據返回到Core；第5步，Core將數據發送到ChainlinkOracle智能合約；第6步，ChainlinkOracle智能合約會把所有響應的數據進行處理并合并為一個響應數據包發送到User智能合約。此方案安全性依賴于Chainlink節點上的Core和Adapter，雖然通過形成內部網絡來分散應用程序，以檢測和處理數據的不一致性，但是引入了Core和Adapter，安全性依賴于第三方。

4.2 基于軟件Oracle

在軟件Oracle方面，獲取鏈外數據無須可信第三方，但是通常需要對通信協議進行更改，提供數據交互的證據來進行真實性驗證，因而在一定程度上增加了數據計算。同時，對協議進行更改將導致數據難以進行解析。文獻[48-51]通過修改TLS協議和對TLS協議進行擴展，以證明數據的不可否認性和真實性。Guarnizo等[52]通過采用TDS數據結構構建日志系統，以提供鏈外數據的真實性證明。

2014年，Voyiatzis等[48]對TLS協議進行更改，使用TLSNotary提供證明客戶端與服務器之間發生網絡流量交換的方法。該方法包括3個部分：Client（Auditee）、Server和Auditor。TLSNotary有兩個前提，分別是Auditor擁有ServerMACKey，Auditee擁有ClientEncryptionKey、ServerEncryptionKey和ServerMACKey。Client和Server進行TLS握手時，Client將Server返回的Response作為證據發送到Auditor，Auditor保留一部分Secret數據以防Client偽造Server返回的Response。在Client對Server返回的加密內容Response做出承諾后，Auditor向Client提供其保留的Secret數據，Client得以構造ServerMACKey。至此，Client可以進行TLS協議的解密和認證。但是，TLSNotary證明有局限性：TLSNotary僅支持TLS1.0和TLS1.1；TLSNotary指定使用弱哈希函數，如使用哈希函數MD5和SHA-1；TLSNotary只支持RSA密鑰交換，不提供轉發保密功能。

在Casey的工作基礎上，2017年，Ritzdorf等[49]提出基于TLS擴展的TLS-N的方法。該方法首先由服務器生成關于TLS會話內容的證據，然后在客戶端生成關于TLS會話內容的非交互式證明，接著將會話內容和證明發送到區塊鏈上的第三方或者智能合約進行驗證。該方法通過一個分散的區塊鏈Oracle，將Web上的內容安全傳輸到區塊鏈上，無須區塊鏈外的可信第三方，同時支持TLS1.3，是目前較為有效的獲取鏈外數據的方法。但是，此方法在證據生成過程中應用了MerkleTree[50]和SaltTree[51]，所以數據不容易被智能合約解析，同時TLS協議需要進行較大更改。

2018年，Guarnizo等[52]設計了一個實用的智能合約數據饋送（data feeds）服務系統——PDFS，能夠填補Oracle解決方案和傳輸層身份驗證的空白，為智能合約提供通過驗證的數據。該系統允許內容提供商將其Web實體與塊鏈實體無縫鏈接起來而不破壞TLS信任鏈或TLS堆棧，因此不需新的受信任方進行數據驗證。同時，內容提供者可以定義需要的數據格式，便于智能合約解析和使用。PDFS包含4個部分：鏈外的Content Provider、鏈上由Content Provider創建的Content智能合約、Contract Parties和Contract Parties部署的Relying智能合約。Content Provider產生防篡改數據結構（TDS，tamper-evident data structure），用來存儲Content Provider可以向外界提供的數據Entry。TDS更新時，Content Provider重新計算數據結構并將新的DataEntry添加到TDS中，然后將TDS根發送到Content智能合約，因而Content智能合約不需要存儲任何數據，僅僅保存TDS根。Content智能合約把TDS根和Membership證明存儲在鏈上。Content智能合約檢查TDS的更新，同時驗證更新僅僅是添加操作而不存在修改或刪除操作。PDFS工作流程：當Contract Parties調用獲取鏈外數據的方法，這個方法需要使用Content Provider的數據。Contract Parties先獲得由Content Provider產生的數據Entry和Membership證明，并將數據Entry和Membership證明作為調用方法的參數；然后，根據參數，Contract Parties驗證Content Provider是否產生過這兩個參數，同時Relying智能合約調用Content智能合約的Membership驗證方法以驗證身份。當數據Entry驗證通過后，Relying智能合約通過Content智能合約提供的TDS根獲取Content Provider提供的鏈外數據。此方法無須可信第三方，數據更容易被智能合約解析。

4.3 基于共識Oracle

基于共識的Oracle，Xu等[53]提出多重模型Oracle。一個可靠的多重模型Oracle，遵循博弈原理，有經濟激勵和懲罰措施，越多節點參與，其真實性越高。當數據發送到智能合約時，需要保證參與者節點無法知曉其他參與者的數據，智能合約從眾多數據中選擇最接近中位數的數據，如果是二元數據，則統計得票數據最多的數據。最后對提供正確數據的節點進行獎勵。除此之外，利用預測市場也可以獲取鏈外數據[54]，但是此方法責任方不明確，并且數據輸入依賴人工，數據質量不高。

5 結束語

區塊鏈技術的發展為智能合約提供了可信的執行環境，允許在不依賴第三方的情況下進行可信、可追蹤且不可逆的合約交易。智能合約的普及和大規模的應用，必須滿足安全性、一致性、完整性、原子性等屬性，其中，安全性受到重點關注。本文總結和分析了主流的Ethereum、Hyperledger Fabric和EOS平臺上的智能合約運行機制以及智能合約鏈上安全性和鏈外安全性的最新相關研究成果。針對智能合約鏈上安全性，主要總結和討論了架構設計安全和代碼安全。在架構設計安全方面，從平臺安全和模式安全兩個方面出發，介紹了開發過程中的智能合約開發框架安全和設計模式安全。在代碼安全方面，從漏洞挖掘、語言安全和法律合約與代碼一致性3個方面出發，概述了智能合約開發時的智能合約漏洞挖掘、開發語言安全以及法律合約與代碼一致性。

針對智能合約鏈外安全性，主要涉及智能合約與鏈外數據交互時的安全。Oracle充當代理機制與鏈外數據進行交互，重點關注了基于軟件Oracle的TLSNotary方法、TLS擴展的TLS-N方法和PDFS系統等，總結了基于硬件Oracle的TC系統和Chainlink解決方案。另外，分析了基于共識的多重模型Oracle以及Oracle分類。

綜上所述，針對智能合約鏈上和鏈外安全性的方案，不同研究團體對于其安全性形成了各自不同的特色，并且取得了許多重要成果。從智能合約發展趨勢來看，今后一段時間內的安全性研究將呈現以下特點。

1) 智能合約動態安全。目前，智能合約的安全性主要關注其靜態安全，較少關注動態安全（如智能合約執行過程中的安全性）。智能合約安全應該涵蓋靜態安全和動態安全。因而，智能合約動態安全是重要研究方向之一。

2) 法律合約與智能合約代碼的一致性。將法律合約與智能合約結合，必將改變傳統的庭審模式。但是，有時會出現某項法律規則的法律含義與其實際適用含義不一致的現象，這給法律規則的代碼化帶來了困難。目前法律合約與智能合約的研究主要涉及：如何由法律合約生成智能合約代碼并保證其一致性；如何驗證法律合約和智能合約代碼的一致性。這兩個問題將成為智能合約未來研究熱點。

3) 區塊鏈鏈上存儲空間有限。智能合約與鏈外數據交互驗證數據安全性時往往會導致鏈上負載增加，進一步壓縮了鏈上存儲空間，從而造成智能合約平臺吞吐量降低，交易延遲提高，不利于智能合約的發展。因而，如何在驗證鏈外數據安全性的同時不增加鏈上負載可作為今后研究工作的一個重點。

4) 智能合約開發技術、安全監管標準不統一。智能合約平臺和監管合約的標準主要由分散的區塊鏈應用聯盟搭建，如2015年摩根大通、巴萊克等全球9大銀行聯手制定了區塊鏈支付標準和協議；2016年5月區塊鏈技術提供商Chain和第一資本、花旗銀行等金融機構發布了區塊鏈方面的開放標準[55]，在智能合約框架方面實現了突破。雖然分散的標準都在建立，但是在全球層面缺乏一個統一的技術開發標準，智能合約使用的兼容性不高，對于智能合約安全性的監管受到極大挑戰。

5) 目前智能合約應用邏輯是根據已有場景的“if-then”類型的條件響應預定義規則，可以滿足當前交易自動化和數據處理的需求。但是未來智能合約應當做到根據未知場景做“what-if-then”推理演算、計算實驗和一定程度的自主決策，實現由“自動化合約”向“智能合約”的轉變。而在此過程中，智能合約推理自身代碼、開發安全性，以及針對推理做出相應的智能決策應當受到重點關注。

隨著研究方法的改善和研究技術的成熟，以上5點研究將會得到更好發展，必將對智能合約的發展產生深遠影響。

[1] WIKIPEDIA. Smart contract[EB].

[2] SZABO N. Formalizing and securing relationships on public networks[J]. First Monday, 1997, 2(9).

[3] OUADDAH A, ABOU E A, AIT O A. Fair-access: a new blockchain-based access control framework for the Internet of things[J]. Security and Communication Networks, 2016, 9(18): 5943-5964.

[4] ZHENG Z, XIE S, DAI H, et al. An overview of blockchain technology: architecture, consensus, and future trends[C]//2017 IEEE International Congress on Big Data. 2017: 557-564.

[5] LI X, JIANG P, CHEN T, et al. A survey on the security of blockchain systems[J]. Future Generation Computer Systems, 2017, 10(8): 274-287.

[6] YLI-HUUMO J, KO D, CHOI S, et al. Where is current research on blockchain technology —a systematic review[J]. PloS one, 2016, 11(10).

[7] ZHENG Z, XIE S, DAI H N, et al. Blockchain challenges and opportunities: a survey[J]. International Journal of Web and Grid Services, 2018, 14(4): 352-375.

[8] DINH T A, WANG J, CHEN G, et al. Blockbench: a framework for analyzing private blockchains[C]//The 2017 ACM International Conference on Management of Data. New York: ACM, 2017: 1085-1100.

[9] BARTOLETTI M, POMPIANU L. An empirical analysis of smart contracts: platforms, applications, and design patterns[C]// International Conference on Financial Cryptography and Data Security. Berlin: Springer, 2017: 494-509.

[10] ZHENG Z, XIE S, DAI H N, et al. Blockchain challenges and opportunities: a survey[J]. International Journal of Web and Grid Services, 2018, 14(4): 352-375.

[11] WOOD G. Ethereum: a secure decentralised generalised transaction ledger[J]. Ethereum Project Yellow Paper, 2014, 151: 1-32.

[12] BOGNER A, CHANSON M, MEEUW A. A decentralised sharing app running a smart contract on the ethereum block-chain[C]//The 6th International Conference on the Internet of Things. New York: ACM, 2016: 177-178.

[13] ANDROULAKI E, BARGER A, BORTNIKOV V, et al. Hyperledger Fabric: a distributed operating system for permissioned block-chains[C]//The Thirteenth EuroSys Conference. New York: ACM, 2018: 30.

[14] CACHIN C. Architecture of the hyperledger blockchain fabric[C]//Workshop on Distributed Cryptocurrencies and Consen-susLed- gers. 2016, 310.

[15] WANG S, YUAN Y, WANG X, et al. An overview of smart contract: architecture, applications, and future trends[C]//2018 IEEE Intelligent Vehicles Symposium (IV). 2018: 108-113.

[16] LI J, TANG J, ZHANG J, et al. Eos: expertise oriented search using social networks[C]//The 16th international conference on World Wide Web. 2007: 1271-1272.

[17] KALRA S, GOEL S, DHAWAN M, et al. Zeus: analyzing safety of smart contracts[C]//The 25th Annual Network and Distributed System Security Symposium. 2018: 18-21.

[18] SáNCHEZ D C. Raziel: private and verifiable smart contracts on blockchains[J]. arXiv preprint, arXiv: 1807.09484, 2018.

[19] DARGAYE Z, KIRCHNER F, TUCCI-PIERGIOVANNI S, et al. Towards secure and trusted-by-design smart contracts[C]//The 29th Francophone Days of Application Languages. 2018: 7-18.

[20] KOSBA A, MILLER A, SHI E, et al. Hawk: the blockchain model of cryptography and privacy-preserving smart contracts[C]//2016 IEEE symposium on security and privacy (SP). 2016: 839-858.

[21] W?HRER M, ZDUN U. Smart contracts: security patterns in the Ethereum ecosystem and solidity[C]//2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE). 2018: 2-8.

[22] 付夢琳, 吳禮發, 洪征, 等. 智能合約安全漏洞挖掘技術研究[J]. 計算機應用, 2019, 39(7): 1959-1966.

FU M L, WU L F, HONG Z, et al. Research on smart contract security vulnerability mining technology[J]. Journal of Computer Applications, 2019, 39 (7): 1959-1966.

[23] NATOLI C, GRAMOLI V. The blockchain anomaly[J]. arXiv preprint, arXiv:1605.05438, 2016.

[24] ATZEI N, BARTOLETTI M, CIMOLI T. A survey of attacks on Ethereum smart contracts (SOK)[M]//Principles of Security and Trust. 2017: 164-186.

[25] TONELLI R, DESTEFANIS G, MARCHESI M, et al. Smart contracts software metrics: a first study[J]. arXiv preprint, arXiv:1802.01517, 2018.

[26] GRISHCHENKO I, MAFFEI M, SCHNEIDEWIND C. A semantic framework for the security analysis of Ethereum smart contracts[C]//International Conference on Principles of Security and Trust. Berlin: Springer, 2018: 243-269

[27] FRANTZ C K, NOWOSTAWSKI M. From institutions to code: towards automated generation of smart contracts[C]//2016 IEEE 1st International Workshops on Foundations and Applications of Self* Systems (FAS*W). 2016: 210-215.

[28] CLACK C D, BAKSHI V A, BRAINE L. Smart contract templates: foundations, design landscape and research directions[J]. arXivpre-print, arXiv:1608.00771, 2016.

[29] 沈鑫，裴慶祺，劉雪峰 .區塊鏈技術綜述[J]. 網絡與信息安全學報, 2016, 2(11): 11-20.

SHEN X，PEI Q Q，LIU X F. Survey of block chain[J]. Chinese Journal of Network and Information Security, 2016, 2(11): 11-20.

[30] 周學峰, 趙梓皓. 解析計算法律學[J]. 北京：中國計算機學會通訊, 2017: 43-51.

ZHOU X F, ZHAO Z H. Analysis of computational law[J]. Beijing: Communications of the CCF, 2017: 43-51

[31] NECULA G. Proof-carrying code[J]. Encyclopedia of Crypto- graphy & Security, 1996, 141(1):106-119.

[32] THOMAS D, PAUL G, MAURICE H, et al. Proof-carrying smart contracts[J]. Stevens Institute of Technology, 2018, 325-338.

[33] LUU L, CHU D H, OLICKEL H, et al. Making smart contracts smarter[C]//The 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016: 254-269.

[34] BHARGAVAN K, DELIGNAT-LAVAUD A, FOURNET C, et al. Formal verification of smart contracts: short paper[C]//The 2016 ACM Workshop on Programming Languages and Analysis for Security. New York: ACM, 2016: 91-96.

[35] BAI X, CHENG Z, DUAN Z, et al. Formal modeling and verification of smart contracts[C]//The 7th International Conference on Software and Computer Applications. Washington: ACM, 2018: 322-326.

[36] 章峰, 史博軒, 蔣文保. 區塊鏈關鍵技術及應用研究綜述[J]. 網絡與信息安全學報, 2018, 4(4): 22-29.

ZHANG F, SHI B X, JIANG W B. Review of key technology and its application of blockchain[J]. Chinese Journal of Network and Information Security, 2018, 4(4): 22-29.

[37] 薛銳, 吳迎, 劉牧華, 等. 可驗證計算研究進展[J]. 中國科學: 信息科學, 2015, 45(11): 1370-1388.

XUE R, WU Y, LIU M H, et al. Progress in verifiable computing[J]. China Science: Information Science, 2015, 45(11): 1370-1388.

[38] HARZ D. Trust and verifiable computation for smart contracts in permissionless blockchains[D]. KTH, School of Information and Communication Technology. 2017.

[39] TEUTSCH J, REITWIE?NER C. A scalable verification solution for blockchains[EB].

[40] ZYSKIND G. Efficient secure computation enabled by blockchain technology[D]. Massachusetts: Massachusetts Institute of Technology, 2016.

[41] AS S. Enabling data markets using smart contracts and multi-party computation[C]//Business Information Systems Workshops: BIS 2018 International Workshops. Berlin: Springer, 2019: 258.

[42] NEIDHARDT N, KOHLER C, NUTTGENS M. Cloud service billing and service level agreement monitoring based on blockchain[C]//EMISA. 2018: 65-69.

[43] MOLINA-JIMENEZ C, SOLAIMAN E, SFYRAKIS I, et al. On and off-blockchain enforcement of smart contracts[C]//European Conference on Parallel Processing. 2018: 342-354.

[44] XU X, PAUTASSO C, ZHU L, et al. The blockchain as a software connector[C]//2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA). 2016: 182-191.

[45] EBERHARDT J, TAI S. On or off the blockchain? Insights on off-chaining computation and data[C]//European Conference on Service-Oriented and Cloud Computing. 2017: 3-15.

[46] ZHANG F, CECCHETTI E, CROMAN K, et al. Town crier: an authenticated data feed for smart contracts[C]//The 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016: 270-282.

[47] ADLER J, BERRYHILL R, VENERIS A, et al. Astraea: a decentralized blockchain oracle[C]//2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communica-tions (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). 2018: 1145-1152.

[48] VOYIATZIS A G, WEIPPL E. Whom you gonna trust? a longi-tudinal study on TLS notary services[C]//Data and Applications Security and Privacy XXX: 30th Annual IFIP WG 11.3 Conference. 2016: 18-20.

[49] RITZDORF H, WüST K, GERVAIS A, et al. TLS-N: non-repudiation over TLS enabling ubiquitous content signing for disintermediation[J]. IACR ePrint Report, 2017, 578.

[50] JAKOBSSON M, LEIGHTON T, MICALI S, et al. Fractal Merkle tree representation and traversal[C]//Cryptographers’ Track at the RSA Conference. 2003: 314-326.

[51] XUE J, XU C, ZHANG Y, et al. DStore: a distributed cloud storage system based on smart contracts and blockchain[C]//International Conference on Algorithms and Architectures for Parallel Processing. 2018: 385-401.

[52] GUARNIZO J, SZALACHOWSKI P. PDFS: practical data feed service for smart contracts[J]. arXiv preprint, arXiv:1808.06641, 2018.

[53] XU X, PAUTASSO C, ZHU L, et al. The blockchain as a software connector[C]//2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA). 2016: 182-191.

[54] BANERJEE A. Blockchain technology: supply chain insights from ERP[M]//Advances in Computers. 2018: 69-98.

[55] FABIANO N. The internet of things ecosystem: the blockchain and privacy issues the challenge for a global privacy standard[C]//2017 International Conference on Internet of Things for the Global Community (IoTGC). 2017: 1-7.

Survey of smart contract security

MENG Bo, LIU Jiabing, LIU Qin, WANG Xiaoxiao, ZHENG Xurui, WANG Dejun

School of Computer Science, South-Central University for Nationalities, Wuhan 430074, China

Blockchain provides a new technology for building transmission and trust mechanism of social ralue. The rapid development of blockchain has promoted the deep integration of smart contract with artificial Intelligence, big data and internet of things, so its security has attracted attention. In recent years, researches on security of blockchain and smart contract have made great progress. Thus, based on smart contract on the blockchain, the related works on security of operating mechanism, on-chain smart contract security and off-chain security were classified, analyzed, compared, summarized and discussed. The hot issues of smart contract security in the future were forecasted.

blockchain, smart contract, on-chain security, off-chain security, security analysis

TP393

A

10.11959/j.issn.2096?109x.2020030

2019?09?03；

2019?12?19

孟博，mengscuec@gmail.com

國家自然科學基金（61272497）；湖北省自然科學基金（BZY18001）；中央高校攻關計劃專項基金（CZT20013）

The National Natural Science Foundation of China (61272497), The Natural Science Foundation of Hubei Province (BZY18001), The Key Research Funds for the Central Universities (CZT20013)

孟博, 劉加兵, 劉琴, 等. 智能合約安全綜述[J]. 網絡與信息安全學報, 2020, 6(3): 1-13.

MENG B, LIU J B, LIU Q, et al. Survey of smart contract security[J]. Chinese Journal of Network and Information Security, 2020, 6(3): 1-13.

孟博（1974-），男，河北石家莊人，博士，中南民族大學教授，主要研究方向為區塊鏈、安全協議和形式化方法。

劉加兵（1994-），男，湖北黃石人，中南民族大學碩士生，主要研究方向為區塊鏈智能合約、協議分析。

劉琴（1990-），女，湖北黃岡人，中南民族大學碩士生，主要研究方向為智能合約代碼與法律合約的一致性。

王瀟瀟（1996-），女，安徽宿州人，中南民族大學碩士生，主要研究方向為區塊鏈共識機制。

鄭旭睿（1996-），男，湖北武漢人，中南民族大學碩士生，主要研究方向為區塊鏈自我主權認證。

王德軍（1974-），男，湖北荊門人，博士，中南民族大學副教授，主要研究方向為安全協議和形式化方法。