0. Introduction

In this post, we will look at the recently popular concepts of zkCoprocessor and zkOracle and compare their differences.

1. Definition of zkCoprocessor

When a term is coined, its true meaning is not defined by itself. We have seen this very much in the case of blockchain.

1. ZK: While academics often refer to the privacy features of Zero Knowledge, in the blockchain context, ZK often just stands for the succinctness and validity of the technology. Even projects that are built on ZK Rollup call themselves zkSomething.
2. DA: Until now, many people didn’t really realize that Data Availability is not Data Storage, so in order to solve this terminology problem, some people have suggested replacing DA with DP (Data Publishing), or making the whole meaning of DA into Data Publishing + Data Storage (1, 2).

We see a similar phenomenon in the term zkCoprocessor. Everyone uses the term, but they don’t necessarily refer to the same things.

So we wanted to express what the project itself thinks about zkCoprocessor, what the community understands about zkCoprocessor, and what zkCoprocessor really means and does from our perspective.

a) From Project Themselves

Definition 1 from Axiom: zkCoprocessor proves historical data onchain.

The concept of the zkCoprocessor was popularized by Axiom, which originally conceived it as a zkAttestor. From Axiom’s idea, zkCoprocessor represents the component that “proves historical data on-chain and trustlessly use that data in a smart contract”.

Note that the Brevis team said that this type of zkCoprocessors are essentially an API/DSL layer on top of the underlying zk circuit. So this is not programmable.

Definition 2 from RISC Zero: zkCoprocessor offloads computation from onchain to offchain.

RISC Zero also often refers to itself as a zkCoprocessor. From their perspective, they see zkCoprocessor as a broader concept, “a tool for using ZKPs to offload computation from on-chain to off-chain”.

b) From Community

Definition from Peteris (the same as 1): zkCoprocessor can access to historical onchain state.

Peteris from Aera Finance believes that zkCoprocessor acts very much like a state oracle, with the main function being access to historical data. At the same time, he and Rishabh from BananaHQ believes that the description of definition 2 is more like a zkVM than a subclass of zkCoprocessor.

Definition from Messari, Modular Media, and Kobi (the same as 2): zkCoprocessor offloads computation from onchain to offchain.

Messari has also given its own definition of zkCoprocessor. Sami, a researcher at Messari, believes that zkCoprocessor enables smart contract devs to easily offload complex logic offchain without new trust assumptions. Modular Media also gives the same concept. Kobi from Geometry compares rollup with a coprocessor, Brevis added that zkCoprocessor trades off the cost of maintaining a permanent state storage against hyper-boosted performance, Taiko came up with the design of Booster Rollup that further explored the idea of Rollup Coprocessor. These are the same definition as RISC Zero.

c) From Us

To summarize, we conclude that there are two types of zkCoprocessor in practice, and they are as follows:

1. Data Access zkCoprocessor: mainly feeds certain data (historical block, historical state) to a certain place (smart contract).
2. zkVM Compute zkCoprocessor: computes by the offchain zkVM, then feed result back to the onchain. Compresses O(n) compute into just O(1) verification.

2. Definition of zkOracle

a) Oracle

Hyper Oracle provides us with an explanation of Oracle in Defining zkOracle for Ethereum.

Oracle practically sums up the “infra” in any blockchain space, as a better definition than coprocessor.

If the input to the infra/oracle is off-chain data and the output is on-chain, then it is an input oracle (e.g. Chainlink Price Feed). Conversely, it is an output oracle (e.g. The Graph). If the output oracle is first, then the input oracle, then it is an I/O oracle (e.g. Gelato Network).

In short, oracle is very similar to the concept of coprocessor, but at the same time have the characteristics of data access and computation.

b) zkOracle

Taking Hyper Oracle as an example, what is the relationship between a zkOracle and a zkCoprocessor?

The zkOracle discussed in Defining zkOracle for Ethereum actually has the capabilities of both zkCoprocessors.

For example, a zkOracle such as Hyper Oracle:

1. Access to historical data in trustless way.
2. Can perform programmable computations.

3. zkCoprocessor and zkOracle

When we directly compare the two types of zkCoprocessor with zkOracle, we can see that zkOracle has all the features of zkCoprocessor at the same time:

1. asynchronous processing for smart contract
2. interoperating with and enhancing the capabilities of existing applications on L1 or L2
3. off-loading computation in a resource-constrained system

By direct comparison, zkOracle is a more end-to-end solution can provide developers with a more complete technology stack.

The two zkCoprocessors expand on their respective verticals, e.g., the Data Access zkCoprocessor unlocks cross-chain scenarios, and the zkVM Compute zkCoprocessor represents a zkVM-based zk rollup.

4. Build with zkCoprocessor or zkOracle

Which one to choose when building?

In a step-by-step order, we can make some decisions about building an application.

a) DApp with Pure Smart Contract

First, a pure Solidity implementation of smart contracts is still a very good choice. While pure smart contracts do not provide some of the best novel features, they are still sufficient in certain scenarios. Also the current availability of Arbitrum Stylus has unlocked a lot of new applications with pure smart contract.

b) DApp that Needs Richer Data Access

In many cases, developers may want to use Data Access zkCoprocessor or zkOracle for smart contracts to access richer data sources.

In this scenario, if Data Access zkCoprocessor is used alone, the computation is still handled in the smart contract. The role of the zkCoprocessor is to reduce the complexity of obtaining data in the traditional way, but not to make the smart contract more computationally powerful.

In this scenario, we see a lot of small data-related projects, rather than full-fledged DApps in the traditional sense:

1. Using zkCoprocessor Axiom: Better LP Management, MEVictim Rebate
2. Using zkOracle Hyper Oracle: Uniswap v2 Price, OpenSea Trade Activity, USDT Volume Monitor

c) DApp that Needs Heavy Compute

Often, some complex algorithms cannot be computed directly on the chain, for games, the computational logic is very complex, such as etherquake and GameOfLife that costs $2k to run one step. Or ML-related complex algorithms. Or ML-related complex algorithms that are impossible to run on chain. Therefore, we need zkVM zkCoprocessor or zkOracle to run the computation on the offchain, and then submit it to the chain as ZKP.

In this example, we can see some of their unlimited computational potential:

1. Using zkCoprocessor Bonsai: Zeth (Prove Reth in zkVM), zk-sentiment
2. Using zkOracle Hyper Oracle or zkWASM: zkGo (Prove L2-Geth in zkVM, Type-0 zkEVM), zkAMM

d) Next-Gen DApp with Full Features (DeFi 3.0)

Finally, we talked about applications that can only be built with zkOracle. Taking the DeFi application as an example, a complete DeFi is very complex. The next generation of DeFi applications, or DeFi 3.0 DApps, will require:

1. Richer Data Access
2. Unlimited Compute
3. Autonomous (for liquidation, parameter update, protocol governance)

We have already discussed how zkOracle shares the capabilities of both zkCoprocessors, while fulfilling the first two functional requirements. How does zkOracle fulfill the autonomous feature and how does zkCoprocessor not?

1. zkOracle: No human intervention is required. Data access and compute tasks can be fully defined and executed in programmable and automated way. All onchain calls are always trustless and valid ones.
2. zkCoprocessor: Requires onchain monitoring and filtering of computation response by relayer, or the addition of extra complex mechanisms.

So what does the absence of autonomous in the zkCoprocessor entail: the

1. Inadequate decentralization
2. Risk of potentially complex mechanisms
3. Developer mental burden

Therefore, zkOracle is a perfect and sufficient choice for a complete application like DeFi.

It is worth noting that Hooks can also handle some of zkCoprocessor’s missing functionality, but ONLY in scenarios like DeFi, and not universally.

Disclaimer：

1. This article is reprinted from [mirror]. All copyrights belong to the original author [SevenX Ventures]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.