追求极致的设计理念！用 RISC-V 从头设计 CKB 虚拟机

Nervos 底层公链 CKB 的虚拟机（CKB-VM）是基于 RISC-V 指令集打造的区块链虚拟机。在上一堂分享中，我们简单介绍了区块链虚拟机，以及我们理想中的区块链虚拟机的样子。在本篇文章中，CKB-VM 设计者将详细的介绍 CKB 虚拟机的设计理念，以及选择 RISC-V 指令集背后的思考逻辑。

秘猿科技区块链小课堂第 23 期

---

CKB-VM 的设计理念

CKB 是 Nervos Network 的基础层，其目标是 为上层应用提供足够的安全性和去中心化 。在调研 CKB-VM 选型的过程中，我们反复思考：CKB-VM 应该要有哪些特性？显然，对于一个在区块链上使用的虚拟机，有两个关键特性在任何情况下都必须满足：

1. 确定性 ：对于固定程序和输入，虚拟机必须始终返回固定的输出结果，结果不会由于时间、运行环境等其他外部条件而改变；
2. 安全性 ：执行虚拟机时不会影响到平台本身的运行。

但是这些条件仅仅是强制性条件，我们希望设计出一个虚拟机，能够更好地服务于 CKB 的目标。经过深思熟虑，我们认为这样的虚拟机应该 满足如下特性：

• 灵活性

我们的目标是设计出一个足够灵活，能够长期运转的虚拟机，从而使得 CKB 能够与密码学的发展携手并进。密码学的历史是一段「执剑」和「破壁」的永恒之战：数千年的密码学发展史，加密与解密是一场没有终点的智力角逐，过往如此，未来亦然。一些适用于今天的加密算法，比如 secp256k1，将来可能会被淘汰；未来还会有更多有价值的新算法和技术（如 Schnorr 或后量子签名等）不断涌现。在区块链的虚拟机上运行的程序，应该能够更自由便捷地使用新的算法，同时那些已经被过时的算法应该能够自然地被淘汰。

为了方便理解，我们用比特币来举例。目前，比特币使用的是 SIGHASH 1 来进行交易签名，并且在共识协议中使用了 SHA-256 哈希算法。那么我们能够确保几年后比特币用的这种 SIGHASH 方式仍然是最好的选择吗？或者说，伴随着日益增长的算力，SHA-256 仍然适合作为稳定的哈希算法吗？而目前我们研究的所有区块链协议，若需要升级加密算法，则则不可避免地需要硬分叉。 在设计 CKB 时，我们希望探索如何通过 VM 的设计来降低硬分叉的可能性。

我们在思考，虚拟机是否可以允许升级加密算法？或者说，是否能够向 VM 添加新的交易验证逻辑？比如，在仍然使用 secp256k1 的情况下，如果有经济激励的驱动，或者出现更新算法的需求，我们是否可以在不分叉的前提下实现更高效的签名验证算法？又或，如果有人找到了在 CKB 上实现更好算法的途径，或者需要引入一个新的加密算法，那么我们是否能够确保他/她自由的实现？

我们希望 CKB-VM 能够给大家提供更多的实现空间，最大限度地提供灵活性，并且可以让用户无需等待硬分叉即可使用新的加密算法。

• 运行透明性

在对当前这一代区块链 VM 进行研究后，我们注意到了一个问题，还是以比特币为例：比特币的 VM 层提供的仅仅是一个堆栈，并且执行时堆栈无法知晓可以存储在堆栈上的数据大小，或堆栈深度，其它所有以堆栈模式实现的 VM 都有同样的问题，虽然共识层可以提供堆栈深度的定义或间接提供堆栈深度（基于指令长度或 gas 限制）。这会让 VM 上的程序开发者必须要去猜测程序运行时的状态，这种类型的 VM 让程序无法充分发挥 VM 的全部潜能。

基于这个问题，我们认为应该优先定义 VM 操作期间所有资源的限制，包括 gas 限制和堆栈空间大小，并让在 VM 上运行的程序能够查询资源的使用情况， 这将使得在 VM 上运行的程序可以根据资源可用性来采用不同的算法 。通过这种设计，程序可以充分发挥 VM 的潜能。并且在以下场景中，我们能够看到 VM 更多的灵活性：

1. 可以根据用户在 CKB 上可用的存储空间（Cell Capacity）为存储数据的智能合约选择不同的策略。当 Cell Capacity 充足时，程序可以直接存储数据以减少使用的 CPU cycle（CPU 要执行一条机器指令经过的步骤）数量；当 Cell Capacity 受限时，程序可以压缩数据以适应较小的 Capacity，使用更多的 CPU cycle。
2. 可以根据用户存储的数据（Cell Data）的总量和剩余内存的大小为智能合约选择不同的处理机制。当存在少量 Cell Data 或大量剩余内存时，所有的 Cell Data 都可以被读取到内存中进行处理。当存在大量 Cell Data 或剩余内存很少时，每个操作可以仅读取部分内存，类似于交换内存的操作。
3. 对于一些常见的合约，比如哈希算法，可以根据用户提供的 CPU cycle 数选择不同的处理方法。例如，SHA3-256 的安全性已经足以满足大多数场景的需求，但是，合约可以通过使用更多的 CPU cycles 来利用 SHA3-512算法以满足更高的安全要求。

• 运行期开销

以太坊虚拟机（EVM）中的 Gas 机制是一个非常天才的设计，它优雅地解决了区块链应用场景下的停机问题（因为以太坊是图灵完备的，所以允许循环语句，但是无限循环语句容易导致停机问题，Gas 机制限定了一个区块的最大计算量，从而避免了这个问题），并允许程序在完全去中心化的虚拟机上进行计算。但是我们发现，在 EVM 中针对不同的 Opcode（操作符）设计一个合理的 Gas 计算方式是一件非常难的事情，EVM 几乎在每次版本更新时都要调整 Gas 计算机制（EVM 的抽象层级相对较高，一条 EVM 指令可能对应若干条底层硬件指令，在执行程序时，处理的数据量和计算复杂度都只能通过估算来定价，所以 EVM 需要不断的调整 Gas 计算机制）。

因此我们设想：能不能通过 VM 的设计来确保程序运行时资源消耗的计算方式更加合理准确？

我们希望能够找到一个提供上述所有功能的 VM 设计，但是发现并没有现成的解决方案可以实现我们对 CKB 的愿景。于是，我们决定重新设计一个能满足上述所有特性的 VM，以更好的实现 CKB 的愿景。

解决方案：RISC-V

RISC-V 是由加州大学伯克利分校的教授于 2010 年设计的开源 RISC 指令集架构（ISA）。RISC-V 的目标是提供一个通用的 CPU 指令集架构，以支持下一代系统架构开发，并在未来数十年中不会产生遗留架构问题所带来的负担。

RISC-V 可以满足从低功耗小型微处理器，到高性能数据中心（DC）处理器的实现要求 。与其他 CPU 指令集相比，RISC-V 指令集具有以下优点：

• 透明性

RISC-V 的核心设计和实现均遵照 BSD 许可协议（自由软件中使用最广泛的许可协议之一）。任何公司和机构都可以使用 RISC-V 指令集，并可以不受限制地创造新的软 / 硬件。

• 精简性

RISC-V 的 32 位整数核心指令集只有 41 条指令，即使支持 64 位整数，也只有 50 条指令左右。在提供同样功能的前提下，RISC-V 指令集比起有上千条指令的 x86 指令集，实现起来更容易也更能避免 Bug （x86 指令集手册有 2000 余页，并会不断的增加，而 RISC-V 指令集手册仅 100 余页）。

• 模块化

RISC-V 采用简化的内核，使用模块化机制以提供更多扩展指令集设置。例如，CKB 可能会选择实现 RISC-V 内核中定义的 V extension 来支持向量计算或为 256 位整数计算添加扩展指令集，从而为高性能加密算法提供可能性。

• 支持的广泛性

GCC 和 LLVM 等编译器都支持 RISC-V 指令集，Go 针对 RISC-V 的后端也在开发中。CKB-VM 的实现使用的是广泛的 ELF 格式，也就是说， 任何可以编译成 RISC-V 指令集的语言均可以直接用来为 CKB 开发智能合约。

• 成熟性

RISC-V 核心指令集已经得到了最终的确认和固定，未来所有 RISC-V 的实现都需要向后兼容。所以当更新 VM 指令时，CKB 不会因此出现硬分叉。另外，RISC-V 指令集已经有了硬件实现，并在真实的应用场景中验证过，且不会存在一些存在于其他支持较少的指令集中的潜在风险。

虽然其他指令集可能也具备上述特性中的一部分特性，但根据我们的评估，RISC-V 指令集是 唯一一个具备所有上述特性的指令集 。因此，我们选择使用 RISC-V 指令集来实现 CKB-VM，另外，智能合约将使用 ELF 格式以确保更广泛的语言支持。

此外，我们将为 CKB-VM 添加动态链接以确保 Cell Sharing。尽管 CKB 的实现提供的是最流行的加密算法，但我们鼓励社区提供更优化的加密算法实现以减少运行时开销（CPU cycles）。