趙淦森，謝智健，王欣明,4，何嘉浩，張成志，林成創(chuàng)，Ziheng Zhou,6，陳冰川,7，Chunming Rong

ContractGuard：面向以太坊區(qū)塊鏈智能合約的入侵檢測系統(tǒng)

趙淦森1,2,3，謝智健1,2,3，王欣明1,2,3,4,5，何嘉浩1,2,3，張成志5，林成創(chuàng)1,2,3，Ziheng Zhou1,3,6，陳冰川3,7，Chunming Rong8

（1. 華南師范大學計算機學院，廣東 廣州 510000；2.廣州市云計算安全與測評技術(shù)重點實驗室，廣東 廣州 510000；3. 華南師范大學唯鏈區(qū)塊鏈技術(shù)與應(yīng)用聯(lián)合實驗室，廣東 廣州 510000；4. 拉卡拉集團，北京 100080；5. 香港科技大學, 中國 香港 999077；6. VeChain Foundation Limited, Singapore 238463；7. 廣東財經(jīng)大學，廣東 廣州 510000；8. Stavanger University, Norway Stavanger 4036）

以太坊智能合約本質(zhì)上是一種在網(wǎng)絡(luò)上由相互間沒有信任關(guān)系的節(jié)點共同執(zhí)行的已被雙方認證程序。目前，大量的智能合約被用于管理數(shù)字資產(chǎn)，使智能合約成為黑客的重要攻擊對象。常見的攻擊方法是通過利用智能合約的漏洞來實現(xiàn)特定操作的入侵攻擊。ContractGuard是首次提出面向以太坊區(qū)塊鏈智能合約的入侵檢測系統(tǒng)，它能檢測智能合約的潛在攻擊行為。ContractGuard的入侵檢測主要依賴檢測潛在攻擊可能引發(fā)的異常控制流來實現(xiàn)。由于智能合約運行在去中心化的環(huán)境以及在高度受限的環(huán)境中運行，現(xiàn)有的IDS技術(shù)或者工具等以外部攔截形式的部署架構(gòu)不適合于以太坊智能合約。為了解決這些問題，通過設(shè)計一個嵌入式的架構(gòu)，實現(xiàn)了把ContractGuard直接嵌入智能合約的執(zhí)行代碼中，作為智能合約的一部分。在運行時刻，ContractGuard通過相應(yīng)的context-tagged無環(huán)路徑來實現(xiàn)入侵檢測，從而保護智能合約。由于嵌入了額外的代碼，ContractGuard一定程度上會增加智能合約的部署開銷與運行開銷，為了降低這兩方面的開銷，基于以太坊智能合約的特性對ContractGuard進行優(yōu)化。實驗結(jié)果顯示，可有效地檢測83%的異常行為，其部署開銷僅增加了36.14%，運行開銷僅增加了28.17%。

區(qū)塊鏈；以太坊智能合約；入侵檢測系統(tǒng)；異常檢測

1 引言

自比特幣[1]出現(xiàn)以來，區(qū)塊鏈技術(shù)作為分布式賬本技術(shù)中的一種形式，引起了廣泛的關(guān)注并被推廣應(yīng)用。區(qū)塊鏈系統(tǒng)中的參與者共同運行共識協(xié)議以維護和保護鏈上共享賬本的數(shù)據(jù)。區(qū)塊鏈在應(yīng)用過程中逐步超越了單純的記賬和支付，已經(jīng)擴展為允許以智能合約形式進行可編程交易的平臺級技術(shù)。以太坊智能合約[2]是一種可以由互不信任的網(wǎng)絡(luò)節(jié)點共同執(zhí)行的程序，該程序通過特定的共識協(xié)議以數(shù)字方式強制節(jié)點執(zhí)行：任何節(jié)點甚至智能合約的創(chuàng)建者均無法修改智能合約代碼、影響代碼執(zhí)行。

由于用戶委托智能合約來處理和轉(zhuǎn)讓有價值的資產(chǎn)，吸引了大量的黑客關(guān)注與大量的惡意攻擊。智能合約受到惡意攻擊往往導致比常規(guī)網(wǎng)絡(luò)系統(tǒng)上的攻擊更加嚴重的后果，因為智能合約一旦部署在區(qū)塊鏈上后不可更改，智能合約的管理者無法對智能合約維護以更正漏洞保護智能合約。以太坊上的智能合約已經(jīng)發(fā)生了許多有據(jù)可查的攻擊實例[3]。

在已有文獻中，靜態(tài)分析存在大量的研究工作，這些分析工具可以在智能合約部署之前進行漏洞檢測[4-11]。但是，相關(guān)的調(diào)研中目前尚沒有發(fā)現(xiàn)有文獻報道可以在智能合約部署后保護智能合約的相關(guān)安全研究成果和進展。

對于傳統(tǒng)系統(tǒng)而言，管理員早就認識到，即使開發(fā)人員盡了最大的努力來修復缺陷，漏洞仍然會存在。入侵檢測系統(tǒng)（IDS）[12]通常是保護已部署系統(tǒng)免受安全攻擊的主要手段。根據(jù)入侵檢測的方式，IDS分為基于簽名的IDS和基于異常的IDS[12]兩種類型。典型的基于異常的IDS是對動態(tài)程序行為與正常程序行為進行監(jiān)視，并在檢測到異常時發(fā)出警報。正常程序行為是通過機器訓練和分析來學習的。

本文提出了嵌入式的IDS架構(gòu)ContractGuard實現(xiàn)區(qū)塊鏈智能合約的安全防護，突破了智能合約在運行時無法獲得外在安全監(jiān)管和防護的限制。圖1展示了該系統(tǒng)的基本思路，IDS被嵌入智能合約中，作為智能合約的一部分與智能合約一起在虛擬機中運行。當內(nèi)嵌的IDS檢測到智能合約運行時的異常行為，其將回滾所有針對該智能合約狀態(tài)的更改，并向系統(tǒng)管理員發(fā)出警報。這項技術(shù)可以彌補因漏洞而帶來的損失。例如，在著名的The DAO事件中[13]，如果管理員應(yīng)用了本文所提出的ContractGuard技術(shù)來保護其智能合約，就可以防止該攻擊。該攻擊觸發(fā)了智能合約在內(nèi)部測試過程中未發(fā)現(xiàn)的異常控制流，即可重入控制流。同樣地，由于攻擊觸發(fā)了帶有異常的庫代碼，出現(xiàn)了異常的控制流，因此本文所提出的ContractGuard也可以防止奇偶校驗Multisig Wallet[14]事件的發(fā)生。實驗表明，本文所設(shè)計的ContractGuard可以在發(fā)生漏洞攻擊時為系統(tǒng)管理員提供有效的防御手段。

圖1 智能合約入侵檢測系統(tǒng)的基本思路

Figure 1 The idea of IDS for smart contract

一般而言，在部署和裝配IDS的情景下，區(qū)塊鏈系統(tǒng)有眾多的約束，使傳統(tǒng)IDS架構(gòu)并不適用于智能合約，原因如下。

1) 由于以太坊本質(zhì)上是一個去中心化的應(yīng)用平臺[2]，目前并無現(xiàn)成的技術(shù)架構(gòu)可以實現(xiàn)對一個動態(tài)的、開放的、去中心化的區(qū)塊鏈網(wǎng)絡(luò)進行邊界或主機的全覆蓋。因此，傳統(tǒng)的基于主機和基于網(wǎng)絡(luò)的IDS[12]技術(shù)均不適用。

2) 以太坊智能合約運行在被稱為以太坊虛擬機（EVM）的高度受限環(huán)境中，該環(huán)境缺乏眾多常見的功能，這些功能包括硬件寄存器[15]、調(diào)用堆棧遍歷[16]和事件鉤子[17]等，導致傳統(tǒng)的IDS實現(xiàn)方法在EVM中無法實現(xiàn)。此外，EVM規(guī)定了每個智能合約不能大于24 576 B，使智能合約在設(shè)計和實現(xiàn)上其功能和邏輯復雜度受到限制。

3) 智能合約在部署后不能進行修改，在運行時刻不受任何的外部管理和控制。簡單而言，智能合約一旦部署后，其不接受任何外部的管理和干預，包括代碼維護和補丁以及運行的終止和監(jiān)控等。傳統(tǒng)IDS架構(gòu)需要從外部對受保護對象進行監(jiān)測、獲取運行狀態(tài)以及對其運行進行干預，明顯不適用于智能合約的情景。

4) 以太坊的運行模型與傳統(tǒng)系統(tǒng)的運行模型存在著本質(zhì)上的區(qū)別，特別是在成本和性能方面。常規(guī)IDS優(yōu)化的目標是提升運行效率、提高響應(yīng)速度。然而，對于以太坊智能合約來說，執(zhí)行時間是無關(guān)緊要的，重要的是執(zhí)行所需要的Gas開銷[18]，這部分開銷主要是部署和運行時產(chǎn)生的，因此，這需要以成本為導向的開銷優(yōu)化，這點與常規(guī)IDS優(yōu)化思路是不同的。

基于區(qū)塊鏈平臺，本文提出了嵌入智能合約代碼中的基于異常的IDS架構(gòu)ContractGuard。ContractGuard作為區(qū)塊鏈上第一個基于異常的IDS，其以嵌入式架構(gòu)實現(xiàn)在智能合約中融合原有的業(yè)務(wù)處理邏輯和新的安全防護邏輯于一體，解決上述在以太坊智能合約中存在的挑戰(zhàn)。與基于簽名的方法相比，ContractGuard的優(yōu)點是在檢測異常行為時不需要已知漏洞的簽名，并且可以發(fā)現(xiàn)未知攻擊。遵循許多現(xiàn)有的基于異常的IDS相關(guān)工作[15,19-20]，ContractGuard通過監(jiān)視智能合約控制流路徑以對執(zhí)行行為進行分類，通過鑒別異常控制流來發(fā)現(xiàn)潛在的攻擊行為和惡意行為。其中關(guān)鍵的思路是將以下兩種技術(shù)結(jié)合起來，以滿足對智能合約IDS有效性和效率的嚴格要求。

1) 上下文標記無環(huán)路徑分析：ContractGuard使用Ball和Larus[21]所提出的經(jīng)典算法來高效索引和分析程序內(nèi)無環(huán)路徑。為了提高異常檢測的效率，ContractGuard將上下文調(diào)用添加到每個程序路徑上。由于EVM不提供直接遍歷調(diào)用棧的功能，ContractGuard引入了一種分析方案來檢測智能合約中的上下文調(diào)用。

2) 高效Gas的自適應(yīng)路徑集存儲：EVM中使用賬戶存儲開銷十分高昂。傳統(tǒng)的基于內(nèi)存的實現(xiàn)將會大量耗費Gas。因此，作為智能合約存儲（Storage）的替代品，ContractGuard自適應(yīng)地選擇3個數(shù)據(jù)結(jié)構(gòu)中的1個（嵌入式列表、嵌入式最小完美哈希表[22]和內(nèi)置映射）以優(yōu)化存儲成本。從本文實驗結(jié)果可得，使用ContractGuard帶來的額外開銷都是合理可行的。

值得注意的是，本文在EVM二進制代碼上實現(xiàn)了ContractGuard所有技術(shù)需求，開發(fā)實現(xiàn)了ContractGuard的原型。區(qū)塊鏈智能合約管理員可以使用ContractGuard來保護以太坊智能合約，而無須智能合約的Solidity源代碼。

為了驗證提出的設(shè)計，本文研究使用真實的以太坊智能合約進行了3組實驗。第一組實驗關(guān)注ContractGuard在Gas開銷和危險警報方面的實用性。本文對在以太坊主網(wǎng)上部署的8 314份智能合約上應(yīng)用ContractGuard實施安全防護（收集這些智能合約時主網(wǎng)塊高度為4 200 000，即2017年8月24日前），且收集到的智能合約至少有100筆交易。實驗結(jié)果表明，ContractGuard的平均部署開銷和運行開銷僅增加了36.14%和28.27%。第二組實驗通過將ContractGuard應(yīng)用于以太坊智能合約上發(fā)現(xiàn)的6個漏洞，以研究ContractGuard對安全威脅監(jiān)控和防護的有效性。該實驗的結(jié)果表明，ContractGuard能夠成功應(yīng)對所有這些攻擊行為。第三組實驗驗證ContractGuard運用在人工植入漏洞的智能合約上是否有效，實驗結(jié)果表明，ContractGuard能檢測到其中83%的漏洞。

從技術(shù)角度來看，本文作出了以下貢獻。

1) 本文對智能合約漏洞進行詳細研究，并提出了一種基于檢測異常控制流路徑的方法以抵御針對智能合約進行的惡意攻擊。

2) 本文提出了一個適用于區(qū)塊鏈智能合約技術(shù)要求的嵌入式IDS架構(gòu)，實現(xiàn)對智能合約運行時刻的監(jiān)測，識別因為惡意攻擊引起的異常控制流、發(fā)現(xiàn)入侵攻擊并回滾智能合約狀態(tài)，實現(xiàn)對智能合約在部署后的保護。

3) 本文對IDS的嵌入過程進行了優(yōu)化并開展了相應(yīng)的實驗。實驗結(jié)果顯示在以太坊智能合約上部署IDS是可行的。部署開銷和運行開銷被控制在一個合理的水平，嵌入的IDS可以在發(fā)現(xiàn)異常控制流時觸發(fā)警報。上述各項性能達到了理想的水平。

4) 本文證明ContractGuard可以擴展到現(xiàn)實生活中真實的智能合約，可以針對即使沒有源代碼的智能合約提供有效的防御，同時能夠有效地監(jiān)測到未知漏洞引起的異常攻擊。本文同時開展了實驗，實驗驗證ContractGuard可以高效檢測到現(xiàn)實漏洞以及實驗過程中人工植入的漏洞。

2 相關(guān)工作

2.1 智能合約分析與驗證

目前，在智能合約的相關(guān)文獻中，已經(jīng)提出了許多工具來驗證智能合約。這些工具可以根據(jù)底層技術(shù)進行分類，其中一些工具依賴程序分析來發(fā)現(xiàn)漏洞，包括Oyente[23]、Teether[4]、Gasper[5]，這些工具以及Grossman等在最近的工作[24]中使用符號執(zhí)行來挖掘是否存在路徑可以觸發(fā)已知的漏洞。Contract fuzzer[11]使用隨機發(fā)放來發(fā)現(xiàn)潛在的攻擊向量。其他的工作依賴于形式化驗證和定理證明。例如，Zeus[6]使用抽象解釋和帶約束的horn從句，MadMax[10]使用Datalog理論證明器，Grishchenko等[25]的工作則使用了F*定理證明器。

盡管這些工具可以檢測到智能合約中的漏洞，但僅使用它們還不足以保護智能合約程序的執(zhí)行。這些工具大多數(shù)旨在處理特定的已知漏洞，它們針對未知漏洞將顯得力不從心。與之相反，ContractGuard基于控制流異常檢測到的漏洞并不會受限于特定的已知模式。只要這些漏洞觸發(fā)了未在訓練中出現(xiàn)的控制流路徑，它就可以防御未知的漏洞。另外，作為在部署后使用的工具，ContractGuard補充了現(xiàn)有的部署前驗證工具。

2.2 執(zhí)行分析

除了控制流，執(zhí)行過程的其他方面也可以被分析，如數(shù)據(jù)流[30]或者動態(tài)不變性[31]。關(guān)于它們對保護智能合約程序有用性的研究留待將來的工作。

2.3 入侵檢測系統(tǒng)

傳統(tǒng)的入侵檢測系統(tǒng)可以分為基于簽名或者基于異常的入侵檢測。基于簽名的入侵檢測系統(tǒng)[32-33]嘗試識別具有可預先識別的入侵簽名來識別已知的入侵模式，而基于異常的入侵檢測系統(tǒng)假設(shè)入侵的性質(zhì)是不可知的，但是入侵會偏離訓練中描述的程序正常行為。基于簽名的入侵檢測系統(tǒng)通常更精確，因為它們利用特定的漏洞屬性來檢測攻擊。然而，它們僅適用于已知的漏洞。此外，盡管簽名數(shù)據(jù)庫不是傳統(tǒng)系統(tǒng)的主要關(guān)注點，但是對于入侵檢測系統(tǒng)來說，簽名數(shù)據(jù)庫很大，無法被存儲在智能合約中。這就是ContractGuard遵循基于異常的方法的原因之一。

現(xiàn)有的基于異常的入侵檢測系統(tǒng)使用不同的模型來定義受保護系統(tǒng)的行為。對于模型來說，主要有兩個維度：第一個維度是分析執(zhí)行信息，包括系統(tǒng)調(diào)用[19]、調(diào)用棧[16]、輸入數(shù)據(jù)/網(wǎng)絡(luò)數(shù)據(jù)包[19]和跳轉(zhuǎn)序列[16]；第二個維度是執(zhí)行信息如何被抽象成一個模型，除了簡單的序列模型，還提出了其他更復雜的模型，如Dyck模型[19]、跳轉(zhuǎn)滑動窗口模型[15]和路徑點模型[16]。ContractGuard通過新的上下文標記的非循環(huán)路徑模型增加了這一研究范圍。該模型旨在滿足保護以太坊智能合約程序的嚴格要求。

3 智能合約程序模型與監(jiān)控手段

3.1 以太坊智能合約程序模型

以太坊智能合約程序模型如圖2所示，以太坊智能合約程序由一個或多個部署了智能合約代碼實例的合約賬戶以及一個或多個擁有以太幣作為加密貨幣的用戶賬戶組成。用戶依靠客戶端與以太坊網(wǎng)絡(luò)進行交互，以太坊網(wǎng)絡(luò)由一群將交易打包到區(qū)塊鏈中的礦工維護。以下將從以太坊智能合約的程序架構(gòu)、調(diào)用模型和數(shù)據(jù)管理模型3個層面介紹。

3.1.1 程序架構(gòu)

以太坊智能合約大多使用類似Javescript的Solidity語言編寫[34]。Solidity語言是類型化的編程語言。在源碼層面，用Solidity編寫的合約類似于面向?qū)ο缶幊陶Z言中的類。智能合約可以包含狀態(tài)變量的聲明、函數(shù)的定義、修飾符以及構(gòu)造函數(shù)。為了能夠在以太坊平臺上進行部署，開發(fā)人員將智能合約源代碼編譯為EVM二進制執(zhí)行代碼。智能合約的入口點是一段被稱作函數(shù)選擇器的代碼。每當有函數(shù)被調(diào)用時，智能合約就會在函數(shù)選擇器的位置開始執(zhí)行。函數(shù)選擇器會解析消息并跳轉(zhuǎn)到恰當?shù)暮瘮?shù)。當沒有明確調(diào)用智能合約的具體函數(shù)時，將自動觸發(fā)回調(diào)函數(shù)。

3.1.2 調(diào)用模型

部署后，智能合約的外部/公共函數(shù)可以使用3種不同的方法進行調(diào)用。第1種方法是用戶通過客戶端發(fā)送交易進行調(diào)用，該交易的信息包含目標函數(shù)的簽名哈希和函數(shù)所需的參數(shù)。這是一種可以更改賬戶余額和智能合約狀態(tài)的寫入操作。“礦工”將會向發(fā)送方收取以太幣，以支付交易過程中所產(chǎn)生的Gas費用。第2種方法是通過智能合約直接調(diào)用另一個智能合約的函數(shù)。這種操作本質(zhì)上是智能合約間的消息調(diào)用。第3種方法是由客戶端在本地調(diào)用智能合約中的view函數(shù)或pure函數(shù)，該函數(shù)不會修改狀態(tài)也不需要花費Gas。

圖2 以太坊智能合約程序模型

Figure 2 Ethereum smart contract program model

3.1.3 數(shù)據(jù)管理模型

以太坊虛擬機EVM是256位的基于堆棧的虛擬機。智能合約可以訪問4種數(shù)據(jù)：最大容量為1 024的操作堆棧（Stack），用作易失性存儲的字尋址的字數(shù)組內(nèi)存（Memory），用于持久性存儲的字尋址的字數(shù)組存儲（Storage）以及作為消息調(diào)用數(shù)據(jù)復制的只讀字數(shù)組（Calldata）。其中，堆棧的開銷為3，內(nèi)存的開銷至少為3，存儲的開銷至少為20 000，實際運行時情況較為復雜，這里無法給出精確的數(shù)值，針對本文研究的額外開銷將在第7.4節(jié)中探討。

3.2 執(zhí)行路徑和控制流

ContractGuard通過監(jiān)視context-tagged無環(huán)路徑來保護智能合約，其中，context-tagged無環(huán)路徑標識了智能合約的執(zhí)行路徑和控制流。

3.2.1 context-tagged無環(huán)路徑

context-tagged無環(huán)路徑是由Ball和Laurus[21]對過程內(nèi)無環(huán)路徑的擴展。context-tagged無環(huán)路徑用一個元組<,>表示，其中是過程內(nèi)無環(huán)路徑，是調(diào)用的上下文信息。通俗地講，context- tagged無環(huán)路徑是控制流圖（CFG）無循環(huán)版本的路徑，即替換回邊后的控制流圖。通過用兩個替代邊entry→v和w→exit替換每個控制流圖中所出現(xiàn)的回邊w→v，替換完畢后可以得到控制流圖的非循環(huán)版本。例如，圖3(a)中的CFG，在圖3(b)中兩個回邊3→1和4→3被替代為邊Entry_C→3，3→Exit_C和4→Exit_C。

context-tagged無環(huán)路徑具有兩個特性，使其特別適合異常檢測任務(wù)。首先，非循環(huán)CFG中不能存在循環(huán)路徑，因此該CFG中路徑的數(shù)量總是有限的。其次，原始CFG中的完整路徑可以在回邊處分成多個非循環(huán)路徑。例如，圖3(a)中的路徑Entry_C→1→2→3→4→3→4→3→4→3→1→5→ Exit_C可以被分解為p1: Entry_C→1→2→3→4→ Exit_C，p2: Entry_C→3→4→Exit_C，p3: Entry_C→ 3→4→Exit_C，p4: Entry_C→3→Exit_C，p5: Entry_C→1→5→Exit_C。可以看出，非循環(huán)路徑對應(yīng)于循環(huán)之前、循環(huán)內(nèi)部或者循環(huán)之后的路徑段。具有不同循環(huán)迭代次數(shù)的完整路徑可以共享同一組非循環(huán)路徑。

3.2.2 智能合約執(zhí)行檢測

為了獲得智能合約運行過程中的信息，ContractGuard需要先構(gòu)建智能合約的函數(shù)調(diào)用圖。

圖3 上下文標記的無環(huán)圖例子

Figure 3 Examples of context-tagged acyclic path

函數(shù)調(diào)用圖是指在給定的具體智能合約中，將智能合約存在的所有函數(shù)作為圖中的節(jié)點，而調(diào)用的上下文信息則表示為調(diào)用函數(shù)f前函數(shù)之間的調(diào)用序列[35]。例如，在圖3(c)中，函數(shù)B的調(diào)用上下文信息可以為S→b1，也可以為S→a1→c1→b2，還可以為S→a1→c2→b2，具體信息由實際運行情況決定。由于遞歸，函數(shù)調(diào)用圖可能包含循環(huán)，與在CFG中將回邊替換為代用邊一樣，每一條遞歸的邊都將換成從智能合約入口到函數(shù)調(diào)用處的邊。例如，將圖3(c)中的智能合約調(diào)用圖轉(zhuǎn)換為圖3(d)中的，結(jié)果中存在函數(shù)C的4個調(diào)用上下文信息：S→a1→c1，S→a1→c2，S→b1→c3和b*→c3。

為了獲得更多智能合約運行過程中的信息，可以通過代碼中不存在的虛擬分支對過程內(nèi)無環(huán)路徑進行拓展。這些虛擬分支檢查每個指令的潛在前提條件，具體來說，對于每個算術(shù)運算，檢查是否滿足上溢/下溢的前提條件。對于每個函數(shù)調(diào)用，檢查后置條件，如返回值是否為空（當返回值是地址類型）、false（當返回值是布爾類型）或0（當返回值是整數(shù)類型）。

4 研究思路

4.1 研究假設(shè)

研究發(fā)現(xiàn)，異常的交易一般會觸發(fā)漏洞從而進行攻擊。ContractGuard中有一個關(guān)鍵的假設(shè)：通過比較不同交易所觸發(fā)的控制流來區(qū)分正常的交易和異常的交易。具體來說，ContractGuard對交易的控制流進行監(jiān)測，并對控制流進行分析和校驗，識別異常的控制流，并對引發(fā)異常控制流的交易發(fā)出告警，認為其可能為異常交易。

一般而言，測試用例所產(chǎn)生的控制流是合法的。測試用例中合法交易類的測試用例應(yīng)該被智能合約所接受，其控制流反映了合法的交易處理。測試用例中非法交易類的測試用例應(yīng)該被智能合約所拒絕，其控制流反映了智能合約對非法交易的合法的出錯處理。因此，本文認為異常交易所觸發(fā)的不安全路徑不會出現(xiàn)在測試用例所覆蓋的安全路徑集中。文獻[12]表明在傳統(tǒng)系統(tǒng)中這一假設(shè)是成立的。

4.2 異常控制流分析

為進一步驗證這一個假設(shè)，本文參考了最近幾項關(guān)于智能合約漏洞的研究[3,6,11,36-38]，總結(jié)出11種主要的安全漏洞，并研究這些漏洞是否觸發(fā)了智能合約中的不安全路徑。

(1) 可重入漏洞[12]

智能合約A調(diào)用智能合約B或者向智能合約B發(fā)送以太幣時，外部調(diào)用可能被攻擊者利用，使智能合約A執(zhí)行一段額外的代碼。如果這段額外的代碼能回調(diào)智能合約A本身，而智能合約A沒有對可重入行為進行檢查，繼續(xù)正常執(zhí)行，不觸發(fā)任何異常，則智能合約A將很容易被攻擊者攻擊，隨機改變其智能合約狀態(tài)。著名的DAO事件[6]就是利用此漏洞造成了巨大的經(jīng)濟損失。

根據(jù)外部調(diào)用所調(diào)用的函數(shù)是否為這個函數(shù)本身，本文將可重入漏洞分為相同函數(shù)可重入漏洞和交叉函數(shù)可重入漏洞[6]。代碼1是相同函數(shù)可重入漏洞的一個例子。在代碼1的第6行，智能合約向攻擊者構(gòu)造的合約發(fā)起調(diào)用，這里并沒有指明調(diào)用的函數(shù)，EVM則會自動觸發(fā)回調(diào)函數(shù)（在代碼1的第12行），這時攻擊者構(gòu)造的合約將會觸發(fā)智能合約的withdraw函數(shù)，從而造成智能合約的異常狀態(tài)更改。

代碼1

1) contract InnocentContract{

2) mapping(address=>uint)private balances;

3) function withdraw(){

4) uint amount = balances[msg.sender];

5) if(amount > 0){

6) msg.sender.call(balance[msg.sender]);

7) balances[msg.sender]=0;

8) }

9) }

10) }

11) contract AttackerContract{

12) function(){

13) Wallet wallet = msg.sender;

14) wallet.withdraw();

15) }

16) }

異常控制流：該漏洞會觸發(fā)異常的控制流，無論是相同函數(shù)可重入漏洞還是交叉函數(shù)可重入漏洞都會觸發(fā)一條異常的可重入控制流路徑。當用來提取安全路徑的測試用例包含這些控制流時，開發(fā)人員可以發(fā)現(xiàn)問題并修復此問題。值得注意的是，偵測此類漏洞需要相關(guān)的程序執(zhí)行上下文信息，因此ContractGuard需要標識并獲取對應(yīng)的上下文信息。

(2) 危險的deleagatecall[11]

當一個智能合約使用delegatecall()調(diào)用外部函數(shù)時，外部函數(shù)執(zhí)行時的程序上下文信息將不會改變，保持原來的程序上下文信息。這一特性有利于共享庫代碼的構(gòu)造。然而，這一特性也會引發(fā)不安全的漏洞，當一些庫代碼在錯誤的上下文信息中執(zhí)行時將會發(fā)生錯誤的狀態(tài)改變。

代碼2是一個Parity多重簽名智能合約delegatecall漏洞的簡化版。在代碼2的第11行，智能合約使用delegatecall()以及函數(shù)簽名和函數(shù)的輸入?yún)?shù)選定庫代碼中的函數(shù)，并對該函數(shù)進行調(diào)用。在代碼2的第15行，攻擊者觸發(fā)第11行的代碼，使智能合約觸發(fā)init函數(shù)，在該執(zhí)行過程中由于上下文信息保持不變，即保持InnocentContract合約中的所有信息，攻擊者可以操縱InnocentContract合約中的信息，InnocentContract合約的擁有者將轉(zhuǎn)換為攻擊者。

代碼2

1) contract DelegateLibrary{

2) address public owner;

3) function init(){

4) owner = msg.sender;

5) }

6) }

7) contract DelegateLibrary{

8) address public owner;

9) DelegateLibrary _library;

10) function (){

11) _library.delegatecall(msg.data);

12) }

13) }

14) contract DelegateLibrary{

15) ...innocent.call(

16) bytes4(keccak256(“init()”)));...

17) }

異常控制流：該漏洞會觸發(fā)異常的控制流。在錯誤的上下文信息環(huán)境中執(zhí)行智能合約，是在調(diào)用者或者開發(fā)者意料之外的，因此，這些智能合約的測試用例中肯定不會包含因意外而產(chǎn)生的路徑，所以該漏洞所觸發(fā)的路徑都是異常控制流路徑。

(3) 算術(shù)上溢/下溢[3]

在算術(shù)運算中，當操作一個超出固定范圍大小的數(shù)字時，會出現(xiàn)算術(shù)上溢或下溢，如uint8的數(shù)據(jù)經(jīng)過算術(shù)運算后變成uint256的數(shù)字，則會產(chǎn)生算術(shù)上溢。2018年4月，攻擊者利用整數(shù)溢出的漏洞對美鏈（BECToken)）進行攻擊[39]，幾乎將美鏈中的“數(shù)字貨幣”全部清空。

異常控制流：該漏洞會觸發(fā)異常的控制流。在3.2節(jié)介紹的拓展控制流，添加虛擬分支就是為了處理這種情況。當所有測試用例所產(chǎn)生的交易都是合法時，測試用例所覆蓋的控制流路徑都不會包含觸發(fā)上溢/下溢的路徑。

(4) 默認類型[37]

在Solidity語言中，函數(shù)的默認類型都是public的，這將允許其他智能合約或者外部合約調(diào)用其外部函數(shù)。當開發(fā)人員因疏忽而暴露原本應(yīng)該為私有的方法給其他人使用時，可能會給不法分子提供攻擊合約的渠道。

異常控制流：該漏洞會觸發(fā)異常的控制流。當開發(fā)人員忘記特別指明函數(shù)類型時，即忘記加上internal關(guān)鍵字時，將出現(xiàn)異常的控制流。由于測試人員在測試合約時不會直接調(diào)用這些函數(shù)，因此測試用例不會覆蓋此類路徑。

(5) 隨機種子[37]

在以太坊中，智能合約經(jīng)常使用區(qū)塊的時間戳作為隨機數(shù)的隨機種子。此類操作容易被黑客利用、影響和控制，因為這些隨機變量受礦工節(jié)點決定。

異常控制流：該漏洞不會觸發(fā)異常控制流。此漏洞與變量的錯誤使用有關(guān)，與控制流無關(guān)。

(6) 對外部調(diào)用的檢查[6]

當一個智能合約出現(xiàn)錯誤的外部調(diào)用時，這條交易將不會進行正常的回滾。當智能合約的外部調(diào)用是call()或者send()觸發(fā)時，外部調(diào)用返回錯誤結(jié)果，而不是直接進行回滾。很多漏洞是因為沒有對call()和send()的返回結(jié)果進行檢查所導致的。例如，在代碼3中，開發(fā)者希望當?shù)?行代碼發(fā)生錯誤時，程序直接進行回滾，但實際上第2行發(fā)生錯誤時，程序繼續(xù)往下執(zhí)行，智能合約的狀態(tài)將隨共識的結(jié)束而改變。

代碼3

1) if (gameHasEnded && !prizePaidOut){

2) winner.send(1000);

3) PrizePaidOut = True;

4) }

異常控制流：該漏洞會觸發(fā)異常的控制流。在第3.2節(jié)提到的虛擬分支會對外部調(diào)用的返回結(jié)果進行檢查。假設(shè)本文的測試用例都是正確的，它們將不會覆蓋使call()和send()失敗的路徑。

(7) 交易順序[6]

在此類漏洞的攻擊中，“礦工”會嘗試與調(diào)用智能合約的用戶競爭，將有問題的交易放在用戶交易之前，因此能利用此方法對用戶造成損失。

異常控制流：該漏洞不會觸發(fā)異常的控制流。該漏洞的攻擊針對智能合約的運行環(huán)境，并不會引起控制流的變化。

當智能合約使用Tx.Origin進行身份驗證時，該合約通常能夠進行釣魚攻擊。攻擊者會欺騙用戶在這份釣魚合約中進行身份驗證。例如，在代碼4中，InnocentContract利用第3行的代碼確保只有InnocentContract的擁有者才能進行轉(zhuǎn)賬操作。然而，攻擊者欺騙InnocentContract的擁有者轉(zhuǎn)賬給攻擊者設(shè)計好的AttackerContract ，即代碼4的第8行。這時第9行的回調(diào)函數(shù)會被觸發(fā)，由于使用了Tx.Origin，第3行的代碼不會觸發(fā)異常，代碼會繼續(xù)往下執(zhí)行，這時InnocentContract的擁有者會更改，攻擊者成為InnocentContract的擁有者。

代碼4

1) contract InnocentContract{

2) function transfer(address dest, uint amount){

3) if (tx.origin != owner) throw;

4) dest.send(amount);

5) }

6) }

7)}

8) contract AttackerContract{

9) function (){

10) Wallet w = Wallet(walletAddr);

11) w.transfer(thiefAddr, msg.sender.balance);

12) }

13) }

(8) Tx.Origin[6]

異常控制流：該漏洞會觸發(fā)異常的控制流。為了讓此漏洞的攻擊能成功，攻擊者必須觸發(fā)一次特定的交易。這次交易必須由被欺騙者發(fā)起調(diào)用，通過攻擊者所構(gòu)造的合約再次調(diào)用被欺騙者所持有的合約，并且該合約是使用Tx.Origin進行身份驗證的。在正常的情況下，測試用例只會直接調(diào)用此合約，并不會用其他合約對此進行調(diào)用。

(9) 拒絕服務(wù)[6]

此類型的攻擊定義非常廣泛，但從根本上說，它就是使用某些攻擊手段造成智能合約在一小段時間甚至永久性失效。

異常控制流：該漏洞會觸發(fā)異常的控制流。當有控制流造成智能合約失效，說明該控制流本身就是異常的，因為沒有測試用例嘗試讓智能合約失效。

(10) 短地址攻擊[37]

當傳遞給智能合約的參數(shù)短于預期長度時，EVM將會在參數(shù)末尾添加0。當?shù)谌匠绦驔]有對交易輸入的參數(shù)進行檢查時，則很容易受到此類攻擊。

異常控制流：該漏洞不會觸發(fā)異常的控制流。這種漏洞的發(fā)生與智能合約自身無關(guān)，而是發(fā)生在與智能合約進行交互的第三方程序。因此，該漏洞不會觸發(fā)異常的控制流。

(11) 邏輯錯誤[6]

使用過多復雜的謂詞容易出現(xiàn)相關(guān)的邏輯錯誤，如使用過多的邏輯操作符和關(guān)系操作符。這些邏輯錯誤很有可能出現(xiàn)意想不到的漏洞。

異常控制流：有可能會觸發(fā)異常的控制流。如果引起漏洞的控制流路徑和正常的控制流路徑?jīng)]有重疊，就可以檢測出異常的控制流[40]。然而，由于這種情況下，很有可能出現(xiàn)路徑重疊情況，異常的控制流路徑不一定都可以檢測出來。

表1總結(jié)本文的調(diào)查和分析結(jié)果。如上述分析討論顯示，對大多數(shù)漏洞，其攻擊是能觸發(fā)異常的控制流。這初步證實了基于異常控制流的IDS對漏洞攻擊能進行有效的防御。對于其他漏洞，其攻擊的目標并非智能合約本身，而是針對以太坊的運行環(huán)境產(chǎn)生的漏洞（#5.隨機種子和#7.打包交易順序），或者針對第三方與智能合約進行交互所產(chǎn)生的漏洞（#10.短地址攻擊）。

表1 漏洞的異常控制流

5 ContractGurad智能合約防護方案

5.1 概覽

ContractGuard整個智能合約防護的過程，主要分為訓練、保護和審計3個階段如圖4所示。

在訓練階段，需要在以太坊測試環(huán)境中部署未插樁的待保護的智能合約。可選的主流測試環(huán)境有3種：以太坊私有鏈、Ropsten測試鏈、Ganache以太坊模擬器[41]。因為Ganache提供最為純凈的部署環(huán)境以及較快的交易執(zhí)行速度，本文選擇Ganache作為測試環(huán)境。

智能合約在測試環(huán)境中部署后，本文的實驗通過合約開發(fā)者提供的測試用例向待保護的智能合約發(fā)起訓練交易。在這些交易執(zhí)行完畢后，收集交易中合約的執(zhí)行路徑并從中提取出context-tagged 無環(huán)路徑。這些路徑可視為初始安全路徑集合。因為在訓練階段提取安全路徑的開銷遠遠小于部署后提取安全路徑的開銷，開發(fā)者在測試階段提供大量的測試用例可以大量減少ContractGurad所帶來的額外開銷。

圖4 ContractGuard的總覽

Figure 4 Overview of ContractGuard

在保護階段，在智能合約的字節(jié)碼中插入可以起到防衛(wèi)攻擊的兩類探針，分別是實時記錄context-tagged無環(huán)路徑以及檢查路徑是否在安全路徑集合中的代碼片段。這個過程實際上是對原有智能合約進行插樁的過程。待智能合約管理員在以太坊主網(wǎng)上部署插樁后的智能合約，合約在運行過程中可以自行記錄每個交易運行的context-tagged無環(huán)路徑并且校驗其是否在安全集合中。若ContractGuard發(fā)現(xiàn)至少一條非法路徑，則會自動進行回滾取消交易并且對外告警。

在審計階段，智能合約管理員可以通過監(jiān)控以太坊主網(wǎng)的交易記錄獲知智能合約是否發(fā)出警報。智能合約管理員有機會查看所有發(fā)生回滾的交易，并且在測試環(huán)境中重現(xiàn)交易查看智能合約是否正確執(zhí)行。若交易被智能合約管理員確認是安全的，管理員可以向以太坊主網(wǎng)中發(fā)起交易，請求將之前誤報的路徑添加到安全路徑集中。

5.2 ContractGuard的防衛(wèi)邊界

觸發(fā)IDS回滾的情景1共有3種，如圖5所示。

情景1

此次交易全過程都在保護的邊界中，整個過程為用戶u發(fā)起交易1調(diào)用智能合約A，智能合約A發(fā)起消息1調(diào)用智能合約B。交易第一個執(zhí)行的public/external函數(shù)就在被保護的智能合約A中，并且不再對邊界外的任何智能合約發(fā)起調(diào)用。在這種情景下，ContractGuard記錄執(zhí)行過程中所有函數(shù)的context-tagged無環(huán)路徑，并確保這些路徑的安全性。當發(fā)生跨智能合約的調(diào)用時，可以在calldata的消息中植入當前calling-context的信息，以確保可以建立完整的calling-context計算。一旦到達context-tagged無環(huán)路徑的末尾，ContractGuard會檢查路徑的安全性。倘若路徑異常，則ContractGuard把此次交易標記為異常交易。此標記隨執(zhí)行過程通過在returndata進行植入的方式返回到此交易各層合約的入口函數(shù)。直到整個交易的入口，ContractGuard通過檢查此標記決定進行告警以及整個交易的回滾[18]。

圖5 ContractGuard的保護邊界和可能保護的情況

Figure 5 Protection boundary of ContractGuard and the possible protection scenarios

情景2

此次交易首先由用戶u發(fā)起交易1調(diào)用在保護范圍中的智能合約A，然后智能合約A發(fā)起消息調(diào)用2調(diào)用不在保護范圍中的智能合約C，智能合約C再發(fā)起消息調(diào)用3調(diào)用在保護范圍中的智能合約B。交易首個調(diào)用的智能合約是被保護的智能合約，但隨著智能合約的執(zhí)行，此次交易會調(diào)用到未被保護的智能合約，并且這些未被保護的智能合約有機會調(diào)用被保護的智能合約。例如，在圖5中，智能合約A調(diào)用智能合約C，之后智能合約C再調(diào)用智能合約B。這種情景下，ContractGuard會記錄A和B的context-tagged無環(huán)路徑，但A和B是獨立進行異常標記以及回滾的。因此，所造成的結(jié)果取決于警報在何處觸發(fā)。若在B觸發(fā)警報，那只有B發(fā)生回滾。若在A觸發(fā)警報，則在A、B、C這3個智能合約都發(fā)生回滾。另一種更好的解決方案是保證交易的原子性。但要實現(xiàn)這種回滾的原子性，智能合約與智能合約之間必須使用額外的消息調(diào)用以及storage存儲實現(xiàn)異常標記的同步，因為未被保護的智能合約是不受ContractGuard所控制的。這類實現(xiàn)方式導致執(zhí)行開銷太高，因此這種方案是不可行的。

更廣泛地說，現(xiàn)有被保護的智能合約X和智能合約Y、未被保護的智能合約Z，調(diào)用順序為智能合約X調(diào)用智能合約Z，接著智能合約Z調(diào)用智能合約Y。當被保護的智能合約X調(diào)用未被保護的智能合約Z時，ContractGuard并不會把當前的calling-context傳給Z調(diào)用的Y。但有一種例外的情況，就是智能合約X與智能合約Y是同一個合約，這種情況下，ContractGuard通過智能合約storage的方式來傳遞calling-context。采用這種實現(xiàn)方式可以防護可重入的攻擊，但同時會對每個外部調(diào)用造成5 000 Gas的額外開銷，因而這種實現(xiàn)方式是產(chǎn)生額外運行開銷的最大原因。

情景3

此次交易首先由用戶u發(fā)起交易2調(diào)用不在保護范圍內(nèi)的智能合約C，然后智能合約C發(fā)起消息調(diào)用3調(diào)用在保護范圍內(nèi)的智能合約B。這個情景交易的首個智能合約是未保護的合約，是通過調(diào)用的方式進入被保護的智能合約中的。在此情形中，保護的智能合約僅有B，當智能合約B觸發(fā)警報時，智能合約B的狀態(tài)會產(chǎn)生回滾，而智能合約C的狀態(tài)將不受到回滾的影響。

5.3 函數(shù)內(nèi)的路徑編碼

ContactGuard采用Ball和Larus[21]提出的EPP算法對函數(shù)內(nèi)的路徑進行記錄和編碼。算法的輸入是所有回邊都被替代后的有向無環(huán)圖。這種變換已經(jīng)在第3.2節(jié)介紹。

圖6是EPP算法示例與描述，核心思路是使用兩個數(shù)值標記無環(huán)控制流圖。對于無環(huán)控制流圖中的每個頂點，使用NumPaths(v)標記從v到exit頂點的路徑數(shù)量。例如，圖6中的D有兩條路徑可到達exit頂點F（D→F和D→E→F），為此標記值為2。此外，e1, e2, … ,e為點v的出邊。E1可以標記為0，其余的邊可用以下公式計算標記值。

通過這種標記系統(tǒng)，可以證明對于每個頂點v，所有從v到exit的路徑都可以用唯一的數(shù)值表示，并且這些數(shù)值是連續(xù)不斷的。如圖6(b)的算法所示，EPP[21]可以為每個頂點和邊生成準確無誤的標記。

Figure 6 The example and description of EPP algorithm

利用EPP算法進行標記后，就可以利用這些標記有效地記錄函數(shù)內(nèi)路徑：在函數(shù)入口，初始化局部整型變量epp為0。當控制流通過邊e時，若val(e)不為0，則累加至epp中。在函數(shù)結(jié)尾，可以在epp中得到所覆蓋路徑的唯一編號。除此之外，在循環(huán)的回邊中，也可以得到唯一的編號epp。之后epp重置為0并重新記錄路徑。

EPP算法通過進一步優(yōu)化，即最小化邊標記中非零值可以減少ContractGuard帶來的額外開銷[42]。ContractGuard使用的是優(yōu)化后的EPP算法。

5.4 調(diào)用上下文的記錄與編碼

除了函數(shù)內(nèi)部的路徑外，ContractGuard還需要調(diào)用上下文信息。受EPP算法的啟發(fā)，本文設(shè)計了高效的上下文調(diào)用信息標識與配置算法，如圖7所示。

圖7 上下文標識調(diào)用信息標識與配置算法的示例與描述

Figure 7 The example and description of efficient calling-context indexing and profiling algorithm

本文所提算法的輸入是所有遞歸調(diào)用邊都被替換后的有向無環(huán)的函數(shù)調(diào)用圖，其中，程序中的每個callsite都被表示為調(diào)用邊和返回邊。

從本質(zhì)上來說，這個算法是作用在函數(shù)調(diào)用圖中翻轉(zhuǎn)版本的EPP算法。與EPP類似，這個算法同樣對頂點和邊進行標記。不同的是，EPP使用逆拓撲順序，而此算法使用拓撲排序。此算法利用NumCCs(f)對每個點f進行標記。NumCCs(f)表示程序入口到f所有調(diào)用路徑的數(shù)量。接著，1，2,…,c是所有進入頂點f的調(diào)用邊，1，2,…,r表示的是返回邊。邊1標記為0，其余的c利用下面的公式進行標記。

同時，對于所有的返回邊r=-c。

與EPP類似，可以證明頂點f，每個調(diào)用上下文都可以通過對每個call edge的Val(c) 進行累加而被賦上唯一且連續(xù)的值。這個證明與EPP的證明類似。

為了實現(xiàn)調(diào)用上下文記錄與編碼算法，需要設(shè)置初始化為0的全局變量ctx。對每個call-site，在函數(shù)調(diào)用前，利用Val(c)對ctx進行累加，并在return后，把Val(c)的值從ctx中減去。在每個函數(shù)的入口，ctx的值表示當前函數(shù)所處的調(diào)用上下文。

5.5 存儲安全路徑的方案

ContractGuard結(jié)合了上面兩種記錄和編碼的方式得到可以記錄和編碼context-tagged無環(huán)路徑的方案：對每個函數(shù)f的入口e，其context-tagged無環(huán)路徑可以連續(xù)地編碼為0，1，2,…,NumPaths(e)*NumCCs(f)?1。當程序在運行階段，每當?shù)竭_函數(shù)內(nèi)無環(huán)路徑的結(jié)束點，可以使用ctx*NumPaths(e)+epp為此路徑進行編碼。

使用上述的編碼體系，安全路徑查詢的問題可以形式化為：給定一個整型數(shù)，如何確定此整型數(shù)在集合中？對于這個問題，有很多現(xiàn)成的解決方案，但是基于EVM的Gas計算體系下，下面3種解決方案是最有效的。

1) 嵌入式列表：把查詢變成與S中常量進行比較的代碼并嵌入合約中。

2) 嵌入式完美哈希表（MPHT）：該方案通過把作為MPHT嵌入至合約中。ContractGuard使用CHD算法[22]，CHD算法通過兩層hash構(gòu)造哈希表。第一層哈希把映射到不同的槽中，每個槽可以使用第二層哈希映射到槽中的元素。

3) 合約storage映射表：使用Solidity中的mapping數(shù)據(jù)類型在合約的storage中存儲集合。

圖8展示了ContractGuard實現(xiàn)上述3種存儲方案的性能比較。在部署開銷上，3種存儲方案都是和集合的大小線性相關(guān)的。但是，使用智能合約storage映射表的開銷是最大的，因為每存儲一個值都需要耗費20 000 Gas。而其余的兩種方案，僅需要為每條指令支付額外的200 Gas開銷。在查詢階段，嵌入式完美哈希表和智能合約storage映射表所需要的Gas固定，而嵌入式列表的Gas是和集合大小線性相關(guān)的。但是，當集合元素小于6時，嵌入式列表消耗的Gas是最小的。

根據(jù)上述的分析，可以動態(tài)決定選擇采用何種存儲方案。當在訓練階段后，ContractGuard可以根據(jù)安全路徑集合的大小選擇使用嵌入式MPHT還是嵌入式列表進行安全路徑集合的初始化，智能合約storage映射表不會使用在此階段。但是在智能合約部署后，智能合約管理員新添加的安全路徑集合大多使用智能合約storage映射表來實現(xiàn)。

圖8 3種存儲方案的性能比較

Figure 8 The performance comparison of 3 storage solutions

6 基于以太坊主網(wǎng)的實驗

為了評估ContractGuard的效率，本文進行了仿真實驗，主要從開銷方面分析將IDS嵌入智能合約的實際可行性和可操作性，以及嵌入式IDS對異常行為的識別過程是否導致過多無效的錯誤警報。

6.1 ContractGuard的開銷最小化

一般來說，使用嵌入式入侵檢測器ContractGuard保護智能合約會涉及兩種開銷，這兩種開銷都需要花費額外的以太幣。

1) 部署開銷：智能合約嵌入帶有異常檢測功能和初始安全路徑集的代碼后，智能合約的代碼規(guī)模會擴大，而智能合約的部署開銷與其代碼規(guī)模有關(guān)。因此，以太坊將在智能合約創(chuàng)建時收取額外的Gas費用，從而增加部署成本。

2) 運行開銷：在交易執(zhí)行期間，嵌入式IDS對控制流路徑進行了設(shè)置。此外，當路徑終止時，IDS需要檢查該路徑是否在安全路徑集中。該操作作為受保護的智能合約原來的交易處理之外的額外處理，不可避免地會增加智能合約的處理和計算，從而增加交易過程中的Gas花費成本。

雖然只有管理員來支付部署開銷費用，但是將交易發(fā)送到受保護合約的所有用戶都需要支付運行開銷費用。如果開銷不合理地增加，導致智能合約的交易成本過高，合約管理員和用戶將不會使用本文所提出ContractGuard，即使它可以有效地保護智能合約。

為了調(diào)查在現(xiàn)實世界中為智能合約部署ContractGuard的開銷，本文實驗運行了最新版本的以太坊（Geth）全節(jié)點（1.9.0）（可重新訓練所有歷史信息），并與以太坊主網(wǎng)進行了同步，同步的塊數(shù)量達到4 200 000（截至2017年8月24日）共有341 585個智能合約。其中，332 008個智能合約的交易少于100個，另外1 173個智能合約導致控制流程圖提取工具崩潰了（本文實驗使用了控制流程圖提取工具Vandal[7]）。最后選擇了剩余的8 314個合約賬戶作為調(diào)查對象，因為它們交易數(shù)量大于100次，最有可能代表實際中使用的合約。在此期間，用戶共向這些合約發(fā)送了19 944 547筆交易。

本文比較了這8 314個實例的代碼，發(fā)現(xiàn)有985份獨特的智能合約，其他智能合約復制至這些獨特的智能合約。接下來，本文將報告完整的8 314個智能合約和985個獨特的智能合約的部署額外開銷平均值。

本文將ContractGuard應(yīng)用于所有收集到的智能合約中。由于部署智能合約的成本與二進制代碼大小（每字節(jié)200個Gas[18]）成正比，因此將部署額外開銷度量為（檢測代碼大小）/（原始代碼大小）-100%。本文設(shè)置每個智能合約的安全路徑集，其中包含發(fā)送到該智能合約的所有交易覆蓋的所有context-tagged無環(huán)路徑。這種處理模擬了部署額外開銷的最壞情況。

圖9(a)顯示了所有智能合約部署額外開銷的分布，較大的20%智能合約平均部署額外開銷為24.07%，較小的20%智能合約的平均部署額外開銷為51.84%。總體而言，所有8 314個智能合約的平均部署額外開銷為36.14%，而985個獨特的智能合約的平均部署額外開銷為37.76%。圖9(b)顯示了部署額外開銷最大的前5個智能合約的情況。

圖9中的結(jié)果提供了初步的證據(jù)，表明智能合約嵌入IDS所需部署開銷是切實可行的，其增加的成本在合理范圍內(nèi)：本質(zhì)上，管理員只需要多支付36.14%的Gas費用，以換取更高的智能合約安全性。值得注意的是，在部署ContractGuard后，8 314個智能合約均未超過24 576 byte的限制。

接下來，本文通過實驗調(diào)查了嵌入ContractGuard后的智能合約的運行開銷。對于發(fā)送給收集到智能合約的所有19 944 547筆交易，本文收集了其詳細的執(zhí)行路徑。然后，將每條路徑與ContractGuard所部署的代碼對齊，并得到ContractGuard所要執(zhí)行的所有指令。以這種方式，本文通過累積執(zhí)行額外指令所花費的額外Gas成本來獲得ContractGuard在每個交易上精確的運行開銷。

圖9 部署額外開銷的測量結(jié)果

Figure 9 Measurement of deployment overhead

圖10(a)以Gas增加量的方式展示了運行時Gas開銷的分布情況。平均而言，8 314個智能合約運行額外開銷為25.98%，985個獨特的智能合約運行額外開銷為17.5%。這與常規(guī)系統(tǒng)中基于實際控制流異常的IDS相當（如Giffin等[19]的工作中，平均執(zhí)行時間開銷為22%）。對于94.5%的交易，運行時Gas開銷都低于30%。整體而言，嵌入ContractGuard后的智能合約運行時開銷的增加在較低、合理以及可實際接收的水平。

圖10(b)顯示了運行時額外開銷最大的前5個智能合約情況。在最壞的情況下，運行額外開銷增加了86.0%。在7.4節(jié)中，本文將對影響運行開銷的因素進行詳細分析。經(jīng)研究發(fā)現(xiàn)，對于少量交易而言，運行額外開銷如此之高的原因是，它們對外部未受保護的合約進行了大量頻繁的調(diào)用。發(fā)生這種情況時，ContractGuard必須使用昂貴的智能合約存儲來保存調(diào)用上下文。目前，ContractGuard應(yīng)用于類似情景中成本可能偏高（在8 314個主題合約中，這部分情況低于5%）。本文將在7.5節(jié)對此問題進行更多的討論。

圖10 運行開銷的測量結(jié)果

Figure 10 Measurement of runtime overhead

6.2 手動處理錯誤警報的可行性分析

除了開銷之外，另一個可能影響ContractGuard實際使用的重要問題是錯誤警報的觸發(fā)情況[43]，它對應(yīng)于被ContractGuard誤認為是惡意交易的合法交易。為了避免拒絕合法的交易，管理員需要手動查看每個警報，如果是錯誤警報，則將路徑追加到安全路徑集中，這可能需要一定的人工干預。

為了調(diào)查錯誤警報的數(shù)量，本文使用8 314個真實世界的智能合約進行至少100交易。假設(shè)開發(fā)人員部署的智能合約都是沒有測試用例的，從而無初始化的安全路徑集。ContractGuard最初將設(shè)置一個空的安全路徑集。本文進一步假設(shè)所有交易都是合法的，并且當該交易被誤認為異常交易時，管理員立即將交易的上下文標記的無環(huán)路徑添加到安全路徑集中。因此，ContractGuard將不會對之前誤報的交易發(fā)出警報。在這些假設(shè)下，本文計算每個合約的誤報數(shù)量。本質(zhì)上，這就是估計在現(xiàn)實世界中處理錯誤警報所需的手動工作量。

圖11(a)顯示了錯誤警報的分布情況，而圖11(b)顯示了具有最多錯誤警報的前5個智能合約。在假設(shè)的情況下，ContractGuard會為每個智能合約平均報告2.88次錯誤警報。對于大多數(shù)交易（92.2%），錯誤警報的數(shù)量低于5。此結(jié)果為使用IDS保護智能合約時錯誤警報問題是可管理的假設(shè)提供有力的證據(jù)。

圖11 錯誤警報次數(shù)的測量結(jié)果

Figure 11 Measurement of the false alarm counts

7 基于現(xiàn)實世界合約漏洞的受控實驗

本節(jié)對ContractGuard的有效性進行實驗評估，將評估3個研究問題。

問題1：ContractGuard是否可以有效地檢測漏洞？

問題2：部署開銷、運行開銷和錯誤警報的數(shù)量是多少？

問題3：哪些因素會影響部署和運行時開銷？

本節(jié)介紹了用于評估所提出的研究問題的實驗，并報告了實驗結(jié)果。

7.1 實驗對象

為了研究問題1和問題2，本文研究設(shè)計了兩組實驗。第一組實驗（見表2）的實驗對象是6個已經(jīng)被報道存在漏洞并成為攻擊受害者的真實智能合約。本文選擇這些實驗對象是因為它們代表已造成重大經(jīng)濟損失的著名漏洞攻擊和典型漏洞攻擊。例如，第1個實驗對象“DAO”合約[6]，黑客從中竊取了價值6 000萬美元的代幣，最終導致了以太坊的硬分叉，產(chǎn)生了以太坊經(jīng)典（ETC）[6]。第2個實驗對象“MultiSig”包含一個漏洞[7]，最終導致價值3億美元的加密貨幣被凍結(jié)，并且（可能）將會永遠損失。第4個實驗對象“BecToken”是一個在2018年4月遭到惡意攻擊者攻擊的智能合約，黑客將存儲在該智能合約的金額幾乎全部取走[39]。

第二組實驗（見表3）使用實際在主網(wǎng)運行的去中心化應(yīng)用（DApp，decentralized application），DApp實際上是多個智能合約所組成的程序。這些項目都是開源的，并包含開發(fā)者使用Truffle框架所編寫的測試用例。本文選擇這些實驗對象是因為就代碼大小而言，它們是Github上存在的最復雜的DApp。本文研究的所有實驗對象、測試用例、漏洞以及其攻擊的例子將發(fā)布到項目網(wǎng)站。為了調(diào)查問題3，本文使用了以太坊主網(wǎng)上的8 314個智能合約實例，對這些實驗結(jié)果的解釋可以在6.1節(jié)中找到。

表2 應(yīng)用在現(xiàn)有項目的實驗結(jié)果

表3 人工植入的漏洞實驗

7.2 真實漏洞的實驗研究

根據(jù)6個已報告的智能合約漏洞和對應(yīng)的攻擊方式（見表2），本文實驗嚴格按照這些報告構(gòu)建能觸發(fā)漏洞的攻擊交易。然后將此交易與從以太坊主網(wǎng)中隨機選擇的99個正常交易混合在一起，以創(chuàng)建一個測試用例，即100條交易組成的序列。攻擊交易被隨機放置在序列末尾10%位置。為了避免巧合，實驗過程中重復此過程以創(chuàng)建100個不同的測試用例。智能合約創(chuàng)建部署方式來自主網(wǎng)，并在測試用例之間共享。

由于沒有開發(fā)者針對這些智能合約所寫的測試用例，因此實驗過程中省略了智能合約的訓練過程，從空的安全路徑集開始。一開始假設(shè)管理員會檢查所有在正常交易中引發(fā)的錯誤警報，并且這些正常交易的路徑將立即插入安全路徑集中。在此假設(shè)下，將ContractGuard應(yīng)用于每個智能合約并使用100個測試用例執(zhí)行它們，用召回率衡量測試結(jié)果，召回率觸發(fā)警報的測試用例數(shù)量占所有測試用例數(shù)量的百分比，即觸發(fā)警報的測試用例數(shù)量/所有測試用例數(shù)量×100%。

表2顯示了實驗結(jié)果。對于所有測試，召回率為100%。這表明ContractGuard可以有效地防御這些已知漏洞。另外，運行開銷、部署開銷和錯誤警報與之前在主網(wǎng)上的8 314個智能合約上（第6.1節(jié)）觀察到的結(jié)果一致。截至2019年8月30日，平均Gas價格為1.4683×10-8ETH，ETH的價格為$ 168.21[54]。如表2所示，最大的部署和運行開銷是分別為59 846.26 Gas和68 371.95 Gas。因此，如果管理員要在這6個現(xiàn)實世界中的智能合約上應(yīng)用ContractGuard來提供入侵檢測，最多需要在智能合約部署時為每個智能合約支付額外$0.147，而用戶最多需要為每筆交易支付額外$0.168 9。

7.3 人工植入漏洞的實驗研究

表3中的DApp來自開源項目并且?guī)в谢赥ruffle框架所寫的測試用例。當需要將ContractGuard運用到實際中的DApp時，這些測試用例是用來收集安全路徑的最佳選擇，但這些DApp不存在任何已報告的漏洞。為了方便實驗，本文參考了表1中的11個主要漏洞，并人工植入了其中的4種漏洞。

1) ＃3算術(shù)上溢/下溢：用直接算術(shù)運算符替換SafeMath[55]調(diào)用。

2) ＃4默認可見性：刪除關(guān)鍵字“private”。

3) ＃6未檢查的send：刪除整個用于檢查send和transfer返回值的分支。

4) ＃11邏輯錯誤：替換關(guān)系運算符和邏輯運算符。

植入其余7種漏洞是困難的，要么因為它們與智能合約代碼（＃5，＃7，＃10）沒有直接關(guān)系，要么因為這些程序沒有可以植入這些漏洞的相關(guān)程序結(jié)構(gòu)（＃1，＃2，＃8，＃9）。值得注意的是，第一個實驗包含漏洞＃1，＃2，＃8。

對于每個DApp，本文研究盡可能多地植入安全漏洞。漏洞總數(shù)和這4個漏洞各自的總數(shù)為表3的人工植入漏洞總數(shù)列中。然后，在每個植入了安全漏洞的DApp上執(zhí)行開發(fā)人員所寫的測試用例，無法通過測試用例的人工構(gòu)造版本將被丟棄。

接下來，隨機抽取100個交易來創(chuàng)建一個測試用例，這100個交易來自測試池，測試池主要由主網(wǎng)和手動構(gòu)建的一批用于觸發(fā)植入漏洞的交易組成。在原始DApp和植入漏洞的DApp上都執(zhí)行測試用例。

如果兩份DApp都通過了測試用例，但是各自的智能合約存儲值在執(zhí)行交易后存在差別，就將此植入漏洞的DApp添加到目標測試集中，并將此交易標記為攻擊交易。重復此過程，直到每個目標測試集有了100個測試用例。但使用這些目標測試集來模擬開發(fā)人員測試用例無法檢測部署后可能成為被黑客利用的漏洞。表3主要植入的漏洞列中報告了它們的總數(shù)以及4個漏洞的總數(shù)。對于每個目標測試用例，應(yīng)用ContractGuard并使用開發(fā)人員提供的測試用例進行訓練。然后用DApp執(zhí)行100個測試用例。測量哪些測試用例成功引發(fā)了警報并在攻擊交易中進行回滾，并以該測試用例數(shù)量的占比（成功回滾測試用例數(shù)量/測試用例總數(shù)量×100%）作為該DApp召回率。由于存在多個人工植入漏洞的DApp，因此報告每個DApp的平均召回率。

表3顯示了實驗結(jié)果。所有DApp的平均召回率為83.3%。對剩余16.7%的情況，經(jīng)檢查發(fā)現(xiàn)，所有ContractGuard不能防護人工植入的漏洞都是邏輯錯誤。ContractGuard無法阻止邏輯錯誤是因為出現(xiàn)了一種奇妙的“巧合”：開發(fā)人員提供的測試用例與攻擊交易觸發(fā)了智能合約相同路徑，但DApp運行時并沒有出現(xiàn)異常，因此攻擊交易的路徑被放入了安全路徑集中，導致ContractGuard無法發(fā)現(xiàn)偵察出異常。

7.4 影響開銷的因素

為了調(diào)查可能影響額外開銷的因素，本文將ContractGuard的實現(xiàn)分解為各種探針（IP），每種探針表示原始代碼中要插入檢測代碼的點。

表4顯示了每種探針的部署/運行Gas消耗。部署成本很簡單，即檢測代碼的字節(jié)大小乘以200。最高開銷來自每份智能合約開始時的智能合約構(gòu)造器。這就是為什么較小的智能合約往往具有較高的部署開銷。本文實驗使用EVM的Gas模型計算運行時開銷[18]。如表4所示，除了合同構(gòu)造的前期成本外，最昂貴的開銷是外部調(diào)用不受保護的合約。成本高是因為需要將變量ctx存入智能合約持久存儲：一條在存儲中重寫256 bit的SSET指令需要花費5 000 Gas。這是檢測出可重入控制流的代價。請注意，對受保護的智能合約進行外部調(diào)用要便宜得多，因為在這種情況下ctx可以在消息調(diào)用數(shù)據(jù)內(nèi)部傳遞，而無須執(zhí)行開銷昂貴的寫入智能合約持久存儲操作。

表4 探針在各類嵌入點中的開銷

注：是初始的安全路徑集大小。

7.5 討論

本文實驗中出現(xiàn)的幾個問題值得進一步討論和分析并作研究。

1) 目前，由于特殊的“巧合”，ContractGuard可能無法非常有效地防御復雜的邏輯錯誤。短路求值就是一個典型的例子，本文研究推測可以通過添加針對判斷短路求值的虛擬分支來提高ContractGuard的有效性。在未來的研究中，計劃對此問題進行更深入的探索。

2) 因為外部調(diào)用未受保護的智能合約時會產(chǎn)生的昂貴開銷，ContractGuard實際應(yīng)用于有著豐富特性的智能合約時會產(chǎn)生相當高的額外開銷。盡管這似乎是一個限制，但應(yīng)該注意到調(diào)用不信任的合約是一種危險的做法，不鼓勵這種編寫智能合約的方式[37]。另外ContractGuard在外部調(diào)用受保護的合約時并不會產(chǎn)生高成本，這是多份智能合約所組成的程序（即DApp）中常規(guī)做法。

3) 盡管在現(xiàn)有的以太坊主網(wǎng)中未發(fā)現(xiàn)智能合約大小超過24 576 B的情況，但不排除使用ContractGuard后智能合約大小會超出這個范圍。這種情況原因可能是初始安全路徑設(shè)置太大，導致其不能作為一個嵌入式列表或嵌入式完美哈希表。在這種情況下，ContractGuard將使用智能合約存儲一些路徑。這將大大增加部署開銷，因為管理員需要支付額外的費用才能寫入智能合約存儲，而每條路徑將花費20 000 Gas。但是這不會增加運行開銷，因為每次集合成員測試始終包含對智能合約存儲的訪問，以檢查是否有動態(tài)添加的路徑，并且不論映射大小如何，訪問成本都是不變的。

8 結(jié)束語

從管理員的角度來看，以太坊智能合約程序在部署后容易受到攻擊。一旦合約部署后，任何地方的用戶都可以匿名檢查它的實現(xiàn)和當前的智能合約狀態(tài)。而一旦一個漏洞被發(fā)現(xiàn)，只要黑客擁有足夠的以太幣，他們會立即進行入侵攻擊。造成的損害一旦被主鏈接受將會是不可挽回的，也沒有機會來修復這個錯誤。

在本文研究工作中，首要目標是解決這個無法修補損失的現(xiàn)狀，并為管理員提供一次彌補損失的機會。本文提出的ContractGuard是第一個以太坊智能合約的入侵檢測系統(tǒng)，并通過嵌入式架構(gòu)把入侵檢測系統(tǒng)嵌入智能合約中，實現(xiàn)了在以太坊虛擬機的受限和抗干預環(huán)境中對智能合約進行異常檢測和防護。通過將ContractGuard應(yīng)用在現(xiàn)實世界以太坊主網(wǎng)的智能合約，本文證明了ContractGuard只需要較低的部署開銷與運行開銷即可以有效地防護漏洞。

[1] NAKAMOTO S, Bitcoin: a peer-to-peer electronic cash system[EB].

[2] BUTERIN V. A next-generation smart contract and decentralized application platform[EB].

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

[4] KRUPP J, ROSSOW C. Teether: gnawing at Ethereum to automatically exploit smart contracts[C]//27th USENIX Security Symposium (USENIX Security 18). 2018: 1317-1333.

[5] CHEN T, LI X, LUO X, ZHANG X. Under-optimized smart contracts devour your money[C]//Software Analysis, Evolution and Reengineering (SANER). 2017: 442-446.

[6] KALRA S, GOEL S, DHAWAN M, et al. ZEUS: analyzing safety of smart contracts[C]//NDSS. 2018.

[7] BRENT L. Vandal: a scalable security analysis framework for smart contracts[J]. arXiv preprint arXiv:1809.03981, 2018.

[8] ZAKRZEWSKI J. Towards verification of Ethereum smart contracts: a formalization of core of solidity[C]//Working Confer-ence on Verified Software: Theories, Tools, and Experiments. 2018: 229-247.

[9] NIKOLI? I, KOLLURI A, SERGEY I, et al. Finding the greedy, prodigal, and suicidal contracts at scale[C]//The 34th Annual Computer Security Applications Conference. 2018: 653-663.

[10] GRECH N, KONG M, JURISEVIC A, et al. MadMax: surviving out-of-gas conditions in Ethereum smart contracts[J]. Proceedings of the ACM on Programming Languages, 2018, 2: 1-27.

[11] JIANG B, LIU Y, CHAN W K. Contract fuzzer: fuzzing smart contracts for vulnerability detection[C]//33rd ACM/IEEE International Conference on Automated Soft-ware Engineering. 2018: 259-269

[12] LIAO H J, LIN C H R, LIN Y C, et al. Intrusion detection system: a comprehensive review[J]. Journal of Network and Computer Applications, 2013(36): 16-24.

[13] Understanding the DAO attack[EB].

[14] Parity multisig hacked again[EB].

[15] ZHANG T, ZHUANG X, PANDE S, et al. Anomalous path detection with hardware support[C]//The 2005 International Conference on Compilers, Architectures and Synthesis for Embedded Systems. 2005: 43-54.

[16] FENG H H, KOLESNIKOV O M, FOGLA P, et al. Anomaly detection using call stack information[C]//2003 Symposium on Security and Privacy. 2003: 62-75.

[17] GARFINKEL T, ROSENBLUM M. A virtual machine introspection based architecture for intrusion detection[C]//NDSS. 2003: 191-206.

[18] WOOD G. Ethereum yellow paper[EB].

[19] GIFFIN J T, JHA S, MILLER B P. Efficient context-sensitive intrusion detection[C]//NDSS. 2004.

[20] XU H, DU W, CHAPIN S J. Context sensitive anomaly monitoring of process control flow to detect mimicry attacks and impossible paths[C]//International Workshop on Recent Advances in Intrusion Detection. 2004: 21-38.

[21] BALL T, LARUS J R. Efficient path profiling[C]//29th Annual ACM/IEEE International Symposium on Microarchitecture, 1996: 46-57.

[22] BELAZZOUGUID, BOTELHO F C, DIETZFELBINGER M. Hash, displace, and compress[C]//European Symposium on Algorithms. 2009: 682-693.

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

[24] GROSSMAN S. Online detection of effectively callback free objects with applications to smart contracts[C]//ACM on Programming Languages, 2017(2): 48.

[25] 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, 2018: 243-269.

[26] LARUS J R. Whole program paths[C]//ACM SIGPLAN 1999 Conference on Programming Language Design and Implementation (PLDI). 1999, 34: 259-269.

[27] MELSKI D, REPS T. Interprocedural path profiling[C]// International Conference on Compiler Construction. 1999: 47-62.

[28] D’ELIA D C, DEMETRESCU C. Ball-larus path profiling across multiple loop iterations[J]. ACM Sigplan Notices, 2013, 48: 373-390.

[29] SUMNER W N, ZHENG Y, WEERATUNGE D, et al. Precise calling context encoding[J]. IEEE Transactions on Software Engineering, 2012, 38(5): 1160-1177.

[30] AMMONS G , LARUS J R. Improving dataflow analysis with path profiles[J]. ACM SIGPLAN Notices, 1998, 33: 72-84.

[31] ERNST M D, COCKRELL J, GRISWOLD W G, et al. Dynamically discovering likely program invariants to support program evolution[J]. IEEE Transactions on Software Engineering, 2001, 27(2): 99-123.

[32] KUMAR V, SANGWAN O P. Signature based intrusion detection system using SNORT[J]. International Journal of Computer Applications & Information Technology, 2012, 1(3): 35-41.

[33] CUI W, PEINADO M, WANG H J, et al. Shieldgen: automatic data patch generation for unknown vulnerabilities with informed probing[C]//2007 IEEE Symposium on Security and Privacy (SP’07). 2007: 252-266.

[34] DANNEN C. Introducing Ethereum and solidity[M]. Berlin: Springer, 2017.

[35] ZHUANG X, SERRANO M J, CAIN H W, et al. Accurate, efficient, and adaptive calling context profiling[J]. ACM Sigplan Notices, 2006(41): 263-271.

[36] LI X, JIANG P, CHEN T,et al. A survey on the security of blockchain systems[C]//Future Generation Computer Systems. 2017.

[37] MANNING D A. Solidity security: comprehensive list of known attack vectors and common antipatterns[EB].

[38] DERIVATIVES D N | T. A survey of solidity security vulnerability[EB].

[39] BEC spiked 4000% on first trading day, another pump-and-dump scheme[EB].

[40] WANG X, CHEUNG S C, CHAN W K, et al. Taming coincidental correctness: coverage refinement with context patterns[C]//ICSE. 2009: 45-55.

[41] Truffle Suite. Sweet Contracts[EB].

[42] BALL T, LARUS J R. Optimally profiling and tracing programs[J]. ACM Transactions on Programming Languages and Systems (TOPLAS), 1994, 16(4): 1319-1360.

[43] TJHAI G C, PAPADAKI M, FURNELL S M, et al. Clarke, investigating the problem of IDS false alarms: an experimental study using snort[C]//IFIP International Information Security Conference. 2008: 253-267.

[44] Understanding the DAO attack[EB].

[45] An in-depth look at the parity multisig bug[EB].

[46] Post-mortem[EB].

[47] Detecting integer arithmetic bugs in Ethereum smart contracts[EB].

[48] Smart contract wallets created in frontier are vulnerable to phishing attacks[EB].

[49] MerdeToken[EB].

[50] CryptoKitty[EB].

[51] StatusNetwork[EB].

[52] DecentralizedVoting[EB].

[53] PoolShark[EB].

[54] Etherscan[EB].

[55] SafeMath OpenZeppelin[EB].

ContractGuard:defend Ethereum smart contract with embedded intrusion detection

ZHAO Gansen1,2,3, XIE Zhijian1,2,3, WANG Xinming1,2,3,4,5, HE Jiahao1,2,3, ZHANG Chengzhi5, LIN Chengchuang1,2,3, Ziheng ZHOU1,3,6, CHEN Bingchuan3,7, Chunming RONG8

（1. South China Normal University School of Computer Science, Guangzhou 510000, China2. Guangzhou Key Laboratory of Cloud Computing Security and Assessment Technology, Guangzhou 510000, China 3. VeChain blockchain technology and application joint laboratory, Guangzhou 510000, China 4. Lakala Payment Company Limited,Beijing 100080, China 5. HK University of Science and Technology, Hong Kong 999077, China 6. VeChain Foundation Limited, Singapore 2384637. Guangdong university of finance and economics, Guangzhou 510000, China 8. Stavanger University, Stavanger 4036, Norway）

Ethereum smart contracts are programs that can be collectively executed by a network of mutually untrusted nodes. Smart contracts handle and transfer assets of values, offering strong incentives for malicious attacks. Intrusion attacks are a popular type of malicious attacks. ContractGuard, the first intrusion detection system (IDS) was proposed to defend Ethereum smart contracts against such attacks. Like IDSs for conventional programs, ContractGuard detects intrusion attempts as abnormal control flow. However, existing IDS techniques or tools are inapplicable to Ethereum smart contracts due to Ethereum’s decentralized nature and its highly restrictive execution environment. To address these issues, ContractGuard was designed by embedding it in the contracts. At runtime, ContractGuard protects the smart contract by monitoring the context-tagged acyclic path of the smart contract. As ContractGuard involves deployment overhead and deployment overhead. It was optimized under the Ethereum Gas-oriented performance model to reduce the overheads. The experimental results show that this work can effectively detect 83% of vulnerabilities, ContractGuard only adds to 36.14% of the deployment overhead and 28.27% of the runtime overhead.

blockchain, Ethereum smart contract, intrusion detection system, anomaly detection

HKSAR (No.RGC/GRF16202917), The National Key R&D Program of China (No.2018YFB1404402), Guangdong Science &Technology Fund (No.2019B010137003), Guangzhou Science & Technology Fund (No.2016B030305006, No.2018A07071702, No.201804010314, No.2012224-12), VeChain Foundation (No.SCNU-2018-01), Guangdong Provincial Department of Education Characteristic Innovation Project (Natural Science) (No. 2017KTSCX074)

TP393

A

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

趙淦森（1977? ），男，廣東東莞人，華南師范大學教授、博士生導師，主要研究方向為信息安全、區(qū)塊鏈。

謝智健（1995? ），男，廣東云浮人，華南師范大學碩士生，主要研究方向為軟件測試、區(qū)塊鏈應(yīng)用。

王欣明（1980? ），男，香港科技大學博士生，主要研究方向為金融科技、軟件測試與軟件分析、區(qū)塊鏈。

何嘉浩（1995? ），男，廣東廣州人，華南師范大學碩士生，主要研究方向為軟件分析、區(qū)塊鏈應(yīng)用。

張成志（1963? ），男，中國香港人，香港科技大學教授、博士生導師，主要研究方向為軟件工程。

林成創(chuàng)（1990? ），男，廣東韶關(guān)人，華南師范大學博士生，主要研究方向為計算機視覺、醫(yī)療人工智能。

Ziheng Zhou（1979? ），男，新加坡人，博士，主要研究方向為區(qū)塊鏈、共識算法、計算機視覺和機器學習。

陳冰川（1975? ），男，廣東財經(jīng)大學講師，主要研究方向為人工智能、推薦系統(tǒng)和軟件工程。

Chunming Rong（1969? ），男，挪威人，挪威工程院院士，挪威斯塔萬格大學終身教授，主要研究方向為區(qū)塊鏈。

論文引用格式：趙淦森, 謝智健, 王欣明, 等. ContractGuard: 面向以太坊區(qū)塊鏈智能合約的入侵檢測系統(tǒng)[J]. 網(wǎng)絡(luò)與信息安全學報, 2020, 6(2): 35-55.

ZHAO G S, XIE Z J, WANG X M, et al. ContractGuard: defend Ethereum smart contract with embedded intrusion detection[J]. Chinese Journal of Network and Information Security, 2020, 6(2): 35-55.

2020?01?15；

2020?03?25

王欣明，wangxinming@lakala.com；張成志，scc@cse.ust.hk

中華人民共和國香港特別行政區(qū)政府資金資助項目（No.RGC/GRF16202917）；國家重點研發(fā)計劃基金資助項目（No.2018YFB1404402），廣東省重點研發(fā)計劃基金資助項目（No.2019B010137003）；廣東省科技計劃基金資助項目（No.2016B030305006, No.2018A07071702, No.201804010314, No.2012224-12）；唯鏈基金會資金資助項目（No.SCNU-2018-01）；廣東省教育廳特色創(chuàng)新項目（自然科學）（No.2017KTSCX074）