智能合約Gas 優化綜述

宋書瑋 倪孝澤 陳廳

（電子科技大學計算機科學與工程學院 成都 611731）

區塊鏈的概念最早在2008 年作為比特幣的底層技術被提出[1].最初，區塊鏈被視為一個分布式的公共賬本，記錄虛擬貨幣的所有交易.這個階段的區塊鏈僅局限于虛擬貨幣的開發和買賣.然而，隨著近年來區塊鏈技術的快速發展，它所具備的去中心化、防篡改、匿名、可審計等特性引起了學術界和工業界的廣泛關注，區塊鏈技術被認為可以應用于除虛擬貨幣以外更多的領域[2]，其中一個很有前景的應用是智能合約（smart contract）.

對智能合約的支持標志著區塊鏈進入2.0 時代[2].智能合約是一種根據預先定義的代碼邏輯在區塊鏈的多個節點上同步運行的計算機軟件[3].區塊鏈賦予智能合約不依賴可信中心機構而在相互不信任的節點上正確執行的能力[3].由于智能合約具備去中心化、抗偽造等傳統計算機軟件不具備的獨特優勢，它有潛力重塑銀行、保險和內容平臺等行業[4].目前，在最流行的支持智能合約的區塊鏈以太坊[5]中，已經部署了超過4 400 萬個智能合約[6].因此，本文主要關注以太坊以及其上部署的智能合約，下文中若無特殊說明，則區塊鏈特指以太坊區塊鏈，智能合約指部署在以太坊上的智能合約.

開發者通常使用高級語言（例如Solidity 和Vyper）編寫智能合約，開發完成后，將其編譯成能夠在以太坊虛擬機（Ethereum virtual machine，EVM）中運行的EVM 字節碼.然后，通過發送一筆特殊的交易將智能合約的字節碼部署到區塊鏈上.用戶可以發送交易來調用已經部署的智能合約，交易中應當指定用戶想調用的智能合約、接口，并攜帶接口所需的參數.根據以太坊黃皮書的規定，區塊鏈網絡中每個節點都應維護一份相同的區塊鏈副本，且都應執行存儲在區塊鏈中的所有交易[7].這表明部署后的智能合約被存儲在所有節點的磁盤中，被調用的智能合約在所有節點的EVM 中執行.綜上所述，部署和調用智能合約會消耗區塊鏈網絡中每個節點的計算資源（CPU、磁盤空間、內存等）.因此，攻擊者可以通過部署大量智能合約或者發起大量交易調用智能合約對區塊鏈實施拒絕服務攻擊[8].

為了應對上述的資源濫用和攻擊，以EVM 作為智能合約執行環境的區塊鏈（例如以太坊、BNB Smart Chain[9]和polygon[10]等）采用了燃料（Gas）機制向部署和調用智能合約這兩種活動收取費用.具體來說，區塊鏈根據被部署智能合約的大小和被調用的智能合約中執行的指令，分別向開發者和用戶收取費用.體積大的智能合約占用更多存儲空間，復雜的指令相較簡單的指令消耗更多資源，因此需要支付更多費用.

Gas 機制提高了攻擊者實施拒絕服務攻擊的成本，有效地防止了區塊鏈資源被濫用.然而，它同時也給智能合約的開發引入了新的挑戰.由于開發者缺乏經驗、不了解Gas 機制、編譯器優化不足和缺少輔助工具等原因，許多代碼效率低下的智能合約被部署到區塊鏈[11].此類智能合約實際消耗的費用大于其真正必需的費用，因此造成資源浪費.一方面，部署智能合約時，未經優化的冗余代碼消耗更多存儲空間，開發者將支付更多費用；另一方面，部署后的智能合約中低效率的代碼可能被調用無數次，這將浪費大量資源，用戶將支付更多費用；除此之外，未經優化的智能合約容易遭受攻擊（詳見2.2 節）.因此，研究智能合約優化方法具有重要的現實意義.

目前已經出現了一些智能合約優化方法，它們能夠從源代碼、字節碼等不同角度優化智能合約從而降低Gas 費用.基于目前研究進展，本文對現有的智能合約優化方法進行回顧與總結，概括出3 個研究挑戰和3 類典型的優化方法，希望能夠給當前和未來的智能合約優化相關研究提供一定的參考.

1 相關背景知識

1.1 區塊鏈、以太坊和智能合約

2008 年，Nakamoto[1]在其論文中提出了比特幣和一種點對點電子交易系統，該系統中的去中心化共享賬本通過密碼學方法保證其不可篡改和不可偽造.2009 年1 月，該系統首次發布，標志著比特幣的誕生.此后，比特幣因具備優于傳統貨幣的一些優良特性（例如去中心化、匿名、免監管和全世界流通等）而迅速吸引了大量關注.

區塊鏈是比特幣、以太幣以及類似數字加密貨幣的基礎，它本質上是若干數據區塊鏈接而成的一種鏈狀數據結構，并且使用數字簽名、加密哈希和分布式共識等算法來實現去中心化、可審計等特性[12].其中每個數據區塊記錄時間戳、若干交易和前一個區塊的哈希值[1].區塊鏈不存儲在某個中心化的服務器，而是存儲于P2P 網絡中的每個節點，即每個節點都存儲一份區塊鏈的副本并通過同步使副本之間保持一致[3].為了與其他節點達成共識，每個節點都會執行提交到區塊鏈上的交易[7].節點之間沒有上下級關系（即沒有中心節點）并且它們的地理位置是分散的，任何節點都可以加入或者退出該P2P 網絡.這表明所有的數據都是公開的，并且容易被任何節點驗證.因此，除非取得所有節點的一致同意，否則很難修改區塊鏈中記錄的交易[3].區塊鏈技術使得互不信任的雙方可以在不借助可信第三方的情況下安全地進行交易.

盡管數字加密貨幣是區塊鏈最早、最著名的應用，但區塊鏈的應用不止于此.智能合約的出現使得基于區塊鏈的更復雜的應用得以實現.智能合約一詞最早在1997 年被Szabo[13]提出，他認為將法律合同中的條款編寫成代碼，使其自動、強制地執行，可以減少成本并避免惡意行為.在其論文中，智能合約指使用軟件來實現和執行的法律合同.時至今日，智能合約在不同學科中有著不同的含義，其中一個概念被廣泛采用，本文也基于此概念展開研究：智能合約是根據預先定義的代碼邏輯在區塊鏈網絡的多個節點上自動、同步運行的軟件[14].智能合約具有4 點特性[13]：1）自動，即智能合約由交易觸發，然后自動地執行；2）自治，即一旦被觸發，就無法阻止智能合約執行；3）透明，即智能合約對區塊鏈網絡中的每個節點都是透明的；4）靈活，即智能合約可以根據不同的場景需求進行調整.

以太坊（Ethereum）自2015 年發布以來已經逐步發展為最流行的支持智能合約的區塊鏈平臺[3].以太坊采用與傳統銀行系統類似的賬戶模型[15]，它包含2個類型的賬戶：由公私鑰對控制的外部所有賬戶（external owned account，EOA）和由智能合約代碼控制的合約賬戶（contract account）.兩類賬戶的 主要區別在于：1）EOA 可以發送交易以調用智能合約，合約賬戶無法主動與EOA 交互，但它可以在執行過程中調用其他智能合約；2）合約賬戶包含智能合約代碼而EOA 沒有.

智能合約的生命周期通常包含開發、編譯、部署、調用、執行和銷毀6 個階段.

1）開發階段.開發者使用編程語言（例如：Solidity 和Vyper）開發智能合約.由于開發者的水平、經驗和目的不同，導致開發出的智能合約可能存在代碼效率低、包含惡意行為等問題.2）編譯階段.智能合約的源代碼被編譯成字節碼.字節碼由超過150種指令排列組合而成[7]，根據指令操作的對象可以將指令分為如表1 所示的5 類[8].每種指令的功能不一樣，因而執行它們所消耗的計算資源也不同.3）部署階段.開發者發起一筆接收者為空的交易，該交易將被區塊鏈視為合約部署請求.區塊鏈將創建一個新的合約賬戶來存儲交易中攜帶的智能合約代碼.4）調用階段.當交易的接收者是一個合約賬戶時，該交易被視為智能合約調用請求.根據交易中指定的函數和參數，事先部署的智能合約代碼將被執行.5）執行階段.以太坊提供一個基于棧的圖靈完備的虛擬機（EVM）來執行智能合約.EVM 中包含3 種存儲結構以輔助智能合約的執行：用于存放局部變量的棧（stack）、用于存放函數參數和返回值的內存（memory）和用于持久化存放數據的存儲（storage）.其中，棧和內存是非持久化的，它們在完成一次交易后將被清除，因此存儲的空間相較于棧和內存更加昂貴.6）銷毀階段.如果開發者計劃在未來銷毀智能合約，可以在開發階段添加“自毀”代碼，以便于從區塊鏈中抹除該合約賬戶.

Table 1 Five Types of Instructions for EVM表1 以太坊虛擬機的5 類指令

1.2 Gas 機制

如1.1 節所述，區塊鏈網絡中每個節點都應存儲區塊鏈的完整副本，并執行歷史上所有的交易以進行同步，如此重復的存儲和執行導致部署和調用智能合約會消耗區塊鏈網絡中每個節點的計算資源（例如CPU、磁盤空間、內存等）.為了防止計算資源被故意或無意地濫用，以太坊引入了Gas 機制，即根據交易消耗的計算資源向交易發送方收取費用，執行交易所需的計算資源越多，那么交易發送方需要支付的費用就越多[8].交易發送方在發起交易時應該指定愿意為此交易支付的Gas 總限額（gas limit），如果該限額比執行智能合約時實際花費的Gas 小，則會產生Gas 耗盡異常（out-of-gas exception）[8]，使得交易失敗.一旦一條交易失敗，區塊鏈將恢復到執行該交易之前的狀態，但是交易發起者支付的Gas 不會被退還，因為執行該交易已經消耗了節點的計算資源[16].Liu 等人[17]的研究發現Gas 耗盡異常在以太坊所有異常情況中占據90%以上，這在一定程度上表明：Gas 機制阻止了大量的意圖以不合理的/不夠的費用執行交易的用戶和攻擊者.

Gas 機制主要從3 個方面發揮作用[18]：1）向交易發起者收取費用可以抑制攻擊者通過發起毫無價值的交易來浪費節點的計算能力；2）通過設置較高的Gas 消耗，抑制用戶使用過多的存儲空間；3）使交易一定會終止，從而防止基于非終止交易的拒絕服務攻擊.

交易費用是Gas 價格（gas price）和Gas 消耗（gas cost）的乘積，其中Gas 價格是受市場影響的動態值，它指交易發起者愿意為每個單位的Gas 所支付的價格.例如，2022 年9 月23 日的平均Gas 價格為1.306×10?8以太幣[19]，約等于1.7×10?5美元[20].Gas 價格在不斷波動當中，峰值價格有時甚至能夠達到往常的百倍以上[19].影響交易費用的另一因素是Gas 消耗，是由以太坊規定的靜態值，每個EVM 指令都有其對應的Gas 消耗值，它是指執行某個指令需要多少單位的Gas[8].以太坊將指令的Gas 消耗與執行該指令所需的計算資源設計成正比.如表2 所示，有些指令所需的Gas 消耗相對較少（例如ADD，POP 和AND 等），因為它們只涉及簡單的操作，而另一些指令Gas 消耗較高（例如用于創建賬戶的指令CREATE 以及用于寫入存儲的指令SSTORE，值得注意的是，SSTORE指令將一個非零的值寫入存儲中原本為零值的位置時，它消耗20 000 個單位的Gas；其余情況消耗5 000個單位的Gas）.此外，部署智能合約的開發者也需要支付Gas，該費用與智能合約字節碼長度成正比[8].

綜上所述，交易發起者需要為部署和調用智能合約付費，例如向棧頂壓入一個數需要3 個單位的Gas（約等于5.1×10?5美元）.由于智能合約中包含若干條指令并且每個智能合約可能被調用無數次，所以即便一條指令所需的費用較低，智能合約所消耗的總費用也可能增長為一個龐大的數目.為了展示交易費用的規模及其影響，Albert 等人[16]統計了2017—2019 年用于交易的資金，調查結果顯示該數值達到了1.57 億美元.

Table 2 Gas Cost for Some Instructions [7]表2 某些指令的Gas 消耗[7]

2 Gas 優化的動機與挑戰

具備完全相同功能的智能合約可能有多種不同的實現，因而部署和調用它們所需要的Gas 也不盡相同.由于Gas 與金錢直接相關，用戶自然地愿意選擇使用功能完整且成本更低的智能合約，進而促使開發者對智能合約進行優化以減少Gas 開銷，然而一些挑戰阻礙了開發者完成這一目標.

2.1 低效的智能合約

受到包括但不限于開發者的開發經驗、編程習慣、使用的編程語言、開發工具等多種因素的影響，具備完全相同功能的智能合約可能有多種不同的實現.例如，Liao 等人[21]對智能合約的大規模實證研究發現智能合約中某些由高級語言編寫的代碼片段可以用內聯匯編替代，但不會改變或影響原智能合約的功能.

圖1 中展示了2 個具備完全相同功能的智能合約，即圖1（a）中的ExpensiveSampleContract 和圖1（b）中的CheapSampleContract.首先，它們的第2 行代碼都定義了一個無符號整數類型的全局變量count.值得注意的是，智能合約的全局變量被存放在存儲中.其次，從2 個智能合約的第3 行代碼開始，它們都定義了一個函數用于循環執行某種操作（例如：每次循環中若滿足某種條件就向一個賬戶轉移以太幣），并且count被用于記錄該操作執行的次數.2 個智能合約的差別在于：ExpensiveSampleContract 直接在循環中更新count；而CheapSampleContract 在循環操作之前先將count的值賦給一個臨時變量temp，然后在循環結束后將更新后temp的值賦給count.因此，CheapSampleContract 的代碼包含更多指令，并且運行時需要額外的空間來存儲局部變量temp.相較之下，ExpensiveSampleContract 似乎是相同功能下更優的一種實現.

Fig.1 Two smart contracts with identical functionality圖1 功能完全相同的2 個智能合約

然而，請注意1.1 節中提及的內容：存儲空間用于持久化存放數據并且每個節點都應維護副本，而棧和內存中的數據是非持久化的，因此存儲資源更昂貴.如表2 所示，存儲操作的Gas 消耗遠遠超過棧操作和內存操作.從消耗資源的角度分析，Expensive-SampleContract 分別讀取和寫入存儲n次，而Cheap-SampleContract 將該讀取或寫入的次數降低至1.此外，由于新增的局部變量temp存放在棧中，所以CheapSampleContract 對棧的讀取和寫入分別增加n+1次（循環內n次，循環外1 次）.假設讀取并寫入存儲一次需消耗CStorage個單位的Gas，讀取并寫入棧一次需消耗CStack個單位的Gas，則CheapSampleContract 相比ExpensiveSampleContract 能夠節省的Gas 數量為

因為CStorage?CStack，因此式（1）的值大于零，即CheapSampleContract 相對消耗更少的Gas.為證明上述推斷，本文使用最新的編譯器Solidity 0.8.17 編譯2個智能合約，并將它們部署到搭建的私有以太坊區塊鏈上.然后，在交易中分別將參數n設置為100，500，1 000，并調用2 個智能合約以測試Gas 消耗量.重復上述測試過程10 次，并對測試結果求平均值以減少偶然產生的誤差.如表3 所示，CheapSampleContract始終消耗更少的Gas.

綜上所述，CheapSampleContract 大幅減少了Gas消耗極高的存儲操作，而且只引入了開銷很小的棧操作，從而可以為調用該合約的用戶節省交易費用.雖然字節碼長度的增加會導致部署成本升高，但由于部署是一次性的活動，增加少量成本以吸引用戶對開發者來說是可以接受的.

本文稱類似于ExpensiveSampleContract 的智能合約為“低效的”.具體來說，如果一個智能合約存在另一種功能完全相同并且更節省Gas 的實現，則本文將其視為低效的智能合約，這與另一些研究中定義的“優化不足的智能合約”[22]“Gas 效率低的智能合約”[11]具有相同的含義.Chen 等人[22]提出：智能合約低效的原因是其中包含Gas 消耗大（gas-costly）的指令序列，該指令序列可以被另一些消耗更少Gas（包括一次部署和多次執行所消耗的Gas）的指令序列替代而不影響原本的語義[23].

Table 3 Comparison of Gas Consumption of Two Smart Contracts表3 2 個智能合約的Gas 消耗量對比

2.2 Gas 優化的動機

2.1節中提到低效的智能合約存在另一種更節省Gas 的實現，這意味著低效的智能合約實際消耗的Gas 數量超過完成其功能必需的數量.隨之帶來的問題包括：1）開發者和用戶的金錢被浪費，因為Gas與金錢直接相關；2）區塊鏈的計算資源被浪費，因為Gas 消耗反映計算資源的消耗.受高交易費用影響的用戶可能不愿意長期使用智能合約，進而使智能合約開發商的收入不能得到保證.此外，對計算資源的浪費可能引發環保問題.綜上，低效的智能合約將阻礙區塊鏈的健康持續發展.

如果低效的智能合約是少數，那么上述2 個問題尚不足以帶來嚴重影響.不幸的是1）相關研究表明大部分的智能合約都是低效的[11]；2）據統計，以太坊一天之內（2019 年5 月16 日）產生的Gas 費用就超過了2.5 億美元[24].這些調查結果極大地促使了從業者和研究者關注Gas 優化，即用高效的智能合約替換原本低效的版本以節省Gas、節省計算資源以及節省使用區塊鏈的成本.

對智能合約進行優化能夠提高攻擊者發起拒絕服務攻擊[25]的難度.具體而言，攻擊者發起交易、設置了智能合約的狀態后，將使得后續對該合約發起的交易以一定概率產生Gas 耗盡異常.例如，攻擊者往一個數組中添加大量元素，將使得后續對該數組進行遍歷需要更多Gas，如果用戶調用該合約時仍然按常規設置Gas 總限額，則可能產生Gas 耗盡異常.為緩解上述拒絕服務攻擊，Gas 優化通過降低執行智能合約的Gas 消耗量，提升產生Gas 耗盡異常的閾值，從而增加攻擊難度.

2.3 Gas 優化的挑戰

研究者認為優化智能合約的代碼在節省成本方面具有巨大的潛力[24]，然而實施Gas 優化并非易事，它面臨諸多方面的挑戰，本節總結為3 個方面：

1）智能合約與傳統計算機程序的優化具有顯著差異，所以不能將已有的優化方法直接應用到智能合約上.以圖1 中的2 個智能合約為例，傳統的優化方法會認為ExpensiveSampleContract 相對CheapSample-Contract 更優，所以無需優化，主要原因為：①傳統程序中，訪問局部變量和全局變量的開銷沒有明顯區別，而在智能合約中訪問全局變量的成本極高；②ExpensiveSampleContract 少使用了一個局部變量（即temp），因此運行時占用的內存更少；③由于Expensive-SampleContract 包含相對更少的步驟（即無需對局部變量temp賦值和把temp的值賦給全局變量count），所以它的字節碼中包含相對更少的指令，于是存放其代碼所需的磁盤空間更少.

2）開發高效的智能合約對開發者提出了較高的要求.為了開發高效的智能合約，開發者通常需要采用有利于節省Gas 的編程模式，深入了解EVM 字節碼、不同指令的Gas 消耗等知識.然而，開發者的水平參差不齊、缺乏開發和優化智能合約的經驗、對Gas 機制的了解不夠充足等原因，導致大量低效的智能合約被部署到區塊鏈[11].

3）編譯器對Gas 優化的支持非常有限.如1.1 節所述，智能合約以字節碼的形式部署和運行，因此編譯器有機會在編譯階段優化智能合約.例如，Solidity編譯器向開發者提供了一個編譯選項（即optimize），開啟該編譯選項后，編譯器將嘗試優化大型常量存儲和調度歷程[26].然而，盡管隨著編譯器的迭代，新版本的編譯器在Gas 優化方面相比舊版本已經有所改進，其優化效果仍然有限，智能合約中大部分低效的指令序列都無法被消除[11].例如，2.1 節中的實驗表明：即便是最新的編譯器（即2022 年9 月9 日發布的Solidity 0.8.17），也無法將ExpensiveSampleContract 的Gas 成本優化至CheapSampleContract 的水平.

3 研究現狀與進展

本節主要介紹智能合約Gas 優化相關研究的現狀與進展情況.本文通過分析現有的相關文獻，將當前智能合約Gas 優化的研究總結為3 類方法：面向智能合約字節碼的優化方法、面向智能合約源代碼的優化方法以及為一般軟件設計的通用優化方法.其中，為一般軟件設計的通用優化方法不是專門為智能合約設計的，但它仍然可以應用于智能合約Gas優化.

3.1 面向字節碼的優化

智能合約無論由何種高級編程語言開發，它們最終都將被編譯為字節碼[22].研究者發現編譯器生成的字節碼中可能存在一些指令序列消耗大量Gas，如果能用一段語義相同但Gas 消耗更少的指令序列替換它們，就能達到節省資金的目的.因此，如何定義、檢測并替換低效的指令序列，是此類方法的研究重點.具體而言，面向字節碼的優化方法通常分為3 個階段：1）基于開發經驗或實證研究確定低效的指令序列的模式（或特征）；2）借助上述模式從智能合約的字節碼中檢測待替換的指令序列；3）用更高效的指令序列替換原來的指令序列以完成優化.若新的指令序列中所有指令的總Gas 消耗值比優化前小，則優化后的智能合約可以為調用者節約交易費用；若新的字節碼長度比優化前更短，則可以為開發者節省部署智能合約的成本.

關于低效的指令序列，Chen 等人[23]在其論文中給出了詳細的定義.首先，指令的執行被定義為將一個函數作用于一個EVM 狀態（即程序計數器、內存、棧和存儲等），使其轉移到另一個狀態.例如，執行ADD 指令會使程序計數器和棧發生改變[7].然后，基于以上對指令執行的定義，給出低效的指令序列（在其論文中稱為“anti-pattern”）的定義：對于一段指令序列OS1，如果存在另一段指令序列OS2在語義上與OS1等效，但消耗更少Gas，則OS1是低效的指令序列.其中，OS1與OS2的語義等效是指給定一個EVM狀態，分別執行OS1和OS2后得到的2 個新的EVM狀態是相等的.讓gd1，ge1，gd2，ge2分別表示部署和執行OS1和OS2所需的Gas 數量，由于智能合約只需部署一次但可能被調用多次，所以用T表示指令序列所在的智能合約預計被調用的次數，如果(gd1?gd2)+(ge1–ge2)×T>0，則OS2比OS1更高效.

Gasper[22]是第一個用于檢測智能合約字節碼中低效指令序列的工具.如表4 所示，文獻[22]首先人工地確定了兩大類（共7 種）低效指令序列，即與無用代碼相關的和與循環相關的低效指令序列.例如，死代碼（dead code）是一種典型的與無用代碼相關的低效指令序列，它表示無論調用智能合約的哪個接口、用任何參數來調用，都不會被執行的代碼片段.Chen 等人[22]認為如果可以減少智能合約的大小（例如刪除死代碼、刪除不必要的比較操作）或者減少智能合約的計算（例如將昂貴的指令移出循環），則可以降低開發者和用戶的成本.因此，Chen 等[22]開發了Gasper，它能夠從智能合約字節碼中自動地識別兩類低效的指令序列；Gasper 直接對字節碼而非源代碼進行檢測，因為只有極少數的智能合約是開放源代碼的.輸入一個智能合約，Gasper 首先對字節碼進行反匯編并構建控制流圖，然后基于控制流圖對智能合約進行符號執行以探索和分析所有的程序路徑，在此過程中檢測預先定義的7 種低效指令序列.例如，識別不透明斷言（詳見表4）：Gasper 對智能合約進行符號執行，在執行到條件跳轉時記錄其分支（即true和false），若檢測到某個條件跳轉具有一條從未執行的分支，則識別到不透明斷言.目前，Gasper 支持識別3 種低效指令序列，即死代碼、不透明斷言和循環中的昂貴指令.使用Gasper 分析2016 年11 月5 日之前部署的全部智能合約，結果顯示93.5%，90.1%和80%的智能合約分別受這3 種低效指令序列影響[22].

Table 4 Patterns of Two Types of Inefficient Instruction Sequences表4 兩類低效指令序列的模式

此后，Gasper 被擴展為GasReducer[23]，旨在檢測智能合約字節碼中更多種類的低效指令序列并自動地將其替換為高效代碼.文獻[23]首先通過人工分析已部署智能合約的歷史執行軌跡（即execution traces）總結出24 個低效字節碼的模式.例如，〈swap(X),swap(X)〉就是一個典型的低效指令序列，swap(X)指令的作用是交換棧中2 個元素的位置，而2 個這樣的指令連續執行會使棧維持原狀.因此，直接刪去該指令序列不會影響原本的語義，從而節省6 個單位的Gas（每個swap(X)指令的Gas 消耗是3）.針對這24 種模式，GasReducer 首先將智能合約的字節碼反匯編為匯編代碼，然后檢查并記錄匯編代碼中的低效指令序列的位置.其次，GasReducer 在每個記錄的位置上把低效指令序列替換為相應的高效指令序列.最后，重新構造組裝代碼，輸出優化后的智能合約.GasReducer 對截至2017 年6 月10 日部署的所有智能合約的檢測結果顯示[23]：存在超過940 萬個低效指令序列，為了部署它們，開發者浪費了超過20 億個單位的Gas；通過檢查這些智能合約的歷史執行軌跡，GasReducer 發現在用戶調用智能合約時，這些低效字節碼序列總共浪費了70 億個單位的Gas.GasReducer與Gasper 的差別在于：1）雖然兩者都研究智能合約字節碼中的低效指令序列，但Gasper 確定的低效指令序列來自于高級結構（例如循環），而GasReducer直接來源于字節碼；2）GasReducer 可以識別并優化24 種模式，而Gasper 只能檢測3 種并且不支持優化；3）GasReducer 評估了部署和執行智能合約具體浪費的Gas 數量.

GasChecker[11]是Gasper 的另一個擴展版本.區別于GasReducer，它不優化智能合約，而是提升Gasper的擴展性以支持檢測數百萬個智能合約中的低效指令序列.為了實現此目標，文獻[11]提出了利用云計算平臺使符號執行并行化的方法.具體而言，它根據MapReduce 編程模型對符號執行進行了并行化，并且提出了基于反饋的負載均衡策略來提高計算資源的利用率.實驗結果表明，GasChecker 具有較高的精度（假陽性率約為2.5%）.使用GasChecker 分析1 500 個已部署的智能合約，結果顯示平均每個合約中有超過70 段低效指令序列.此外，文獻[11]還研究了不同版本的編譯器在Gas 優化方面的作用，即使用最新或較新的編譯器編譯智能合約，再使用GasChecker檢測生成的字節碼.實驗結果表明最新的編譯器能夠優化少量舊的編譯器無法優化的低效指令序列，但大部分低效指令序列還是被保留下來.為了量化Gas 優化的效果，文獻[11]優化1 500 個智能合約中的3 種低效指令序列并與優化前對比，結果顯示，如果部署和調用優化后的智能合約，總共可以節約相當于1 520 美元的Gas.

以上識別和優化低效指令序列的方法均依賴于人工預先定義的模式，這可能導致完整性不足的缺陷，即人工定義的模式不足以覆蓋智能合約中所有的低效指令序列；此外，人工定義還存在耗時、容易出錯等問題.因此，為了克服上述缺陷，一些研究嘗試將超級優化技術[27]應用于智能合約Gas 優化.超級優化技術在1987 年被提出.給定一段需要優化的指令序列，超級優化技術通過窮舉搜索找出所有語義相同的指令序列，然后從中找出最優的一個來替換原指令序列[27].然而，超級優化通常被認為過于耗時，除非是特殊情況，否則無法在軟件開發期間使用.研究者認為智能合約就屬于可以使用超級優化的一種特殊情況，因為智能合約一旦被部署到區塊鏈上就無法被修改，但花費額外的時間來優化可能被無數次調用的程序是值得的[28].利用超級優化技術，智能合約Gas 優化可以轉換為一個對計算量要求較大的窮舉搜索問題，而不依賴于人工預先定義的模式.

Nagele 和Schett[28]提出了一個名為ebso 的智能合約字節碼超級優化器，這是超級優化技術在智能合約上的首次應用.ebso 使用約束求解來優化智能合約字節碼，為此它首先提供來自EVM 的相關信息的編碼（例如EVM 狀態、EVM 指令的編碼），然后為字節碼找到多種不同的目標程序，并確定其中Gas消耗最少的一個.ebso 對字節碼中每個代碼塊（即一段不包含跳轉指令的指令序列）執行上述優化，跨越不同代碼塊的指令序列不被考慮在內.Nagele 和Schett[28]在評估ebso 時把它應用于一個編程競賽的智能合約數據集，該競賽旨在挑戰為給定的編程題目編寫Gas 消耗最少的字節碼，ebso 在這個已經達到相當高優化水平的數據集中仍然能找到19 個可以進一步優化的代碼塊.然而，實驗結果還證實了超級優化技術的極端計算要求，即ebso 在幾乎82%的案例中出現了超時，這說明使用超級優化技術為代碼塊尋找最優替代仍然具有挑戰性.

文獻[26]提出了一種新的基于超級優化的智能合約Gas 優化方法.首先，該方法將智能合約字節碼作為輸入，通過符號執行獲得控制流圖中每個代碼塊的棧 功能規 約（stack functional specification，SFS），即對執行代碼塊前的初始棧和執行代碼塊后的最終棧的功能描述.其次，該方法使用SMT 求解器來合成符合棧功能規約的指令序列.為了提升求解器的性能，該方法提出了一種有效的編碼，只考慮棧操作（例如PUSH，DUP 和SWAP 等指令）的語義，其他指令被視為未解釋的函數.最后，該方法通過添加軟約束來編碼指令的Gas 消耗，并利用最新的Max-MAT優化器提供的功能來改進搜索，得到符合棧功能規約的并且Gas 消耗最小的指令序列.文獻[26]在一款名為syrup 的工具中實現了這種基于超級優化的Gas優化方法，將它應用于128 個最常被調用的智能合約可以獲得0.59%的Gas 節省量.此外，syrup 只在處理8.64%的代碼塊時產生超時，這遠遠優于ebso 的92.12%超時率.

文獻[16]在syrup 的基礎上采用更多簡化規則豐富棧功能規約、制定不同的約束條件來提高性能、增加棧功能規約驗證以保證優化后的智能合約維持原始功能，并將syrup 擴展到syrup2.0.syrup2.0 可以與編譯器集成，從而在編譯時優化智能合約.此外，文獻[16]進行了一系列實驗以確定優化效果和編譯時間的最佳權衡.

另一種常見的優化技術是窺孔優化[29].編譯器通過應用一些代碼替換規則并使用模式匹配來優化滑動窗口（即窺孔）內的代碼.然而，這些替換規則通常依賴于人類的專業知識和經驗；列舉規則既耗時又缺乏系統性，因而找到合理的優化規則是窺孔優化的一個挑戰.智能合約由于發展時間較短，還沒有累積足夠的替換規則，例如：Solidity 的編譯器solc 只有十余條替換規則，而較成熟的LLVM 已經有超過1 000條規則[29].針對此問題，文獻[29]提出一個全新的方法以實現自動填充智能合約窺孔優化器中需要的替換規則.首先，對現有的代碼庫執行超級優化，找到代碼庫中低效的指令序列以及它們的優化版本.然后，從上一步的優化結果中提取底層模式，生成窺孔優化規則.文獻[29]根據上述方法，結合超級優化器ebso 和規則生成器sorg，實現了一個面向EVM 字節碼的窺孔優化規則生成器ppltr.利用以太坊中250 個最常被調用的智能合約來評估ppltr，ppltr 生成了993個替換規則，然后將這些規則應用于1 000 個最常被調用的智能合約，結果顯示可以節省4.58%的Gas.

3.2 面向源代碼的優化

面向字節碼的優化方法是從字節碼到字節碼的轉換方法，然而開發者通常使用高級語言而不是字節碼編寫智能合約，這導致面向字節碼的優化方法對智能合約開發者來說是不透明的，即開發者無法直觀地看到優化方法對智能合約進行了哪些修改.由于智能合約一旦部署到區塊鏈就無法被修改，并且智能合約通常控制或影響著用戶的資產，所以優化的不透明性會困擾開發者和用戶，開發者和用戶一方面希望減少智能合約的部署和執行成本，另一方面不希望不透明的優化過程中發生預期之外的修改（例如：智能合約原本的功能被改變），因為即便很微小的變化也可能引起大量的損失.研究者還注意到盡管智能合約字節碼分析工具能夠分析所有已部署的智能合約（因為智能合約的字節碼是區塊鏈上公開可獲取的信息），但是它們無法利用源代碼中的有用信息（例如函數名和事件名）[30].因此，對于擁有智能合約源代碼的開發者來說，能夠快速定位源代碼中問題的分析工具可能比字節碼分析工具更有用.此外，一些研究[31-34]還表明字節碼分析工具的效率低于源代碼分析工具.

基于以上考慮，一些研究者關注面向源代碼的優化方法，致力于讓優化過程變得透明.與面向字節碼的優化方法類似，面向源代碼的優化方法主要也分為3 個階段：1）基于開發經驗或實證研究確定可能引起Gas 浪費的編程模式、代碼片段的特征；2）借助模式匹配等方法從智能合約中識別編程模式或特征；3）用更高效的代碼片段替換識別出的低效代碼片段以完成優化.

Tikhomirov 等人[35]總結了21 種智能合約的代碼問題，其中2 種代碼問題與低效代碼有關：第1 種低效代碼是被定義為byte[]類型的數據，它們可以被更節省Gas 消耗的bytes 類型替代；第2 種低效代碼是內部帶有函數調用的循環，因為重復的函數調用將導致相當大的Gas 消耗.值得注意的是，第1 種低效代碼很難被面向字節碼的優化方法識別，因為字節碼中不包含類型信息，導致其很難在不借助源代碼的情況下區分byte[]和bytes.Tikhomirov 等人[35]又開發了一個名為SmartCheck 的可擴展靜態分析工具以檢測這些代碼問題.SmartCheck 首先對Solidity 源代碼進行詞法和句法分析，將源代碼轉換為基于XML解析樹的中間表示.然后，SmartCheck 對該中間表示使用Xpath 查詢以檢測預定義的代碼問題.文獻[35]對大量現實世界的智能合約進行測試，檢測到0.006%的智能合約具有第1 種低效代碼，2.164%的智能合約具有第2 種低效代碼.

Zhang 等人[30]提出SolidityCheck，旨在使用正則表達式定義智能合約中存在問題的語句特征，并使用正則匹配來檢測對應的問題.關注SmartCheck 中總結出的兩類與低效代碼相關的代碼問題，實驗結果表明，使用正則匹配來識別代碼問題比使用詞法和句法分析更高效.SolidityCheck 將分析單個合約所消耗的時間從SmartCheck 的1.83 s 縮短到了0.23 s.

Feist 等人[36]提出的智能合約靜態分析框架Slither 可以檢測2 種導致智能合約部署和執行成本變高的代碼模式：第1 種是應該聲明為常量卻被聲明為變量的數據，如果變量被聲明為常量，數據將不會占用智能合約的存儲空間，并且在使用數據時可以執行更少的指令，Slither 是唯一一個能找到此類代碼模式的可用工具；第2 種是本應該聲明為外部函數卻未被聲明為外部函數的函數，因為外部函數的代碼可以被編譯器優化.Slither 將Solidity 代碼轉化為一種中間表示，然后使用數據流和污點分析從中間表示中提取這2 種代碼模式，并對Slither 可以檢測的第1 種低效代碼模式進行了評估，結果顯示超過50%的智能合約至少包含一個應該聲明為常量的變量，其中甚至包含一些從未被訪問過的變量.

以上面向智能合約源代碼的研究[30,35-36]根據預先定義的代碼模式從源代碼中標記出低效的代碼片段，從而幫助開發者改進智能合約.此后在此基礎上進一步研究針對低效代碼片段的自動優化.

據我們所知，GASOL[37]是第一款支持自動檢測并優化智能合約源代碼中低效代碼片段的工具.GASOL 的優化目標是減少與訪問存儲（即SSTORE指令）相關的Gas 消耗.GASOL 包含1 個分析模塊和1 個優化模塊，如果分析模塊檢測到智能合約中對相同存儲位置的多次訪問，則GASOL 將其視為一個潛在的優化機會，優化模塊將嘗試使用節省Gas 的內存訪問來代替存儲訪問.具體而言，GASOL 的目標是用1 次訪問來替換1 個循環結構中對同一個全局變量的多次訪問（如表2 所示，存儲操作的Gas 消耗為5 000 或20 000），它將存儲空間中的數據復制到內存中，然后訪問該內存地址（如表2 所示，內存操作的Gas 消耗僅為3），并且只在必要時對存儲進行最終更新.GASOL 將這種對存儲訪問的優化方法應用于超過40 000 個真實智能合約的公共函數，結果顯示6.81%的公共函數都存在優化機會[38].

同樣針對智能合約中的存儲操作，文獻[39]注意到現有工作沒有考慮到的2 個方面：1）控制流結構不僅包含循環，還包含各種分支，以前的研究工作[11,37]在優化智能合約時只考慮了循環結構中的存儲操作.因此，以前的研究工作[11,37]在減少用于存儲訪問的Gas 消耗時可能導致其他程序路徑上的Gas消耗增加.2）文獻[36-37]都只考慮基本數據類型（例如int，bool）而沒有考慮對復合數據類型的優化（例如數組），然而90%的包含循環的智能合約都至少在一個函數中使用了數組，這意味著在數組訪問方面存在較大的Gas 優化機會.文獻[39]針對上述2 個方面提出解決方案以彌補現有工作的不足：1）針對存儲訪問的優化，優化目標是：給定一個智能合約C，將其優化為C'，使得對于C中的每個函數f，C'都有一個對應的函數f'，并且對于f中的每個執行路徑p，f'都有一個與其語義相同的執行路徑p'，其中p'訪問存儲的次數比p少.文獻[39]提出的優化方法是在GASOL的基礎上增加了對每條程序路徑的優化而不僅限于循環結構.2）針對數組訪問的優化，其目標是消除不必要的數組越界檢查所帶來的Gas 消耗.根據Solidity語言規范，每個數組訪問都需要進行運行時的越界檢查以避免非法越界，保證用于訪問數組的索引不超過聲明的數組大小（0

Liao 等人[21]發現內聯匯編還可以在5 種情況下替代Solidity 源代碼以優化智能合約的Gas 消耗.本節只介紹2 種：1）類型轉換.Solidity 的類型系統限制了每種類型的變量可用的指令，比如算數運算的操作數不能是一個地址類型的變量.若試圖對地址類型變量進行算數運算，必須提前將地址類型變量轉換為整數類型.然而，類型轉換需要執行特定的指令，從而消耗更多Gas.使用內聯匯編可以解決此問題，因為內聯匯編中沒有類型的區分，所以地址類型變量在內聯匯編中無需轉換就可以進行算數運算.2）訪問字符串的任意長度子串.Solidity 不支持直接訪問字符串的子串或字符串中的某個字符，若要實現此功能，智能合約必須先將字符串轉換為bytes 類型，然后再用一個循環來獲取其子串.內聯匯編可以優化此過程，這是因為內聯匯編允許開發者直接使用MLOAD 指令來訪問內存的任意位置，從而獲取字符串的子串.使用內聯匯編以優化智能合約的其余3 種情況請參閱文獻[21]和表5.

回顧本節列舉出的面向源代碼的優化方法，我們發現，研究者通常提出一些低效的代碼模式，然后運用正則匹配、靜態程序分析等方法從源代碼中識別并優化此類低效代碼.然而，大多數研究沒有闡述低效代碼模式是如何獲得的（例如：通過人工分析真實的已部署的智能合約來獲得，或從隨機構造的代碼中獲得），這可能導致開發者和研究人員無法了解這些代碼模式在真實智能合約中的泛濫程度.即便有研究通過實驗評估了一些低效代碼模式的占有率[35-37]，文獻[35-37]所覆蓋的少量代碼模式也無法揭示宏觀情況.

Table 5 Saving Gas by Using Inline Assembly表5 使用內聯匯編節省Gas

對開發者和真實智能合約進行大規模的調查，總結開發者面臨的智能合約優化問題和真實智能合約中實際存在的低效代碼模式，是解決開發者和研究人員無法了解低效代碼模式在真實智能合約中的泛濫程度的問題的一個方法.例如，Kong 等人[40]從開發者論壇的大量帖子中總結低效代碼模式，并通過大規模的實證研究揭示這些模式的普遍性.據悉，在線論壇和問答網站（例如：由Solidity 開發團隊推薦的官方討論網站——Ethereum Stack Exchange[41]）中包含的短文、問題和答案等非正式文檔是智能合約開發者的寶貴資源，其中可以找到低效智能合約的真實案例以及關于如何進行Gas 優化的建議.因此，文獻[40]從Ethereum Stack Exchange 的帖子中提取智能合約的低效代碼模式.具體而言，首先爬取該網站截至2020 年7 月9 日的所 有25 000 個帖子（包含問題、答案和評論）；然后利用關鍵詞過濾、手動過濾與Gas 優化不相關的帖子；進一步，從剩余的474 個帖子中總結出6 種低效代碼模式以及對應的優化方法[40]，其中只有“重復賦值”和“頻繁使用全局變量”這2 種模式被研究過.基于發現的低效代碼模式，文獻[40]提出了一種Gas 優化方法，該方法利用抽象語法樹從源代碼級別優化智能合約，并構造源代碼到源代碼的轉換，旨在讓優化過程對開發者透明；最后，將提出的檢測和優化方法應用于包含超過160 000 個真實智能合約的數據集上，實驗結果表明，52.75%的合約至少包含1 種低效代碼模式，優化這些低效代碼模式將至少為每個智能合約減少0.3 美元的成本.

區別于其他面向源代碼的優化方法，Chen 等人[42]從數據類型轉換的角度而非替換低效代碼的角度重構智能合約以節省Gas.文獻[42]提出，優化智能合約的Gas 消耗需要對底層數據布局進行顯著地修改，這要求開發者嘗試更改不同的數據結構、重新實現智能合約中某些重要的代碼段，而以往的所有研究都沒有解決此問題.基于此觀察，文獻[42]開發了一個名為Solidare 的工具，用于自動執行智能合約的數據結構重構任務.給定智能合約的Solidity 源代碼和所需的數據類型重構操作，Solidare 將自動生成一個帶有重構數據類型的等效智能合約.借助Solidare，智能合約開發者可以方便、快速地嘗試各種不同的數據表示并測量重新實現的智能合約的Gas 消耗量.將Solidare 應用到20 個真實的智能合約上，其中18個智能合約的Gas 消耗量平均減少了16%.

3.3 通用優化方法

智能合約是一種特殊的計算機軟件，因此，軟件工程領域的優化方法也能被運用到智能合約的開發過程中.

例如，文獻[43]基于對Solidity 文檔、博客和開發者論壇等在線資源和現有智能合約的調查，提出了5 類共14 種可以幫助開發者進行智能合約Gas 優化的設計模式，每個設計模式是針對某一個頻繁出現的設計問題的典型解決方案.這5 類設計模式被概括為：1）外部交易.例如盡量讓外部系統直接訪問區塊鏈中的事件日志而不要將信息存放在智能合約的存儲空間中；2）存儲.例如始終使用內存來存儲非持久化數據；3）節約空間.例如建議使用mapping 類型來管理數據列表；4）函數功能.例如使用庫；5）其他.例如借助編譯器的優化選項.

文獻[44]將智能合約在結構和功能方面的優化歸結為2 個基本層面，即使用適當類型的變量和使用最優方式實現智能合約的功能.文獻[44]主要研究如何為可能產生大量Gas 消耗的元素（例如循環、數據類型）編寫最優的智能合約源代碼.更重要的是，文獻[44]提出了一系列建議開發者在開發智能合約時遵循的有序優化步驟.文獻[11，21-23，26，28-30，35，37，39-40，42]雖然提出了很多優化建議和方法，但沒有指導開發者以何種次序采用不同的優化方法取得最好的效果.為了彌補這個空白，文獻[44]提出的指導原則包含11 個建議：1）為智能合約創建適當的數據類型；2）變量有時需要重新排序或打包，以充分利用存儲空間；3）盡量使用內存而不是存儲中的變量；4）盡可能使用關鍵字constant 聲明智能合約中的常量；5）使用更節省Gas 的mapping 類型來替代數組類型；6）特別注意優化循環相關的這部分源代碼，例如盡量不在循環中添加Gas 消耗高的指令；7）最好調用內部函數；8）使用OR 或AND 運算符時，由于“短路”[44]，運算符的右操作數可能被跳過，因此建議將Gas 消耗高的操作放在運算符的右邊；9）消除無用代碼；10）消除不必要的變量；11）開啟編譯器優化.

Bentley[45]曾在1982 年為一般軟件制定了一套通用和抽象的優化規則.近年來，研究者發現這些規則可能有助于優化智能合約[46].具體來說，這套規則分為6 類：1）空間換時間規則.通過增加所需的空間以減少程序的運行時間來實現優化；2）時間換空間規則.存儲冗余信息以減少程序運行時間；3）循環規則.通過修改或刪除循環來實現優化；4）邏輯規則.旨在不改變語義的情況下修改代碼邏輯以提高效率；5）步驟規則.該規則處理的是一個按步驟組織的程序的底層結構；6）表達式規則.處理表達式優化，例如復用計算結果或用開銷小的替換開銷大的表達式.

3.4 不同類型優化方法的對比

目前，智能合約Gas 優化方法主要分為3 類，即面向字節碼的優化方法、面向源代碼的優化方法和通用優化方法，它們具有各自的優勢和劣勢.

回顧1.1 節中描述的智能合約生命周期，即無論智能合約最初由何種高級語言編寫，在部署上鏈前都須編譯為EVM 字節碼.因此，面向字節碼的優化方法能夠兼容不同編程語言編寫的智能合約.然而，此類方法通過字節碼到字節碼的轉換實現Gas 優化，開發者更容易閱讀、理解源代碼，這導致開發者難以判斷優化過程中是否發生了預期之外的錯誤.

為了讓優化過程對開發者更透明，一些研究工作關注面向源代碼的優化方法.通過對比優化前后的智能合約源代碼，開發者能夠容易地定位到優化的位置，并利用自身開發經驗判斷優化是否合理.因此，面向源代碼的優化方法對開發者更友好、透明.此外，由于只有源代碼中包含類型信息，所以此方法還能識別到一些與變量類型相關的優化機會.然而，此類優化方法依賴于特定的編程語言，不同編程語言編寫的智能合約源代碼具有顯著差異，因而針對一種語言的優化方法往往無法快速移植到另一種語言上.

相比于面向字節碼和面向源代碼的優化方法，通用優化方法依賴于軟件工程領域的經驗與方法論，而無需設計、開發專門的優化工具或程序，因此相對容易實施.然而，優化效果的好壞取決于開發者是否積累了足夠的經驗，所以此類方法對開發者的水平提出了較高要求.表6 從3 種不同類型的方法中挑選出了代表性的優化技術，并進行了對比.

3.5 與Gas 相關的其他研究

除了圍繞智能合約Gas 優化的研究工作，還有研究者關注Gas 的其他方面，例如.估計執行智能合約所需的Gas、識別智能合約中與Gas 相關的漏洞等.本節簡要介紹這些研究工作.

V-Gas[47]利用靜態分析和模糊測試方法對執行智能合約所需的最大Gas 消耗量進行估計，并以此為智能合約用戶提供設置Gas 總限額的建議，從而避免因Gas 總限額設置太小而引起的Gas 耗盡異常.GASTAP[48]是一個Gas 感知（Gas-Aware）智能合約分析平臺，它將智能合約作為輸入，并通過構建控制流圖、從低級代碼到高級表示的反編譯等一系列代碼轉換和分析，自動推斷該合約中所有公共（public）函數的Gas 消耗量上限.Marescotti 等人[49]提出了一種受有界模型檢查技術啟發的技術，并基于該技術計算智能合約最壞情況下的準確Gas 消耗量.Soto 等人[50]通過搭建私有區塊鏈并隨機生成交易來模擬公共區塊鏈，他們在私有區塊鏈中多次測試執行智能合約的Gas 消耗量，以此幫助用戶預測在公共區塊鏈中調用智能合約所需的成本.Li 等人[51]認為靜態分析難以確定智能合約中循環體的執行次數，因此靜態分析方法無法準確估計循環結構的Gas 消耗量.針對此問題，他們提出了一種基于交易軌跡的Gas估計方法，該方法通過了解智能合約的過往交易所消耗的Gas 量來估計新交易的Gas 消耗.

Li 等人[52]提出了一種動態數據復制方案GRuB，可在區塊鏈和鏈外的云存儲之間動態地復制數據，從而降低數據密集型智能合約的Gas 消耗.

Grech 等人[25]對與Gas 相關的合約漏洞進行了分類總結，他們認為這類漏洞是開發者最難防范的漏洞之一，因為與Gas 相關的合約漏洞在非攻擊場景中很難被觸發.因此，他們提出了一種高精度、可擴展的靜態程序分析技術MadMax，用于自動檢測與Gas 相關的漏洞.

Chen 等人[53]提出了一個基于仿真的框架來自動測量執行每個EVM 指令所產生的計算資源消耗量.基于該框架，他們發現目前為每個指令制定的固定Gas 消耗值不能適應指令在不同環境下的資源消耗量的變化.因此，攻擊者可以利用Gas 消耗較小而計算資源開銷大的指令發動拒絕服務攻擊.針對此問題，他們提出了一種新的Gas 消耗機制，該機制根據指令的執行次數動態地調整指令的Gas 消耗值，從而阻止拒絕服務攻擊.

4 未來研究方向

區塊鏈是一項新興的技術，其發展速度可謂日新月異.近年來，基于區塊鏈的智能合約被認為是一個極具潛力和前景的領域.隨著研究者和開發者將智能合約的使用場景拓展到包括供應鏈[54]、物聯網[55]、醫療系統[56]、數字版權管理[57]、保險[58]、金融體系[59]和房地產[60]在內的各種領域，智能合約的數量與日俱增.智能合約的繁榮應用吸引了大量的用戶，例如，以太坊區塊鏈上每天可以產生超過一百萬條交易[61]，用于支付這些交易的費用價值高達數百萬美元[24].總而言之，隨著智能合約及其應用的發展，可預見越來越多的智能合約將被部署到區塊鏈、越來越多的用戶將使用智能合約.因此，為減少資源浪費并保證區塊鏈健康持續發展，對智能合約Gas 優化的重要性的認識正不斷提升，需要繼續對其進行研究以彌補現有優化方法的缺陷和不足.本文將未來研究方向歸納為以下4 個方面.

1）增加對更多智能合約編程語言的研究.據我們所知，現有面向源代碼的優化方法都以Solidity 語言編寫的智能合約為優化對象，然而其他的智能合約編程語言（例如Vyper[62]）沒有被研究過.使用這些編程語言的開發者不能從現有優化方法中獲得支持，導致開發出浪費Gas 的低效智能合約.針對此問題，文獻[36]提出，可以先將其他語言編寫的智能合約轉化為現有的中間表示，然后對該中間表示實施優化.除了文獻[36]提出的方法，面向字節碼的優化方法也能在一定程度上解決該問題，因為無論何種語言編寫的智能合約，在部署到區塊鏈之前都需要編譯成EVM 字節碼.但是，面向字節碼的優化方法存在不透明性，有待在未來的研究工作中解決.此外，現有面向字節碼的優化方法沒有評估其對不同語言編寫的智能合約的優化效果.

Table 6 Comparison of Different Types of Optimization Methods表6 不同類型優化方法的對比

2）提升超級優化技術的擴展性和效率.超級優化技術因為過于耗時而阻礙了其廣泛應用，雖然現有研究將其應用到智能合約上并得到了Gas 優化效果，但是超級優化技術存在的固有缺陷影響了Gas優化效果和效率.例如：①現有智能合約超級優化方法對單個代碼塊內的指令序列進行優化，而無法實現跨代碼塊的優化；②由于超級優化依賴大量計算，為了減少時空開銷，現有研究只對棧操作編碼，而不考慮其他指令（例如內存、存儲操作），導致優化范圍有限.未來研究或許可以借鑒GasChecker 的思路，即利用云計算平臺使一些操作并行化，從而提升超級優化的效率.

3）將優化方法集成到智能合約編譯器.目前，編譯器對Gas 優化的支持非常有限，文獻[11]發現即便開啟編譯器的優化選項，仍然無法消除絕大部分低效指令序列.如2.3 節所述，即便是最新的編譯器，也無法優化圖1（a）中展示的低效代碼.值得注意的是，這種低效代碼模式已經能夠被現有工具GASOL 識別并優化.如果在未來的研究工作中能將現有的優化方法和工具集成到智能合約編譯器中，這將為開發者提供極大的便利.據我們所知，syrup2.0 已經在這方面做出了努力，但是超級優化技術的固有缺陷限制了它的優化效果和效率.

4）設計一種在智能合約運行時進行Gas 優化的方法.智能合約一旦部署到區塊鏈就無法被修改，因此現有的基于代碼替換的Gas 優化方法無法應用于已部署的智能合約.這部分智能合約可能在未來還會被多次調用，從而產生難以避免的資源浪費.未來的研究工作或許可以考慮在智能合約運行時進行Gas 優化，以減少實際執行的指令數量，從而在不修改已部署智能合約代碼的情況下減少Gas 消耗量.

5 總結

基于區塊鏈的智能合約是目前廣受研究者和開發者關注的技術，未經優化的智能合約將浪費Gas和計算資源.本文總結目前智能合約Gas 優化的研究進展：1）介紹了Gas 機制的基本概念；2）闡述了智能合約Gas 優化的動機；3）總結了實施優化所面臨的3項主要挑戰；4）總結了當前智能合約Gas 優化研究的3 大方向，即面向字節碼的方法、面向源代碼的方法和通用優化方法；5）從現有研究的不足出發，展望了未來研究的發展方向.

作者貢獻聲明：宋書瑋負責收集文獻并撰寫論文；倪孝澤負責完成實驗并修改論文；陳廳提出指導意見并修改論文.