zk预言机 和 zk协同处理器

0. 简介

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

1. zkCoprocessor的定义

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

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

我们在 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 的 Peter相信 zkCoprocessor 的行为非常像一个状态预言机，主要功能是访问历史数据。与此同时，他和来自 BananaHQ 的 Rishabh 认为定义2的描述更像是zkVM而不是zkCoprocessor的子类。

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

Messari也给出了自己对zkCoprocessor的定义。梅萨里 (Messari) 研究员萨米 (Sami)相信 zkCoprocessor 使智能合约开发人员能够轻松地将复杂的逻辑卸载到链下，而无需新的信任假设。模块化媒体还给出了相同的概念。几何中的科比将 rollup 与协处理器进行比较，Brevis补充说zkCoprocessor权衡维护永久状态存储的成本与超提升的性能，Taiko 提出了这样的设计助推器汇总 进一步探讨了 Rollup 协处理器的思想。这些与 RISC Zero 的定义相同。

c) 来自我们

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

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

2.zkOracle的定义

a) Oracle

Hyper Oracle 为我们提供了 Oracle 的解释为以太坊定义 zkOracle。

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

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

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

b) zkOracle

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

为以太坊定义 zkOracle 中讨论的 zkOracle 实际上具有两个 zkCoprocessor 的功能。

例如，Hyper Oracle 等 zkOracle：

1. 以去信任的方式访问历史数据。
2. 可以执行可编程计算。

3. zkCoprocessor和zkOracle

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

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

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

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

4. 使用 zkCoprocessor 或 zkOracle 构建

建造时选择哪一种？

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

a) 纯智能合约的DApp

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

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

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

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

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

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

c) 需要大量计算的DApp

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

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

1. 使用 zkCoprocessor Bonsai：Zeth（在 zkVM 中证明 Reth）、zk-sentiment
2. 使用 zkOracle Hyper Oracle 或 zkWASM：zkGo（在 zkVM、Type-0 zkEVM 中证明 L2-Geth），兹卡AMM

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

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

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

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

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

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

1. 权力下放不足
2. 潜在复杂机制的风险
3. 开发者心理负担

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

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

声明：

1. 本文转载自[mirror]，著作权归属原作者[SevenX Ventures]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。