作者:Hill,SevenX Ventures Research;翻译:0xjs@金色财经
在这篇文章中,我们将了解最近流行的 zkCoprocessor 和 zkOracle 概念,并比较它们的差异。
当一个术语被创造出来时,它的真正含义并不是由它本身定义的。我们在区块链的例子中已经看到了很多这样的情况。
ZK:虽然学术界经常提到零知识的隐私特征,但在区块链背景下,ZK往往只代表技术的简洁性和有效性。即使是基于 ZK Rollup 构建的项目也称自己为 zkSomething。
DA:直到现在,很多人还没有真正意识到Data Availability并不是Data Storage,所以为了解决这个术语问题,有人建议用 DP(Data Publishing)代替DA,或者把DA的全部含义变成数据发布+数据存储。
我们在 zkCoprocessor 一词中看到了类似的现象。每个人都使用这个术语,但他们不一定指的是相同的事物。
所以我们想表达项目本身对 zkCoprocessor 的看法,社区对 zkCoprocessor 的理解,以及从我们的角度来看 zkCoprocessor 的真正含义和作用。
Axiom 的定义 1:zkCoprocessor 在链上证明历史数据。
zkCoprocessor 的概念由 Axiom 推广,最初将其设想为 zkAttestor。从 Axiom 的想法来看,zkCoprocessor 代表了“在链上证明历史数据并在智能合约中无需信任地使用该数据”的组件。
请注意,Brevis 团队表示,这种类型的 zkCoprocessor 本质上是底层 zk 电路之上的 API/DSL 层。所以这是不可编程的。
RISC Zero 的定义 2:zkCoprocessor 将计算从链上卸载到链下。
RISC Zero 也经常将自己称为 zkCoprocessor。从他们的角度来看,他们将 zkCoprocessor 视为一个更广泛的概念,“一种使用 ZKP 将计算从链上卸载到链下的工具”。
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 的定义相同。
综上所述,我们得出实际中zkCoprocessor有两种类型,分别如下:
数据访问 zkCoprocessor:主要将某些数据(历史区块、历史状态)馈送到某个地方(智能合约)。
zkVM计算zkCoprocessor:由链下zkVM计算,然后将结果反馈给链上。将 O(n) 计算压缩为 O(1) 验证。
Hyper Oracle 在Defining zkOracle for Ethereum中为我们提供了 Oracle 的解释。
Oracle 实际上总结了任何区块链空间中的“基础设施”,作为比协处理器Copocessor更好的定义。
如果基础设施/预言机的输入是链下数据并且输出是链上数据,则它是输入预言机(例如 Chainlink Price Feed)。反之,它是一个输出预言(例如The Graph)。如果输出预言机在前,然后是输入预言机,则它是 I/O 预言机(例如 Gelato Network)。
总之,预言机与协处理器的概念非常相似,但协处理器同时具有数据访问和计算的特点。
以Hyper Oracle为例,zkOracle和zkCoprocessor之间是什么关系?
Defining zkOracle for Ethereum中讨论的 zkOracle 实际上具有两个 zkCoprocessor 的功能。
例如,Hyper Oracle 等 zkOracle:
以无需信任的方式访问历史数据。
可以执行可编程计算。
当我们直接将两种类型的zkCoprocessor与zkOracle进行比较时,我们可以看到zkOracle同时具有zkCoprocessor的所有功能:
智能合约的异步处理
与 L1 或 L2 上的现有应用程序互操作并增强其功能
卸载资源受限系统中的计算
通过直接比较,zkOracle是一个更加端到端的解决方案,可以为开发者提供更加完整的技术栈。
两类zkCoprocessor在各自的垂直领域进行了扩展,例如,数据访问zkCoprocessor解锁了跨链场景,zkVM计算zkCoprocessor代表了基于zkVM的zk rollup。
建设时选择哪一种?
按照一步一步的顺序,我们可以做出一些关于构建应用程序的决定。
首先,智能合约的纯 Solidity 实现仍然是一个非常好的选择。虽然纯粹的智能合约不能提供一些最好的新颖功能,但在某些场景下它们仍然足够了。此外,Arbitrum Stylus 的当前可用性还通过纯智能合约解锁了许多新应用程序。
在许多情况下,开发人员可能希望使用数据访问 zkCoprocessor 或 zkOracle 进行智能合约来访问更丰富的数据源。
在这种场景下,如果单独使用数据访问zkCoprocessor,计算仍然在智能合约中处理。zkCoprocessor的作用是降低传统方式获取数据的复杂度,而不是让智能合约的计算能力更强。
在这个场景中,我们看到了很多与数据相关的小型项目,而不是传统意义上成熟的 DApp:
使用 zkCoprocessor Axiom:更好的 LP 管理、MEVictim 回扣
使用 zkOracle Hyper Oracle:Uniswap v2 价格、OpenSea 交易活动、USDT 交易量监控
通常,一些复杂的算法无法直接在链上计算,对于游戏来说,计算逻辑非常复杂,例如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
最后,我们讨论了只使用 zkOracle 构建的应用程序。以 DeFi 应用为例,一个完整的 DeFi 是非常复杂的。下一代 DeFi 应用程序,或 DeFi 3.0 DApps,将需要:
更丰富的数据访问
无限制的计算
自治(用于清算、参数更新、协议治理)
我们已经讨论了 zkOracle 如何共享两个 zkCoprocessors 的功能,同时满足前两个功能要求。zkOracle 如何实现自治功能,而 zkCoprocessor 如何不实现自治功能?
zkOracle:不需要人工干预。数据访问和计算任务可以以可编程和自动化的方式完全定义和执行。所有链上调用始终是无需信任且有效的。
zkCoprocessor:需要通过中继器对计算响应进行链上监控和过滤,或者添加额外的复杂机制。
那么 zkCoprocessor 缺乏自主性意味着什么:
去中心化不足
潜在复杂机制的风险
开发者心理负担
因此,对于像 DeFi 这样的完整应用程序来说,zkOracle 是一个完美且充分的选择。
值得注意的是,Hooks 还可以处理 zkCoprocessor 缺失的一些功能,但仅限于 DeFi 等场景,而不是普遍适用。
声明:本文系金色财经原创稿件,版权属金色财经所有,未经授权不得转载,已经协议授权的媒体下载使用时须注明"稿件来源:金色财经",违者将依法追究责任。
提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。
金色图览
金色财经 善欧巴
蜂巢Tech
Biteye
区块律动BlockBeats
Techub News
YBB Capital