階段2：使用以太坊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將對協議的整體效能和吞吐量造成巨大影響。
結果究竟會如何呢？讓我們拭目以待吧！
