TLDR： ZK 协处理器是一种让 dApp 利用链下计算资源的方案，本文主要讨论了协处理器的实现方式、各类应用以及未来的发展方向，主要内容有：

1. RISC Zero 的 zkVM 是一种 ZK 协处理器解决方案，它让链上合约能调用链下 zkVM 跑特定的 Rust 代码，并将结果返回给链上，同时提供 zkp 供合约验证计算是否正确。
2. ZK 协处理器有不同的实现方式，除了 zkVM，用户还可以自行为程序写定制化 ZK 电路，或者使用预制的框架写电路，进而让合约能利用链下计算资源。
3. ZK 协处理器可以在 DeFi 上发挥作用，例如把 AMM 的计算放在链下进行，进而让协议捕获类似 MEV 的价值，或者让 AMM 实现复杂且需要大量计算的运行逻辑。ZK 协处理器还可以让借贷协议实时计算利率，使保证金计算透明化等。zkAMM 有两种实现方式，一种是用 zkVM，另一种是用 zkOracle。
4. ZK 协处理器还有其他潜在用法，比如钱包可以用 ZK 协处理器把身份验证放在链下执行，协处理器还可以让链上游戏能执行更复杂的计算，降低 DAO 治理所需的 gas 等。
5. ZK 协处理器的格局未定，但相比用户自己写电路，用一个项目做接口调用链下资源是更加友好的，但那“接口”项目背后接入了什么计算服务提供商（传统云厂商、去中心化资源共享）就是另一个值得讨论的问题了。

1. ZK 协处理器的含义与应用

ZK 协处理器的核心是把链上计算挪到链下，用 ZK 证明链下计算过程的可靠性，使得智能合约能够轻松处理大量的计算，同时让合约能核实计算的可靠性。**这和 zkRollup 的思路是类似的，但 Rollup 是链协议层利用链下计算资源，而 ZK 协处理器是 dApp 利用链下资源。

**这里用 RISC Zero 来解释一种 ZK 协处理器实现方式，但 ZK 协处理器有很多种实现方式，后文会继续介绍。**RISC Zero 开发了 Bonsai ZK 协处理器架构，其中的核心是 RISC Zero 的 zkVM， 开发者可以在 zkVM 上为“某段 Rust 代码被正确执行”这件事生成 zkp。有了 zkVM 后，实现 ZK 协处理器的具体流程为：

1. 开发者向 Bonsai 的中继合约发起请求，即在 zkVM 中跑开发者要求的程序
2. 中继合约把请求发给链下请求池
3. Bonsai 在链下 zkVM 中执行请求，进行链下的大规模运算，然后为其生成一个凭证（receipt）。
4. 这些证明，也叫做“收据”，由 Bonsai 通过中继合约发布回链上。

在 Bonsai 中证明的程序被称作 Guest Program ，凭证（receipt）用来证明 guest program 被正确执行。凭证包括一个 journal 和一个印章（seal）。具体而言，Journal 承载了 zkVM 应用的公共输出，而印章用于证明凭证的有效性，即证明 guest program 被正确执行 ，印章本身也是一个由证明者生成的 zkSTARK。验证凭证可以保证 journal 是用了正确的电路等构建所得 。

Bonsai 为开发者简化了从 Rust 代码到 zkVM 字节码的编译、程序上传、在 VM 中的执行和证明反馈等流程，让开发者能够更聚焦于程序的逻辑设计。而且不仅是部分的合约逻辑，而且整个合约逻辑都可以放到链下跑。RISC Zero 还使用了 continuations，它把一个大的 proof 生成拆分成很多份，然后每份单独进行证明。这样既可以为大型程序生成证明，也不会占用太多内存。除了 RISC Zero， 还有 IronMill , =nil; Foundation 和 Marlin 几个项目也提供了类似的通用解决方案。

2. ZK 协处理器在 DeFi 上的应用

2.1 AMM - Bonsai 为协处理器

zkUniswap 就是一种利用了链下计算资源的 AMM，它的核心是把 swap 的部分计算放在链下，而且它使用了 Bonsai。用户在链上发起一个 swap 请求。Bonsai 的中继合约获得请求，发起链下计算，Bonsai 完成计算后向 EVM 中的 callback 函数返回计算结果和 proof。如果 proof 被验证为成功，swap 就会被执行。

**但 swap 不是一次完成的，请求和执行过程分别在不同的 transactions 中，这带来了一定风险，即在提交请求后和 swap 完成前，池子的状态可能发生变化。**因为验证是基于提交请求时池子的状态。如果一个请求还在等待时，池子状态变了，那么验证就会失效。

**为了解决这个问题，开发者设计了一个池子锁。**当用户发起请求时，除了结算 swap 以外的所有操作都被锁了起来，直到链下成功触发链上 swap 或者 swap 超时了（会预设这个时间）。有时间限制的话，即使中继或 zkp 出问题，池子也不会被一直锁着。而具体的时间限制可能是几分钟。

**zkUniswap 对 MEV 有个特殊的设计，即开发者希望让协议捕获 MEV 价值。**理论上 zkAMMs 同样有 MEV，因为第一个提交易的人就能上锁，所以大家还是会争 gas， builders 同样可以为请求交易排序。但 zkUniswap 会把 MEV 收益自己吃掉，用到的方法是可变利率渐变式荷兰拍卖（VRGDA）。

zkUniswap 把 lock 拿出来自己降价拍卖，如果 lock 很快卖掉，那协议就知道目前需求量大，然后自动升价，如果售出 lock 的速度变慢，协议就会降低价格。这会成为新的收入来源。相当于，协议提供了一个新东西决定交易顺序，而竞争价格的钱直接通过新东西给到项目方，这个很有想象力。

2.2 AMM - zkOracle 为协处理器

**除了用 zkVM，还有人提出用 zkOracle 来实现对链下计算资源的利用， 而zkOracle 是兼顾输入和输出的预言机。**一般预言机有两种，一种是输入预言机，一种是输出预言机，输入预言机是把链下数据整理（计算）后放到链上，输出预言机是把链上数据整理（计算）后提供给链下。I/O（输入兼输出）预言机（zkOracle ），是先做输出，再做输入，让链上能利用链下计算资源。

zkOracle 一方面使用链上数据作为数据源，另一方面用 ZK 保证预言机节点的计算没有作假，可以实现协处理器的功能。因此，可以把 AMM 的核心计算放在 zkOracle 中，实现传统 AMM 功能的同时，还可以用 zkOracle 实现更复杂更消耗计算资源的操作。

2.3 借贷利率计算、保证金计算等其他应用

抛开实现方式，有了 ZK 协处理器后可以实现很多功能。比如，借贷协议可以不再预设参数，而是根据实时的借贷情况调整利率。比如在借钱需求旺盛时提高利率吸引供给，然后在需求降低时降低利率。这要求借贷协议能实时获得链上数据，同时进行大量的计算，得出合适的参数，这就需要链下计算了（除非链上成本极低）。

**计算保证金余额、未实现的盈亏、清算金额等的复杂运算也可以将其转移到协处理器来执行。**用协处理器的优势在于它让这些应用更透明、更可验证，保证金引擎的逻辑不再是一个秘密的黑盒子。虽然计算是在链下完成的，但用户可以完全信任其执行的正确性。此外，这种做法也适用于期权的计算。

3. ZK 协处理器的其他应用

3.1 钱包-用 Bonsai 为协处理器

**Bonfire Wallet 用 zkVM 把验证身份的计算放到了链下。**这个钱包的目标让用户能用生物信息（指纹），或加密硬件 yubikey 创建 burner 钱包。

具体而言，Bonfire Wallet 使用了 WebAuthn 这个通用的网页验证标准，让用户不用密码，直接用设备来完成网页上的身份验证。所以在 Bonfire 钱包中，用户通过 WebAuthn 生成一个公钥（不是链上的，给 WebAuthn 用的），然后用它来创建钱包。

每个 Burner 钱包在链上都有合约，其中包含了 WebAuthn 的公钥，合约需要验证用户的 WebAuthn 签名。但这个计算量是很大的，所以用到了 Bonsai 把计算放在链下，通过一个 zkVM guest 程序在链下验证签名，并生产 zkp 供链上验证。

3.2 链上数据索取-用户自行写 ZK 电路

**Axiom 是一个没有用 zkVM 但使用另一种协处理器解决方案的应用。**先介绍一下 Axiom 想做什么，它希望利用 ZK 协处理器让合约能查阅历史链上信息。其实让合约读历史数据是很难的，因为智能合约一般是获得实时的链上数据，而且很贵，合约很难获得账户过往余额或者交易记录等有价值的链上数据。

**Axiom 节点访问所需链上数据并在链下执行指定的计算，然后为计算生成一个零知识证明，证明结果是根据有效的链上数据正确计算出来的。**这个证明在链上被验证，确保合约可以信任这个结果。

为链下计算生成 zkp 就需要把程序编译进 ZK 电路里，前文也提到了用 zkVM 来做这件事，而 Axiom 官方指出在这件事情上有很多方案，需要权衡性能，灵活度和开发体验：

1. 定制电路：开发者为程序定制电路，那性能肯定最好，但要花时间开发；
2. eDSL/DSL：开发者还是自己写电路，但有一些可选框架帮开发者把 ZK 相关的问题解决掉，这样可以平衡性能和开发体验。
3. zkVM：开发者直接用现成的虚拟机里跑 ZK，这非常方便但 Axiom 官方认为效率很低

因此，Axiom 选了第二种，项目方还为用户提供了一套优化过的 ZK 模块，使其可以自行设计电路。

与 Axiom 类似的项目还有 Herodotus ，但它想做的是跨链信息传输的中间件。由于信息处理是在链下，所以让不同链获得处理后的数据是很合理的思路。而另一个项目 Space and Time 则是用类似架构实现了数据索引。

3.3 链上游戏、DAO 治理等其他应用

**除此以外，链上游戏，DAO 治理都可以用 ZK 协处理器。**RISC Zero 认为，任何需要 250k gas 以上的计算使用 ZK 协处理器的话成本都会更低，但具体如何得出的还有待考究。DAO 治理也可以用到 ZK 协处理器，因为涉及多人和多个合约，这很耗计算资源。RISC Zero 称使用 Bonsai 后 gas 费可以降 50%。ZKML 本质上也是 ZK 协处理器的思路，因此 Modulus Labs ，Giza 也是这个领域的项目，只不过 ZK 协处理器的概念更大 。

此外，ZK 协处理器这个领域还有一些辅助性项目，比如 ezkl，它提供制作 ZK 电路的编译器， ZK 部署的工具套件，把链上计算移到链下的工具等。

4. 未来展望

协处理器使得链上应用拥有了如“云”一样的外部计算资源，它提供了相对廉价的大量计算，而链上只处理必要的计算。在实际情况下，zkVM 也可以在云上面跑，ZK 协处理器本质上是一个架构，是把链上计算放到链下的方式，而链下计算资源由谁提供是不限制的。

**本质上说，链下计算资源由传统的大厂商，甚至去中心化的计算资源共享，和本地设备都有可能。**这三个方向各有差异，传统大厂可以做到相对成熟的链下计算解决方案，在未来去中心化计算资源的“鲁棒性”可能更强，而用户本地计算也很有想象空间。但目前很多 ZK 协处理器项目都选择闭源提供服务的阶段，因为这个赛道的上下游尚未形成，无法把服务细化并交给不同项目，未来有两种可能：

1. ZK 协处理器的每一个环节都有大量的项目相互竞争
2. 一个服务体验良好的项目占据大部分市场

从开发者的角度，其使用 ZK 协处理器时可能只会用一个“接口”项目，这也是亚马逊云占据市场大量的原因，开发者会习惯于一种部署方式。但作为那一个链下计算资源的“接口”项目，背后接入了什么计算服务提供商（传统云厂商、去中心化资源共享）就是另一个赛道值得讨论的问题了。