引言：隨著越來越多的應用部署在以太坊網絡上，我們對擴展不可能三角（可擴展性、安全性和效率）的邊界有了更強烈的需求。
具體來說，制約不可能三角的因素主要是共識機制(consensus protocols)、轉賬簽名(transaction signing)和執行引擎(execution engine)。
對於以太坊而言，目前的執行引擎或者說是整個協議架構的執行層就是以太坊虛擬機(EVM)，這是一種基於棧(Stack)的執行環境，通過運行字節碼指令(bytecode instruction)將系統從一種狀態轉換為另一種狀態，驅動著整個以太坊的運轉。
隨著鏈上部署的應用越來越多，合約的功能越來越複雜，提高虛擬機的執行效率就顯得尤為重要。
圖片源：以太坊架構
WebAssemly(WASM)，作為近年來興起的Web執行環境，是一種為基於棧的虛擬機設計的的二進制指令格式。相對JavaScript，擁有更好的性能、較低的存儲成本、更安全的執行環境、更多的語言支持等優勢。
以太坊2.0，正是想利用這些特性把當前的EVM替換成以太坊定制的WASM (eWASM) ，來提升智能合約的兼容性和執行效率。
因為相比於EVM，eWASM具有更好的性能以及更好的擴展性，可以支持Solidity、C++、Rust、AssemblyScript等編程語言，開發合約會更容易。 eWASM也與當前的Web標準兼容，因而更容易在普通瀏覽器中運行，用戶無需擴展程序即可訪問dApp。
此外，以太坊並不是唯一一個使用WASM(VM)作為其底層執行引擎的，EOS、Dfinity、Polkadot、Tron、Cardano、Spacemesh等都已經或正在採用WASM。
接下來，我們想通過三個問題，來幫助大家初識以太版WASM——eWASM
1.現有的EVM存在什麼問題，為什麼尋求WASM替代EVM？
2.什麼是WASM(WebAssemly)？
3.以太坊是如何“定制”自己的WASM，使其成為eWASM的？
現有的EVM存在什麼問題
為什麼尋求WASM替代EVM？
首先我們先來回顧一下EVM執行智能合約的過程。
智能合約的源碼(.sol 或.vy)在被編譯(compile)成字節碼(EVM bytecode)後才會被放在區塊鏈上。具體來說，EVM字節碼被存儲在合約地址的存儲層中，在被EOA或其他合約調用後會被放入EVM的虛擬只讀存儲器中(Virtual ROM)，再使用CODECOPY指令複製到主存儲器(Main Memory)中。最後，EVM的棧會根據主存儲器中的指令一步一步地執行，直到EVM停機或者Gas被耗盡。
以上過程可以認為是，在沙箱中運行了一個以太坊世界狀態的副本。
圖片：EVM執行過程
我們知道EVM是基於棧的虛擬機，它的內存結構是通過棧來組織和訪問的。
由於EVM的每個棧的寬度都必須是256-bit的，所以即使是小於256位的計算也必須轉碼為256-bit的格式，然後EVM才能處理它們。這就導致執行指令需要多次轉碼，一些較簡單的計算變得冗雜，加大了執行的複雜度。
另外，由於EVM包含了很多較複雜的高級指令，如SHA3、Create Contract等，使得EVM這個虛擬機環境和目前32-bit或64-bit的硬件規格相去甚遠，一些執行時的優化策略無法直接用來優化EVM的指令，導致不能最大地優化EVM指令的執行效率。
什麼是WASM(WebAssemly)？
WebAssemly(Web上的彙編)的名字由兩部分組成：Web和Assembly。
首先，我們來看一下什麼是Assembly(彙編)。
計算機語言分為低級語言和高級語言，我們平時講的編程一般是指人類可讀的高級語言編程，而計算機真正能夠理解的是低級語言，用二進制數表示，它專門用來控制硬件。
圖片源：網絡
一段計算機程序在進入CPU之前，首先要加載到RAM中，而後這些程序和數據進入CPU。
CPU真正負責計算和邏輯判斷的是算數邏輯單元(ALU)，指令被拆分為Operand（操作數）和Operation Code（操作碼），前者指明操作對象的地址（也就是寄存器的地址），後者告訴CPU需要對Operand執行什麼操作。
如下圖中，111010101 001010就是CPU在把寄存器中位置為001和010中寄存的數據進行加和操作(ADD)。
彙編語言是二進制指令的文本形式，而彙編過程就是把ADD這樣的彙編語言轉換成111010101這樣的機器語言。
圖片源：網絡
加上Web這個修飾詞之後，WebAssemly面向的是一種概念上機器的“機器語言”，而不是一種真實存在的物理機器，不會直接映射到特定的機器碼。
如下圖，它的指令是高級語言編譯後形成的.wasm的二進製文件。與JavaScript源碼相比，虛擬指令跟機器碼的映射來得更為直接，執行效率也就更高。最後，瀏覽器會下載WebAssembly，然後把它編譯為本地機器的機器代碼執行。
也就是說，WebAssembly是一種虛擬指令，通過執行引擎（虛擬機），聯繫著程序本身和我們電腦物理意義上的處理器。
圖片：WASM編譯
可見，WebAssembly不是一種語言，而是規定了一種虛擬指令集，可以作為各個語言的編譯目標，然後通過WASM的虛擬機運行到瀏覽器還有其他各個平台中。
eWASM給自己的定義是，以太坊為自己定制的一個受限的WASM子集。
以太坊是如何“定制”WASM
使其成為eWASM？
從WASM到eWASM，我們通過下面的式子來展開上面提到的“受限”和“子集”：
– 浮點數
由於浮點數在不同硬件上的精度可能會有所不同，會造成一定的誤差，而在去中心化網絡中完成共識需要以太坊中代碼的執行是百分百確定的（deterministic），也就是執行結果不能因硬件不同而發生偏差。
所以，eWASM不能支持浮點數。
+ ECI
以太坊合約接口(ECI)，是區塊鍊和執行合約代碼的虛擬機交互的接口。
其中，導入只能通過API導入EEI中規定的符號（方法），這意味著eWASM模塊指定的所有導入都必須來自ethereum命名空間，如getAddress、getBalance等，這確保了以太坊合約執行始終是一個沙盒環境。另外，每個合約提供兩個export方法，一個是main，供虛擬機執行調用。一個是memory供EEI調用，用來保存執行的結果。
+ EEI
Ethereum Environment Interface(EEI)，以太坊環境接口。
由於WASM屬於低級語言，並不支持以太坊環境中所需的所有opcode，因此需要一個中間件(Ethereum Environment Interface,EEI) 幫助底層的WASM和以太坊做交互，通過API的方式來為eWASM合約提供必要和常用的方法來獲取鏈上信息。
以下就是部分EEI中的方法和當前EVM opcode的一一對應關係：
圖片源：https://ewasm.readthedocs.io/en/mkdocs/fee_schedule/#calls-to-the-eei
+ Metering
Metering用來測量執行eWASM指令所需的計算量，可以對應到某些特定硬件上所需的計算時間。
在eWASM中，有三個地方需要支付Gas：運行opcodes、擴展內存、調用EEI中的方法。
opcodes是指WASM中自帶的操作碼，每個WASM操作碼會被分配一個適當的Intel IA-32 (x86架構)操作碼（機器碼），而每個操作碼都會對應一個固定的計算量。根據以太坊節點目前的硬件算力，得出每單位計算量對應0.0045 gas。那麼，我們就可以根據每個opcode的計算量得出執行它所需消耗的gas個數。
Gas cost =
下圖中，我們截取了一些eWASM的opcode對應的Gas Cost：
圖片源：網絡媒體
目前，所有opcodes的gas price=1；
內存可以按頁進行擴展，其中一個頁對應於65536字節的空間。按照當前EVM擴展內存的公式：words * 3 + words ^ 2 / 512，一個word佔32為字符，擴展一個內存頁會消耗14336個gas；
eWASM調用EEI接口的gas price和執行當前的EVM opcode相同。
執行eWASM字節碼所需的Gas費的計算方式和EVM一樣：
Gas Fee =
eWASM:
以太坊2.0“心臟置換”
為了應對越來越複雜的以太坊鏈上業務邏輯，以太坊2.0希望通過eWASM代替原有的EVM，來提高虛擬機的執行效率。
由於當前以太坊虛擬機的棧的設計和主流處理器的原生格式不匹配，使得執行指令需要多次轉碼，加大了複雜度。同時，一些常用的優化策略無法直接應用，導致EVM的執行效率無法最大化。
WASM作為一種更接近本地執行虛擬指令集，讓以太坊的執行層擁有更好的性能、較低的存儲成本、更多的語言支持。為了適配WASM，以太坊2.0通過限制(去掉浮點數，限制符號)和增加接口(EEI,ECI)等一系列改造，讓eWASM能夠在以太坊的執行層中順利地接過EVM的接力棒，達到高虛擬機的執行效率，降低開發門檻的目的。
以太坊2.0分為三個階段：PoS、分片、以及eWASM，目前共識機制由POW轉向POS的merge還在緊張測試中，eWASM的開發仍需等待前兩個階段的完善。
因此，目前eWASM的更新並不頻繁，更多實施的細節仍待確定。儘管如此，WASM在其它公鏈的表現已經證明了它在區塊鏈領域應用的潛力，eWASM在以太坊上的實現還是值得期待的。
作者｜Mabrary
編輯｜小歐
