SevenX Ventures Understanding the Concepts and Differences of zkOracle and zkCoprocessor in One Article

SevenX Ventures A Comprehensive Guide to Differentiating zkOracle and zkCoprocessor

Author: Hill, SevenX Ventures Research; Translator: 0xjs@LianGuai

0. Introduction

In this article, we will explore the concepts of zkCoprocessor and zkOracle, which have recently gained popularity, and compare their differences.

1. Definition of zkCoprocessor

When a term is created, its true meaning is not defined by itself. We have seen many such cases in the example of blockchain.

• ZK: Although the academic community often mentions the privacy features of Zero-Knowledge, in the context of blockchain, ZK often represents the simplicity and effectiveness of the technology. Even projects built on ZK Rollup will refer to themselves as zkSomething.

  • XRP: A Resilient Painting in the Cryptocurrency Market
  • What is Flash Trade (闪电交易)?
  • A Developer’s Guide to Starknet for Solidity Developers

• DA: Until now, many people have not really realized that Data Availability is not Data Storage. So, to address this terminology issue, some suggest using DP (Data Publishing) instead of DA, or expanding the full meaning of DA to include data publishing + data storage.

We see a similar phenomenon in the term zkCoprocessor. Everyone uses this term, but they may not be referring to the same thing.

So, we want to express the project’s own view of zkCoprocessor, the community’s understanding of zkCoprocessor, and the true meaning and role of zkCoprocessor from our perspective.

a) From the project itself

Axiom’s definition 1: zkCoprocessor proves historical data on-chain.

The concept of zkCoprocessor was popularized by Axiom, initially envisioned as zkAttestor. From Axiom’s perspective, zkCoprocessor represents a component that “proves historical data on-chain and allows the use of that data in smart contracts without trust.”

Please note that the Brevis team states that this type of zkCoprocessor is essentially an API/DSL layer on top of underlying zk circuits. So, it is not programmable.

RISC Zero’s definition 2: zkCoprocessor offloads computations from on-chain to off-chain.

RISC Zero also often refers to itself as zkCoprocessor. From their perspective, they see zkCoprocessor as a broader concept, “a tool that offloads computations from on-chain to off-chain using ZKP”.

b) From the community

Peteris’ definition (same as 1): zkCoprocessor can access historical on-chain states.

Peteris from Aera Finance believes that zkCoprocessor functions very much like an oracle, with its primary function being to access historical data. At the same time, both he and Rishabh from BananaHQ believe that the description of definition 2 sounds more like zkVM, rather than a subclass of zkCoprocessor.

Messari, Modular Media, and Kobi’s definition (same as 2): zkCoprocessor offloads computations from on-chain to off-chain.

Messari also provides its own definition of zkCoprocessor. Sami, a researcher at Messari, believes that zkCoprocessor allows smart contract developers to easily offload complex logic off-chain without requiring new trust assumptions. Modular Media also presents the same concept. Kobi from Geometry compares rollup with coprocessor, and Brevis adds that zkCoprocessor balances the cost of maintaining permanent state storage with greatly improved performance. Taiko proposes the design of Booster Rollup, further exploring the idea of Rollup Coprocessors. These align with the definition of RISC Zero.

c) From us

In conclusion, we have identified two types of zkCoprocessors in practice, as follows:

• Data access zkCoprocessor: mainly feeds certain data (historical blocks, historical states) to a certain location (smart contract).

• zkVM computation zkCoprocessor: computed by off-chain zkVM and then the result is fed back to the chain. It compresses O(n) calculations into O(1) verifications.

2. Definition of zkOracle

a) Oracle

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

Oracle actually summarizes the “infrastructure” in any blockchain space, as a better definition than the Copocessor.

If the input of the infrastructure/oracle is off-chain data and the output is on-chain data, it is an input oracle (such as Chainlink Price Feed). Conversely, if it is an output oracle (such as The Graph). If the output oracle comes first, followed by the input oracle, it is an I/O oracle (such as Gelato Network).

In summary, the concept of oracle is very similar to the Coprocessor, but the Coprocessor has both data access and computation characteristics.

b) zkOracle

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

The zkOracle discussed in Defining zkOracle for Ethereum actually has the functionality of two zkCoprocessors.

For example, zkOracle like Hyper Oracle:

• Access historical data in a trustless manner.

• Can perform programmable computations.

3. zkCoprocessor and zkOracle

When we directly compare the two types of zkCoprocessors with zkOracle, we can see that zkOracle has all the functionalities of zkCoprocessor:

• Asynchronous processing of smart contracts

• Interoperability with existing applications on L1 or L2 and enhancing their functionalities

• Offloading computations in resource-constrained systems

By direct comparison, zkOracle is a more end-to-end solution that can provide developers with a more comprehensive tech stack.

The two types of zkCoprocessors have expanded in their respective vertical areas. For example, data access zkCoprocessor unlocks cross-chain scenarios, while zkVM computation zkCoprocessor represents zk rollup based on zkVM.

4. Building with zkCoprocessor or zkOracle

Which one should you choose when building?

According to the step-by-step order, we can make some decisions about building applications.

a) Pure Smart Contract DApps
Firstly, a pure Solidity implementation of smart contracts is still a very good choice. Although pure smart contracts may not provide some of the best novel features, they are still sufficient in certain scenarios. Furthermore, the current availability of Arbitrum Stylus unlocks many new applications through pure smart contracts.

b) DApps that require richer data access
In many cases, developers may want to use data access zkCoprocessor or zkOracle to access richer data sources in smart contracts.

In this scenario, if data access zkCoprocessor is used alone, the computation is still handled within the smart contract. The role of zkCoprocessor is to reduce the complexity of traditional methods of obtaining data, rather than making the computing power of smart contracts stronger.

In this scenario, we see many small projects related to data, rather than mature DApps in the traditional sense:

– Using zkCoprocessor Axiom: better LP management, MEVictim rebates
– Using zkOracle Hyper Oracle: Uniswap v2 prices, OpenSea transaction activities, USDT trading volume monitoring

c) DApps that require a large amount of computation
Generally, some complex algorithms cannot be directly computed on-chain. For games, the computation logic is very complex, such as with etherquake and GameOfLife, where one step costs $2000. Or complex algorithms related to machine learning are not possible to run on-chain. Therefore, we need zkVM zkCoprocessor or zkOracle to run the computation off-chain and then submit it to the chain in the form of ZKP (Zero Knowledge Proof).

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

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

d) Full-featured next-generation DApps (DeFi 3.0)
Finally, we discuss applications built solely using zkOracle. Taking DeFi applications as an example, a complete DeFi is very complex. Next-generation DeFi applications, or DeFi 3.0 DApps, will require:

– Richer data access
– Unrestricted computation
– Autonomy (for liquidation, parameter updates, protocol governance)

We have discussed how zkOracle can share the functionality of two zkCoprocessors while meeting the first two functional requirements. How zkOracle achieves autonomy, and how zkCoprocessor does not achieve autonomy?

So what does it mean for zkCoprocessor to lack autonomy:

• Lack of decentralization

• Risk of potential complex mechanisms

• Developer psychological burden

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

It’s worth noting that Hooks can also handle some of the functions that zkCoprocessor lacks, but only in specific scenarios like DeFi, rather than being universally applicable.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!