摘要

本报告首先分析了区块链智能合约应满足的设计要求与实现思路 ：

智能合约应满足确定性，需要在设计时采用确定性的算法和确定性的数据来源；

智能合约应满足可终止性，可通过有限命令、gas模式、资源控制、准入限制等方式实现。

在具体实现技术路线上，目前主要有 脚本方式、容器化方式、虚拟机方式等。其中包括以太坊在内很多区块链系统采用了虚拟机方式实现智能合约。

但EVM在设计实现上还存在一些问题。不少区块链系统用多种方式进行了改进；EVM本身也在考虑用基于WebAssembly的方式来实现。我们通过搭建私有测试环境方式来测试对比估计EVM在采用WebAssembly技术前后的性能表现，主要得到以下结果和技术指导建议：

基于WebAssembly的以太坊虚拟机目前对数学计算方面并没有太大提升，因此如果只为实现ERC20等合约转账等操作，可能远不如通过其他技术改造，例如共识机制、分片等方式对性能的提升来的更为明显。

但在实现排序等更复杂的合约逻辑时，WebAssembly会显示出强大的性能优势，可为复杂场景的区块链业务应用提供更好的技术支撑。

报告正文

1.引言

智能合约是区块链2.0的标志性技术之一，可以在无须信任环境下实现更为复杂完备的业务逻辑，为区块链在实际业务场景中的应用形成技术基础。

从设计上来看，为满足智能合约的确定性，需要在设计时采用确定性的算法和确定性的数据来源；为满足智能合约的可终止性，可通过有限命令、gas模式、资源控制、准入限制等方式进行设计。

具体的实现上，目前主要有 脚本方式、容器化方式、虚拟机方式 等。其中包括以太坊在内很多区块链系统采用了虚拟机方式实现智能合约。但EVM设计实现上存在一些问题。不少区块链系统用多种方式进行了改进；EVM本身也在考虑用基于WebAssembly的方式来实现。我们通过搭建私有测试环境方式来测试对比估计EVM在采用WebAssembly技术前后的性能表现。

2.主要测试结论

经过研究与测试分析，我们得到以下主要结论及技术建议：

基于WebAssembly的以太坊虚拟机目前对数学计算方面并没有太大提升，因此如果只为实现ERC20等合约转账等操作，可能远不如通过其他技术改造，例如共识机制、分片等方式对性能的提升来的更为明显。

但在实现排序等更复杂的合约逻辑时，WebAssembly会显示出强大的性能优势，可为大规模、复杂场景下区块链业务应用提供更好的技术支撑。

3.简介

智能合约的概念最早由尼克·萨博（Nick Szabo）在上世纪90年代提出[1]，被设想为一种可自动执行合同条款的计算机化交易协议，在不需要中介的情况下安全、可信的实现通用的合同条款。

他同时指出，当时由David Chaum推出的eCash可被视为智能合约的一种典型案例。但eCash后来并没有成功持续运行下去。由于没有一个可以实际运行的智能合约场景，这一理论始终停留在概念阶段，缺少实际的技术支撑。

这一观点得到印证要等到后来比特币与区块链的发展：相对于比特币为代表的区块链早期探索应用，人们广泛认可的区块链2.0阶段的一个重要标志就是智能合约概念的实现，可以在区块链的分布式账本基础上，实现去中心的多方参与、规则透明不可篡改、符合条件即可执行的合约。这意味着区块链从最早期只能转账的“点对点”电子现金系统，发展成为可以在分布式网络上形成可编程、不受干预的合约系统，可以在无须信任环境下实现更为复杂完备的业务逻辑，为区块链在实际业务场景中的应用形成技术基础。

4.设计要求与实现思路

从定义上看，智能合约是一种由机器实现的协议或程序，但由于运行在一个需要进行拜占庭容错来达成共识的分布式系统环境中，智能合约与一般的计算机程序还存着很大区别。

通常认为，智能合约需要满足的条件包括确定性和可终止性[2][3]。

4.1.确定性

确定性在传统计算机理论中已有明确定义：如果给定一个输入，计算机（状态机）经过同样的状态变化顺序后总会产生相同的结果，那么这个算法即可被称为是确定性的[4]。这一特性在分布式系统特别是区块链系统中尤其重要，因为所有节点必须按照智能合约约定的规则产生相同的计算结果，否则合约执行的结果无法被各个节点所共识。

导致非确定性结果的具体原因有很多，而目前在区块链的解决思路也不少。下面我们按照“程序=算法+数据结构”的角度从算法和数据两个角度分别对这些原因和解决思路进行讨论。

4.1.1. 确定性算法

对于确定性的算法上，我们又可以从“时间”和“空间”的角度上来分别讨论。

在程序执行的时间上，如果一个算法本身不是确定性的，那么如果将实现这个算法的程序重复执行多次，每次执行的结果无法确定。例如产生随机数的函数每次执行的结果无法保证是一样的。

在空间上，即便每个节点都执行同样的、确定性的指令操作，但由于节点间的底层机器指令或操作系统实现差异也可能导致出现不同的结果。

为实现确定性的算法，目前区块链较多采用的是限制操作，比较常见的是只提供确定性指令或系统函数。

例如比特币中的脚本系统只提供了为数不多的操作，避免可能导致节点间差异的功能；以太坊采用了虚拟机（EVM）来屏蔽不同节点的实现差异，同时只提供确定性的系统函数。具体虚拟机方面的内容我们将在下文继续讨论。

4.1.2.确定性数据

除了操作本身差异外，如果对同一个算法给予不同的数据输入，也会导致结果存在差异。

目前的解决思路从链上、链下可分为2种。

链上的思路为，限制智能合约的数据只能从链上读取已共识后的账本信息，以此来达到数据来源相同的目的。

但这种方法也存在不少限制，因为一些合约的执行有赖于对现实世界的条件判断，例如天气、股市行情等等，而链上数据的来源、种类、实时性等各方面很多时候无法满足。

链下的思路进一步扩展了数据来源，一般采用预言机（Oracle）的方式，将外部数据提供给智能合约进行读取，并保证数据的一致性。

4.2.可终止性

可终止性的问题是区块链实现智能合约的另一个挑战。因为区块链上的智能合约必须是可终止的，否则当出现例如无论是主观故意还是客观存在的死循环等无法终止的合约时会持续占用区块链的计算或存储资源。

为实现可终止性的目标，智能合约在实现时主要有以下几种方式可以实现。

4.2.1.有限命令方式

比特币采用的方式是实现了一个图灵不完备的脚本系统。图灵完备系统会包括一系列操作数据的动作，其中包括循环、递归等逻辑操作，用以实现任何图灵机。而比特币的脚本系统限制了操作指令的种类，不包含循环等操作，因此可同时实现其确定性和可终止性。但这种方式也很大程度上降低了在比特币上实现合约的可扩展性。

4.2.2.gas方式

为了提高可扩展性，在比特币之后的很多区块链系统，例如以太坊等开始采用支持图灵完备的智能合约系统，以支持实现更复杂和完备的业务逻辑。为了解决支持图灵完备下的可终止性问题以及避免网络滥用，以太坊引入了gas概念。以太坊智能合约中的每步操作和每个账本存储都会对应于一定的gas消耗；当gas消耗完后合约即会被终止[5]。gas方式相当于即时付费的手续费模式，目前被大多数的公有区块链平台所采用。

4.2.3.资源控制方式

与gas的即时付费模式不同，另有一些公有区块链平台采用了预付费的模式，通过控制可使用的资源来实现可终止性的效果。其中最典型的代表是EOS。尽管交易不需要支付手续费，但用户需要提前抵押或购买足够多的CPU、RAM以及带宽等使用资源来进行交易和运行合约。EOS通过这种方式来避免用户在无手续费情况下对资源的滥用。

4.2.4.准入限制方式

除了以上介绍的公有链上的解决方式外，一些联盟链采用了其他的方式来解决可终止性问题。由于联盟链的特殊性，一般来说在加入区块链网络前，节点已被区块链组织所认可、其身份已被其他节点所知晓，对于单个节点的可控性更高，因此很多联盟链会给予该节点更高的自由度。例如在联盟链的典型代表Hyperledger Fabric中，可由节点用户来自主控制智能合约程序（即链上代码，Chaincode）的启停，同时综合以运行时间等方式将合约执行长度和占用资源控制在可接受的范围内，从而实现可终止性。

5.技术路线及典型案例解析

综合以上技术思路后，我们继续对可实现以上思路来支持智能合约的技术方案进行梳理，目前可主要总结为 脚本方式、容器化方式、虚拟机方式 等。

5.1.脚本方式

脚本方式可以说是最传统的实现可编程逻辑的一种方式，最早在比特币系统中被采用。比特币的UTXO模型采用了一种类似Forth语言[6]的签名脚本体系，用于验证该笔交易的合法性。交易一般会包括输入脚本和输出脚本两个，分别用于解锁上一笔交易的输出以及设置该笔交易金额的解锁条件。

比特币脚本采用堆栈结构方式的逆波兰表达式，用户需要按照顺序将匹配的签名、公钥等提供给脚本作为执行的输入用以解锁该笔交易。因此，脚本方式的另一特点是，和UTXO方式的配合使用效果较好。

但这种方式的缺点也很明显，主要在于功能的扩展性上，脚本方式。因此，如果从功能完备性和编程可扩展性方面来看，很多人认为比特币的脚本方式能实现的编程业务非常有限。 因此从狭义的角度来看，脚本方式区块链可认为是只实现了简单的可编程特性，而没有通常意义下的智能合约体系。

按照火币研究院的区块链代际划分的思路[7]，目前使用脚本方式来实现可编程特性的，都可认为是区块链1.0版本的系统，可对应的包括以下3大类：

1） 比特币及相关分叉币、竞争币

2）匿名加密货币

3）DAG类的区块链

5.1.1.比特币的分叉币竞争币

使用脚本方式较多的是比特币及早期相关采用UTXO模型的一些加密货币，包括比特币的分叉币、竞争币等，主要包括：Litecoin、Bitcoin Cash等等。

5.1.2.匿名加密货币

主打匿名、隐私保护的加密货币也较多的使用了脚本体系。出于对隐私保护和交易追溯性的隐藏，这类加密货币很多都采用了抽象、简化的脚本体系，包括Monero、Dash等。

5.1.3.部分DAG

还有一些会用到脚本方式来运行合约的会是基于有向无环图结构（DAG）的区块链系统。火币研究院此前的研究报告《【超越白皮书3】DAG技术解析与实测》中曾介绍过，由于DAG系统的原生特性，包括交易时长不可控、不存在全局排序机制等特点，较难在DAG的分布式账本系统上实现出一个图灵完备的智能合约系统[8]。因此为了提高并发TPS、简化交易处理过程，一部分基于DAG的分布式账本系统也会采用脚本方式来构建自己的可编程体系。

5.2.容器化方式

容器化方式，是近年来兴起的、不同于虚拟机的一种新型虚拟化技术。相对于虚拟机在用户程序和底层环境中增加的一层中间环境，容器技术只需要将应用程序所需要的依赖打包即可独立运行，而不需要一个附加的虚拟操作系统环境。

使用容器化的方式实现区块链平台的智能合约环境，相对于堆栈执行代码的虚拟机方式相对更为独立和灵活、可调用的资源也更多。

尽管容器化技术从整体系统架构来看更为轻便与灵活，但从单个应用的角度来看，则需要考虑更“重”的一些系统因素，因为在容器环境中的进程可访问包括文件、系统功能等在内的更多系统资源。 这就对区块链自身的运行环境提出了较多要求，因此采用这种方式的区块链平台较为少见。

典型使用容器化方式的区块链项目是Hyperledger Fabric。其智能合约的运行方式是在节点部署一个链上代码后，所有相关节点均会启动一个在Docker容器中独立运行的链码进程。链码通过容器中对外的gRPC接口完成与节点的交互。

目前对于链码的运行，Fabric采用的仍然是一种较为手动和底层的方式来管理维护。因为是联盟链的环境，相当于是默认所有被许可加入网络的节点均可以较为自觉的使用系统资源，即上文提到的 准入限制方式 。这一思想在对于链码生命周期的维护方面就体现的比较明显：在目前最新的Fabric 1.3版本中，只提供了package（打包）、install（安装）、instantiate（实例化）、upgrade（升级）等4个命令，在未来才会考虑提供一个在不用实际删除链码情况下，禁用（stop）和重新启用（start）链码的命令。

因此若想在公有链环境下用容器化的方式来构建智能合约环境，则需要采用例如资源控制等更多的方法来适应改造。

5.3.虚拟机方式

相较于上述两种方式， 目前实现智能合约方式的最多的一种是虚拟机方式。 它可以为程序提供一个完全对底层透明的执行环境。这种思路的典型应用可追溯到传统IT技术中Java的JVM虚拟机。其目的是为了实现“一次编写，到处运行”的特性，而不是让程序开发人员为兼容每个不同的服务器编写不同版本的程序。而这一特点正是分布式部署与运行的智能合约所需要的：屏蔽区块链节点自身执行环境的区别，在所有节点上运行均一致，实现上文所述智能合约需要满足的确定性特点。

区块链2.0的一个代表性项目——以太坊系统即采用的是EVM（以太坊虚拟机）。以太坊虚拟机构建了一个基于栈的虚拟运行环境，定义了一套跟节点自身环境隔离的环境，屏蔽了每个节点的底层差异，实现不同节点执行合约的相同结果（确定性）。

以EVM为代表虚拟机的另一个特点在于，由于提供了一个较为底层的通用基础设施，基于这个虚拟机，可以设计出符合该虚拟机或者说区块链系统的高级编程语言，例如以太坊的Solidity语言、Nxt使用Javascript及相应环境下的API等[9]。相应的，如果该语言设计的不合理也会带来相应的缺陷。

综合以上各个特点来看，虚拟机方式仍然是目前可实现智能合约技术中较为稳妥的一种技术路线 ，也是目前包括以太坊在内的大多数区块链系统采用的方式。

但在具体实现方面，EVM目前普遍认为存在一些设计缺点[10]，主要包括以下几点：

1） 256位字长 。采用目前主流CPU所支持的8、16、32、64等长度时，CPU可直接提供原生支持，程序效率高。但EVM采用的字长是256位，处理器需要额外的操作才可以正常处理，因此运算效率较低。同时相较于主流字长，256位也会存在一定的存储浪费，进而影响gas消耗。目前一部分测试表明，当字长改为64位或128位时，合约代码的运行效率、存储成本（以gas值体现）均有改良[11]。

2） 不支持浮点数及缺少标准库。 此问题不支持浮点数对于要支持。而正像上文提到的，通常与EVM配合使用的Solidity语言也因为缺少原生标准库的，使得这一问题更为突出。OpenZeppelin的出现使得这一问题得到了缓解。其ERC20、ERC721的编写框架使得开发变得容易。但依赖于第三方代码库始终存在一定风险。例如前段时间有许多采用OpenZeppelin的ERC20通证合约因为函数返回值的问题，可导致转账结果无法预计[12]。

3） 合约代码不可修改升级。 由于EVM采用的不是标准冯诺依曼结构，程序代码被保存在一个独立的虚拟ROM中，而不是一般计算机内存中的代码区位置，理论上只可以通过重新部署合约来实现对合约的升级。因此当合约中存在bug等情况时，无法通过打补丁等形式来进行补救。

因为以上缺点，在以太坊EVM之后，很多区块链项目从多种技术方向来实现虚拟机。我们可以按照技术实现方式的特点可进一步分为以下几类来讨论。 需要注意的是，目前不少公链仅公布了其开发计划，无实际可运行的虚拟机程序代码，具体实施情况可能随着其项目进度会而有所变化。

5.3.1.改进EVM

尽管EVM有上述种种缺点，很多区块链系统仍然是采用在EVM基础上改进来设计实现。这样一方面可以复用原有以太坊的功能，降低开发工作量；另一方面可以利用现有的以太坊生态，进行快速的开发。虽然目前的一些公链平台例如EOS等在用户活跃度等方面有赶超以太坊之势，但以太坊长期形成的生态环境是一个新生公链在考虑未来开发及运营时绝对不可忽视的一个重要因素。像在主打联盟链平台的Hyperledger中，Burrow项目是搭建了带授权管理的以太坊智能合约区块链节点，并搭配Cosmos的Tendermint共识引擎以此来兼容以太坊的Solidity开发生态[13]。

在这种大环境下， 许多公链在设计实现虚拟机时，均采用了在EVM基础上改进的方式来实现。

例如，Nervos公链平台中Layer1的CKB使用了RISC-V作为指令集实现CKB-EVM。通过RISC-V的工具链，CKB-EVM可以支持任意编程语言进行智能合约开发[14]。

Aion采用的FastVM在设计时采用了128位的字长，并在底层采用LLVM JIT作为运行引擎，以此来提高存储效率和运算速度。Aion的虚拟机同时计划在未来支持从128到64和32等多种字长，以适应更多的应用场景和业务需求[15]。

另外也可从虚拟机的运行流程上进行优化。由于以太坊需要每个全节点都运行相同的虚拟机计算并检验结果后才更新账本，该方式显然会影响性能。一些区块链平台对此进行了改进，例如Zilliqa采用了数据流图的方式来进行计算分片，以此来提高并发度[16]。

5.3.2.兼容传统指令集

另有一些区块链系统实现合约引擎的思路是 与传统的机器指令集技术进行兼容。

这其中一类是 直接使用传统虚拟机技术作为合约引擎，但需要进行一些改造以从技术上解决确定性问题。 例如，R3 Corda使用了JVM作为其智能合约的执行环境，即Corda中的交易类型均使用JVM的字节码来定义和执行。但由于传统JVM中仍有一些可能导致非确定性的操作，例如随机数、Java的垃圾回收等等，因此Corda目前也在尝试开发一个确定性的JVM沙盒环境（Determinstic JVM， 简称DJVM）用来检测用户开发的代码是否存在非确定性[17]。

这种方式的思路在于，JVM有一些相对于EVM的实现智能合约引擎的优势[18]：

1）JVM已经过大规模、长时间的工业检验。作为底层相对于EVM更有安全和健壮性方面的优势

2）利用Java语言和现有的开发生态，可以让开发者更快上手

3）一些语言特性，包括对浮点数的支持等也会比Solidity更有优势

而缺点在于，JVM存在很多和区块链需求无关的功能，同时要增加通证经济中的gas机制来实现可终止性也并不容易。

除了用传统虚拟机技术外，还有一些 是用仿真器来模拟传统的指令运行环境 ，支持多语言开发并让存量代码尽可能低成本的迁移到区块链开发环境中。例如Qtum的x86虚拟机设计为兼容传统已被广泛应用的x86服务器指令集，这样可以使得行业长期内积累起来的海量代码通过少量改造即可用于基于智能合约的区块链执行环境中；同时可以提供多语言支持。

5.3.3.wasm方式

除上述方式外，WebAssembly技术被越来越多的用来实现智能合约引擎。

WebAssembly是一种跨平台二进制指令格式，可以用于基于栈的虚拟机中，希望将客户端和服务端程序均可以部署在web上。由于其优良的性能和多语言支持的广泛兼容性，目前已在web开发中被推广使用，被Chrome、Edge、Firefox等现代浏览器所支持，被认为将有可能取代现有的JavaScript。很多大型应用也在尝试使用WebAssembly，例如运行在浏览器中的Windows 2000[19]。不少人将2018年视作是WebAssembly技术元年。

在区块链领域内，也有一些平台开始使用WebAssembly技术，这也是近期智能合约实现技术的一种流行趋势。 例如目前EOSIO已采用WebAssembly来实现其虚拟机WAVM。

相对于以太坊的EVM，使用WebAssembly技术的虚拟机，主要有以下优势：

1）可以支持C、C++、Rust等多语言进行开发，降低了开发者的进入门槛和学习成本

2）编译成wasm的结果对CPU架构透明，虽然不能运行在CPU之上，但可以在主流现代浏览器中部署运行

3）WebAssembly因为构建方式是尽可能接近机器代码，编译体积小、加载速度快，性能相对较高

但WebAssembly也有其一些缺点待改进，例如作为一项底层技术，WebAssembly还不够成熟，例如存在一些浏览器新老版本兼容问题；生态工具各方面也有待发展。

不过，以太坊已在考虑将EVM采用WebAssembly方式实现，即eWASM。而在目前使用Rust实现的Parity以太坊节点上，已可选用WebAssembly方式来实现其虚拟机。

6.实测分析

对于以太坊将使用WebAssembly实现EVM的计划，我们采用程序代码实测的方式来对比评估是否有较大幅度的性能提升。

由于目前Parity已实现了一个基于WebAssembly的节点并且没有改变字长等其他内容，变量较为可控，可以大致比较出改用WebAssembly前后的性能对比。我们通过使用标准EVM的geth客户端与WebAssembly（pwasm）的Parity客户端，分别搭建了私有区块链网络，并用Solidity和Rust编写完成相同功能的合约，并编译部署、对比运行。

6.1.测试环境

运行的硬件环境：

操作系统：Ubuntu16.04 x86_64

CPU：Intel core i7-6700HQ

EVM版本：

geth版本：1.8.15-stable

go版本：go1.10.4 linux/amd64

Solidity版本：0.4.24

pwasm（Parity WebAssembly）相关版本为：

Parity版本：v2.1.3-beta

rustup版本：1.14.0

JavaScript测试代码环境：

NodeJS版本：v8.9.0

web3库版本：1.0.0-beta.36

6.2.测试场景及结论

6.2.1.测试场景1

以太坊的转账流程更多的是基于账户体系上的余额增减，因此第一个场景是在虚拟机上进行1000次循环加法运算，测量其程序运行时间及空间占用等技术指标。

在EVM和pwasm上的测试结果分别如下：

可以看到，换用了WebAssembly后，运行速度会有所提升，但幅度有限。

6.2.2.测试场景2

场景2使用100次乘法，进行相同的运行对比测试。

可以看到与场景1的循环加法，测试的指标结果比较类似：WebAssembly同样对运行速度有所提升但依然不显著。

6.3.3.测试场景3

除了基本的加法、乘法外，场景3使用10个数字的10轮冒泡排序来进行更复杂的业务逻辑测试。

可以看到在排序这种场景下，WebAssembly降低了一半左右的运行时间，优化效果明显。

因此可以看到，如果只为实现简单的ERC20等合约转账等操作，单靠使用WebAssembly的虚拟机并不能带来很大的性能提升，可能远不如通过其他技术改造，例如共识机制、分片等方式对性能的提升来的更为明显。

但在实现更复杂的合约逻辑时，WebAssembly会显示出强大的性能优势，可为大规模、复杂场景下的区块链业务应用提供更好的技术支撑。

7.参考资料

[1] SZABO N. Smart Contracts[EB/OL]. (1994). http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html.

[2]  张铮文, 达鸿飞. 重构智能合约（上）：非确定性的幽灵[EB/OL]. . https://zhuanlan.zhihu.com/p/25764739.

[3] 苏小乐. 十问智能合约（二）-道友，你的智能合约环境有什么不同？[EB/OL]. . https://zhuanlan.zhihu.com/p/42528521.

[4] WIKIPEDIA. Deterministic algorithm[EB/OL]. . https://en.wikipedia.org/wiki/Deterministic_algorithm.

[5] Ethereum Yellow Paper[EB/OL]. . https://github.com/ethereum/yellowpaper.

[6] Forth (programming language)[EB/OL]. wikipedia, . https://en.wikipedia.org/wiki/Forth_ (programming_language).

[7] 袁煜明, 刘洋. 【火币区块链产业专题报告】区块链技术可扩展方案分层模型[R]. .

[8] 袁煜明, 胡智威. 【超越白皮书3】DAG技术解析与实测[R]. .

[9] SAMEEH T. An Overview Of Smart Contract Scripting For Cryptocurrency Blockchains[EB/OL]. . https://www.deepdotweb.com/2017/01/15/overview-smart-contract-scripting-cryptocurrency-blockchains/.

[10] EARLS J. The Faults and Shortcomings of the EVM[EB/OL]. . http://earlz.net/view/2017/08/13/0451/the-faults-and-shortcomings-of-the-evm.

[11] Aion FastVM[EB/OL]. . https://github.com/aionnetwork/aion_fastvm.

[12] CREMER L. Missing return value bug — At least 130 tokens affected[EB/OL]. Medium, 2017. (2017). https://medium.com/coinmonks/missing-return-value-bug-at-least-130-tokens-affected-d67bf08521ca.

[13] Hyperledger Burrow[EB/OL]. . https://www.hyperledger.org/projects/hyperledger-burrow.

[14] Nervos Network 简介[EB/OL]. . https://docs.nervos.org/.

[15] FOUNDATION A. Introducing the FastVM[EB/OL]. . https://blog.aion.network/aionfastvm-c5ccd1628da0.

[16] TEAM T Z. Zilliqa Technical Whitepaper[J]. Zilliqa, 2017: 1–8.

[17] LILLEHAGEN T. DJVM Behind the Scenes[EB/OL]. . https://medium.com/corda/djvm-behind-the-scenes-2ba7f5cb9275.

[18] EVANS B. Deterministic Execution on the JVM[EB/OL]. . https://www.infoq.com/articles/Deterministic-Execution-JVM.

[19] Windows 2000 emulated in WebAssembly[EB/OL]. . https://www.reddit.com/r/webdev/comments/98ufca/windows_2000_emulated_in_webassembly/.

本报告由火币区块链研究院出品，报告发布时间2018年11月5日，作者：袁煜明、胡智威。

免责声明：

1. 火币区块链研究院与本报告中所涉及的数字资产或其他第三方不存在任何影响报告客观性、独立性、公正性的关联关系。

2. 本报告所引用的资料及数据均来自合规渠道，资料及数据的出处皆被火币区块链研究院认为可靠，且已对其真实性、准确性及完整性进行了必要的核查，但火币区块链研究院不对其真实性、准确性或完整性做出任何保证。

3. 报告的内容仅供参考，报告中的事实和观点不构成相关数字资产的任何投资建议。火币区块链研究院不对因使用本报告内容而导致的损失承担任何责任，除非法律法规有明确规定。读者不应仅依据本报告作出投资决策，也不应依据本报告丧失独立判断的能力。

4. 本报告所载资料、意见及推测仅反映研究人员于定稿本报告当日的判断，未来基于行业变化和数据信息的更新，存在观点与判断更新的可能性。

5. 本报告版权仅为火币区块链研究院所有，如需引用本报告内容，请注明出处。如需大幅引用请事先告知，并在允许的范围内使用。在任何情况下不得对本报告进行任何有悖原意的引用、删节和修改。