区块链系统中的EOS-VM是什么

EOS-VM是EOS.IO成为通用区块链协议的重要基石，同时超越了EOS.IO自身，将会成为事实上的区块链虚拟机技术标准，甚至会将以太坊和波卡尚在起步阶段的虚拟机开发扼杀在襁褓中。

0、前言

EOS.IO开发团队 Block.One于2019年6月1日发布了全新的EOS-VM。

EOS原力团队在经过大规模测试后认为，EOS-VM 将成为区块链行业使用率最高的 VM，也将率先成为区块链行业 VM 的事实标准。

我们在《EOS.IO 将迎来史上最复杂硬分叉升级》一文中曾经讲过，多个重要的分支都在积极开发中，而 EOS-VM 就是一个重要性不亚于 1.8.0 的分支。该分支从 2018 年 7 月份就开始了，从提交记录上来看，早期的 EOS-VM 并没有特别紧凑的开发计划。然而从 2019 年开始，经过了一系列密集的开发，初步完成了今天我们所看到的 EOS-VM 项目。

如果说 EOSIO1.8.0 版本让我们看到了 Block.one 在 EOS.IO 上的决心，那么 EOS-VM 可以让我们一窥 Block.one 在区块链行业的野心。

1、什么是VM

VM全称为Virtual Machine，在区块链语境下可以理解为智能合约的运行环境。

我们可以将智能合约类比于互联网中的 HTML，区块链系统可以看作操作系统，那么 VM 则是浏览器，各种基于智能合约的 DAPP 就是互联网中的各种网站。

以太坊完成了区块链系统中首个系统的智能合约支持，其 EVM 虚拟机也是早期智能合约开发者的主流开发环境，同时有非常多的项目都借鉴了以太坊的 VM，如 TRX 的 TVM。

但是 EVM 有其局限性，虚拟机效率相对成熟的虚拟机系统来说极其低下，难以支持更加复杂的应用和环境。

成熟的虚拟机系统是一个由一系列庞大的项目构成的体系，事实上，在目前的环境下，从零开始实现一个完整成熟的虚拟机系统是非常困难的，同时也是没有必要的，因为对于这样一个庞大的工程项目，从零开始意味着开发者和社区要承受大量的兼容和学习成本，最好的方式是基于现有成熟的虚拟机标准来开发适用于区块链项目的虚拟机实现。

因此，大多数区块链项目都选择使用现有成熟的虚拟机实现，目前可以说最适合的莫过于 WebAssembly 虚拟机，除了 EOS.IO 之外，polkadot 也选择基于 WebAssembly，而以太坊也在开发基于 WebAssembly 的 ewasm 项目。

对于区块链领域来说 ， 无论是不是「The Lesser Evil」，WebAssembly 已经成为非常重要的一部分了。

作为一个高性能的去中心化智能合约平台，EOSIO 中所使用的虚拟机实现是整个项目中非常重要的一部分，在阅读早期的 EOSIO 实现代码时会发现，在调用虚拟机时，EOSIO 实现代码中少有的做了很严格的封装，以此来隐藏虚拟机实现的细节，可以见得 EOSIO 项目将会在虚拟机方面做持续重大的改进 。

// EOSIO chain 实现中少有的接口封装

class wasm_interface {

public：

enum class vm_type {

wavm，

wabt

};

。..

private：

unique_ptr《struct wasm_interface_impl》 my;

。..

};

从最早使用的 wavm 虚拟机，到后面支持的 wabt 虚拟机，Block.one 团队一直在改进虚拟机的支持，也在为多虚拟机兼容作准备，最终 EOSIO 发起了更高的挑战，开发出了全新的 EOS-VM，最为 EOSIO 使用的虚拟机实现。

如果说 EVM 是一个区块链虚拟机的话，那么 EOS-VM 则会是第一个可大规模商用的虚拟机。

2、EOS-VM 是什么

我们先来看看 EOS-VM 到底是什么，EOS-VM 是一个区块链系统专用的 wasm 运行时。

在区块链系统中，合约代码会被编译成字节码的形式，这些字节码不能直接在操作系统上运行，需要一个执行器来执行这些合约，在软件体系中，可以把这些执行器视为一个抽象的「机器」，EOS-VM 就是这样一个执行器。

EOS-VM 主要做四件事：

首先 ，EOS-VM 负责加载和解析编译后的智能合约字节码，也就是 wasm；

其次，EOS-VM 负责在字节码运行过程中为其分配资源，当然对于智能合约来说，可用的资源就是内存；

再次，EOS-VM 负责向智能合约的字节码提供虚拟机外的 API 调用功能；

最后，EOS-VM 负责执行字节码来计算智能合约运行的结果。

在 EOS-VM 中 eosio：：vm：：backend 类是整个虚拟机系统调用的入口，在 tools 目录下有两个使用 EOS-VM 虚拟机的测试工具，想要详细了解 EOS-VM 实现的读者可以通过这些作为入口来阅读 EOS-VM 的代码。

int main（int argc，char**argv） {

。..

// 设置看门狗 ， 限制运行时间为秒

watchdog《std：：chrono：：nanoseconds》 wd;

wd.set_duration（std：：chrono：：seconds（3））;

try {

。..

// 加载 wasm 字节码

auto code = backend_t：：read_wasm（ argv［1］ ）;

// 创建执行环境

backend_t bkend（ code ）;

wd.set_callback（［&］（）{

bkend.get_context（）.exit（）;

}）;

。..

// 执行

bkend.execute_all（&wd）;

} catch （ 。.. ） {

}

return 0;}

这里说的 EOS-VM 的主要工作，但如果只是这些的话，那其实和 wavm、wabt 没什么区别了，在完成基本的必要工作之外，EOS-VM 针对区块链应用场景做了一些重要的改进和优化，下面我们来结合 EOS-VM 的介绍文档以及代码实现来看看 EOS-VM 有哪些重要的改进。

3、EOS-VM 有哪些重要的改进

EOS-VM 针对区块链应用场景作了很多的改进，这些改进对于智能合约开发者来说是最好的礼物。

下面我们先结合 EOS-VM README 文档看看有哪些改进，再结合现有的 EOS-VM 代码具体看一下 EOS-VM 是如果做到的。

在早期 EOS-VM 的 README 中 ，Block.one 列举了以下的改进 ：

1. Satisfying the needs of a blockchain.

2. Security built into the framework.

3. Performance centric design.

4. Light weight and easy to integrate solution.

5. Effortless extendability.

目前的 README 中改为了对于非开发者更加易懂的描述 ：

· Extremely Fast Execution （6x faster than WABT）

· Extremely Fast Parsing/Loading （20x faster than WABT）

· Efficient Time Bound Execution

· Deterministic Execution （Soft Float & Hardware Floating Point options）

· Standards Compliant

· Designed for Parallel Execution

· C++ / Header Only

· Simple API for integrating Native Calls

我们来逐条分析 ：

3.1 满足区块链场景下的需求

首先 Block.one 对 EOS-VM 的定位是「A VM for Blockchain」，这意味着 EOS-VM 中在 WebAssembly 的基础上添加了很多区块链所需的特定功能。

目前主要是三方面：

首先是浮点数的支持。对于浮点数，很多开发者往往片面的认为其运算是不精确的，无法用于区块链系统。实际上并非如此，只是对于一些不同的硬件中，因为各种各样的历史原因，硬件中固化的浮点数运算有一些差异，解决这一点最好的方式是使用 softfloat 库，不使用机器硬件提供的浮点数，这样不同的硬件机器上，浮点数运算的结果都是相同的了。当然这里 Block.one 也提到，如果不在乎所有平台上保持浮点数运算的确定性，则可以使用基于硬件的浮点数运算，这样效率会比使用 softfloat 快很多，这种情况一般是节点硬件机器会保持统一的状态下使用的。

在 EOSIO 中其实也集成了 softfloat 库，但是之前的实现是在链中嵌入的，原生的虚拟机中本身不支持，现在并入虚拟机实现，可以降低其他区块链使用 EOS-VM 时的开发成本。

其次是 EOS-VM 增加了 watchdog 机制以确保运行字节码的运行时间限制，这个类似看门狗的机制，会在细粒度上对合约进行资源使用限制。

这一点很重要 ， 以至于后期的介绍文档中要单独分出一节来描述。

如果看过 EOS 现在的代码，会发现有很多大量杂乱的代码在处理合约执行超时的问题，对于一个图灵完备的智能合约来说，最大的困难在于我们如果不执行一遍其合约，就无法知道其执行消耗，所以 EOS 中需要边执行智能合约边判定其消耗时间，对于 EOS 链的环境来说 VM 是个黑盒，所以如果在 VM 外来进行合约执行时间判定的话就会非常困难，而 EOS-VM 在这方面提供了内置支持，相关的实现就会非常简单，也会避免这方面出现的问题。

最后是一些虚拟机执行时的边界限制，这些边界限制乍看上去是一些功能的限制，但是在区块链应用场景下，这些限制不会带来实际功能的限制，反而基于这些断言，EOS-VM 可以得到极大的优化。

3.2 内置的安全性支持

支持智能合约的区块链系统可以视作一台公用的计算机，而公用意味着必须对使用者进行限制。如果使用者可以毫无限制的运行自己的代码，那么会带来很大的安全性问题，对于公链来说，这是不能接受的。

这里的安全性问题主要是两方面：代码行为的安全性和代码消耗的有界性。

首先，EOS-VM 通过内置类型来保证类型的安全性，并且通过可选的分配器来使用系统提供的机制来保证沙箱性。

另外，上文提到的 watchdog 机制以确保运行字节码的运行时间限制。对于公链来说，如果没有有效的机制，这一点往往会引起公链的安全问题。EOSIO 之前就出现过基于延迟交易引发的阻塞攻击问题，这个问题本质上就是没有有效细致的界定资源使用的问题。相应的以太坊也多次出现类似的问题，以太坊早期的数次硬分叉都是为了解决这类问题。

最后，EOS-VM 在任何时候都不会触发无限制的递归或循环，严格限制某些 WASM 有意或者无意导致的崩溃或无限挂起机器的情况。

这些内置的安全性支持将会大大提高链的安全性，同时也会提供一个可控的安全性保证。

3.3 面向高性能的设计

在很多时候，特化就是最好的优化。

实际上，如果完全兼容 WebAssembly，那么 EOS-VM 优化的空间并不大。但是对于区块链的需求场景，很多 WebAssembly 的设计并不需要，EOS-VM 基于这一点做了大量的特化，同时意味着性能上，EOS-VM 也得到了非常大幅度的优化。

EOS-VM 性能主要得益于对其内置化的类型的优化，EOS-VM 内置了绝大多数合约需要的数据类型，对于这些类型 EOS-VM 就可以对其一一优化，特别是 variant，这个类型其实并不是一个原生的功能。如果直接使用类似 union 的话，会造成很大的类型安全问题，使用 variant，虽然在实现时得到了很好的安全性和易用性保证。但是如果不将其集成入虚拟机层，那么其复杂的实现会带来很大的性能损耗。

类似的还有 vector，如果阅读现在的 EOS 系统合约，会发现大量使用了 vector，诚然对于合约设计来说，使用 vector 是非常便捷的，但是很多对性能特别敏感的开发者可能会对此感到非常「不安」，如今 VM 直接集成 vector，可以料想后续这些开发者就可以「更愉快的」使用 vector 了。

现在的 EOS 合约开发需要依赖一个规模不算小的基础库，这意味着每个使用这些基础功能的合约都要集成其实现代码，将大量的基础库代码带入 wasm 层，如今 EOS-VM 在虚拟机的实现层植入这些基础类型，性能优化空间自然得到很大提高。

3.4 轻量级易于植入的架构

EOS-VM 是纯头文件的，这意味着 EOS-VM 可以被嵌入进几乎所有的 C++项目中。

同时，EOS-VM 在设计做了特别的处理，使得 EOS-VM 可以很好的适应多线程环境，C++多线程编程一度是个「深坑」，构建一个可以在并发环境下安全运行的库很多时候需要避免很多问题，EOS-VM 在这个问题上做了很多准备，可以避免重蹈像 std：：string 在多线程环境下那样的「覆辙」。

纯头文件的优势还有很多，在这个方面 EOS-VM 已经很像在很多方面得到广泛应用的 LUA，后者同样以轻量级的运行时著称，可以预见，未来会有更多的非 EOS 甚至非区块链项目使用 EOS-VM。

3.5 高度可扩展性

EOS-VM 拥有一套精细设计的结构，从某些方面上来讲，EOS-VM 要比 EOSIO 的代码结构好得多。

EOS-VM 的设计中充分考虑了其拓展性，对于一个 VM 来说其主干结构几乎没有什么需要拓展和修改的地方，因为其功能就是上面提到的四件事。

但是对于不同的应用场景，其字节码格式和功能必然需要拓展和修改，EOS-VM 在响应的地方都做了设计，其中深度应用了 visitor 模式，使得在不改变类架构的前提下也可以很容易的为整个 VM 添加功能。

在很多人眼里，一个良好的架构似乎没有什么作用，毕竟你并不能把「架构良好」看作一个「前无古人」的新特性，但是对于项目开发而言，良好的架构会决定着整个项目后续的潜力。

总的来说，阅读现在的 EOS-VM 项目，会有一种类似 lua 或者 redis 项目的感觉，整个项目规模不大，结构紧凑，代码很干净。

虽然大量使用 C++特性会让一些初学者感到困惑，但并不会影响到对功能的理解，我们认为 EOS-VM 在未来将会在更广泛的领域中发挥更大的作用。

4、EOS-VM 对 EOSIO 生态的影响

EOSIO 作为一个开源软件，社区基于 EOSIO 启动了不同功能和治理理念的 EOS 网络、EOS、EOS 原力、ENU、Telos、worbli，BOS 等网络均在 Block.one 的技术支持下发展，而本次 VM 的改革将使得所有基于 EOSIO 启动的公有链受益。

从现有的实现来看，EOS-VM 将会尽量与当前 EOSIO 虚拟机实现保持兼容，出现不兼容的地方，也可以基于 abi 中的 version 来进行区别。未来即使出现大量和 EOS 原力一样对 EOSIO 底层代码进行了大量改进的区块链，也可以轻松兼容。

未来一段时间之内，基于 EOSIO 链的公链的开发者可以集成 EOS-VM 到链中，同时保持原有 wasm 支持。

引入 EOS-VM 可以为链带来很多好处和影响。

4.1 节约用户资源消耗

如上文所述，使用 EOS-VM 可以提升链的性能，用户使用基于 EOS-VM 运行的智能合约可以节省大量的链上资源消耗。

在基于 EOSIO 的公链中往往主要有三类资源：CPU、NET 和 RAM，CPU 主要由合约运行消耗的实际时间来结算，NET 主要与交易的大小相关，而 RAM 主要是基于合约带来的状态变换所使用的内存大小来决定的。

其中，现阶段 EOS-VM 主要将会节省用户 CPU 资源，这方面也是现在 EOSIO 网络主要的资源限制，对于 EOSIO 网络来说，NET 资源消耗往往固定，而 RAM 可以通过不断的增发来激励节点升级，这样就可以在网络上增加 RAM 的供给。

从硬件的角度来说，目前的服务器性能所支持的 RAM 升级空间还是非常宽裕的，但是对于 CPU，目前的限制很大，正如 BM 在电报群中所发的「牢骚」，英特尔并没有给 EOS 造出 100 太赫兹的 CPU，当然这只是开的玩笑，但是确实当前服务器 CPU 性能限制还是比较大的，对于服务器来说，近几年主要是并行计算能力的提高，单核性能虽然也得到了一定程度上的提升，但依然显得不足。

为 EOSIO 添加并行计算支持是一个比较长的过程，即使 EOSIO 可以支持并行计算，也会受单核计算性能限制，因为对于合约来说，其计算过程依然是单线程的，提升虚拟机效率，对基于 EOSIO 的链来说非常有用。

4.2 使得链具有更强的拓展性

EOS-VM 无论是代码还是架构都十分简介明了，为了保持简单和纯头文件化，Block.one 甚至没有引入其「祖传」的 fc 库，多数开发者只要简单了解一下 wasm 字节码的定义文档，就可以没有障碍的阅读和理解 EOS-VM 的设计和代码。

这样，开发者可以很简单的在 EOS-VM 的基础之上进行二次开发，尤其对于一些基于 EOSIO 技术的链，开发者可以简单的添加新的类型以满足特定链的特殊需求。

4.3 更简单的开发外围工具

EOS-VM 是纯头文件的，这意味着 EOS-VM 可以被嵌入进几乎所有的 C++项目中，而且通过简单的处理，EOS-VM 也可以被基于其他语言开发的项目中。

如 EOS-VM 中 tools 中的 interp，只需要不到 100 行代码就可以构建起 EOS-VM 的运行时环境，这样对于开发用于开发 EOSIO 合约的工具非常有用。

很多 EOS 合约开发的初学者都会想要调试合约代码，在以往这是几乎不可能的，虽然新版的 cdt 中也提供了一个 native lib，但是这样也无法完美的模拟合约的运行环境。

虽然「好的代码不是调出来的」，但是缺乏一个调试环境也会带来一些麻烦。另一方面，我们也要考虑合约运行时与现有开发工具的集成问题，而 EOS-VM 可以很好的满足这一点。

通过 EOS-VM，未来 EOSIO 开发生态将会更加完善，开发效率将会大幅提高。

5、EOSIO 正在向真正的协议演进

不知不觉中，EOSIO 的官网 slogan 已经从「最强大的去中心化应用平台」改为「build on chang，build on EOSIO」。同样在 EOS-VM 的设计中，开发者已经无法明显感受到 EOSIO 和 DPOS 共识机制的存在，EOS-VM 的设计非常独立。

如果一直关注 EOSIO 发展的话，会发现 EOSIO 的合约层在逐渐的去 EOSIO 化，从像 eosio_assert 改为 check 这样的改名，到 cdt 中完全去除 capi 的调用这样的重构，目前的 EOS 合约开发中，开发者会越来越少的碰到「EOS」。

一个典型的例子就是不同 EOSIO 姊妹链间的合约移植，现在基于 cdt 的合约在不同的项目间的差别已经越来越少，早期社区曾经对像 enu 这样由于大量不必要的改名所引发的不兼容表示非常困扰，但现在如果使用 cdt 工具，开发者几乎感受不到 enu 改名所带来的不兼容。

这一切都在意味着 EOSIO 正在向真正的协议演进。

Block.one 团队在早期并不像其他项目一样，急于构建抽象的协议和形式化的黄皮书，而是以非常务实的态度进行 EOS 的开发，这也在一定方面上使得 EOSIO 这一公链的主网启动要远远早于其他的「第三代」区块链项目。

我们认为 Block.one 团队不会一直在「埋头造车」， 而是采用自底向上的思路，不断的发展 EOSIO 生态，使其向真正的协议演进，最终成为一个极具竞争力的区块链协议事实标准。

6、Block.one 打响区块链标准之争的第一枪

长久以来，任何一个软件的细分领域都在谋求技术标准的整合和统一，这样的统一并非是由中心话组织去强制推行，而是通过软件本身逐渐得到主流市场的认可，最后成为事实上的技术标准。

而在区块链 VM 领域，旧的虚拟机如 EVM 性能低下，单一功能的虚拟机无法承载复杂的智能合约，基于通用设计虚拟机将会成为未来主流区块链项目的必需品，而这样的区块链项目目前唯一可选的只有 EOS-VM，EOS-VM 领跑行业一年多，将会成为最好的智能合约运行环境的标准，其行业地位将会类似于 ARM 在手机芯片行业的地位，甚至未来 ETH 的智能合约有望在 EOS-VM 上运行。

甚至我们也可以大胆的假设，EOS-VM 不会限于区块链行业，由于其优异的设计和实现，甚至会被用于像游戏引擎、数据库、Web 框架这样的传统软件开发领域。

7、加密社区的开源与技术标准垄断

我们都知道，Block.one 在向社区募资时一直强调自己是一个开源组织，所募集的钱也均要用于开发开源的 EOSIO 软件回馈社区，也为加密经济社区带来了大量的贡献。

但 EOS-VM 与 Block.one 以往任何一个开源项目都不同 ，Block.one 罕见地对 EOS-VM 项目保留了其权利 ， 这意味着这个项目不会像其他开源库一样仅仅是一个开源库。保留权利这一动作与其募资时纯粹的开源组织定位产生了一定的偏差，甚至可能会通过商业性质的授权来限制其使用场景。

与传统互联网行业不同，加密经济的大部分技术都是开源的，无论是扩容之争和治理理念之争均未涉及到技术标准层面，在开源的加密经济市场中出现一个志在垄断的 VM 将带来什么样的影响，我们拭目以待。