基于 RISC-V 打造的区块链虚拟机——CKB-VM 诞生记(一)

Nervos 底层公链 CKB 的虚拟机(CKB-VM)是基于 RISC-V 指令集打造的区块链虚拟机。在《CKB-VM 诞生前记》中,我们简单介绍了区块链虚拟机,以及我们理想中的区块链虚拟机的样子。在本篇文章中,CKB-VM 设计者肖雪洁将详细的介绍 CKB 虚拟机的设计理念,以及选择 RISC-V 指令集背后的思考逻辑。

CKB-VM 的设计理念

CKB 是 Nervos Network 的基础层,其目标是 为上层应用提供足够的安全性和去中心化 。在调研 CKB-VM 选型的过程中,我们反复思考:CKB-VM 应该要有哪些特性?

显然,对于一个在区块链上使用的虚拟机,有两个关键特性在任何情况下都必须满足:

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

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

  • 灵活性

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

为了方便理解,我们用比特币来举例。目前,比特币使用的是 SIGHASH 来进行交易签名,并且在共识协议中使用了 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

v2-a088614b604321bf0a545e4b87f4a851_r

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)。

CKB 团队内部会经常讨论一些非常有意思的话题,比如如何激励开发者们在 CKB 上改进加密原语。我们希望 CKB-VM 可以在不需要通过硬分叉来升级协议的情况下,和加密算法以及社区一起发展、进化,实现自我完善。 在下一篇文章中,我们将详细讨论基于 RISC-V 指令集打造 CKB-VM 的设计过程和优势, 也欢迎在评论区写下你对 CKB-VM 的想法,CKB 团队将会在这里和你一起讨论。

作者:肖雪洁

翻译:Kelly & Clare

校对:Ryan & Daniel

原文链接: Introduction to the RISC-V Instruction Set CKB-VM and its Requirements

5 Likes