圖 1 智慧合約應滿足的條件
4.1.確定性
確定性在傳統計算機理論中已有明確定義：如果給定一個輸入，計算機（狀態機）經過同樣的狀態變化順序後總會產生相同的結果，那麼這個演算法即可被稱為是確定性的[4]。這一特性在分散式系統特別是區塊鏈系統中尤其重要，因為所有節點必須按照智慧合約約定的規則產生相同的計算結果，否則合約執行的結果無法被各個節點所共識。
導致非確定性結果的具體原因有很多，而目前在區塊鏈的解決思路也不少。下面我們按照“程式=演算法+資料結構”的角度從演算法和資料兩個角度分別對這些原因和解決思路進行討論。
4.1.1.確定性演算法
對於確定性的演算法上，我們又可以從“時間”和“空間”的角度上來分別討論。
在程式執行的時間上，如果一個演算法本身不是確定性的，那麼如果將實現這個演算法的程式重複執行多次，每次執行的結果無法確定。例如產生隨機數的函式每次執行的結果無法保證是一樣的。
在空間上，即便每個節點都執行同樣的、確定性的指令操作，但由於節點間的底層機器指令或作業系統實現差異也可能導致出現不同的結果。
為實現確定性的演算法，目前區塊鏈較多采用的是限制操作，比較常見的是隻提供確定性指令或系統函式。
例如比特幣中的指令碼系統只提供了為數不多的操作，避免可能導致節點間差異的功能；以太坊採用了虛擬機器（EVM）來遮蔽不同節點的實現差異，同時只提供確定性的系統函式。具體虛擬機器方面的內容我們將在下文繼續討論。
4.1.2.確定性資料
除了操作本身差異外，如果對同一個演算法給予不同的資料輸入，也會導致結果存在差異。
目前的解決思路從鏈上、鏈下可分為 2 種。
鏈上的思路為，限制智慧合約的資料只能從鏈上讀取已共識後的賬本資訊，以此來達到資料來源相同的目的。
但這種方法也存在不少限制，因為一些合約的執行有賴於對現實世界的條件判斷，例如天氣、股市行情等等，而鏈上資料的來源、種類、實時性等各方面很多時候無法滿足。
鏈下的思路進一步擴充套件了資料來源，一般採用預言機（Oracle）的方式，將外部資料提供給智慧合約進行讀取，並保證資料的一致性。
4.2.可終止性
可終止性的問題是區塊鏈實現智慧合約的另一個挑戰。因為區塊鏈上的智慧合約必須是可終止的，否則當出現例如無論是主觀故意還是客觀存在的死迴圈等無法終止的合約時會持續佔用區塊鏈的計算或儲存資源。
為實現可終止性的目標，智慧合約在實現時主要有以下幾種方式可以實現。
4.2.1.有限命令方式
比特幣採用的方式是實現了一個圖靈不完備的指令碼系統。圖靈完備系統會包括一系列運算元據的動作，其中包括迴圈、遞迴等邏輯操作，用以實現任何圖靈機。而比特幣的指令碼系統限制了操作指令的種類，不包含迴圈等操作，因此可同時實現其確定性和可終止性。但這種方式也很大程度上降低了在比特幣上實現合約的可擴充套件性。
4.2.2.gas 方式
為了提高可擴充套件性，在比特幣之後的很多區塊鏈系統，例如以太坊等開始採用支援圖靈完備的智慧合約系統，以支援實現更復雜和完備的業務邏輯。為了解決支援圖靈完備下的可終止性問題以及避免網路濫用，以太坊引入了 gas 概念。以太坊智慧合約中的每步操作和每個賬本儲存都會對應於一定的 gas 消耗；當 gas 消耗完後合約即會被終止[5]。gas 方式相當於即時付費的手續費模式，目前被大多數的公有區塊鏈平臺所採用。
4.2.3.資源控制方式
與 gas 的即時付費模式不同，另有一些公有區塊鏈平臺採用了預付費的模式，透過控制可使用的資源來實現可終止性的效果。其中最典型的代表是 EOS。儘管交易不需要支付手續費，但使用者需要提前抵押或購買足夠多的 CPU、RAM 以及頻寬等使用資源來進行交易和執行合約。EOS 透過這種方式來避免使用者在無手續費情況下對資源的濫用。
4.2.4.准入限制方式
除了以上介紹的公有鏈上的解決方式外，一些聯盟鏈採用了其他的方式來解決可終止性問題。由於聯盟鏈的特殊性，一般來說在加入區塊鏈網路前，節點已被區塊鏈組織所認可、其身份已被其他節點所知曉，對於單個節點的可控性更高，因此很多聯盟鏈會給予該節點更高的自由度。例如在聯盟鏈的典型代表 Hyperledger Fabric 中，可由節點使用者來自主控制智慧合約程式（即鏈上程式碼，Chaincode）的啟停，同時綜合以執行時間等方式將合約執行長度和佔用資源控制在可接受的範圍內，從而實現可終止性。
5. 技術路線及典型案例解析
綜合以上技術思路後，我們繼續對可實現以上思路來支援智慧合約的技術方案進行梳理，目前可主要總結為指令碼方式、容器化方式、虛擬機器方式等。
5.1.指令碼方式
指令碼方式可以說是最傳統的實現可程式設計邏輯的一種方式，最早在比特幣系統中被採用。比特幣的 UTXO 模型採用了一種類似 Forth 語言[6]的簽名指令碼體系，用於驗證該筆交易的合法性。交易一般會包括輸入指令碼和輸出指令碼兩個，分別用於解鎖上一筆交易的輸出以及設定該筆交易金額的解鎖條件。
比特幣指令碼採用堆疊結構方式的逆波蘭表示式，使用者需要按照順序將匹配的簽名、公鑰等提供給指令碼作為執行的輸入用以解鎖該筆交易。因此，指令碼方式的另一特點是，和 UTXO 方式的配合使用效果較好。
但這種方式的缺點也很明顯，主要在於功能的擴充套件性上，指令碼方式。因此，如果從功能完備性和程式設計可擴充套件性方面來看，很多人認為比特幣的指令碼方式能實現的程式設計業務非常有限。因此從狹義的角度來看，指令碼方式區塊鏈可認為是隻實現了簡單的可程式設計特性，而沒有通常意義下的智慧合約體系。
按照火幣研究院的區塊鏈代際劃分的思路[7]，目前使用指令碼方式來實現可程式設計特性的，都可認為是區塊鏈 1.0 版本的系統，可對應的包括以下 3 大類：
· 比特幣及相關分叉幣、競爭幣
· 匿名加密貨幣
· DAG 類的區塊鏈
5.1.1.比特幣的分叉幣競爭幣
使用指令碼方式較多的是比特幣及早期相關採用 UTXO 模型的一些加密貨幣，包括比特幣的分叉幣、競爭幣等，主要包括：Litecoin、Bitcoin Cash等等。
5.1.2.匿名加密貨幣
主打匿名、隱私保護的加密貨幣也較多的使用了指令碼體系。出於對隱私保護和交易追溯性的隱藏，這類加密貨幣很多都採用了抽象、簡化的指令碼體系，包括 Monero、Dash 等。
5.1.3.部分 DAG
還有一些會用到指令碼方式來執行合約的會是基於有向無環圖結構（DAG）的區塊鏈系統。火幣研究院此前的研究報告《【超越白皮書 3】DAG 技術解析與實測》中曾介紹過，由於 DAG 系統的原生特性，包括交易時長不可控、不存在全域性排序機制等特點，較難在 DAG 的分散式賬本系統上實現出一個圖靈完備的智慧合約系統[8]。因此為了提高併發 TPS、簡化交易處理過程，一部分基於 DAG 的分散式賬本系統也會採用指令碼方式來構建自己的可程式設計體系。
5.2.容器化方式
容器化方式，是近年來興起的、不同於虛擬機器的一種新型虛擬化技術。相對於虛擬機器在使用者程式和底層環境中增加的一層中間環境，容器技術只需要將應用程式所需要的依賴打包即可獨立執行，而不需要一個附加的虛擬作業系統環境。
圖 2 容器（左）與虛擬機器（右）的結構區別
使用容器化的方式實現區塊鏈平臺的智慧合約環境，相對於堆疊執行程式碼的虛擬機器方式相對更為獨立和靈活、可呼叫的資源也更多。
儘管容器化技術從整體系統架構來看更為輕便與靈活，但從單個應用的角度來看，則需要考慮更“重”的一些系統因素，因為在容器環境中的程序可訪問包括檔案、系統功能等在內的更多系統資源。這就對區塊鏈自身的執行環境提出了較多要求，因此採用這種方式的區塊鏈平臺較為少見。
典型使用容器化方式的區塊鏈專案是 Hyperledger Fabric。其智慧合約的執行方式是在節點部署一個鏈上程式碼後，所有相關節點均會啟動一個在Docker 容器中獨立執行的鏈碼程序。鏈碼透過容器中對外的 gRPC 介面完成與節點的互動。
目前對於鏈碼的執行，Fabric 採用的仍然是一種較為手動和底層的方式來管理維護。因為是聯盟鏈的環境，相當於是預設所有被許可加入網路的節點均可以較為自覺的使用系統資源，即上文提到的准入限制方式。這一思想在對於鏈碼生命週期的維護方面就體現的比較明顯：在目前最新的 Fabric 1.3 版本中，只提供了 package（打包）、install（安裝）、instantiate（例項化）、upgrade（升級）等 4 個命令，在未來才會考慮提供一個在不用實際刪除鏈碼情況下，禁用（stop）和重新啟用（start）鏈碼的命令。
因此若想在公有鏈環境下用容器化的方式來構建智慧合約環境，則需要採用例如資源控制等更多的方法來適應改造。
5.3.虛擬機器方式
相較於上述兩種方式，目前實現智慧合約方式的最多的一種是虛擬機器方式。它可以為程式提供一個完全對底層透明的執行環境。這種思路的典型應用可追溯到傳統 IT 技術中 Java 的 JVM 虛擬機器。其目的是為了實現“一次編寫，到處執行”的特性，而不是讓程式開發人員為相容每個不同的伺服器編寫不同版本的程式。而這一特點正是分散式部署與執行的智慧合約所需要的：遮蔽區塊鏈節點自身執行環境的區別，在所有節點上執行均一致，實現上文所述智慧合約需要滿足的確定性特點。
區塊鏈 2.0 的一個代表性專案——以太坊系統即採用的是 EVM（以太坊虛擬機器）。以太坊虛擬機器構建了一個基於棧的虛擬執行環境，定義了一套跟節點自身環境隔離的環境，遮蔽了每個節點的底層差異，實現不同節點執行合約的相同結果（確定性）。
以 EVM 為代表虛擬機器的另一個特點在於，由於提供了一個較為底層的通用基礎設施，基於這個虛擬機器，可以設計出符合該虛擬機器或者說區塊鏈系統的高階程式語言，例如以太坊的 Solidity 語言、Nxt 使用 Javascript 及相應環境下的 API 等[9]。相應的，如果該語言設計的不合理也會帶來相應的缺陷。
綜合以上各個特點來看，虛擬機器方式仍然是目前可實現智慧合約技術中較為穩妥的一種技術路線，也是目前包括以太坊在內的大多數區塊鏈系統採用的方式。
但在具體實現方面，EVM 目前普遍認為存在一些設計缺點[10]，主要包括以下幾點：
· 256 位字長。採用目前主流 CPU 所支援的 8、16、32、64 等長度時，CPU 可直接提供原生支援，程式效率高。但 EVM 採用的字長是 256位，處理器需要額外的操作才可以正常處理，因此運算效率較低。同時相較於主流字長，256 位也會存在一定的儲存浪費，進而影響 gas 消耗。目前一部分測試表明，當字長改為 64 位或 128 位時，合約程式碼的執行效率、儲存成本（以 gas 值體現）均有改良[11]。
· 不支援浮點數及缺少標準庫。此問題不支援浮點數對於要支援。而正像上文提到的，通常與 EVM 配合使用的 Solidity 語言也因為缺少原生標準庫的，使得這一問題更為突出。OpenZeppelin 的出現使得這一問題得到了緩解。其 ERC20、ERC721 的編寫框架使得開發變得容易。但依賴於第三方程式碼庫始終存在一定風險。例如前段時間有許多采用OpenZeppelin 的 ERC20 通證合約因為函式返回值的問題，可導致轉賬結果無法預計[12]。
· 合約程式碼不可修改升級。由於 EVM 採用的不是標準馮諾依曼結構，程式程式碼被儲存在一個獨立的虛擬 ROM 中，而不是一般計算機記憶體中的程式碼區位置，理論上只可以透過重新部署合約來實現對合約的升級。因此當合約中存在 bug 等情況時，無法透過打補丁等形式來進行補救。
因為以上缺點，在以太坊 EVM 之後，很多區塊鏈專案從多種技術方向來實現虛擬機器。我們可以按照技術實現方式的特點可進一步分為以下幾類來討論。需要注意的是，目前不少公鏈僅公佈了其開發計劃，無實際可執行的虛擬機器程式程式碼，具體實施情況可能隨著其專案進度會而有所變化。
5.3.1.改進 EVM
儘管 EVM 有上述種種缺點，很多區塊鏈系統仍然是採用在 EVM 基礎上改進來設計實現。這樣一方面可以複用原有以太坊的功能，降低開發工作量；另一方面可以利用現有的以太坊生態，進行快速的開發。雖然目前的一些公鏈平臺例如 EOS 等在使用者活躍度等方面有趕超以太坊之勢，但以太坊長期形成的生態環境是一個新生公鏈在考慮未來開發及運營時絕對不可忽視的一個重要因素。像在主打聯盟鏈平臺的 Hyperledger 中，Burrow 專案是搭建了帶授權管理的以太坊智慧合約區塊鏈節點，並搭配 Cosmos 的 Tendermint 共識引擎以此來相容以太坊的 Solidity 開發生態[13]。
圖 3 公鏈平臺 DApp 數量對比（截止 2018 年 10 月 25 日）
在這種大環境下，許多公鏈在設計實現虛擬機器時，均採用了在 EVM 基礎上改進的方式來實現。
例如，Nervos 公鏈平臺中 Layer1 的 CKB 使用了 RISC-V 作為指令集實現 CKB-EVM。透過 RISC-V 的工具鏈，CKB-EVM 可以支援任意程式語言進行智慧合約開發[14]。
Aion 採用的 FastVM 在設計時採用了 128 位的字長，並在底層採用 LLVM JIT 作為執行引擎，以此來提高儲存效率和運算速度。Aion 的虛擬機器同時計劃在未來支援從 128 到 64 和 32 等多種字長，以適應更多的應用場景和業務需求[15]。
另外也可從虛擬機器的執行流程上進行最佳化。由於以太坊需要每個全節點都執行相同的虛擬機器計算並檢驗結果後才更新賬本，該方式顯然會影響效能。一些區塊鏈平臺對此進行了改進，例如 Zilliqa 採用了資料流圖的方式來進行計算分片，以此來提高併發度[16]。
5.3.2.相容傳統指令集
另有一些區塊鏈系統實現合約引擎的思路是與傳統的機器指令集技術進行相容。
這其中一類是直接使用傳統虛擬機器技術作為合約引擎，但需要進行一些改造以從技術上解決確定性問題。例如，R3 Corda 使用了 JVM 作為其智慧合約的執行環境，即 Corda 中的交易型別均使用 JVM 的位元組碼來定義和執行。但由於傳統 JVM 中仍有一些可能導致非確定性的操作，例如隨機數、Java 的垃圾回收等等，因此 Corda 目前也在嘗試開發一個確定性的 JVM 沙盒環境（Determinstic JVM， 簡稱 DJVM）用來檢測使用者開發的程式碼是否存在非確定性[17]。
這種方式的思路在於，JVM 有一些相對於 EVM 的實現智慧合約引擎的優勢[18]：
· JVM 已經過大規模、長時間的工業檢驗。作為底層相對於 EVM 更有安全和健壯性方面的優勢
· 利用 Java 語言和現有的開發生態，可以讓開發者更快上手
· 一些語言特性，包括對浮點數的支援等也會比 Solidity 更有優勢
而缺點在於，JVM 存在很多和區塊鏈需求無關的功能，同時要增加通證經濟中的 gas 機制來實現可終止性也並不容易。
除了用傳統虛擬機器技術外，還有一些是用模擬器來模擬傳統的指令執行環境，支援多語言開發並讓存量程式碼儘可能低成本的遷移到區塊鏈開發環境中。例如 Qtum 的 x86 虛擬機器設計為相容傳統已被廣泛應用的 x86 伺服器指令集，這樣可以使得行業長期內積累起來的海量程式碼透過少量改造即可用於基於智慧合約的區塊鏈執行環境中；同時可以提供多語言支援。
5.3.3.wasm 方式
除上述方式外，WebAssembly 技術被越來越多的用來實現智慧合約引擎。
WebAssembly 是一種跨平臺二進位制指令格式，可以用於基於棧的虛擬機器中，希望將客戶端和服務端程式均可以部署在 web 上。由於其優良的效能和多語言支援的廣泛相容性，目前已在 web 開發中被推廣使用，被 Chrome、Edge、Firefox 等現代瀏覽器所支援，被認為將有可能取代現有的 JavaScript。很多大型應用也在嘗試使用 WebAssembly，例如執行在瀏覽器中的 Windows 2000[19]。不少人將 2018 年視作是 WebAssembly 技術元年。
在區塊鏈領域內，也有一些平臺開始使用 WebAssembly 技術，這也是近期智慧合約實現技術的一種流行趨勢。例如目前 EOSIO 已採用 WebAssembly 來實現其虛擬機器 WAVM。
相對於以太坊的 EVM，使用 WebAssembly 技術的虛擬機器，主要有以下優勢：
· 可以支援 C、C++、Rust 等多語言進行開發，降低了開發者的進入門檻和學習成本
· 編譯成 wasm 的結果對 CPU 架構透明，雖然不能執行在 CPU 之上，但可以在主流現代瀏覽器中部署執行
· WebAssembly 因為構建方式是儘可能接近機器程式碼，編譯體積小、載入速度快，效能相對較高
但 WebAssembly 也有其一些缺點待改進，例如作為一項底層技術，WebAssembly 還不夠成熟，例如存在一些瀏覽器新老版本相容問題；生態工具各方面也有待發展。
不過，以太坊已在考慮將 EVM 採用 WebAssembly 方式實現，即 eWASM。而在目前使用 Rust 實現的 Parity 以太坊節點上，已可選用 WebAssembly 方式來實現其虛擬機器。
6. 實測分析
對於以太坊將使用 WebAssembly 實現 EVM 的計劃，我們採用程式程式碼實測的方式來對比評估是否有較大幅度的效能提升。
由於目前 Parity 已實現了一個基於 WebAssembly 的節點並且沒有改變字長等其他內容，變數較為可控，可以大致比較出改用 WebAssembly前後的效能對比。我們透過使用標準 EVM 的 geth 客戶端與 WebAssembly（pwasm）的 Parity 客戶端，分別搭建了私有區塊鏈網路，並用 Solidity和 Rust 編寫完成相同功能的合約，並編譯部署、對比執行。
6.1.測試環境
執行的硬體環境：
· 作業系統：Ubuntu16.04 x86_64
· CPU：Intel core i7-6700HQ
EVM 版本：
· geth 版本：1.8.15-stable
· go 版本：go1.10.4 linux/amd64
· Solidity 版本：0.4.24
pwasm（Parity WebAssembly）相關版本為：
· Parity 版本：v2.1.3-beta
· rustup 版本：1.14.0
JavaScript 測試程式碼環境：
· NodeJS 版本：v8.9.0
· web3 庫版本：1.0.0-beta.36
6.2.測試場景及結論
6.2.1.測試場景 1
以太坊的轉賬流程更多的是基於賬戶體系上的餘額增減，因此第一個場景是在虛擬機器上進行 1000 次迴圈加法運算，測量其程式執行時間及空間佔用等技術指標。
在 EVM 和 pwasm 上的測試結果分別如下：
可以看到，換用了 WebAssembly 後，執行速度會有所提升，但幅度有限。
6.2.2.測試場景 2
場景 2 使用 100 次乘法，進行相同的執行對比測試。
可以看到與場景 1 的迴圈加法，測試的指標結果比較類似：WebAssembly 同樣對執行速度有所提升但依然不顯著。
6.2.3.測試場景 3
除了基本的加法、乘法外，場景 3 使用 10 個數字的 10 輪氣泡排序來進行更復雜的業務邏輯測試。
可以看到在排序這種場景下，WebAssembly 降低了一半左右的執行時間，最佳化效果明顯。
因此可以看到，如果只為實現簡單的 ERC20 等合約轉賬等操作，單靠使用 WebAssembly 的虛擬機器並不能帶來很大的效能提升，可能遠不如透過其他技術改造，例如共識機制、分片等方式對效能的提升來的更為明顯。
但在實現更復雜的合約邏輯時，WebAssembly 會顯示出強大的效能優勢，可為大規模、複雜場景下的區塊鏈業務應用提供更好的技術支撐。
7. 參考資料
[1] SZABO N. Smart Contracts[EB/OL]. (1994). http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html.
[2] 張錚文, 達鴻飛. 重構智慧合約（上）：非確定性的幽靈[EB/OL]. . https://zhuanlan.zhihu.com/p/25764739.
[3] 蘇小樂. 十問智慧合約（二）-道友，你的智慧合約環境有什麼不同？[EB/OL]. . https://zhuanlan.zhihu.com/p/42528521.
[4] WIKIPEDIA. Deterministic algorithm[EB/OL]. . https://en.wikipedia.org/wiki/Deterministic_algorithm.
[5] Ethereum Yellow Paper[EB/OL]. . https://github.com/ethereum/yellowpaper.
[6] Forth (programming language)[EB/OL]. wikipedia, . https://en.wikipedia.org/wiki/Forth_(programming_language).
[7] 袁煜明, 劉洋. 【火幣區塊鏈產業專題報告】區塊鏈技術可擴充套件方案分層模型[R]. .
[8] 袁煜明, 胡智威. 【超越白皮書3】DAG技術解析與實測[R]. .
[9] SAMEEH T. An Overview Of Smart Contract Scripting For Cryptocurrency Blockchains[EB/OL]. . https://www.deepdotweb.com/2017/01/15/overview-smart-contract-scripting-cryptocurrency-blockchains/.
[10] EARLS J. The Faults and Shortcomings of the EVM[EB/OL]. . http://earlz.net/view/2017/08/13/0451/the-faults-and-shortcomings-of-the-evm.
[11] Aion FastVM[EB/OL]. . https://github.com/aionnetwork/aion_fastvm.
[12] CREMER L. Missing return value bug — At least 130 tokens affected[EB/OL]. Medium, 2017. (2017). https://medium.com/coinmonks/missing-return-value-bug-at-least-130-tokens-affected-d67bf08521ca.
[13] Hyperledger Burrow[EB/OL]. . https://www.hyperledger.org/projects/hyperledger-burrow.
[14] Nervos Network 簡介[EB/OL]. . https://docs.nervos.org/.
[15] FOUNDATION A. Introducing the FastVM[EB/OL]. . https://blog.aion.network/aionfastvm-c5ccd1628da0.
[16] TEAM T Z. Zilliqa Technical Whitepaper[J]. Zilliqa, 2017: 1–8.
[17] LILLEHAGEN T. DJVM Behind the Scenes[EB/OL]. . https://medium.com/corda/djvm-behind-the-scenes-2ba7f5cb9275.
[18] EVANS B. Deterministic Execution on the JVM[EB/OL]. . https://www.infoq.com/articles/Deterministic-Execution-JVM.
[19] Windows 2000 emulated in WebAssembly[EB/OL]. . https://www.reddit.com/r/webdev/comments/98ufca/windows_2000_emulated_in_webassembly/.
來源：火幣區塊鏈應用研究院（超越白皮書 6）
作者：袁煜明、胡智威
更多區塊鏈資訊：www.qukuaiwang.com.cn/news
