來源 | Ivan on Tech

以太坊2.0之eWASM

eWASM是以太坊邁向2.0時代的又一創新之舉。主流看法是，eWASM能夠促進網絡的速度、可擴展性和靈活性，也使得開發者能夠基於以太坊2.0的協議構建更爲複雜的智能合約。除此之外，我們之前的文章還對Eth 2.0的許多不同方面進行了解釋，如 Staking 、 Sharding 、 以太坊Layer-2 、 zk- snark 等。在探討eWASM之前，我們再過一遍以太坊2.0的基本路線。

什麼是以太坊2.0？

以太坊2.0包含一系列升級，將對協議進行顛覆性的改進，擴容以太坊網絡，使其更加高效。其中的升級包括：使用Casper協議的Proof of Stake (權益證明) 機制、分片、Raiden (雷電網絡)、Plasma以及Rollups等等。這些升級將會在 以太坊不同的階段 中實現，以確保合理地部署和執行。

  • 階段0：啓動信標鏈，轉向PoS權益證明機制
  • 階段1：加入分片
  • 階段2：使用以太坊0 eWASM替代現有的以太坊虛擬機 (EVM)

本文將主要探討階段2，如果讀者對以太坊2.0有一些瞭解，那麼應該知道從EVM到eWASM的轉變是非常宏大的工作。在我們進入eWASM之前，先來看看EVM到底是什麼。

以太坊虛擬機是什麼？

每條去中心化的區塊鏈都需要一個虛擬機來處理並執行操作。比特幣的虛擬機相對簡單，因爲它只需要處理交易。然而，由於以太坊支持圖靈完備的智能合約，其複雜度也就更高。因此，我們需要思考另一個重要問題。

既然智能合約要滿足不可篡改性，並且即使歷經多個節點也能無損運行，那麼以太坊虛擬機 (EVM) 需要擁有哪些主要特性？

  • 確定性
  • 可終止性
  • 獨立性

確定性

如果針對相同的一組輸入，無論其執行了多少次代碼，程序都給出相同的輸出，那麼就可以說是該程序具有確定性。確定性函數的一個完美示例就是數學運算。例如，假定所有數字都以10爲底，則無論重複運算多少次，1 + 4始終等於5。

DApps往往需要同時處理大量金額，所以用戶需要清楚知道代碼在每個執行階段如何響應。

可終止性

我們需要謹記一點，以太坊智能合約是圖靈完備的。如果有充足的時間和資源，那麼理論上來說智能合約可以解決任何問題。然而，我們無法判斷合約是否能在給定的時間限制內完成所有操作。這就是爲什麼智能合約需要有終止機制。以太坊智能合約藉助“gas”來定義其使用期限。當合約達到gas上限，則無法繼續進行操作。

獨立性

最後，智能合約應該在一個完全獨立的環境中運行。如果合約發生什麼意外情況 (例如被攻擊或是出現漏洞)，那麼其影響不應該波及到其他底層協議。

要滿足以上三個特性，有兩種系統可以供智能合約使用——虛擬機和Docker容器。由於Docker的合約默認設計不具備確定性，以太坊決定採用虛擬機。

以太坊虛擬機：如何運作？

當我們說到“虛擬機” (virtual machine) 的時候，到底是什麼意思？

傳統的操作系統 (Windows/iOS) 一次只需要在一個系統中運行。而虛擬機 (VM) 是基於本地操作系統所創建更高級抽象，可用於複製物理機的功能。

虛擬機使得用戶能夠在不同的硬件架構和操作系統中同時運行同一平臺。這就是爲什麼虛擬機非常適合像以太坊這樣的去中心化網絡的原因。以太坊的主要目標是成爲一臺全球超級計算機，使得開發者能夠藉助其計算資源構建自己的智能合約和去中心化應用程序。以太坊虛擬機 (EVM) 的功能就類似世界計算機，遍佈全球的節點都能進行訪問。

堆棧和狀態機

相較於普通的虛擬機，EVM還具備兩個額外特性。首先，作爲狀態機的EVM可以讀取輸入然後相應地更新其狀態。其次，EVM還是堆棧式，其內存結構能夠以堆棧形式進行組織和訪問。

如果讀者熟悉數據結構，那麼應該對堆棧並不陌生。堆棧是線性數據結構，其中的操作是通過LIFO (後進先出) 來執行的。

下面舉個例子：

在上圖的堆棧中，第一條插入的數據是Orange，最後一條數據是Apple。根據LIFO的邏輯，我們取出的第一條數據應該是Apple，最後纔是Orange。

現在我們再來看看堆棧操作：Push和Pop。

  • Push：向堆棧中加入數據
  • Pop：使用LIFO邏輯將數據從堆棧中移除

EVM中的堆棧操作

在堆棧式虛擬機中，操作執行如下：

  • 首先移除數據和操作數
  • 相應操作被執行
  • 執行結果被加入堆棧

參考以下圖表：

  • 我們首先移除兩個數字：20和7
  • 將這兩個數字相加，我們得到27
  • 最後，結果被重新加入堆棧

EVM堆棧式系統的優勢

  • 堆棧結構可確保EVM不需要獲取操作數的確切地址。堆棧結構會始終且必然將VM指向下一個操作數。降低大量操作開銷的同時提高了整體效率。
  • EVM擁有：世界狀態(world state)、機器狀態 (machine state) 和虛擬ROM。世界狀態將所有帳戶存儲在網絡中，機器狀態包括程序計數器、可用gas、堆棧和內存等數據。最後，虛擬ROM讀取名爲“ EVM字節碼”的機器級代碼。這是隻有EVM才能理解的獨特語言。

EVM – 讀取字節碼 

編程語言分爲高級和低級語言。低級語言 (如字節碼) 能夠輕鬆被機器讀取，但人類卻難以理解。這也是爲什麼大多數編程語言都是高級形式的原因。那麼，在智能合約中程序是如何運作的呢？

  • Solidity/Vyper語言的智能合約被編譯爲字節碼，使用到的編譯器叫做“solc”
  • 字節碼由網絡讀取並處理
  • 字節碼是Solidity操作碼的二進制形式。從EVM轉向eWASM的過程中，編譯器是非常重要的一個部分，因爲EVM無法理解除了字節碼之外的任何語言。
  • 每個操作碼在規範中都被賦予了易於理解的名稱，並由數字代碼表示。例如，數字0X01代表ADD操作碼。

EVM的功能性

  • EVM是以太坊網絡中的去中心化處理單元。每筆交易、交互和智能合約執行只能通過EVM進行。
  • 負責所有不同的數據結構，包括指令、操作數以及已經處理的數據。
  • EVM通過指令分配器獲取並執行指令，對操作碼進行解碼。
  • EVM還會跟蹤多個網絡組件，例如世界狀態、存儲狀態以及區塊信息。
  • 在以太坊網絡中爲智能合約創建一個運行時環境。該環境包含需要用以執行具體交易的信息，例如gas價格 (最新gas價格)、代碼大小、Caller (交易接收方地址) 以及Origin (交易發送方地址)。

EVM的缺點

雖然EVM具備許多優勢，但也存在四個主要問題，導致網絡的整體吞吐量受限：

  • 由於EVM需要處理大量各種各樣的操作，其速度便不盡人意。EVM的操作碼規範沒有進行更新，也沒有針對不同的硬件平臺做出優化。
  • 第一點提到由於EVM需要處理大量不同操作，就會容易成爲運轉瓶頸。其結果就是嚴重損害整個網絡的效率。
  • 自從發佈初始規範以來，EVM並沒有進行太多優化，導致編寫合約所需的工具和語言極大受限。

假如底層工作環境本身存在巨大缺陷，那麼引入一系列新穎機制 (分片/rollups/Casper) 的意義何在？以太坊之所以尋求從EVM轉向使用eWASM，也出於對以上缺陷的衡量。

那麼什麼是eWASM呢？在此之前，我們需要先理解什麼是WebAssembly。

什麼是 WebAssembly (WASM) ？

WebAssembly最近獲得了許多關注。WebAssembly是由World Wide Web Consortium (W3C, 萬維網聯盟) 創造並定義的新代碼類型，能夠在現代瀏覽器中高效執行。

WebAssembly憑什麼獨樹一幟？

由於WASM具備基於堆棧的低級二進制格式，且在默認情況下很小，從而可以實現快速加載和執行。瀏覽器下載WASM代碼後，便可以快速將其轉換爲任何計算機的程序集。

WebAssembly 的優勢

  • 受多個JavaScript引擎和運行時環境的支持，可以在大多數現代瀏覽器中執行。
  • Go/Rust/C/C++語言可以直接編譯爲WASM
  • 能夠快速適應所有機器級架構，具備極高性能
  • 附帶與大多數現代硬件架構兼容的指令集
  • 在大多數平臺上趨近於本地運行速度

以太坊2.0 eWASM 

讀到這裏大家可能已經發現了，eWASM (Ethereum WebAssembly) 就是以太坊2.0版的WebAssembly。

根據相關團隊的說法：

eWASM = WASM – 非確定性  ( 浮點 ) + 計量 + EEI 路徑 ( 用以與以太坊交互 )

eWASM團隊已經給出其具體的設計目標：

  • 構建EVM轉譯器，並且以eWASM合約形式添加計量注入器
  • 發佈明確詳細的規範：以太坊接口、eWASM合約語義以及細節
  • 爲solc編譯器構建一個eWASM後端
  • 提供C語言和Rust語言的相應指令和庫，以支持智能合約編寫

諸如EOS、Tron以及Cardano等項目已經或者準備採用WASM，實現eWASM之後，以太坊也將成爲其中之一。

eWASM vs EVM

EVM的主要設計目標就是要保證正確性，即使可能會因此犧牲一定的效率。以太坊開發者Lane Rettig認爲EVM是基於理論設計而非實用設計，因此可能無法完美支持現實應用。EVM中的每個節點都必須完整正確地運行EVM，而WASM是爲現實應用而生的，能夠翻譯輕鬆實際的代碼邏輯，因此在效率和速度上更具優勢。

現在有了大概的認識，我將進一步對比eWASM和EVM。

eWASM vs EVM #1: 速度

簡單來說，EVM可以看作是“萬精油”，但沒有達到理想效果。就拿代碼編譯來說吧。

EVM經常無法有效編譯大量代碼。而瀏覽器的本地JS引擎通常需要大量工作來爲某些操作的執行匹配最佳路徑，而這對EVM的整體吞吐量來說會產生巨大影響。此外，EVM只能處理256位的字節碼，因此小於256位的字節碼必須轉換爲256位格式。

EVM的設計極大限制了以太坊的速度和可擴展性，使其每秒最多隻能處理25筆交易。而這對於現實世界和現實需求來說是非常不切實際的。

eWASM可以直接轉換爲編譯代碼，從而提高加載速度，並且大幅提升每個區塊能夠處理的交易量。除此之外，有了分片和layer2解決方案的加持，以太坊2.0的速度會顯著提升。

eWASM vs EVM #2: 預編譯

eWASM還能消除以太坊對預編譯的依賴。預編譯是EVM字節碼的特殊位，好處在於能夠節省gas成本，進行高效的密碼運算。大多數情況下，如果不進行預編譯，那麼幾乎不可能將創建合約所需的gas控制在上限範圍內。而eWASM的gas效率非常之高，以至於能夠省去大部分甚至全部的預編譯。

然而，預編譯也有不足之處。引入新的預編譯往往需要網絡進行系統範圍的硬分叉。根據歷史經驗，因爲可能導致社區分裂，硬分叉多少具有爭議性。

而這些意味着什麼？

eWASM能夠幫助開發者又快又省地創建智能合約，並且沒有硬分叉的顧慮。

eWASM vs EVM #3: 靈活性

最後，相較於標準的EVM，eWASM最顯著的優勢就是代碼靈活性。要編寫智能合約，以太坊開發者必須特地學習Solidity語言，而這就成爲了開發者的知識瓶頸。

eWASM能夠與多種語言進行交互，並且擁有更爲廣泛的開發者工具集。eWASM將支持C/C++/Rust語言。

eWASM將獲得所有主流JavaScript引擎的支持，例如：

  • Microsoft的Chakra引擎 (Microsoft Edge)
  • Google的V8 engine (Node.js及基於Chromium的瀏覽器)
  • Mozilla的Spidermonkey引擎(Firefox及Thunderbird)

eWASM還將獲得以下非瀏覽器實現的支持，例如：

  • ml-proto (OCaml引用解釋器)
  • wasm-jit-prototype (使用LLVM後端的獨立虛擬機)
  • wabt (基於堆棧的解釋器)

EWASM還具有以下的開創性優勢，這些優勢是之前的EVM不可能擁有的：

  • 對於以太坊輕客戶端，得到瀏覽器支持會更簡單，因爲eWASM是根據W3C標準架構的
  • eWASM有更多編譯器和更多種類的開發者工具
  • 由於大量的項目已經在使用eWASM了，它已聚集了一個健康、多元的開發者社區

結語：eWASM能否助Eth 2.0更上一層樓？

關於eWASM，以太坊社區感到非常興奮。然而，相關討論也總是伴隨着天花亂墜的說法，我們還需要聽到不同的聲音。一位資深以太坊開發者Greg Colvin就對eWASM智能合約持疑，其主要觀點是：

  • eWASM無法消除預編譯
  • eWASM過渡依賴編譯器，可能會導致單點故障

其實絕大多數以太坊開發者都相信eWASM將對協議的整體性能和吞吐量造成巨大影響。

結果究竟會如何呢？讓我們拭目以待吧！

聲明：ECN的翻譯工作旨在爲中國以太坊社區傳遞優質資訊和學習資源，文章版權歸原作者所有，轉載須註明原文出處以及ethereum.cn，若需長期轉載，請聯繫[email protected]進行授權。

相關文章