为了给开发者提供更大范围的开发自由度和更强大的功能，迅雷链于18年底开始支持了WASM虚拟机。基于WASM虚拟机和C/C++智能合约编程语言，迅雷链能方便的扩展智能合约功能，例如要为智能合约提供新接口以实现新功能，迅雷链只要提供一个新的库函数即可；并且，迅雷链还提供了合约原地升级功能，使用起来非常方便。

由于用户需要，迅雷链在前天开源了wasm虚拟机，相关github项目包括3个部分：

wagon是wasm的字节码解释器，在go-interpreter/wagon项目的基础上改造而来，例如内存管理、系统调用接口、gas收费机制等。
tc-wasm迅雷链wasm虚拟机代码，包括字节码解决执行和SDK库接口的实现，方便集成到其它区块链平台，支持c/c++编写的智能合约。mock目录的代码提供了集成到以太坊的示例。
tcvm-cdt是迅雷链wasm合约编译工具，提供本地编译工具以及合约SDK库文件源代码。

一、背景介绍

在长期基于EVM的solidity智能合约的开发使用过程中，迅雷链发现EVM存在一些令人难以忍受的问题，例如：
1）强耦合，难扩展：区块链与EVM之间到处充斥着相- 互依赖的关系，例如：

虚拟机指令集中包含大量用于访问账本数据的指令；
虚拟机直接提供以区块链账本作为载体的持久化存储指令；
功能函数实现为虚拟机指令，功能难以扩展，若要新增一个功能，需要修改编译器和EVM；

2）缺少标准库：Solidity中根本就没有标准库。如果你想比较两个字符串，Solidity中根本就没有类似strcmp或memcmp的标准库函数供你调用，你必须自己用代码实现或在网上拷贝代码来实现。

经过一翻调研后，迅雷链选择了WASM作为第二个智能合约虚拟机，解决了上述EVM的问题。

WebAssembly（简称wasm）是为了提供比JavaScript更快的编译和运行速度，让高性能的Web应用在浏览器上运行成为可能。wasm本身是一种面向Web的低级语言（不是直接的机器语言，与IR差不多），理论上来说，开发者能够将任何语言编译成wasm字节码，并运行在web上，而不再局限于JavaScript。目前编译器已经支持将C/C++/Rust编译为wasm字节码，后续还会支持更多的主流语言。

相比于JavaScript，wasm具有如下优点：
1）快速、高效：wasm的二进制格式可以被原生的解码，比JS的解析要快很多；而且wasm的二进制格式更加紧凑，文件更小；
2）可移植：wasm代码可以运行在不同的平台上，以接近本地的速度执行；

以太坊的智能合约是运行在图灵完备的EVM虚拟机上，不过社区已经计划把EVM替换为eWASM，最重要的一个原因是wasm的指令更加接近实际的cpu指令，有更显著的运行性能。

二、设计目标

区块链系统与智能合约的关系如同操作系统与应用程序的关系，操作系统内核为应用程序提供系统调用接口，方便应用程序访问内核资源。同理在区块链系统中，虚拟机作为智能合约的运行环境，会为智能合约提供区块链的系统调用接口，方便智能合约与区块链系统的交互，以及对区块链资源的访问。

但是，区块链系统有其特殊性，因此虚拟机除了要提供必要的系统调用接口外，还需要满足如下要求：
1）确定性：同样的合约调用参数，要求区块链中的每个节点在运行完合约调用之后的状态必须是确定的、一致的，否则区块链的共识就无法达成一致；
2）可终止性：合约的运行不能是无限循环unstopped，这样会导致区块链系统无法继续构建区块；
3）可嵌套：虚拟机需要支持在一个合约代码中嵌套执行另一个合约的代码；
4）可撤销：合约在执行的过程中发生了失败或者异常，虚拟机需要撤销该合约在当前执行过程中的状态修改，恢复到执行前的状态。

由于迅雷链最初是支持EVM的，在引入wasm时，除了上述必须满足的目标，还要求做到：
1）与EVM共存，同时支持EVM和WASM双虚拟机，通过运行时识别字节码来决定是调用EVM还是WASM；
2）支持合约原地升级；
3）封装c++ SDK，隐藏区块链底层细节，方便开发者进行合约开发；

三、细节说明

围绕上述的设计目标，下面将会详细地介绍迅雷链的一些内部实现细节：

1. EVM和WASM双虚拟机支持：

不管是EVM合约还是WASM合约，部署成功后，在迅雷链内部都是统一由Account表示：

type Account struct {
    Nonce uint64
    Balance *big.Int
    Root common.Hash // merkle root of the contract storage
    CodeHash []byte
}

每一个Account都会有一个对应的地址Address，合约账户的地址和普通账户的地址是一样的，统一由20个字节表示。也就是说从地址上直观的观察，是无法辨别出该地址代表的是普通用户，还是合约账户。

在创建虚拟机执行合约代码之前，会根据CodeHash从db读取合约的二进制字节码，判断合约的前4个字节是否为wasm合约的标识符（wasm合约字节码的前4个字节为固定的”.asm”标识符），从而创建对应的虚拟机来执行合约调用，实现双虚拟机的支持。

2.WASM合约原地升级：

之所以要支持合约原地升级功能，最主要的原因是当合约存在安全漏洞、逻辑错误时，可以直接通过原地升级来解决，而不是只能关闭合约功能，停止对外服务。

EVM合约要支持原地升级功能，对合约开发者有较高的开发门槛，体现在如下两方面：
1）首先，合约升级的权限管理，需要在开发者在合约代码中进行严格的权限检查与签名校验；
2）其次，合约数据持久化存储与solidity代码的变量布局有关系，变量的布局改变了，原先存储的数据可能就无法读取到了。因此，基于solidity编写的智能合约要支持升级，需要开发者采用代理合约的策略方式，将合约的逻辑与数据分离成不同的合约，升级的时候只升级逻辑合约，不能够升级数据合约。

对于合约升级的权限管理，迅雷链为了降低开发的难度，直接在区块链系统底层给予支持，不需要开发者而外实现。具体来说，迅雷链在区块链系统底层实现多重签名支持，合约在部署的时候，指定合约的所有者列表owners，后续如果需要升级合约，迅雷链底层会严格按照owners列表来检查合约升级交易的多重签名是否正确，若owners列表为空，自动拒绝合约升级交易的执行。

关于合约的数据存储，迅雷链在迅雷链底层提供系统调用接口，由合约开发者显式地指定数据的key，这样当合约升级后，迅雷链依然可以根据给定的key读取到之前的数据。

3.WASM虚拟机改造：

1）Gas手续费的收取：
迅雷链是由普通机器作为出块节点的，不像EOS是由超级服务器节点组成，若简单的规定合约运行的最大时间为1毫秒，那么稍微功能复杂点的合约，都无法在规定的1毫秒内完成调用，限制太强。因此迅雷链借鉴以太坊的做法，对WASM约执行的每条指令进行按需收费，当合约执行的手续费达到了调用者给定的手续费上限时，WASM虚拟机自动终止合约的继续执行。

2）系统调用接口：
wasm模块支持引入其他的wasm模块以调用其中的函数，如果本模块内调用的函数没有具体实现，就会默认的认为是从env模块导入的。因此，迅雷链把所有的系统调用接口封装到一个env模块中，在执行一个具体的wasm合约之前，会先加载并分析其导入的env模块的每一个函数，将这些函数与迅雷链的系统调用接口关联起来，从而实现wasm合约对native函数的调用。

具体来说，迅雷链提供了如下几大类的系统调用接口：

Libc标准库部分接口：主要是与内存操作相关的函数，如malloc和free。因为wasm虚拟机作为wasm合约执行的宿主环境，需要对合约运行的虚拟内存进行分配与管理；
区块链相关接口：为方便wasm合约方便访问区块链相关信息，迅雷链提供了存储读写、账户转账、事件触发、交易信息等接口；
Library：主要是提供了BigInt和json操作函数，方便合约开发者的编写；

3）内存管理：
为了处理字符串及其他复杂数据类型，WebAssembly提供了内存管理。按照wasm的定义，内存就是一个随着时间增长的字节数组。所以，迅雷链的wasm虚拟机在执行合约前，会根据合约导入的内存，为其创建内存实例，并初始化对应的data数据段内容。具体实现上，迅雷链采用了Buddy伙伴算法来管理wasm合约的运行内存，默认的初始内存大小为64KB，最大可增长到256KB。

4）简化合约开发：
合约作为区块链系统的业务承载体，承载着区块链的落地应用价值，因此迅雷链在合约开发这方面，一直在努力降低合约开发的门槛，简化合约的开发过程，让更多的企业可以将其业务应用迁移到迅雷链系统中来。

C++ SDK提供：

迅雷链知道，一般的业务处理逻辑流程，大致是：解析输入参数，根据参数执行相应的操作（比如持久化存储相关对象），返回处理结果。其中参数解析、对象存储读写、结果返回等，经常需要涉及到对象的序列化与反序列化操作，为此，迅雷链的C++ SDK提供了基于模版的静态反射库，开发者只需要声明对象的相关字段，不需要手写逻辑代码，就能达到与手写序列化操作一样的运行效率。

除此之外，SDK还提供了常用的Address、Hash、Token、BigInt等操作函数，简化合约的编写。

ABI工具：

迅雷链提供配套的ABI工具，通过对合约的ABI分析，自动生成go/python客户端代码，屏蔽合约方法的参数编码细节，方便外部对合约方法的调用。

引入wasm过程中发现的问题及解决方法

迅雷链在引入了wasm虚拟机后，在内部的合约开发测试过程中，还发现了几个其他问题：

1）字节码解析耗时：
根据wasm规范，wasm的字节码是以Module的形式描述的，一个合约编译之后就是一个独立的Module，一个Module是由不同的Section组成的，其中SectionCode才是迅雷链需要真正执行的指令。对于同一个合约，若每次执行前都需要做一次解析操作，无疑是一种多余的浪费，这种浪费会严重影响到迅雷链合约执行性能，因此底层将会缓存同一个合约字节码的解析结果，这样同一个合约每次运行时，只需要重新初始化内存即可。

2）字节码过大：
当迅雷链在合约代码中使用了C++标准库的容器，发现编译后的字节码偏大，功能简单的合约字节码一下子由几KB增大到了几十KB，更别说功能复杂的合约了。为此，迅雷链在C++ SDK中，重新简化实现了常用的标准库代码，防止合约字节码膨胀过大，同时也有利于降低字节码解析的耗时。

3）容易内存泄漏：
迅雷链底层使用go语言实现的，当合约通过系统调用接口访问底层native方法时，底层方法返回的数据保存在wasm的线性内存中，由于这个内存并不是开发者通过malloc分配的，所以会经常忘记调用free来释放，造成内存泄漏。加上底层限制了一个合约可以使用的内存上限是256KB，所以会造成功能复杂的合约，最后由于超出内存上限而执行失败。

因此，为了避免内存泄漏问题，在SDK中采用RAII和SharedPtr方式，不再暴露原始的内存地址，而是返回栈上的临时对象。

合约示例

示例目录提供了一些合约示例，包括链上接口用法、数据存取、合约调用合约、json序列化、token发行等。

一个最简单的合约代码示例：

#include "tcmethod.hpp" 
class Hello : public TCBaseContract{
public:
    //合约类公有成员函数
    const char* SayHello (){      
        return "Hello World!";
    }
};
//TC_ABI声明合约外部接口
TC_ABI(Hello, (SayHello))

合约类Hello继承自TCBaseContract。
TCBaseContract定义如下：

class TCBaseContract : boost::noncopyable {
public:
    void Init(){}
    void Callback(){}
};

TCBaseContract类只定义了两个空函数，需要的话可以在自己的合约类中编写自己的覆盖（override）函数。

Init()函数用于定义合约初始化逻辑，会在合约调用时被自动调用一次。

Callback()函数功能类似于solidity的fallback函数，当合约被调用，但没有匹配的函数名时，Callback()函数就会被调用。

TC_ABI宏用于将合约类的成员函数自动构造成合约入口函数thunderchain_main，支持结构体入参，支持多个返回值，生成相关的ABI文件，详见说明文档。

四、总结

本文主要探讨了迅雷链在支持wasm虚拟机上的实践细节，希望能对相关的区块链从业者提供一些可借鉴的经验。推荐参考迅雷链github开源代码。

作者简介：
周茂青，网心科技软件工程师，现从事迅雷链底层技术研发工作。曾负责过广域网优化产品、分布式文件系统、CDN缓存系统等技术设计和开发等工作，在Linux内核开发、网络协议优化、分布式系统等方面有着丰富的从业经验。

相关文章：
《区块链助力中国版权保护：迅雷链三大核心技术解读》

创作场景

迅雷链在支持 wasm 虚拟机上的实践细节