3.7-zk-vm-vs-zk-evm-building.md

3.7 ZK 发展路线 ZK-VM vs ZK-EVM

阅读提醒：本章内容包含较多专业名词与解释，理解难度较大。不深究底层技术原理，同样可以理解 ZK-Rollup 的工作方式。

当我们考虑 ZK-Rollup 的发展时，还有一个角度值得关注，那就是它与以 EVM（太坊虚拟机）的兼容性。

ZK-VM：从零知识证明的角度出发

第一种思路是从零知识证明技术出发，专门开发适用于零知识证明的算法，从而构建一个 ZK-VM ^[1] （零知识虚拟机），而不是原生兼容 EVM 的 ZK-EVM ^[2] （零知识以太坊虚拟机），在此基础上尽可能实现 EVM 兼容。

StarkWare 和 zkSync 都采用了这种路线。 StarkWare 的 Cairo 语言和 zkSync 的 Zinc 语言都是原生的零知识编程语言，甚至前者的账户地址系统与以太坊也存在很大的差异。

这种路线的优点是能够充分发挥零知识证明的潜力，实现最大化的扩展性。但缺点是开发者需要学习新的编程语言，并且现有项目需要将 Solidity 语言 ^[3] 的代码转换为 ZK-VM 的代码，这个过程中可能出现许多意想不到的问题，并需要重新调试，重新审计。

ZK-EVM：从 EVM 兼容性的角度出发

反过来我们也可以从兼容 EVM 这个目的出发，将 EVM 的交易在操作码 ^[4] 层面切割成更小的步骤，对每个步骤去找对应的零知识证明算法，力求实现完全的 EVM 兼容。 这样做可以使开发者几乎无感地切换到二层网络，方便现有项目迁移，最大程度地保留目前的 EVM 生态成果。 Scroll 和 Polygon Hermez 都采用了这种思路。

但是这种路线的缺点也显而易见， EVM 交易并非为零知识而设计，因此这种方法往往生成的证明体积较大，所需的时间也更长。

读到这里，我们已经了解了 Rollup 的当前进展。特别是零知识证明技术，令人感到十分神奇，使 Rollup 具备了非常大的潜力。但是仅仅通过 Rollup 实现扩容仍然存在上限，未来我们还有其他提升的空间吗？

注释及拓展阅读

^[1] VM（ Virtual Machine ）即虚拟机，一个由软件模拟硬件的可控代码执行环境。 ZK-VM（ Zero Knowledge - Virtual Machine ） 是适应于零知识证明的虚拟机。

^[2] ZK-EVM（ Zero Knowledge - Ethereum Virtual Machine ）是指利用了零知识证明技术的以太坊虚拟机，与原始的以太坊虚拟机有良好的兼容性。

^[3] Solidity 语言是以太坊原生的开发语言，大部分运行在以太坊网络上的智能合约均采用 Solidity 编写。

^[4] 计算机能直接读懂的语言是 0 和 1 ，操作码（ Opcode ）也是非常底层的，与硬件（或是虚拟机中的虚拟硬件）直接交流的代码。操作码是指令集中每个指令的唯一标识符，在计算机执行指令时，用于识别具体指令的一个数字或符号。例如，在 x86 指令集中，加法指令（ ADD ）有一个特定的操作码，用于标识该指令。

此外还有一些相关概念：

1. 指令集（ Instruction Set ）： 指令集是一种用于编程的低级语言，它是计算机硬件能够理解和执行的一组指令。每种处理器都有自己的指令集，这些指令集定义了处理器可以执行的基本操作，如数据移动、算术和逻辑运算、条件分支等。指令集也被称为指令集架构（ ISA，Instruction Set Architecture ）。

2. 字节码（ Bytecode ）： 字节码是一种中间代码，介于源代码和机器代码之间。字节码通常由虚拟机（如 Java 虚拟机，JVM ）执行，而不是直接由硬件执行。字节码的目的是提供一种平台无关的代码表示形式，这样不同平台上的虚拟机都可以执行相同的字节码。字节码通常比源代码更接近机器代码，但仍需要经过解释或编译为特定硬件的指令集。

指令集是计算机硬件能够执行的一组基本操作，每个操作都有一个唯一的操作码。字节码是一种平台无关的中间代码形式，它在执行时需要虚拟机将其转换为特定硬件的指令集。在这个过程中，字节码中的指令也会有相应的操作码。总之，操作码是指令的标识符，它在指令集和字节码中都有应用。