智能合約安全綜述

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

智能合約安全綜述

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

（中南民族大學(xué)計(jì)算機(jī)科學(xué)學(xué)院，湖北 武漢 430074）

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

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

1 引言

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

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

2 智能合約運(yùn)行機(jī)制

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

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

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

Figure 1 Operating mechanism of smart contract

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

2.1 Ethereum智能合約

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

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

2.2 Hyperledger Fabric智能合約

Hyperledger Fabric智能合約被稱為Chaincode（鏈上代碼）。它有6個(gè)狀態(tài)，分別是Install、Instantiate、Invocable、Upgrade、Deinstantiate和Uninstall。Install表示鏈上代碼部署到區(qū)塊鏈上。Instantiate表示智能合約進(jìn)行初始化。Invocable表示經(jīng)過初始化后的智能合約進(jìn)入被調(diào)用的狀態(tài)。聯(lián)盟鏈跨多家企業(yè)、地區(qū)，合約很難保持一致的版本，因而每個(gè)合約都有版本號(hào)，Upgrade表示版本升級(jí)。Deinstantiate和Uninstall對(duì)應(yīng)智能合約離鏈。6個(gè)狀態(tài)之間的關(guān)系是Install→Instantiate→Invocable→Upgrade→Deinstantiate→Uninstall。Hyperledger Fabric中智能合約運(yùn)行機(jī)制[13-14]如圖3所示。

表1 3個(gè)智能合約平臺(tái)分析

圖2 Ethereum智能合約運(yùn)行機(jī)制

Figure 2 Operating mechanism of Ethereum smart contract

Hyperledger Fabric智能合約運(yùn)行機(jī)制包含如下7個(gè)步驟。

1) 應(yīng)用程序或者命令行通過RPC請(qǐng)求向背書節(jié)點(diǎn)發(fā)起鏈上代碼的調(diào)用請(qǐng)求，背書節(jié)點(diǎn)再轉(zhuǎn)發(fā)給鏈上代碼執(zhí)行，應(yīng)用程序不能直接與鏈上代碼通信。調(diào)用之前，應(yīng)用程序?qū)⒕帉懞途幾g完的智能合約打包上傳、部署到背書節(jié)點(diǎn)。

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

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

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

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

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

圖3 Hyperledger Fabric智能合約運(yùn)行機(jī)制

Figure 3 Operating mechanism of Hyperledger Fabric smart contract

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

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

2.3 EOS智能合約

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

EOS智能合約運(yùn)行機(jī)制包含如下4個(gè)步驟。

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

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

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

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

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

3 智能合約鏈上安全

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

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

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

圖4 EOS智能合約運(yùn)行機(jī)制

Figure 4 Operating mechanism of EOS smart contract

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

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

3.2 代碼安全

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

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

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

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

3.3 安全性分析

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

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

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

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

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

4 智能合約鏈外安全

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

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

圖5 Oracle代理機(jī)制

Figure 5 Proxy mechanism of Oracle

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

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

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

4.1 基于硬件Oracle

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

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

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

4.2 基于軟件Oracle

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

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

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

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

4.3 基于共識(shí)Oracle

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

5 結(jié)束語

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

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

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

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

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

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

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

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

隨著研究方法的改善和研究技術(shù)的成熟，以上5點(diǎn)研究將會(huì)得到更好發(fā)展，必將對(duì)智能合約的發(fā)展產(chǎn)生深遠(yuǎ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] 付夢(mèng)琳, 吳禮發(fā), 洪征, 等. 智能合約安全漏洞挖掘技術(shù)研究[J]. 計(jì)算機(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ò)與信息安全學(xué)報(bào), 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] 周學(xué)峰, 趙梓皓. 解析計(jì)算法律學(xué)[J]. 北京：中國計(jì)算機(jī)學(xué)會(huì)通訊, 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ò)與信息安全學(xué)報(bào), 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] 薛銳, 吳迎, 劉牧華, 等. 可驗(yàn)證計(jì)算研究進(jìn)展[J]. 中國科學(xué): 信息科學(xué), 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

國家自然科學(xué)基金（61272497）；湖北省自然科學(xué)基金（BZY18001）；中央高校攻關(guān)計(jì)劃專項(xiàng)基金（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ò)與信息安全學(xué)報(bào), 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-），男，河北石家莊人，博士，中南民族大學(xué)教授，主要研究方向?yàn)閰^(qū)塊鏈、安全協(xié)議和形式化方法。

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

劉琴（1990-），女，湖北黃岡人，中南民族大學(xué)碩士生，主要研究方向?yàn)橹悄芎霞s代碼與法律合約的一致性。

王瀟瀟（1996-），女，安徽宿州人，中南民族大學(xué)碩士生，主要研究方向?yàn)閰^(qū)塊鏈共識(shí)機(jī)制。

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

王德軍（1974-），男，湖北荊門人，博士，中南民族大學(xué)副教授，主要研究方向?yàn)榘踩珔f(xié)議和形式化方法。