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 等场景，而不是普遍适用。