ABCDE Research Report: In-depth Exploration of Co-processors and Various Solutions

Author: Kris & Laobai, ABCDE; Mo Dong, Celer Network

With the recent popularity of the co-processor concept in the past few months, this new ZK use case has begun to attract more and more attention.

However, we find that most people are still relatively unfamiliar with the concept of co-processors, especially regarding the precise positioning of co-processors—what a co-processor is and what it is not remains quite vague. Furthermore, no one has systematically organized a comparison of the technical solutions of several co-processor tracks available in the market. This article hopes to provide the market and users with a clearer understanding of the co-processor track.

1. What is a Co-Processor, and what is it not?

If you were asked to explain the co-processor concept to a non-technical or development person in one sentence, how would you describe it?

I think Dr. Dong Mo's statement might be very close to the standard answer—essentially, a co-processor is "the ability to empower smart contracts with Dune Analytics."

How can we break down this statement?

Imagine a scenario where you are using Dune—you want to become an LP on Uniswap V3 to earn some fees, so you open Dune, find the trading volume of various trading pairs on Uniswap recently, the APR of fees over the past 7 days, the fluctuation range of mainstream trading pairs, etc…

Or when StepN was popular, you started trading shoes and were unsure when to sell, so you monitored the StepN data on Dune daily, including daily trading volume, new user count, and shoe floor prices… planning to run as soon as you see a slowdown or downward trend in growth.

Of course, you are not the only one watching this data; the development teams of Uniswap and StepN are also paying attention to these metrics.

This data is very meaningful—it can help judge changes in trends and can be used to create more variations, just like the "big data" strategies commonly used by large internet companies.

For example, recommending similar shoes based on the styles and prices of shoes that users frequently buy and sell.

For example, launching a "user loyalty reward program" based on how long users hold their genesis shoes, providing loyal users with more airdrops or benefits.

For example, launching a VIP program similar to Cex based on the TVL or trading volume provided by LPs or traders on Uniswap, offering traders reduced trading fees or increased LP fee shares…

Then the question arises—large internet companies play with big data + AI, which is basically a black box; they can do whatever they want, and users cannot see it and do not care.

But in Web3, transparency and trustlessness are our inherent political correctness, rejecting black boxes!

Thus, when you want to achieve the above scenarios, you face a dilemma—either you implement it through centralized means, manually using Dune to compile these indexed data and then deploy it; or you write a smart contract to automatically fetch this data on-chain, perform calculations, and deploy automatically.

The former will lead you into the "politically incorrect" trust issue.

The latter will incur astronomical Gas fees on-chain, which your (project party) wallet cannot afford.

This is where the co-processor comes into play, combining the two methods mentioned earlier while using technical means to "prove its innocence" for the "manual backend" step. In other words, using ZK technology to "prove" the off-chain "indexing + computation" part, then feeding it to the smart contract, thus solving the trust issue and eliminating massive Gas fees—perfect!

Why is it called a "co-processor"? This actually comes from the history of Web 2.0 development with "GPU." The reason GPUs were introduced as a separate computing hardware, independent of CPUs, was that their architectural design could handle computations that CPUs fundamentally struggled with, such as large-scale parallel repetitive calculations and graphics computations. It is this "co-processor" architecture that has led to the spectacular CG movies, games, AI models, etc., we have today. Therefore, this co-processor architecture is actually a leap in computing system architecture. Now, various co-processor teams hope to bring this architecture into Web 3.0, where the blockchain is akin to the CPU of Web 3.0. Whether L1 or L2, they are inherently unsuitable for tasks involving "heavy data" and "complex computation logic," so a blockchain co-processor is introduced to help handle such computations, greatly expanding the possibilities of blockchain applications.

So, summarizing what co-processors do, it boils down to two things:

1. Fetch data from the blockchain and prove through ZK that the data I fetched is real and not tampered with;

2. Perform corresponding calculations based on the fetched data and again prove through ZK that the results I calculated are also real and not tampered with, allowing the computation results to be called by smart contracts with "low fees + trustless."

Recently, Starkware has popularized a concept called Storage Proof, also known as State Proof, which essentially performs step 1, represented by Herodotus, Langrage, etc. Many cross-chain bridge technologies based on ZK technology also focus on step 1.

The co-processor is simply step 1 followed by an additional step 2, performing trustless calculations after trustless data extraction.

So, to describe it more technically, a co-processor should be seen as a superset of Storage Proof/State Proof and a subset of Verifiable Computation.

One important point to note is that a co-processor is not a Rollup.

Technically speaking, the ZK proof of Rollup is similar to the aforementioned step 2, while the process of "fetching data" in step 1 is directly implemented through a Sequencer. Even a decentralized Sequencer retrieves data through some competition or consensus mechanism, rather than in the form of ZK like Storage Proof. More importantly, ZK Rollup needs to implement a storage layer similar to L1 blockchain in addition to the computation layer, which is permanently existing, while ZK Co-processor is "stateless," meaning that after performing calculations, it does not need to retain all states.

From an application scenario perspective, a co-processor can be seen as a service plugin for all Layer 1/Layer 2, while Rollup is a new execution layer that helps scale the settlement layer.

2. Why must it use ZK? Can’t OP work?

After reading the above, you might have a question: does a co-processor really have to use ZK? It sounds a lot like a "Graph with ZK," and we seem to have no major doubts about the results on Graph.

That being said, it is because when you usually use Graph, it does not involve real money; these indexes serve off-chain services. The data you see on the front-end user interface, such as trading volume, transaction history, etc., can be provided by various data indexing providers like Graph, Alchemy, Zettablock, but this data cannot be fed back into the smart contract because once you do, it adds extra trust to this indexing service. When data is linked to real money, especially large TVL amounts, this extra trust becomes crucial. Imagine a friend asking to borrow 100 bucks; you might give it without blinking, but what if they ask for 10,000 or even 100,000?

But on the other hand, does every scenario involving co-processors really need to use ZK? After all, within Rollup, we have both OP and ZK technical routes, and the recently popular ZKML has also proposed corresponding branch routes like OPML. So, is there an OP branch for co-processors, such as OP-Coprocessor?

Actually, there really is—however, we will keep the specific details confidential for now. We will release more detailed information soon.

3. Which co-processor is strong—Comparison of several common co-processor technical solutions in the market

Brevis

The Brevis architecture consists of three components: zkFabric, zkQueryNet, and zkAggregatorRollup.

Below is an architecture diagram of Brevis:

zkFabric: Collects block headers from all connected blockchains and generates ZK consensus proofs to prove the validity of these block headers. Through zkFabric, Brevis achieves a co-processor that is interoperable across multiple chains, allowing one blockchain to access any historical data from another blockchain.

zkQueryNet: An open ZK query engine marketplace that accepts data queries from dApps and processes them. Data queries use verified block headers from zkFabric to process these queries and generate ZK query proofs. These engines have both highly specialized functions and generalized query languages to meet different application needs.

zkAggregatorRollup: A ZK rollup blockchain that acts as an aggregation and storage layer for zkFabric and zkQueryNet. It verifies the proofs from these two components, stores the verified data, and submits the zk-verified state root to all connected blockchains.

ZK Fabric, as the key part for generating proofs for block headers, ensures that the security of this part is very important, as shown in the architecture diagram of zkFabric:

zkFabric is a light client based on zero-knowledge proofs (ZKP) that is completely trustless, without relying on any external verification entities. Its security comes entirely from the underlying blockchain and mathematically reliable proofs.

The zkFabric Prover network implements circuits for the light client protocol of each blockchain, generating validity proofs for block headers. Provers can utilize accelerators such as GPUs, FPGAs, and ASICs to minimize proof time and cost.

zkFabric relies on the security assumptions of the blockchain and underlying cryptographic protocols. However, to ensure the validity of zkFabric, at least one honest relayer is needed to synchronize the correct fork. Therefore, zkFabric adopts a decentralized relayer network instead of a single relayer to optimize the validity of zkFabric. This relayer network can leverage existing structures, such as the state monitoring network in the Celer network.

Prover allocation: The prover network is a decentralized ZKP prover network that needs to select a prover for each proof generation task and pay fees to these provers.

Current Deployment:

Currently, light client protocols implemented for various blockchains (including Ethereum PoS, Cosmos Tendermint, and BNB Chain) serve as examples and proof of concept.

Brevis has currently partnered with Uniswap Hook, which greatly enhances the customization of Uniswap pools. However, compared to CEX, Uniswap still lacks effective data processing capabilities to create functions that rely on large user transaction data (e.g., volume-based loyalty programs).

With the help of Brevis, Hook has solved this challenge. Hook can now read from the complete historical chain data of users or LPs and run customizable computations in a completely trustless manner.

Herodotus

Herodotus is a powerful data access middleware that provides smart contracts with the ability to synchronize access to current and historical on-chain data across Ethereum layers:

• L1 states from L2s

• L2 states from both L1s and other L2s

• L3/App-Chain states to L2s and L1s

Herodotus proposes the concept of storage proof, which integrates inclusion proofs (confirming the existence of data) and computation proofs (verifying the execution of multi-step workflows) to prove the validity of one or more elements in large datasets (such as the entire Ethereum blockchain or rollup).

At the core of the blockchain is a database, where the data is encrypted and protected using data structures like Merkle trees and Merkle Patricia trees. The uniqueness of these data structures lies in the fact that once data is securely submitted to them, evidence can be generated to confirm that the data is included within the structure.

The use of Merkle trees and Merkle Patricia trees enhances the security of the Ethereum blockchain. By cryptographically hashing data at each level of the tree, it becomes nearly impossible to change the data without detection. Any change to a data point requires altering the corresponding hash value on the tree to the root hash, which is publicly visible in the blockchain header. This fundamental characteristic of the blockchain provides a high level of data integrity and immutability.

Furthermore, these trees can be effectively validated through inclusion proofs. For example, when verifying the inclusion of a transaction or the state of a contract, it is unnecessary to search the entire Ethereum blockchain; it suffices to verify the path within the relevant Merkle tree.

The storage proof defined by Herodotus is a fusion of the following:

• Inclusion proof: These proofs confirm the existence of specific data within cryptographic data structures (e.g., Merkle trees or Merkle Patricia trees), ensuring that the relevant data indeed exists within the dataset.

• Computation proof: Verifying the execution of multi-step workflows, proving the validity of one or more elements in extensive datasets, such as the entire Ethereum blockchain or rollup. In addition to indicating the existence of data, they also validate the transformations or operations applied to that data.

• Zero-knowledge proof: Simplifying the amount of data needed for smart contracts to interact. Zero-knowledge proofs allow smart contracts to confirm the validity of claims without processing all underlying data.

Workflow

1. Obtain Block Hash

Every piece of data on the blockchain belongs to a specific block. The block hash serves as the unique identifier for that block, summarizing all its contents through the block header. In the workflow of storage proof, the first step is to identify and verify the block hash of the block containing the data of interest, which is the primary step in the entire process.

2. Obtain Block Header

Once the relevant block hash is obtained, the next step is to access the block header. To do this, the block header associated with the previously obtained block hash needs to be hashed. Then, the hash of the provided block header is compared with the obtained block hash:

There are two ways to obtain the hash:

(1) Using the BLOCKHASH opcode to retrieve

(2) Querying the historical hashes of blocks that have been verified from the Block Hash Accumulator

This step ensures that the block header being processed is authentic. Once this step is completed, the smart contract can access any value within the block header.

3. Determine the Required Root (Optional)

With the block header, we can delve into its contents, particularly:

stateRoot: The cryptographic summary of the entire blockchain state at the time the block was created.

receiptsRoot: The cryptographic summary of all transaction results (receipts) within the block.

transactionsRoot: The cryptographic summary of all transactions that occurred within the block.

These can be decoded, allowing verification of whether a specific account, receipt, or transaction is included in the block.

4. Verify Data Based on the Selected Root (Optional)

With our selected root, and considering that Ethereum adopts the Merkle-Patricia Trie structure, we can utilize Merkle inclusion proofs to verify whether data exists within the tree. The verification steps will vary based on the data and the depth of the data within the block.

Currently Supported Networks:

• From Ethereum to Starknet

• From Ethereum Goerli* to Starknet Goerli*

• From Ethereum Goerli* to zkSync Era Goerli*

Axiom

Axiom provides a way for developers to query block headers, accounts, or storage values from the entire history of Ethereum. AXIOM introduces a new method based on cryptographic links. All results returned by Axiom are verified on-chain through zero-knowledge proofs, meaning that smart contracts can use them without any additional trust assumptions.

Axiom recently released Halo2-repl, a browser-based REPL for halo2 written in Javascript. This allows developers to write ZK circuits using standard Javascript without needing to learn new languages like Rust, install proof libraries, or manage dependencies.

Axiom consists of two main technical components:

• AxiomV1—Ethereum blockchain cache from Genesis onward.
• AxiomV1Query—Smart contracts that execute queries against AxiomV1.

(1) Caching Block Hashes in AxiomV1:

The AxiomV1 smart contract caches Ethereum block hashes since the genesis block in two forms:

First, it caches the Keccak Merkle root of the last 1024 block hashes. These Merkle roots are updated through ZK proofs, verifying whether the block header hash forms a commitment chain ending in one of the last 256 blocks directly accessible by EVM or a block hash already present in the AxiomV1 cache.

Secondly, Axiom stores the Merkle Mountain Range of these Merkle roots starting from the genesis block. This Merkle Mountain Range is built on-chain by updating the cached first part of Keccak Merkle roots.

(2) Fulfilling Queries in AxiomV1Query:

The AxiomV1Query smart contract is used for batch queries, enabling trustless access to any data regarding historical Ethereum block headers, accounts, and account storage. Queries can be executed on-chain and completed on-chain through ZK proofs conducted against the cached block hashes in AxiomV1.

These ZK proofs check whether the relevant on-chain data is directly located within the block header or within the account or storage Trie of the block, achieved by verifying the inclusion (or non-inclusion) proofs of the Merkle-Patricia Trie.

Nexus

Nexus aims to leverage zero-knowledge proofs to build a universal platform for verifiable cloud computing. It is currently machine architecture agnostic, supporting RISC 5/WebAssembly/EVM. Nexus utilizes the Supernova proof system, with the team testing that the memory required to generate proofs is 6GB, and further optimizations will be made to enable ordinary user devices to generate proofs.

Specifically, the architecture is divided into two parts:

• Nexus Zero: A decentralized verifiable cloud computing network supported by zero-knowledge proofs and a general zkVM.

• Nexus: A decentralized verifiable cloud computing network driven by multi-party computation, state machine replication, and a general WASM virtual machine.

Nexus and Nexus Zero applications can be written in traditional programming languages, currently supporting Rust, with plans to support more languages in the future.

Nexus applications run on a decentralized cloud computing network, which is essentially a general "serverless blockchain" directly connected to Ethereum. Therefore, Nexus applications do not inherit Ethereum's security, but in exchange, they can achieve higher computational power (such as computation, storage, and event-driven I/O) due to the reduced scale of their network. Nexus applications run on a dedicated cloud that can achieve internal consensus and provide verifiable computation "proofs" (rather than actual proofs) through Ethereum's internally verifiable global threshold signatures.

Nexus Zero applications do inherit Ethereum's security because they are general programs with zero-knowledge proofs that can be verified on-chain on the BN-254 elliptic curve.

Since Nexus can run any deterministic WASM binary in a replicated environment, it is expected to serve as a source of validity/diversity/fault tolerance for proof generation applications, including zk-rollup sequencers, optimistic rollup sequencers, and other provers, such as the zkVM of Nexus Zero itself.