区块链的虚拟机方式

虚拟机方式

相较于上述两种方式，目前最多用于实现智能合约的方式是虚拟机方式，它可以为程序提供一个完全对底层透明的执行环境。

这种思路的典型应用可追溯到传统IT技术中的JVM虚拟机。其目的是实现“一次编写，到处运行”的特性，而不是让程序开发人员为兼容每个不同的服务器编写不同版本的程序。

而这一特点正是分布式部署与运行的智能合约所需要的：屏蔽区块链节点自身执行环境的区别，在所有节点上的运行均一致，从而实现上文所述智能合约需要满足的确定性特点。

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

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

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

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

·256位字长。采用目前主流CPU所支持的8位、16位、32位、64位等字长时，CPU可直接提供原生支持，程序效率高。但EVM采用的字长是256位，处理器需要额外的操作才可以正常处理，因此运算效率较低。同时相较于主流字长，256位也存在一定的存储浪费，进而影响gas消耗。

目前，一部分测试表明，当字长改为64位或128位时，合约代码的运行效率、存储成本（以gas值体现）均有改良。

·不支持浮点数及缺少标准库。此问题是不支持浮点数。而正如上文提到的，通常与EVM配合使用的Solidity语言也因为缺少原生标准库使得这一问题更为突出。

OpenZeppelin的出现使这一问题得到了缓解，其ERC20、ERC721的编写框架使开发变得容易。但依赖于第三方代码库始终存在一定风险，例如，前段时间有许多采用OpenZeppelin的ERC20通证合约因为函数返回值的问题导致转账结果无法预计。

·合约代码不可修改升级。

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

因为以上缺点，在以太坊EVM之后，很多区块链项目通过多种技术来实现虚拟机。可以按照技术实现方式的特点进一步将其分为以下几类进行讨论。

需要注意的是，目前不少公链只公布了其开发计划，而无实际可运行的虚拟机程序代码，具体实施情况可能会随着项目进度而有所变化。

—-

编译者/作者：NB区块链

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。