【虚拟机专栏】智能合约执行引擎的前世今生

Solidity 作为最早提出的智能合约语言，它的出现为区块链的应用场景打开了新的大门。

——  缘起 ——

智能合约（Smart Contract）这个术语最早于 1994 年由跨领域法律学者尼克·萨博（NickSzabo）⾸次提出。他对智能合约的定义如下：

“一个智能合约是一套以数字形式定义的承诺（commitment），包括合约参与方可以在上面执行这些承诺的协议。”

所以简单来看，尼克·萨博认为智能合约是⼀套承诺。所谓承诺就是参与⽅同意的相互之间的权利和义务。因此智能合约的本质和⽬的即是承诺本身。⽐如⼀个简单的买卖事件，卖家承诺供货，买家承诺⽀付，这两个承诺就可以形成⼀个智能合约。注意尼克·萨博对智能合约定义中提到的关键词：数字形式和协议。这两个关键词决定了智能合约不同于传统意义上的承诺，它在形式和功能上有着决定性的特征。

「智能合约」最开始由以太坊引入区块链。据以太坊白皮书，引入智能合约主要为了解决如下问题：

• 对于脚本语言，脚本是非图灵完备（后文会介绍）的，难以实现复杂的功能，比如椭圆曲线签名算法

• 脚本无法对可以提取的金额进行细粒度控制

• 脚本缺乏状态保存，无法实现更为复杂的有状态合约

• 执行时能获取的数据不够丰富，例如随机数、时间戳和前一个区块哈希的获取

总之，脚本语言无法满足更为丰富的应用操作，所以以太坊设计了独特的智能合约语言 Solidity，同时，执行智能合约的智能合约执行引擎 EVM 也诞生了。

自此，区块链技术的应用场景， 从单一基于 UTXO 的数字货币交易，延伸到图灵完备的通用计算领域。用户不再受限于仅能使用比特币脚本所支持的简单逻辑，而是可以自行设计任意复杂的合约逻辑。

——  总述 ——

以太坊设计智能合约有着如下设计特点：

▲ 执行的确定性

确定性是指程序对于给定的输入，不管在何时何地，执行多少次都有相同的输出。由于区块链维护的是同一份账本，智能合约执行的确定性可以理解为不同的节点执行相同的合约，必须有相同的结果。

以太坊智能合约语言被设计的足够简单，为了保证执行的确定性，其不会实现随机数，不确定的（系统）调用等功能，同时，智能合约的执行在一个环境被限制的虚拟机中进行，这样能够在底层更加保证其结果的确定性。

▲ 图灵完备性

图灵完备的语言，比较官方的解释是“可以计算一切可以用一个算法计算的问题”的语言，包括无限循环。以太坊引入智能合约的目的就是为了实现图灵完备，来支持更为丰富的应用形式。

引入图灵完备之后需要解决的一个问题就是停机问题：在一般情况下，没有办法判断给定的程序是否会停机。

为了避免图灵完备带来的停机问题，以太坊引入 Gas 机制，来对相关的执行过程进行耗费计算。通过将各种操作费用以 gas（每个操作会对应特定的 gas 消耗即有一个 gas 消耗的对应表）为单位计算，并且设置每次执行的 gas 消耗上限，即 gasLimit，在合约执行耗费累计操作 gasLimit 上限后强制停止执行，从而达到停机的效果。Gas 机制的引入，使得用户对使用应用的复杂程度取决于其愿意为其付出的代价，而不是平台物理上的限制。

当然，Gas 机制的引入也还有其他好处，不在此处过多介绍。

▲ 安全性

安全性作为以太坊的设计前提，也是智能合约需要保证的。以太坊智能合约的安全性在设计上主要体现在两个方面：

1）相对简单的智能合约语言

Solidity 语言相对于主流的图灵完备语言而言，由于其专注于区块链场景，所以很多语言特性其没有必要去实现比如多线程，系统调用，这就使得其可以设计得尽可能简化。不过这也是其早期比较难用的原因之一，虽然随着语言的逐渐发展，其功能也在不断的增加与完善。

2）智能合约的执行环境足够隔离

以太坊智能合约运行在以太坊虚拟机 EVM 中，EVM 中的运行不仅被沙盒化，而且实际上是完全隔离的，这意味着在 EVM 中运行的代码无法访问网络、文件系统或其他进程。甚至智能合约中对其他智能合约的访问也很有限。通过运行的隔离很大程度上保证了其可控安全。

但是，不可否认以太坊智能合约仍然存在许多安全上的问题，如著名的“可重入攻击”等。

——  详解 ——

下面，让我们深入 Solidity 合约的执行引擎 — EVM。

EVM 被定义为一种栈式虚拟机，其使用一个字节作为指令。栈式虚拟机的特点是执行运算时都是依靠与操作数栈（operand stack）进行交互。

Solidity 合约源码经过编译后是用一种低级的、基于堆栈的字节码，所以我们真正部署在以太坊上并且在 EVM 中执行的其实是一串字节码。代码由一系列字节组成，其中每个字节代表一个操作。字节码执行时从第一个字节码开始根据字节码的操作含义依次执行，直到到达代码末尾或出现错误（如遇到 REVERT 、STOP 或 RETURN 操作码）。这些操作可以访问三种类型的空间来存储数据：

• 栈: 后进先出容器，其值可以被压入和弹出；

• Memory: 一个无限可扩展的字节数组；

• Storage: 合约的长期存储，为键/值对存储。与计算结束后重置的堆栈和 Memory 不同，存储会长期存在，这部分也就是常说的“世界状态”的一部分。

智能合约的执行过程其实就是依据操作码定义的行为对三种类型存储空间的操作过程，我们以下面的例子进行简单的展示：

下图展示部分合约片段：左边是合约字节码， 右边是字节码代表的操作含义

各个操作码的简单含义如下：

PUSH1：字节码 16 进制为 60 ，操作含义是将紧跟着的一个字节推入栈中

ADD：字节码 16 进制为 01 ，操作含义是将栈上的两个元素弹出相加，然后将结果放回栈中

MSTORE：字节码 16 进制为 52 ，操作含义是将栈中弹出的第二个值存入 Memory 中，存入的索引值为栈中弹出的第一个元素

RET：字节码 16 进制为 f3 ，操作含义是执行结束，返回结果，结果在 Memory 中，起始索引为栈中弹出的第一个值，长度为栈中弹出的第二个值

将这段字节码放入 EVM 中执行，其执行过程如下所示：

其中，PC 代表当前执行操作码的位置，合约片段执行的最后（即：RET 操作码）会从 Memory 中的 60 起始处，取出 5 个字节的数据出来，由此，合约片段执行完毕，最终的结果会被返回给调用者！

细心的同学会发现，图中相关的指令没有和 Storage 相关的操作，其实是因为为了简化没有在示例代码中选取相关的指令如 SStore ，其执行原理和上述的表述类似。

“那么，为什么 EVM 会被设计成这个样子？为什么通过这些栈的进进出出，内存的复制来复制去，以及对 Storage 的操作，就能够解决计算问题，完成对合约状态的获取以及修改呢？”

这就涉及到编程语言的设计了。理论上，在计算理论体系中，指令集架构是一个计算机的抽象模型，指令集包含的指令类型丰富程度直接影响着程序表达的丰富程度。比如，指令集中可以包含算数和逻辑运算类指令如加减乘除，控制类指令如跳转，数据处理指令如读取内存等。而作为虚拟机，可以根据需要选取或者添加指令构建一个指令集，来表达自己期望的功能。比如 EVM 中没有针对与浮点数的相关操作，增加了 Storage 相关的指令，所以这就从指令层面解释了 Solidity 语言不支持浮点数的运算。而在指令确定之后借助现代程序设计的一些工具，即可设计出特定的语言。所以，在某种程度上，如果需要，我们也可以实现自己的语言以及对应的执行引擎。

——  发展 ——

EVM 的本质是通过可编程的语言来操作“世界状态”，也就是我们所说得区块链账本，因此，如何更好、更快的来操作是智能合约虚拟机的一大追求。

随着不断的发展，行业内已拥有多种智能合约执行引擎，同时也不乏新的探索。

• EVM：兼容以太坊 EVM，并进行了性能优化与功能丰富

• HVM：趣链首创支持 Java 语言编写智能合约的高效、易用、完备的智能合约执行引擎

• FVM：支持 Rust 等语言编写智能合约的安全，多样，高效的智能合约执行引擎

• KVSQL：支持在区块链上执行 SQL 语句的新型执行引擎

本文作为【虚拟机】专栏的开篇，介绍智能合约的起源以及以太坊智能合约，接下来系列文章将会对其他执行引擎进行详细介绍，敬请期待！

作者简介

何奇

趣链科技基础平台部区块链虚拟机研究小组

参考文献

[1] 智能合约百度百科

[2] 以太坊黄皮书

[3] 以太坊白皮书