TL;DR

我们正在努力构建第一个基于 PE-VM 的 ZKVM，通过 ZK-friendly 的设计和 ZK 算法的改进，使它具备更高的吞吐率；其技术特点如下：

a. 证明快：

i. ZK-friendly: 获得更小的电路规模，以及精简的底层约束单元；

ii. 更快的 ZK 实现: 对 plonky2 的进一步优化改进；

b. 执行快：

采用并行执行的 VM（在 Parallel prove 技术背景下，证明生成时间越短，作用越明显）。

我们已经做的工作：

a. 2022 年 7 月份，发布了OlaVM的白皮书；

b. 2022 年 11 月份，完成指令集的设计和开发，并初步实现了 OlaVM 的虚拟机执行模块， 你可以打开链接：https://github.com/Sin7Y/olavm 去查看我们的代码，持续更新中！！！

c. 针对目前执行效率最快的 ZK 算法，我们完成 plonky2 的电路设计及算法研究，你可以打开链接：https://github.com/Sin7Y/plonky2/tree/main/plonky2/designs去了解 plonky2 更多的设计，下一步我们将对其进行优化改进，请持续关注。。。

我们正在做什么？

OlaVM 是首个把并行执行的 VM 引入的二层的 ZKVM，融合两种方案的技术点，获得更快的执行速度和更快的证明速度，从而在未来实现更高的系统吞吐率。

在现在的以太坊系统中，造成吞吐率慢的原因主要有两个：

1. 共识的过程：每个节点重复执行交易进行交易的有效性校验；

2. 交易的执行：交易的执行是单线程的。

如何获取高吞吐率？

尽可能快的证明生成 ( 目前最高优先级 )

想要加速证明的生成，其大体可以分为两个部分：尽可能小的电路规模和尽可能快的算法执行；尽可能快的算法执行又可以分为：算法本身参数的提升（比如选择更小的域）和外部执行环境的改善（比如采用硬件加速）。

1. 尽可能小的约束规模

是的，证明生成的消耗是和约束的整体规模 n 强相关的，如果能大幅缩减整体的约束规模，则证明的生成的时间则会明显减少。这就要求，在 VM 的设计中，你需要使用尽可能多的设计以减少整体的约束规模。

a. Prophet

Prophet 的意思为“预言家”，先“预言”再“校验“，其主要目的是：针对一些复杂的计算，我们不需要用 VM 的指令去实现这些复杂的计算（可能会消耗很多的指令，从而增大 VM 的执行轨迹和最终的约束规模）；而是利用内置的 Prophet 去完成计算，并且把结果发送给 VM，然后 VM 只是执行对于这个结果的合法性校验。Prophet 是一些具备特定计算功能的内置函数，比如除法计算，平方根计算，立方根计算等等，我们会根据实际场景，逐渐丰富 Prophets 库，使得对于大部分复杂计算场景，整体约束的缩减效果达到最大化。

b. Zk-friendly

当计算是复杂计算时，Prophet 可以帮助缩减 VM 执行的轨迹大小；但在此之前，我们更希望这个计算本身是 Zk-friendly。因此，在设计中，我们会采用一些 Zk-friendly 的操作，比如常见的哈希算法，验签算法等；这些优化也经常存在于其他 ZK(E)VM 的方案里；但最终的关键就是，当你选择一个 Zk-friendly 的复杂计算时，如何用更小的约束去约束这个复杂的计算？

VM 本身除了要执行计算逻辑之外，还会有一些其他的操作同样需要被证明，比如 RAM 操作。基于堆栈的 VM，每次访问时，都要进行 POP，PUSH 的操作；而在验证层面，仍然需要去校验这个操作的有效性，这些操作会组成独立的 Table，然后用约束去校验这些堆栈操作的有效性；而基于寄存器的 VM，执行相同的逻辑，得到的执行轨迹更小，因此约束规模也更小。

2. 尽可能快的算法执行

ZK 算法发展至今，在工程可用性上已经取得了惊人的进展。场景越来越通用，效率越来越高，从 R1CS 到Plonkish，从较大的域 (Cairo VM:P=2²⁵¹+17·2¹⁹²+1)到更小的域 (Plonky2:P=2⁶⁴–2³²+1)；从 CPU 到 GPU/FPGA/ASIC 的加速实现 ，例如Ingonyama的 FPGA 加速设计和Semisand的 ASIC 设计等。

由于 Plonky2 的惊人性能表现，我们暂时以 Plonky2 作为 OlaVM 的 ZK 后端。我们已经深入分析了 Plonky2 的 Gate 设计，Gadget 设计和协议原理，并从中找到了一些优化方向，你可以关注我们的 Github Repo: Plonky2 designs去了解更多相关的信息。

更快的交易执行 ( 现阶段不是瓶颈 )

在 OlaVM 的设计中，Prover 是无许可的，任何人都可以接入；因此，当你有许多 Prover 资源时，你可以并行的去为这些区块生成证明，然后把这些证明聚合在一起，提交到链上验证。由于 Prover 是可以并行的，因此区块生成的越快（对应的区块里交易执行的越快），对应的证明就可以提前生成，这样最终链上验证的时间也会提前。

兼容性？

对于 ZKVM 来说，具备某种兼容性是为了方便初期的生态构建，毕竟在区块链行业发展至今，已经有许多成熟的应用部署在现有的系统上，以太坊上的生态更为丰富。因此，能实现对这些既有生态的兼容，使得这些项目可以无缝迁移，对项目初期生态的构建有很大的帮助。

当然，OlaVM 的主要目标仍然是构建一个高吞吐的 ZKVM，当我们的第一步做的不错时，我们会考虑去实现兼容性，特别是以太坊的兼容性，这也会在我们的路线图中。

All Together

集成上述所有模块，整个系统的数据流程图大概如下图所示：

Coming Soon

1. 2022-12 月初：

a. 完成 OlaVM DSL 设计；

b. 完成 OlaVM 预编译合约的设计和开发；

c. 完成 OlaVM 指令约束和 Context 约束和预编译合约约束；

d. 完成 Plonky2 的第一阶段优化。

参考

1.OlaVM:https://olavm.org/whitepaper/OlaVM-07-25.pdf