0、引言

在这篇文章中，我们将了解最近流行的 zkCoprocessor 和 zkOracle 概念，并比较它们的差异。

1、zkCoprocessor的定义

当一个术语被创造出来时，它的真正含义并不是由它本身定义的。我们在区块链的例子中已经看到了很多这样的情况。

• ZK：虽然学术界经常提到零知识的隐私特征，但在区块链背景下，ZK往往只代表技术的简洁性和有效性。即使是基于 ZK Rollup 构建的项目也称自己为 zkSomething。
• DA：直到现在，很多人还没有真正意识到Data Availability并不是Data Storage，所以为了解决这个术语问题，有人建议用 DP（Data Publishing）代替DA，或者把DA的全部含义变成数据发布+数据存储。

我们在 zkCoprocessor 一词中看到了类似的现象。每个人都使用这个术语，但他们不一定指的是相同的事物。

所以我们想表达项目本身对 zkCoprocessor 的看法，社区对 zkCoprocessor 的理解，以及从我们的角度来看 zkCoprocessor 的真正含义和作用。

a) 来自项目本身

Axiom 的定义 1：zkCoprocessor 在链上证明历史数据。

zkCoprocessor 的概念由 Axiom 推广，最初将其设想为 zkAttestor。从 Axiom 的想法来看，zkCoprocessor 代表了“在链上证明历史数据并在智能合约中无需信任地使用该数据”的组件。

请注意，Brevis 团队表示，这种类型的 zkCoprocessor 本质上是底层 zk 电路之上的 API/DSL 层。所以这是不可编程的。

RISC Zero 的定义 2：zkCoprocessor 将计算从链上卸载到链下。

RISC Zero 也经常将自己称为 zkCoprocessor。从他们的角度来看，他们将 zkCoprocessor 视为一个更广泛的概念，“一种使用 ZKP 将计算从链上卸载到链下的工具”。

b) 来自社区

Peteris的定义（同1）：zkCoprocessor可以访问历史链上状态。

Aera Finance 的 Peteris认为，zkCoprocessor 的作用非常像一个状态预言机，主要功能是访问历史数据。同时，他和来自 BananaHQ 的 Rishabh认为定义 2 的描述更像是 zkVM，而不是 zkCoprocessor 的子类。

Messari、Modular Media 和 Kobi 的定义（与 2 相同）：zkCoprocessor 将计算从链上卸载到链下。

Messari也给出了自己对zkCoprocessor的定义。Messari 研究员 Sami认为，zkCoprocessor 使智能合约开发人员能够轻松地将复杂的逻辑卸载到链下，而无需新的信任假设。Modular Media也给出了同样的概念。Geometry 的 Kobi将 rollup 与协处理器进行了比较，Brevis 补充说 zkCoprocessor权衡了维护永久状态存储的成本与高度提升性能，Taiko 提出了Booster Rollup的设计，进一步探索了 Rollup 协处理器的想法。这些与 RISC Zero 的定义相同。

c) 来自我们

综上所述，我们得出实际中zkCoprocessor有两种类型，分别如下：

• 数据访问 zkCoprocessor：主要将某些数据（历史区块、历史状态）馈送到某个地方（智能合约）。
• zkVM计算zkCoprocessor：由链下zkVM计算，然后将结果反馈给链上。将 O(n) 计算压缩为 O(1) 验证。

2.zkOracle的定义

a) 预言机

Hyper Oracle 在Defining zkOracle for Ethereum中为我们提供了 Oracle 的解释。

Oracle 实际上总结了任何区块链空间中的“基础设施”，作为比协处理器Copocessor更好的定义。

如果基础设施/预言机的输入是链下数据并且输出是链上数据，则它是输入预言机（例如 Chainlink Price Feed）。反之，它是一个输出预言（例如The Graph）。如果输出预言机在前，然后是输入预言机，则它是 I/O 预言机（例如 Gelato Network）。

总之，预言机与协处理器的概念非常相似，但协处理器同时具有数据访问和计算的特点。

b) zkOracle

以Hyper Oracle为例，zkOracle和zkCoprocessor之间是什么关系？

Defining zkOracle for Ethereum中讨论的 zkOracle 实际上具有两个 zkCoprocessor 的功能。

例如，Hyper Oracle 等 zkOracle：

• 以无需信任的方式访问历史数据。
• 可以执行可编程计算。

3、zkCoprocessor和zkOracle

当我们直接将两种类型的zkCoprocessor与zkOracle进行比较时，我们可以看到zkOracle同时具有zkCoprocessor的所有功能：

• 智能合约的异步处理
• 与 L1 或 L2 上的现有应用程序互操作并增强其功能
• 卸载资源受限系统中的计算

通过直接比较，zkOracle是一个更加端到端的解决方案，可以为开发者提供更加完整的技术栈。

两类zkCoprocessor在各自的垂直领域进行了扩展，例如，数据访问zkCoprocessor解锁了跨链场景，zkVM计算zkCoprocessor代表了基于zkVM的zk rollup。

4、使用 zkCoprocessor 或 zkOracle 建设

建设时选择哪一种？

按照一步一步的顺序，我们可以做出一些关于构建应用程序的决定。

a) 纯智能合约的DApp

首先，智能合约的纯 Solidity 实现仍然是一个非常好的选择。虽然纯粹的智能合约不能提供一些最好的新颖功能，但在某些场景下它们仍然足够了。此外，Arbitrum Stylus 的当前可用性还通过纯智能合约解锁了许多新应用程序。

b) 需要更丰富数据访问的DApp

在许多情况下，开发人员可能希望使用数据访问 zkCoprocessor 或 zkOracle 进行智能合约来访问更丰富的数据源。

在这种场景下，如果单独使用数据访问zkCoprocessor，计算仍然在智能合约中处理。zkCoprocessor的作用是降低传统方式获取数据的复杂度，而不是让智能合约的计算能力更强。

在这个场景中，我们看到了很多与数据相关的小型项目，而不是传统意义上成熟的 DApp：

• 使用 zkCoprocessor Axiom：更好的 LP 管理、MEVictim 回扣
• 使用 zkOracle Hyper Oracle：Uniswap v2 价格、OpenSea 交易活动、USDT 交易量监控

c) 需要大量计算的DApp

通常，一些复杂的算法无法直接在链上计算，对于游戏来说，计算逻辑非常复杂，例如etherquake和GameOfLife，运行一步需要花费2000美元。或者与机器学习相关的复杂算法不可能在链上运行。因此，我们需要 zkVM zkCoprocessor 或 zkOracle 在链下运行计算，然后以 ZKP 的形式提交到链上。

在这个例子中，我们可以看到它们的一些无限的计算潜力：

• 使用 zkCoprocessor Bonsai：Zeth（在 zkVM 中证明 Reth）、zk-sentiment
• 使用 zkOracle Hyper Oracle 或 zkWASM：zkGo（在 zkVM、Type-0 zkEVM 中证明 L2-Geth）、zkAMM

d) 全功能的下一代DApp（DeFi 3.0）

最后，我们讨论了只使用 zkOracle 构建的应用程序。以 DeFi 应用为例，一个完整的 DeFi 是非常复杂的。下一代 DeFi 应用程序，或 DeFi 3.0 DApps，将需要：

• 更丰富的数据访问
• 无限制的计算
• 自治（用于清算、参数更新、协议治理）

我们已经讨论了 zkOracle 如何共享两个 zkCoprocessors 的功能，同时满足前两个功能要求。zkOracle 如何实现自治功能，而 zkCoprocessor 如何不实现自治功能？

• zkOracle：不需要人工干预。数据访问和计算任务可以以可编程和自动化的方式完全定义和执行。所有链上调用始终是无需信任且有效的。
• zkCoprocessor：需要通过中继器对计算响应进行链上监控和过滤，或者添加额外的复杂机制。

那么 zkCoprocessor 缺乏自主性意味着什么：

• 去中心化不足
• 潜在复杂机制的风险
• 开发者心理负担

因此，对于像 DeFi 这样的完整应用程序来说，zkOracle 是一个完美且充分的选择。

值得注意的是，Hooks 还可以处理 zkCoprocessor 缺失的一些功能，但仅限于 DeFi 等场景，而不是普遍适用。