eWASM-001

撰文：Mabrary

引介

随着越来越多的应用部署在以太坊网络上，我们对扩展不可能三角（可扩展性、安全性和效率）的边界有了更强烈的需求。

具体来说，制约不可能三角的因素主要是共识机制(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的每个栈的宽度都必须是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是一种虚拟指令，通过执行引擎（虚拟机），联系着程序本身和我们电脑物理意义上的处理器。

可见，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的一一对应关系：

+ Metering

Metering用来测量执行eWASM指令所需的计算量，可以对应到某些特定硬件上所需的计算时间。

在eWASM中，有三个地方需要支付Gas：运行opcodes、扩展内存、调用EEI中的方法。

• opcodes是指WASM中自带的操作码，每个WASM操作码会被分配一个适当的Intel IA-32 (x86架构)操作码（机器码），而每个操作码都会对应一个固定的计算量。根据以太坊节点目前的硬件算力，得出每单位计算量对应0.0045 gas。那么，我们就可以根据每个opcode的计算量得出执行它所需消耗的gas个数。

Gas cost = <cycle count> * <gas per cycle>

下图中，我们截取了一些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 = <Gas cost> * <Gas price>

小结

为了应对越来越复杂的以太坊链上业务逻辑，以太坊2.0希望通过eWASM代替原有的EVM，来提高虚拟机的执行效率。由于当前以太坊虚拟机的栈的设计和主流处理器的原生格式不匹配，使得执行指令需要多次转码，加大了复杂度。同时，一些常用的优化策略无法直接应用，导致EVM的执行效率无法最大化。

WASM作为一种更接近本地执行虚拟指令集，让以太坊的执行层拥有更好的性能、较低的存储成本、更多的语言支持。为了适配WASM，以太坊2.0通过限制(去掉浮点数，限制符号)和增加接口(EEI,ECI)等一系列改造，让eWASM能够在以太坊的执行层中顺利地接过EVM的接力棒，达到高虚拟机的执行效率，降低开发门槛的目的。

以太坊2.0分为三个阶段：PoS、分片、以及eWASM，目前共识机制由POW转向POS的merge还在紧张测试中，eWASM的开发仍需等待前两个阶段的完善。因此，目前eWASM的更新并不频繁，更多实施的细节仍待确定。尽管如此，WASM在其它公链的表现已经证明了它在区块链领域应用的潜力，eWASM在以太坊上的实现还是值得期待的。