使用符合 CKB 虚拟机当前系统架构的真实 CPU 指令集来构建本身的虚拟机

Nervos 底层公链 CKB 的虚拟机（CKB-VM）是基于 RISC-V 打造的区块链虚拟机。在前两期中，咱们介绍了 CKB 虚拟机的设计理念，以及基于 RISC-V 指令集打造的选择逻辑。那么再往前推一步，咱们为何会选择基于真实 CPU 指令集来构建 CKB-VM 呢？在本篇文章中，CKB-VM 设计者将和咱们继续讨论 CKB-VM 的设计灵感、设计以及基于真实 CPU 指令集来构建 CKB-VM 的额外优点。

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

---

灵感与设计

在设计 CKB-VM 以前，咱们发现不少区块链项目并非用真实的 CPU 指令集来构造本身的虚拟机。咱们熟知的以太坊下一代虚拟机 EWASM、EOS 以及 Dfinity 等都选择了 WASM（WebAssembly，一种编码格式）来构造本身的虚拟机。咱们也彻底能够设计出一个具备高级语言特性的 VM，好比能够用于静态验证，或是能够直接支持高级数据结构，或是支持各类加密算法的 VM。

可是咱们发现，虽然带有高级语言特性的虚拟机可以提供更多的便利，好比可以支持语法各异的编程语言，但同时也会出现其余一些问题：任何复杂的、带有高级语言功能的 VM，不管多么灵活，都不可避免的会在设计层面引入一些语义约束，出于性能的缘由，不一样的语言在底层几乎须要共享相同的语义（带有高级语言特性的虚拟机须要绑定密码学原语，若将来现有的原语被攻破，或者须要更换一套密码学原语时，须要经过分叉来实现）。这样一来， VM 自身的灵活性就会受到限制，这和 CKB 做为加密经济底层基础设施的愿景并不相符。

与此同时，一个带有高级语言功能的 VM 一般会包含某些高级的数据结构与算法，这样任何在 VM 中嵌入的高级数据结构与算法均可能只适合于某一类应用的开发，却不适用于其它应用程序的开发。而且，咱们没法预设全部可能的使用方式，这些嵌入 VM 自己的数据结构或算法除了兼容性以外没有任何做用，随着时间的推移，甚至会成为负担。

另外咱们还发现，全部的区块链项目都要在冯·诺伊曼 CPU 架构（x86，x86_64，ARM 等架构）下才能运行，而且全部高级的 VM 特性都必须映射到现代体系架构的 CPU 汇编指令。

举个例子，虽然 V8 引擎（由 Google 开发的开源 JavaScript 引擎，用于 Google Chrome 及 Chromium 中）看上去能够有无限量的内存，可是其内部实现依然须要依靠一个十分复杂的垃圾回收算法，才能在有限的内存空间中模拟出无限的内存空间。

相似的，Haskell （一种标准化的，通用的纯函数编程语言）或是 Idris（一个通用的依赖类型纯函数式编程语言） 可能具备先进的静态类型检查模式（在某种程度上）来证实软件运行的正确性，但在完成类型检查以后，仍是须要经过一个翻译层把静态验证后的代码转换成未验证的原生 x86_64 汇编指令。

这里的关键在于不管咱们如何设计 VM，都没有办法太过偏离当前的体系结构。换句话说，在任何 VM 的最底层，都须要将操做转变成原始的汇编指令来执行。

因而咱们想： 为何不使用符合 CKB 虚拟机当前系统架构的真实 CPU 指令集来构建本身的虚拟机？

这样一来，咱们不会丢失任何添加静态验证、高级数据结构、或是加密算法的可能性，而且不管咱们在 VM 中提供怎样的数据结构或算法，均可以 最大化 VM 的灵活性 。此外，经过真实的 CPU 指令集，咱们能够最大限度的让开发者写出任何知足要求的合约。

额外的优点

除了 灵活性 以外，基于真实 CPU 指令集的 VM 还有其它额外的优点：

• 稳定性

为硬件设计的 CPU 指令集一旦最终肯定并在芯片中使用，就难以修改，因此与一般是软件实现的 VM 指令集相比，硬件指令集显得很是稳定。这个属性与 Layer 1 区块链 VM 的诉求很是契合，由于稳定的指令集意味着较少的硬分叉，且不会牺牲灵活性。

• 运行期透明性

物理 CPU 在运行时仅须要依靠寄存器和一段内存，在使用堆栈的操做过程当中，一般内存中的空间是指定的。这样一来，咱们能够在程序执行期间根据 VM 中的堆栈指针来获取堆栈空间的使用状况，从而最大限度地提升运行时状态的可见性。

CKB-VM 能够调整堆栈指针、更改内存中的区域分配，甚至根据须要扩大或缩小堆栈区域大小，从而提升 VM 的灵活性。当前 CPU 指令集还能够提供过去周期的计数，从而容许查询 VM 的运行开销状态。

• 运行期开销

具备真实 CPU 指令集的 VM 能够轻松管理运行期的开销，每一个指令执行时所需的 cycle 数（不考虑流水线）是固定的。 咱们能够根据真实 CPU 指令集的这个特性来设计 CKB-VM 运行时的开销计算机制，这样一来，当咱们应用新算法时，也能够准确地计算出所需的开销。

可是，与经过操做码或本机 VM 指令集实现加密算法的 VM 相比，使用真实 CPU 指令集存在一个关键的缺点： 性能 。

不过，根据研究和测试结果，咱们能够经过适当的优化和即时（Just-In-Time，JIT）编译器实现来优化基于真实 CPU 指令集在 VM 上运行的加密算法，从而知足 CKB 应用程序的需求。在处理即时性时，咱们是基于底层指令集进行处理，而不是基于像 JavaScript 这样的高级语言上处理，这样会使得 VM 具有更低的工做负载和更好的性能。

Why Not WASM?

也许有人会问：在区块链社区对 WebAssembly 有着强烈兴趣和普遍关注的状况下， CKB 为何不直接使用 WebAssembly 呢？

WebAssembly 是一个伟大的项目，而且咱们很是但愿它最后可以成功。一个拥有普遍支持的沙盒环境，对于整个区块链行业，甚至整个软件业来讲都是件求之不得的事。从长远来看，WebAssembly 也有潜力实现 CKB 所需的大部分特性，可是它并不能提供咱们在《CKB-VM 诞生记（一） 1》中提到的 RISC-V 能为 CKB-VM 带来的全部好处，好比，目前 WebAssembly 还全都是 JIT 实现，缺乏一个合理的运行期开销计算模型。

另外，RISC-V 从 2010 年开始设计，在 2011 年发布初版规范，2012 年出现基于 RISC-V 构建的硬件；而 WebAssembly 出现于 2015 年，2017 年发布 MVP，相对来讲，RISC-V 会比 WebAssembly 更加的成熟，因此至少在目前阶段，咱们以为使用 WebAssembly 并非 CKB-VM 最好的选择。

固然，咱们并非彻底放弃使用 WebAssembly，考虑到 WebAssembly 与 RISC-V 一样是底层 VM 的实现方式，并且不少设计和指令集十分类似， 咱们彻底有可能提供一个从 WebAssembly 到 RISC-V 的二进制转换器，从而确保 CKB 也能够利用目前区块链上基于 WebAssembly 的创新。 另外，CKB 上也可以支持仅能够编译为 WebAssembly 的语言（好比 Forest：https://github.com/forest-lan... ）。

社区驱动的 CKB-VM

经过 CKB-VM 的设计，咱们的目标是创建一个围绕 CKB 的社区，该社区能够自由地发展和适应新技术的进步，而且能够最大限度地减小人工干预（例如硬分叉）。 咱们相信 CKB-VM 能够实现这一愿景。

注： CKB-VM 与 CKB 同样为开源项目，目前 CKB-VM 仍在开发过程当中，尽管 CKB-VM 的大部分设计已经敲定，但某些设计也可能会在未来，由于你的贡献而有新的变更和推动。这篇文章是为了让咱们的社区更加了解 CKB-VM，这样人人均可以在里面更好的玩耍并作出贡献啦！

CKB-VM：https://github.com/nervosnetw...