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

智能合約安全綜述

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

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

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

區(qū)塊鏈；智能合約；鏈上安全；鏈外安全；安全性分析

1 引言

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

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

2 智能合約運行機制

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

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

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

Figure 1 Operating mechanism of smart contract

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

2.1 Ethereum智能合約

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

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

2.2 Hyperledger Fabric智能合約

Hyperledger Fabric智能合約被稱為Chaincode（鏈上代碼）。它有6個狀態(tài)，分別是Install、Instantiate、Invocable、Upgrade、Deinstantiate和Uninstall。Install表示鏈上代碼部署到區(qū)塊鏈上。Instantiate表示智能合約進行初始化。Invocable表示經(jīng)過初始化后的智能合約進入被調(diào)用的狀態(tài)。聯(lián)盟鏈跨多家企業(yè)、地區(qū)，合約很難保持一致的版本，因而每個合約都有版本號，Upgrade表示版本升級。Deinstantiate和Uninstall對應(yīng)智能合約離鏈。6個狀態(tài)之間的關(guān)系是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) 應(yīng)用程序或者命令行通過RPC請求向背書節(jié)點發(fā)起鏈上代碼的調(diào)用請求，背書節(jié)點再轉(zhuǎn)發(fā)給鏈上代碼執(zhí)行，應(yīng)用程序不能直接與鏈上代碼通信。調(diào)用之前，應(yīng)用程序?qū)⒕帉懞途幾g完的智能合約打包上傳、部署到背書節(jié)點。

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

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

4) 通過鏈上代碼和背書節(jié)點建立的RPC連接，轉(zhuǎn)發(fā)應(yīng)用程序調(diào)用的請求，鏈上代碼在執(zhí)行過程中和背書節(jié)點有多次的數(shù)據(jù)交互。

5) 鏈上代碼執(zhí)行完以后，調(diào)用背書節(jié)點的ESCC對模擬執(zhí)行的結(jié)果進行背書。

6) ESCC對模擬執(zhí)行進行簽名，返回背書結(jié)果。

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

Figure 3 Operating mechanism of Hyperledger Fabric smart contract

7) 背書節(jié)點返回包含背書節(jié)點的背書結(jié)果給應(yīng)用程序，不再轉(zhuǎn)發(fā)給其他背書節(jié)點。

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

2.3 EOS智能合約

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

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

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

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

3) Cleos請求調(diào)用智能合約，服務(wù)器根據(jù)Action請求信息在Action處理函數(shù)集合副本中找到相對應(yīng)的智能合約代碼，并將其加載到內(nèi)存中執(zhí)行。

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

Cleos將一組Action封裝成Transaction數(shù)據(jù)包發(fā)送給服務(wù)器。一個Transaction代表一個事務(wù)，一個Transaction中包含一個或多個Action。為保證事務(wù)的原子性，事務(wù)內(nèi)的Action要么全部執(zhí)行，要么都不執(zhí)行。

3 智能合約鏈上安全

智能合約鏈上安全主要關(guān)注智能合約及其與區(qū)塊鏈內(nèi)部要素交互過程中的安全性，如智能合約架構(gòu)設(shè)計安全、代碼安全、運行安全等。下面從智能合約鏈上代碼的架構(gòu)設(shè)計安全（主要開發(fā)框架、設(shè)計模式）、代碼安全（代碼自身安全性）以及安全性分析3個方面進行總結(jié)歸納。

3.1 架構(gòu)設(shè)計安全

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

圖4 EOS智能合約運行機制

Figure 4 Operating mechanism of EOS smart contract

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

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

3.2 代碼安全

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

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

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

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

3.3 安全性分析

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

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

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

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

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

4 智能合約鏈外安全

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

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

圖5 Oracle代理機制

Figure 5 Proxy mechanism of Oracle

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

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

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

4.1 基于硬件Oracle

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

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

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

4.2 基于軟件Oracle

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

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

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

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

4.3 基于共識Oracle

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

5 結(jié)束語

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

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

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

1) 智能合約動態(tài)安全。目前，智能合約的安全性主要關(guān)注其靜態(tài)安全，較少關(guān)注動態(tài)安全（如智能合約執(zhí)行過程中的安全性）。智能合約安全應(yīng)該涵蓋靜態(tài)安全和動態(tài)安全。因而，智能合約動態(tài)安全是重要研究方向之一。

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

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

4) 智能合約開發(fā)技術(shù)、安全監(jiān)管標準不統(tǒng)一。智能合約平臺和監(jiān)管合約的標準主要由分散的區(qū)塊鏈應(yīng)用聯(lián)盟搭建，如2015年摩根大通、巴萊克等全球9大銀行聯(lián)手制定了區(qū)塊鏈支付標準和協(xié)議；2016年5月區(qū)塊鏈技術(shù)提供商Chain和第一資本、花旗銀行等金融機構(gòu)發(fā)布了區(qū)塊鏈方面的開放標準[55]，在智能合約框架方面實現(xiàn)了突破。雖然分散的標準都在建立，但是在全球?qū)用嫒狈σ粋€統(tǒng)一的技術(shù)開發(fā)標準，智能合約使用的兼容性不高，對于智能合約安全性的監(jiān)管受到極大挑戰(zhàn)。

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

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

[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] 付夢琳, 吳禮發(fā), 洪征, 等. 智能合約安全漏洞挖掘技術(shù)研究[J]. 計算機應(yīng)用, 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] 沈鑫，裴慶祺，劉雪峰 .區(qū)塊鏈技術(shù)綜述[J]. 網(wǎng)絡(luò)與信息安全學報, 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] 章峰, 史博軒, 蔣文保. 區(qū)塊鏈關(guān)鍵技術(shù)及應(yīng)用研究綜述[J]. 網(wǎng)絡(luò)與信息安全學報, 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）；中央高校攻關(guān)計劃專項基金（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]. 網(wǎng)絡(luò)與信息安全學報, 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-），男，河北石家莊人，博士，中南民族大學教授，主要研究方向為區(qū)塊鏈、安全協(xié)議和形式化方法。

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

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

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

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

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