以太坊智能合約的漏洞自動化修復技術研究

傅紫薇，沈子牛，陳云芳，張 偉

(南京郵電大學 計算機學院，江蘇 南京 210023)

0 引 言

區塊鏈技術依據去中心化、不可篡改和公開透明等特性[1]，在近年受到了廣泛關注。區塊鏈2.0開始，智能合約與區塊鏈技術相結合，智能合約的引入使得各種去中性化應用程序DApps迅速發展，極大地豐富了區塊鏈的應用場景。但智能合約也帶來了一系列安全問題。以太坊作為目前最流行的智能合約平臺之一，已經發生了多起重大安全事件，在這些安全事件中，絕大多數是由于智能合約被攻擊所致[2]。例如，2018年4月美鏈BEC的智能合約因其整數溢出漏洞而遭受攻擊[3]，導致60億BEC代幣轉移到惡意賬戶，使得BEC市值幾乎歸零，給BEC市場交易帶來了嚴重的影響。2020年4月，黑客對DeFi交易平臺Lendf.Me[4]的智能合約實施了攻擊，損失金額達2500萬美元。

智能合約正處于發展階段，在設計、開發和應用過程中常存在某些缺陷，且很多基于智能合約的去中心化應用涉及資金流轉，存在漏洞的合約更易成為攻擊者重點關注的目標，因而智能合約安全上鏈前的合約代碼安全審計和修復工作十分關鍵。到目前為止，已經有大量的漏洞自動檢測方法或工具被研發，他們重點關注某種或幾種漏洞類型，以設計專門的檢測方法發現這些漏洞，但在整個智能合約安全保障過程中這些還并不足夠。相比于傳統程序，智能合約在程序開發、編程語言和代碼優化等方面的發展尚不完善，一些開發人員可能并不知道如何正確修改這些漏洞代碼，并且人工修復需要消耗大量資源。漏洞自動化修復技術可以實現漏洞代碼修復的自動化，能解決人工維護能力不足的問題，降低人工維護的成本，提高代碼質量，因此加深對智能合約漏洞自動修復技術的研究很有必要。

該文提出了一個包含漏洞識別和補丁生成兩大關鍵步驟的智能合約部署前漏洞自動化修復流程，主要工作與貢獻如下：

(1)提出了一個適應于自動化修復智能合約漏洞的框架，包括基于智能合約樣本和漏洞庫的輸入、漏洞檢測和報告生成、智能合約的修復以及修復后的驗證；

(2)基于框架的關鍵部分，分析了典型的智能合約漏洞產生原因和漏洞識別技術，分類歸納了基于字節碼和源碼級別生成補丁的最新研究進展；

(3)總結了修復后合約所需滿足的條件，并從有效性、成本問題、可擴展性三個方面展開討論了補丁修復技術的性能評估需求。

1 相關背景

智能合約是對現實中的合約條款執行電子化的量化交易協議[5]，區塊鏈技術的發展為其提供了可信的執行環境。智能合約是傳統合約的數字化版本，簽署合約的參與者在內容上達成一致，存在形式為一段可在區塊鏈上滿足執行條件后自動執行的代碼，它能實現區塊鏈中各類數據的控制和管理，可應用于去中心化金融、醫療保健、供應鏈和物聯網等多個方面。由于運行于區塊鏈之上，智能合約遵循區塊鏈的種種機制，其程序特性與傳統應用程序也有所差異。

1.1 Gas機制

區塊鏈是一種分布式系統，設計者引入激勵機制使得這類去中心化網絡可以達成共識，以保證網絡狀態的一致性。主流的共識算法有工作量證明PoW、權益證明PoS、授權股份證明DPoS等[6]，通過共識算法可以決定哪個網絡節點擁有新區塊的記賬權。在以太坊中，網絡節點主要采用PoW共識算法來競爭記賬權，需要打包的交易都位于交易池中，擁有記賬權的節點負責打包交易并記錄到新區塊。交易種類包括普通轉賬交易、創建合約交易和調用合約交易。智能合約的部署和調用，都通過交易的形式來實現。智能合約的執行和交易合法性的驗證，都將占用一定的資源，因此擁有記賬權的節點可以收取一定的費用作為獎勵，即Gas費用。

智能合約每一條指令的執行都對應一定的Gas消耗，以太坊技術黃皮書[7]詳細講解了不同指令消耗的Gas數量，例如創建合約、數據存儲等操作比較昂貴，需消耗更多的Gas數量。用戶發起交易時需自行設定愿意支付的Gas用量上限并上交費用，執行合約代碼過程中交易實際產生的費用等于實際消耗的Gas用量與單位Gas價格乘積所得的值，單位Gas的價格隨市場變化而變化。如果交易執行完之后還有剩余Gas,將退還給交易發送方，而一旦執行超過了Gas用量上限，交易將會失敗導致交易回滾，但在這個過程中已經消耗的Gas用量并不會退還，Gas機制的設計除了起到獎勵礦工的作用，還在一定程度上防止了以太坊中一些惡意交易和資源浪費現象的發生。

1.2 智能合約運作過程

以太坊是最具代表性的智能合約應用平臺，開發以太坊智能合約的編程語言主要是Solidity，除此之外還有Vyper、LLL等。編碼完成后的智能合約，由以太坊虛擬機(environment virtual machine，EVM)執行編譯過程。EVM是一個基于堆棧的虛擬機，為智能合約提供運行環境，將智能合約源代碼編譯成可在以太坊上執行的字節碼。字節碼由一串十六進制的數字組成，以一個字節為單位，每個字節對應一個操作碼(指令)或操作數。EVM字節碼指令集中目前大約有100多條指令，常見的有堆棧操作指令：PUSH、POP ,跳轉指令：JUMPI，數據讀寫操作指令:MLOAD、MSTORE、SLOAD、SSTORE，算數運算操作指令：ADD、MUL、SUB等。

以太坊的賬戶分為合約賬戶和外部賬戶[8]。合約所有者充當外部賬戶的角色向地址0X0處發起一個交易，交易中的data域中存放合約字節碼，并將交易的轉賬金額設為0，通過這種方式實現合約的創建。創建合約的交易利用區塊鏈中的共識機制實現部署，具體來說，區塊鏈P2P網絡中的全節點首先各自在本地執行創建合約的交易，運行合約代碼并修改數據和狀態，經共識算法決定出擁有記賬權的礦工后，礦工打包交易更新區塊，而后其他節點根據區塊中的交易再執行一遍，更新本地的數據和狀態達到同步，完成部署過程。

最后，每個部署之后的合約會生成唯一的地址，形成合約賬戶。用戶使用外部賬戶向合約賬戶發起交易，同樣經過區塊鏈共識的過程對交易進行驗證并執行，從而調用已經被部署在鏈上的智能合約。部署之后的合約具有不可篡改、公開透明等特點。用戶可以通過運行在windows、linux等操作系統上的以太坊客戶端實現合約調用的操作，EVM確認觸發智能合約的條件滿足后，解釋執行合約代碼。

1.3 智能合約與傳統應用程序的區別

智能合約作為圖靈完備的程序腳本，與傳統應用程序有多個方面的區別，表1展示了智能合約應用與傳統軟件應用在不同角度的對比分析。

表1 智能合約應用與傳統軟件應用對比分析

基于以上的比較，從學習成本、開發難度等方面來看，由于智能合約發展歷史較短，各種開發指導文檔以及測試框架都比較匱乏，Solidity作為一種較新的編程語言，自身也存在很多局限性，而且缺少功能強大的調試器，這些因素導致智能合約開發人員的學習成本和開發難度更高；從安全需求方面來看，傳統應用程序的編碼通常對用戶不可見，只在用戶層提供一些接口，而智能合約的公開可見性，增加了受攻擊的風險，又由于涉及大量資金交易，智能合約對安全性的要求比傳統應用程序更嚴格；另外，從代碼優化和漏洞修復方面來看，傳統軟件應用往往注重于功能擴展和安全性能的優化，而智能合約遵循Gas機制，使得合約代碼在優化和漏洞修復過程還需著重考慮成本問題。Gas機制是智能合約性能優化過程中，區別于傳統軟件應用的一個顯著特征。

2 智能合約漏洞自動化修復框架

智能合約與傳統應用程序存在的種種差異為智能合約的安全問題及其漏洞自動修復技術帶來了不一樣的挑戰。當前針對智能合約漏洞檢測的研究較多，而修復技術的研究相對較少，也缺乏整體認識。對于智能合約上鏈前的代碼漏洞修復，認為其同傳統軟件修復技術[10-11]具有一些共性，同樣存在漏洞定位、補丁生成和補丁驗證等步驟，基于此，可以建立專注于智能合約的自動化修復方案。該文總結性地提出了適應于智能合約漏洞自動化修復技術的研究框架，符合目前已有的智能合約漏洞自動化修復的一般流程，如圖1所示。

圖1 智能合約漏洞自動化修復框架

首先，將待測合約Solidity源碼或者編譯之后的字節碼作為輸入，利用智能合約漏洞庫中相關漏洞類型和特征的記錄，對合約代碼進行漏洞分析，再采用漏洞檢測技術識別漏洞，判斷是否存在安全漏洞并生成漏洞檢測結果報告。報告可以是json格式的文件，其中包含漏洞的類型和所在位置等重要說明。

特征提取與識別是自動修復過程的前提，其識別與定位的準確性會對后面的修復工作產生直接的影響，近年來得到了研究人員的廣泛專注。主要可采取模糊測試、符號執行、污點分析以及形式化驗證等不同的方法手段[12]對程序進行分析，或者嵌入現有的多種漏洞自動檢測工具形成docker鏡像提供漏洞檢測的功能，為后續進行補丁修復提供有效信息。

補丁修復與驗證是消除漏洞的關鍵步驟，依據漏洞報告產生的漏洞分析與定位描述，將通過自動修復方案產生一系列補丁修復語句或根據預先定義的修復模板，生成候選補丁。然后在漏洞位置依據候選補丁進行增加、刪除和替換語句的操作，再通過軟件測試方法使用測試集測試或者使用漏洞測試工具對修復代碼的正確性進行檢驗。目前已有的自動修復技術可根據修復語言級別分為基于字節碼修復與基于源碼修復，具體修復方案的性能可依據漏洞修復的有效性、Gas成本消耗、修復技術可擴展性等角度進行評估。

已修復合約和修復報告是通過漏洞修復技術生成的結果輸出。修復報告包含已修復漏洞類型的說明，并記載修復所在位置、具體操作、時間消耗等詳細信息，可供安全人員或開發人員查閱，有效減少合約開發過程產生的潛在漏洞，提高安全性。

針對智能合約漏洞自動化修復流程所依賴的關鍵部分，下面將展開分析與闡述智能合約漏洞特征識別和補丁生成相關的技術手段。

3 智能合約漏洞分析與識別

3.1 智能合約典型漏洞分析

識別智能合約漏洞需要提取代碼特征并分析特征，因此需要大量詳細的漏洞信息數據的支持，表2展示了現有的記錄智能合約漏洞信息的資源庫。漏洞資源庫對智能合約開發過程中常見的安全漏洞類型及其代碼實例做了描述，可為開發人員提供指導信息，也為安全審計的漏洞自動修復過程提供漏洞特征信息。

以太坊智能合約的安全漏洞種類眾多，根據漏洞發生的層次，可以分為高級語言、虛擬機和區塊鏈三個層面[13]。高級語言層面引入的安全漏洞主要與編程語言設計、用戶程序的編寫等存在缺陷有關，如整數溢出、未檢查外部調用返回值等，虛擬機層面的安全漏洞則與EVM的實現及其字節碼規范有關，如重入漏洞，而區塊鏈層面的安全漏洞則主要與區塊鏈本身的特性相關，如偽隨機數漏洞。下面主要介紹6種典型智能合約漏洞類型的產生原因以及相應的修復策略。

表2 智能合約漏洞信息庫

(1)重入漏洞。

智能合約在執行外部調用的交互過程中，某個合約調用另一個合約但被再次進入，或形成遞歸調用導致將此合約賬戶的資源消耗完的過程，稱為重入攻擊[14]。重入攻擊是智能合約中典型的攻擊手段之一。它攻擊成功的原因是合約中的代碼缺陷，即狀態變量的賦值操作在調用外部函數的語句之后發生。修復重入攻擊可以使用互斥鎖，保證事務執行的原子性，防止重新進入函數，或者將合約中的狀態變量賦值操作移動到在外部調用之前來避免漏洞發生。

(2)整數溢出。

一個整數變量在以太坊虛擬機中會被指定為固定大小的數據類型，因此只能存儲一定范圍內的數字，例如uint8類型的整數變量只能存儲0到255之間的數字，值為255時，如果加1將導致每一位數發生翻轉從而產生整數上溢，同理值為0時，減1會導致整數下溢。整數溢出漏洞也常出現在其他的編程語言當中。針對整數溢出的修復，可以通過使用OpenZeppelin維護的SafeMath庫來處理算術邏輯[15]，它封裝了算數運算接口，可以避免產生溢出漏洞。

(3)權限控制。

權限控制問題主要是合約中函數或變量的越權訪問，例如智能合約的Solidity編程語言與其他高級語言類似，也有public、private等函數屬性，這些屬性控制著訪問函數的方式[16]。沒有被正確設置訪問權限的函數，會增加它們被非法調用的風險。預防和修復這類漏洞，需要在代碼編寫過程中充分檢查并設置嚴謹的函數訪問權限，某些有訪問控制要求的變量可以使用函數修飾符modifier進行修飾。

(4)偽隨機數。

由于區塊鏈分布式共識的特征，以太坊的智能合約無法支持真正的隨機數。很多區塊鏈上的開獎類游戲采用隨機數邏輯作為開獎依據，利用區塊打包時間、區塊打包難度等信息作為計算隨機數的種子，這種方式產生的數是偽隨機數，有可能被預測到。針對隨機數攻擊的修復建議可以是使用鏈下方式生成隨機數，然后利用預言機oracle傳遞到鏈上供使用[17]。第二種方式，可以使用當前區塊的哈希值作為隨機數種子[18]，由于當前區塊在打包之前是不可被預測的，用戶提出交易請求后，合約記錄執行此交易所在區塊的區塊哈希值，此值無法被預測，可以促使產生隨機結果。

(5)Tx.origin漏洞。

Tx.origin是智能合約中的一個全局變量，返回最初調用合約的賬戶地址。如果受害合約內通過此變量對調用合約者的身份進行驗證[19]，容易產生Tx.origin漏洞。某些惡意的中間合約可能會利用Tx.origin變量等于最初調用受害合約的賬戶地址這一特征，實現越權操作。為避免這類攻擊事件的發生，在一些權限驗證的過程中盡量不要使用Tx.origin，而改用msg.sender，msg.sender返回的是當前調用合約的賬戶地址，可以阻止中間合約通過身份驗證。

(6)未檢查call返回值。

Solidity中的一些底層調用函數，如call()、callcode()、delegatcall()和send()，在執行結束之后僅返回布爾值true或false來表示是否執行正確，執行過程中若發生錯誤并不會拋出異常，而會直接繼續執行后面的代碼。所以如果對這類函數不進行返回值的檢查，將有可能致使意外發生[20]。處理這類漏洞最好是在調用這些函數時檢查其返回值，并對可能發生的異常預先設置解決方案。

3.2 漏洞檢測方法

近年來學術界對智能合約漏洞檢測進行了廣泛和深入的研究[21-22]，主要方法包含模糊測試、污點分析、符號執行、形式化驗證等。

模糊測試是向程序提供大量非預期的輸入，在運行時監測異常以發現漏洞的方法。對智能合約進行漏洞檢測時，模糊測試通過迭代生成隨機并且不同的交易，探索合約是否存在異常的執行狀態。ReGuard[23]是一種專用于檢測可重入漏洞的模糊分析器，其利用模糊器不斷生成隨機輸入，執行運行時跟蹤然后傳遞給檢測器檢測漏洞是否存在。Contractfuzzer[24]也是一款基于模糊測試的漏洞檢測框架，但擴展了檢測的范圍，可檢測包括重入漏洞、時間戳依賴等7種漏洞。

污點分析將輸入數據標記為污點作為源，在智能合約運行過程中進行傳播，追蹤污點傳播路徑并判斷數據的流向，從而發現可疑的數據操作來識別漏洞。Sereum工具[14]利用污點跟蹤技術監控智能合約執行過程中的數據流，自動檢測異常狀態，實現了對3種不同的重入攻擊模式的檢測。已有的一些漏洞檢測方案通常將其與符號執行技術融合，例如Osiris[25]為檢測智能合約整數溢出，首先通過符號分析確定程序路徑分支，將路徑中的執行指令傳遞給污點分析器，然后利用污點分析器在堆棧(Stack)、內存(Memory)、存儲(Storage)等位置引入污點并傳播污點，最后通過檢查已執行的指令中數據是否被整數溢出錯誤污染。

符號執行是一種程序分析方法，對智能合約進行分析時，使用符號值代替合約中的變量值，不斷解析指令形成可執行路徑，然后利用約束求解器求解滿足約束的輸入，檢測輸入的符號值是否存在異常問題。這種方法無需模擬以太坊上的執行環境動態地進行檢測，減少了不確定性，有良好的代碼覆蓋率，已經有多種基于符號執行開發的針對智能合約漏洞的靜態分析工具[26-27]。

形式化驗證的方法是利用形式化語言對智能合約進行建模，構建推理系統來驗證合約代碼的正確性，文獻[28]中總結了形式化驗證在智能合約方面的研究，并將已有的基于形式化驗證智能合約的方法分為8類進行闡述，分別是基于定理證明的形式化方法、基于符號執行的形式化方法、基于模型檢測的形式化方法、基于規約語言的形式化方法、基于形式化建模的形式化方法、基于有限狀態機的形式化方法、基于著色 Petri 網的形式化方法、基于運行時驗證的形式化方法。

除了這幾種主流方法，近年來機器學習的進步已經充分體現了其技術優勢，研究人員也積極嘗試結合機器學習算法[29-30]，對智能合約代碼進行特征提取，建立檢測模型來識別易受攻擊的智能合約，并得到了良好的性能。

4 智能合約漏洞補丁生成與驗證

4.1 補丁生成的相關技術

目前對智能合約進行補丁修復的技術主要采用了基于模板、基于遺傳搜索等，表3列出了已有的智能合約漏洞自動化修復工具。而從補丁修復的語言層面來看，可分為基于源代碼和基于字節碼的修復。源碼級別的修復對使用者來說具有更高的可讀性，字節碼的修復可獨立于源碼語言，避免版本原因造成不正確修復等問題。下面將分別對這兩類補丁修復工具所涉及的技術進行梳理和介紹。

表3 智能合約漏洞自動化補丁修復工具

(1)基于源碼。

智能合約源碼級別的漏洞修復直接對產生漏洞處的Solidity源碼進行程序分析，然后采用不同的修復技術產生Solidity源碼補丁進行自動修復。例如圖2(a)中代碼有典型的重入缺陷，結合漏洞類型及其產生的原因，sGUARD工具應用預定義的修復模板，給withdraw()取款函數添加一個nonReentrant_修飾器，應用了此修飾器的withdraw()函數會首先執行圖2(b)中第2～3行的語句，為函數中提取資金的進程上鎖，實現事務原子性，修復缺陷。此外sGUARD還構建了修復整數溢出和Tx.origin漏洞的補丁模板?；谀０宓男迯图夹g由于較高的針對性，其修復質量比較高，但其局限性在于只能用于修復特定的場景和有限的漏洞種類。

Yu等人[35]采用多任務遺傳算法實現了自動修復工具SCRepair，他們提出的搜索技術使用移動、插入、替換三種變異算子將大量小的語句變化植入漏洞合約，通過了所有測試集實例的補丁成為合約代碼的候選補丁。最終實現了異常處理漏洞、整數溢出、交易順序依賴、重入等問題的修復。為提升搜索效率，SCRepair將搜索空間分割為較小的互斥搜索空間，并使用并行搜索，同時通過公式計算候選補丁的Gas消耗篩選高質量補丁。這類方法的搜索深度往往有限，產生的補丁質量和修復速度也有待提升。

(a)重入漏洞代碼

(2)基于字節碼。

智能合約編譯之后形成字節碼，基于字節碼的修復往往先使用靜態分析技術分析程序的控制依賴關系、數據依賴關系，然后獲得字節碼級別的語義信息以識別不正確的數據流或控制流[31]，這個過程也可以直接使用當前已有的靜態漏洞檢測工具來實現。收集到錯誤的信息流之后，利用字節碼重定位技術，將字節碼補丁應用到相應位置，從而實現修復。

由于智能合約的運行環境EVM是基于堆棧的體系結構，程序跳轉指令JUMPI的目的地址(如0x000a)都會通過PUSH指令存放在堆棧中?；谧止澊a的修復在代碼地址空間中插入任何語句時，原先的空間布局都可能會改變，因此必須更新所有相關的地址引用，以確保修改后的程序能調用正確的地址引用,調整地址引用的過程稱為字節碼重定位。字節碼重定位是基于字節碼修復的技術重點同時也是技術難點。

為了解決這一挑戰，Rodler等人[32]實現的自動修復工具EVMpatch在利用靜態分析技術得到程序的控制流圖之后，將需要修復的指令所在的基本塊復制到代碼地址空間的末尾空閑處，然后對此基本塊使用預定義的字節碼補丁模板進行修正，再用JUMPI指令重定向到此基本塊，替換原始的基本塊。這樣就避免了初始的代碼地址空間被修改。但這種基本塊級別的重定位方式，在末尾處占據了與原始基本塊相同大小的地址空間，增加了整體的代碼量。

針對EVMpatch在字節碼重定位方面存在的不足，Ferreira等人[33]采用在預定義的模板中添加語義信息創建修復補丁，并在代碼漏洞之處做出直接修改的方式來修復漏洞。他們在修改之前先創建一個地址副本，用于記錄原始合約所有指令的地址。掃描程序控制流圖進行修復工作，如圖3中，插入虛線框內的修復語句之后，會更新地址副本中所有修復語句之后的所有地址指令。最后對于跳轉地址的更新，分兩步進行：第一步，找到修復后的地址空間中，所有不同于原始地址的JUMPDEST指令，記載它當前所在的地址,如圖3中的JUMPDEST地址由0x00c3變為0x00d2；第二步，查找PUSH值等于原始JUMPDEST指令地址的PUSH指令，使用地址副本中記錄的新值替換PUSH值,如圖3中等于原始JUMPDEST指令地址0x00c3的PUSH值應當替換為0x00d2。這種字節碼重定位的方式無需占用多余的地址空間，節省了一定的資源。

4.2 補丁的性能驗證

考慮智能合約與傳統應用程序的差異，驗證智能合約補丁修復方案性能評估指標所涉及的內容也有所不同，修復后的合約應該滿足以下3個先決條件：

(1)通過所有測試集中的測試用例，不存在漏洞報告中的漏洞；

(2)合約如需部署上鏈，執行消耗的Gas不超過其Gas用量上限；

(3)不影響原始合約的正常功能。

通過分析上述條件，從有效性、Gas消耗、可擴展性三個方面討論智能合約補丁修復的性能評估需求。

(1)有效性。

修改后的智能合約程序要求通過所有測試實例，且合約的正常功能不被破壞，保持與原始合約一致，才被認定是有效的修復。因此，有效性包含正確性和功能一致性兩方面。為了驗證智能合約修復的正確性，可利用軟件測試方法，使其通過測試用例集進行驗證，但這種方法的覆蓋率有限，另外還可以利用現有的漏洞檢測工具如slither[36]對修復合約進行漏洞測試，判斷漏洞是否已被修復，這種方式的驗證效果依賴于檢測工具本身的準確性。為了驗證功能一致性，可重現合約歷史交易。即通過區塊鏈瀏覽器如etherscan查詢大量的原始合約正常歷史交易記錄，分別對修復合約與原始合約模擬重現這些交易，判定兩者的功能是否一致。

(2)Gas消耗。

運行于區塊鏈系統上的智能合約，計算資源受到限制，Gas消耗問題需要著重考慮。代碼修復會改變代碼本身的大小，增加的計算會增加額外的Gas消耗，也因此在求解補丁修復語句時，在保證正確修復漏洞的情況下，應當追求更少的代碼改動和Gas消耗。一些智能合約漏洞補丁修復工具(如sGUARD、SMARTSHIELD等)通過重現合約交易的方式，比較修復合約與原始合約的Gas及時間消耗上的差異，來衡量他們的平均修復成本以及修復質量。為了優化補丁的質量，SCRepair綜合考慮會影響成本的參數，將智能合約的Gas消耗量化為一個計算公式，在產生大量候選的修復補丁時，通過公式計算Gas消耗并排序，擇優進行修復。

(3)可擴展性。

應用程序的功能需求可能會面臨更新，應用程序的擴展性表現為功能模塊之間的依賴與耦合程度。擁有良好擴展性的應用程序意味著可以更好地支持功能修改和拓展。對于智能合約漏洞的自動化補丁修復工具而言，如果實現模塊化的可修復漏洞種類增加、檢測功能與補丁修復功能分離，將可以提高其擴展性。ELYSIUM、EVMpatch等工具均直接利用了現有的漏洞檢測工具在補丁修復前定位合約的漏洞，并在補丁修復后驗證修復效果。

5 結束語

如前所述，已有部分研究人員在智能合約自動化修復問題方面做出了貢獻，并取得了一定的成果。但與傳統程序自動修復技術相對比，智能合約自動修復技術研究時間較短，仍有許多問題尚未得到解決，筆者認為未來在如下幾個方面值得關注：

(1)在漏洞識別階段，基于動態的運行測試方法，其檢測準確率依賴于測試用例，不能保證代碼覆蓋率，提高動態檢測方法的準確率需要有良好的測試用例集。而基于靜態的分析方法可能無法檢測一些運行時的異常行為，因而存在一定的誤報率。漏洞識別的準確性將直接關系到后續補丁修復工作，如何將幾種主流的方法相結合，融合各自的優勢以期找到更具適應性和更高準確率的智能合約漏洞檢測方案，是進一步研究的方向。

(2)目前已實現的補丁生成方案采用的技術方法比較單一，主要是基于模板或結合語義的方法。原因是前期程序分析階段過程中，利用代碼覆蓋率高的靜態分析技術可以方便地獲取程序語義信息，另外基于模板的補丁修復可以利用漏洞特征預先定義修復模式，修復效率較高。但基于模板修復的方式，其修復能力和范圍受限于預先定義的模板數量和質量，可修復漏洞的種類有限，難以廣泛應用，如何結合人工智能技術和智能合約應用場景語義以探索具有場景語義的修復模板值得探討。傳統軟件缺陷自動修復方面，已有基于搜索[37]、基于語義[38]、基于模板[39]以及基于統計分析[40]等多種方法，在未來的方案探索中，可進一步結合這些方法建立適用于智能合約部署前的自動化修復技術，填補當前的研究空缺。

(3)在漏洞補丁修復能力方面，已有的幾種補丁修復工具僅能修復2～7種漏洞，且這些工具關注更多的是高級語言或虛擬機層面的漏洞，而與區塊鏈本身特性有關的漏洞諸如時間戳依賴、條件競爭等很少被研究。隨著智能合約應用規模的發展，研究智能合約更深層次漏洞的自動修復技術顯得尤為重要，研究者需要加強對不同層面漏洞的關注，并不斷擴大可修復的漏洞類型。另外當前的一些自動化修復工具誤報率仍然較高，修復過程產生的額外成本也是一直有待改進的問題。

(4)智能合約上鏈之前的漏洞自動修復不是一個一蹴而就的工作，智能合約漏洞問題也不會因此完全消失，存有漏洞的合約部署上鏈之后暴露在公眾視野種將會存在更大的風險，鏈上合約安全問題同樣值得關注。智能合約升級作為一種修復驗證過程中遺漏錯誤的補救方案，可以根據地址重定向替換原先存在于鏈上的漏洞合約[41]。另外，一些研究提出了通過監測鏈上交易執行，及時阻止危險交易發生的方案來提高安全性[42]。合約升級和交易保護措施為解決鏈上合約安全提供了新的思路。

基于區塊鏈技術的智能合約上鏈之后難以修改，安全性需求高。該文以典型的以太坊平臺為例，介紹了智能合約的運行過程和開發特性，探討了其上鏈前安全審計過程中的漏洞自動修復技術，指出了當前技術方案在漏洞修復準確率、修復代價、修復覆蓋度等方面的不足，并提出了未來進一步研究的方向。