3 月 2 日，在阿里平头哥举办的首届玄铁 RISC-V 生态大会上，RISC-V之父、图灵奖得主 David Patterson 充满信心地说道。
从提出到 100 亿颗处理器，英特尔 x86 架构花了几十年，ARM 花了 17 年，而 RISC-V 只用了大约 10 年的时间，这在芯片架构发展史上前所未有。
有数据预测，到 2025 年，采用 RISC-V 架构的处理器将突破 800 亿颗，在 IoT 领域，预测到 2025 年将会有 28% 的市场会被 RISC-V 所占有。
那么，RISC-V 又是什么呢？（以下内容主要来源于《CKB-VM 诞生记》系列文章）
RISC-V 简介
RISC-V 是一个清晰、简约、开源的 CPU 指令集架构，诞生于美国加州大学伯克利分校。
2010 年，由于其他商业闭源指令集的局限性，该校的一个研究团队在启动一个新项目时，从零开始设计了一套全新的开源指令集。这套全新的指令集有着大量的寄存器和透明的指令执行速度，能够帮助编译器和汇编语言程序员将实际的重要问题转换为适当、高效的代码，并且只包含了不到 50 条指令 。
这套指令集就是 RISC-V，所以 RISC-V 是一个非常年轻的指令集。
那么，在此之前，主要的指令集都有哪些呢？
在 PC 时代，x86 是不可动摇的霸主，x86 是 CISC（Complex Instruction Set Computer，复杂指令集），和 RISC（Reduced Instruction Set Computer，精简指令集）不同，CISC 指令集会随着发展不断增多。这样会使得成本不断上升，性能和功耗也会受到影响。而且，CISC 指令集长度、执行时间都不固定，很难找出一条高效率的通用设计道路来完成指令的执行。
智能手机普及之后，ARM 成了移动端的宠儿。ARM 是精简指令集（RISC）有着低功耗和低成本的特性，但是，因为要保持向后兼容性，ARM 需要保留许多过时的定义，导致指令集冗余严重，这使得 ARM 架构文档的复杂度越来越高。
在 x86 和 ARM 垄断的当下，RISC-V 为市场带来了新的生机。
RISC-V 的目标是提供一个通用的 CPU 指令集架构，以支持下一代系统架构开发，并在未来数十年中不会产生遗留架构问题所带来的负担。
RISC-V 可以满足从低功耗小型微处理器，到高性能数据中心（DC）处理器的实现要求 。与其他 CPU 指令集相比，RISC-V 指令集具有以下优点：
透明性（开源）
ARM 和 x86 都是闭源项目，且授权条款极其苛刻：英特尔不允许除 AMD 和 VIA 之外的任何一家公司使用 x86 指令集；想要获得 ARM 指令集的授权可能需要花费上千万美元的授权费，并且会受到而且授权到期后，需要重新谈判授权事宜。
RISC-V 是一个真正意义上的开源项目，被称为硬件领域的 Linux。事实上，发明 RISC-V 的 David Patterson 教授、Krste Asanovic 教授、Andrew Waterman 和 Yunsup Lee 的初衷就是希望 “Instruction Sets Want to be Free”，全世界任何公司、大学、研究机构与个人都可以开发兼容 RISC-V 指令集的处理器，都可以融入到基于 RISC-V 构建的软硬件生态系统。
RISC-V 使用的是 BSD License 开源协议（自由软件中使用最广泛的许可协议之一），BSD 开源协议允许使用者修改和重新发布开源代码，也允许基于开源代码开发商业软件发布和销售，并可以不受限制地创造新的软 / 硬件。
精简性
经过几十年的发展，x86 与 ARM 的架构文档已经长达数千页，几乎需要花掉一个工程师近一个月的阅读时间，而阅读 RISC-V 文档只需要花费 1～2 天的时间。
这是因为 RISC-V 只将那些最常使用的指令集挑选出来，然后为其进行专门优化，至于不常用的指令，则可以用几个基础指令组合的方式完成，这样就可以大大提高效率。所以，在提供同样功能的前提下，RISC-V 指令集比起有上千条指令的 x86 指令集，实现起来更容易也更能避免 bug。
举个例子，如果我们用的是 x86，那么就必须买下一整个超市，才能享受自身需的物品；而 RISC-V 是一家可以单买的超市，顾客们只需要挑选自己所需的物品，并为此付费即可。
模块化
RISC-V 采用简化的内核，使用模块化机制以提供更多扩展指令集设置。
支持的广泛性
GCC 和 LLVM 等编译器都支持 RISC-V 指令集，Go 针对 RISC-V 的后端也在开发中。
成熟性
RISC-V 核心指令集已经得到了最终的确认和固定，未来所有 RISC-V 的实现都需要向后兼容。另外，RISC-V 指令集已经有了硬件实现，并在真实的应用场景中验证过，且不会存在一些存在于其他支持较少的指令集中的潜在风险。
当 CKB-VM 遇见 RISC-V
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 指令集是唯一一个具备所有上述特性的指令集。
因此，我们最终选择了使用 RISC-V 指令集来实现 CKB-VM。
推荐阅读：
1. 观望、试水、踩坑后，RISC-V站上了进入黄金时代的跳板
2. RISC-V真的成了，这个速度有点超乎想象了
3. 当 CKB-VM 遇见 RISC-V——CKB-VM 诞生前记
https://talk.nervos.org/t/ckb-vm-risc-v-ckb-vm/1667
4. 基于 RISC-V 打造的区块链虚拟机——CKB-VM 诞生记（一）
https://talk.nervos.org/t/risc-v-ckb-vm/1726
5. 灵感、设计和优势——CKB-VM 诞生记（二）
https://talk.nervos.org/t/ckb-vm/1730
6. 如何在 CKB-VM 上愉快的玩耍——CKB-VM 诞生记（三）
https://talk.nervos.org/t/ckb-vm-ckb-vm/1765
7. Zaki Manian 的硬核发问：区块链虚拟机，WASM 和 RISC-V 哪个更合适？
https://talk.nervos.org/t/zaki-manian-wasm-risc-v/463