区块链虚拟机1.0版本：比特币的脚本
比特币的脚本定义上为非图灵完备。
比特币中的脚本解释器基于栈这种数据结构对脚本进行解释执行。
比特币脚本解释器的主要特点是：
基于栈式结构设计；
解释执行；
待解释的例程为图灵非完备。
比特币中脚本从功能上分为锁定脚本和解锁脚本，两者结合来判断和验证交易的有效性和合法性。如下图所示为解锁脚本和锁定脚本的说明：
（图片来自《精通比特币》）
这种脚本的设计在丧失灵活性的同时，通过最小的代价获得了一定的运行时安全。
如下为一个简单的加法验证脚本：
2 3 OP_ADD 5 OP_EQUAL
对上述代码的栈式解释流程如下文叙述：
栈中数据：2
脚本数据：3 OP_ADD 5 OP_EQUAL
-----------------------------
栈中数据：2 3
脚本数据：OP_ADD 5 OP_EQUAL
-----------------------------
栈中数据：5
脚本数据：5 OP_EQUAL
-----------------------------
栈中数据：5 5
脚本数据：OP_EQUAL
-----------------------------
栈中数据：true
脚本数据：无
-----------------------------
区块链虚拟机2.0版本：evm
以太坊智能合约官方语言为Solidity，利用Solidity实现智能合约逻辑后，通过编译器编译成元数据（字节码）最后发布到以太坊上。以太坊虚拟机(EVM)本质上依然是一个基于栈的解释器，但是以下几个方面体现了它和比特币中的脚本解释器在设计和实现上的不同：
固定的机器位宽，目前定义为256位；
运行操作计费模式，操作与消费关联，一种新的模式；
引入合约存储账户概念，多种存储状态，栈上存储，临时存储和永久存储；
智能合约为图灵完备。
以太坊虚拟机采用256位固定的机器字节宽度，这样的字节宽度如果从CPU体系架构来看，无疑是没有优势的，毕竟目前对于256操作数的指令执行需要拆分为多条的低位操作指令，那么这里采用256位的操作数可能出于以下两种原因：
256位符合密码学计算的要求，例如SHA256，这点在precompile_contract中就有体现；
更少的OP操作，这样一定程度上有效的减少Gas的消费。
以太坊支持图灵完备的智能合约，合约运行结束的条件一个是程序自己结束，另外一个就是合约运行消耗完给定的Gas数值。
Gas的设置表面上是保证了虚拟机最终能运行到一个可以停机的状态，其实更主要的是它充当了一种衡量工作的计量单位。以太坊不同于比特币，比特币中的交易费用是根据交易的千字节大小来进行计算的，而以太坊相对于比特币面临的合约操作更加的复杂化，所以需要一种新的衡量标准，这种衡量标准要求每个操作需要支付具体的费用，这样可以保证整个网络不会受大量密集工作的影响而陷入一个僵局的状态。同时Gas和ETH之间的转化在一定程度上也刻画出类似黄金和纸币的模式。
以太坊上数据的存储相对比特币更加的灵活，栈、临时存储和永久存储几乎覆盖了智能合约的存储需求，其中只有栈上数据的存储是免费的，永久存储是最耗费Gas的。虽然栈上数据的存储是免费的，但是其也不是可以任意利用，目前栈的深度最大值设置为1024。
还有重要的一点是以太坊上的智能合约存储在一种称作是智能合约账户的一类账户中，这类账户区别于外部账户，外部账户可以通过交易调用智能合约的账户，而智能合约账户彼此之间也可以通过交易来调用。
区块链虚拟机3.0版本：wasm
发展到区块链3.0的时代，虚拟机的架构总体来说有两种：一种是解释器类型，其多基于栈，一种是JIT技术类型。
EOS代码中提供了一个WASM-JIT的实现，该实现上引入了寄存器的概念到其中。通过将wasm文件内容转化为IR中间语言形式，最后利用LLVM-JIT技术实现代码的运行。其中选用wasm作为智能合约的实现格式，一是考虑到智能合约与虚拟机生态问题，支持力度，二是考虑到目前针对wasm的技术方案相对成熟。
由于工具链的完善，wasm天然可以对应多个语言前端，我们不仅仅可以用JS写智能合约，也可以用c++和c来编写我们的智能合约。
