ABCDE Research Report: In-Depth Analysis of Coprocessors and Solutions from Various Providers
TechFlow Selected TechFlow Selected
ABCDE Research Report: In-Depth Analysis of Coprocessors and Solutions from Various Providers
Systematically organize a technical solution comparison of several companies in the co-processor sector currently on the market, aiming to provide the market and users with a clearer understanding of the co-processor赛道.
Navigating Web3 tides with focused insightsAuthors: Kris & Laobai ABCDE / Mo Dong Celer Network
With the recent surge in interest around the concept of coprocessors, this new use case for ZK technology is gaining increasing attention.
However, we've observed that most people still have a relatively vague understanding of what a coprocessor actually is—especially regarding its precise positioning. What exactly is (and isn't) a coprocessor? Moreover, there hasn't yet been a systematic comparison of the technical approaches taken by various teams in this space. This article aims to provide the market and users with a clearer picture of the coprocessor landscape.
1. What Is a Coprocessor—and What It Is Not?
If you had to explain coprocessors in just one sentence to someone who isn’t technical or a developer, how would you do it?
In our view, Dr. Mo Dong’s description may be very close to the ideal answer: “A coprocessor, at its core, gives smart contracts the capabilities of Dune Analytics.”
What does this mean?
Imagine using Dune: You want to become an LP on Uniswap V3 to earn trading fees, so you open Dune and check recent trading volumes across different pairs, 7-day APRs for fees, price fluctuation ranges for major pairs, etc.
Or when StepN was booming, you started flipping sneakers and weren’t sure when to exit. So every day you monitored StepN data on Dune—daily trading volume, number of new users, sneaker floor prices—planning to sell immediately if growth slowed or prices began falling.
Of course, you’re not alone. The development teams behind Uniswap and StepN likely watch these same metrics closely.
These data points are highly meaningful—not only can they help identify trends, but they also enable more advanced applications, much like how big tech companies leverage “big data” today.
For example, recommend similar sneakers based on a user's purchase history.
Launch a “loyalty rewards program” offering extra airdrops or benefits to users who’ve held Genesis sneakers for a long time.
Introduce a CEX-style VIP tier based on a trader’s volume or an LP’s TVL, granting fee discounts or increased fee shares...
Here’s the problem: In Web2, big tech uses big data and AI in opaque ways—black boxes where users neither see nor care about the inner workings.
But in Web3, transparency and trustlessness are fundamental values—we reject black boxes!
So when trying to implement such scenarios, you face a dilemma: Either go centralized—manually pulling index data via Dune in the backend and acting on it—or write a smart contract to automatically fetch and compute data on-chain.
The first approach introduces trust issues—politically incorrect in Web3.
The second leads to astronomical gas costs—likely unaffordable for any project team.
This is where coprocessors come in: Combine both methods, but replace the manual step with a cryptographic self-audit. Specifically, use ZK technology to prove the integrity of off-chain indexing and computation, then feed the results into smart contracts. Trust issues resolved, gas costs eliminated—perfect!
Why call it a "coprocessor"? The term comes from Web2 computing history—the GPU. GPUs were introduced as separate hardware because their architecture excels at tasks CPUs struggle with—massive parallelism, graphics rendering, etc. This architectural leap enabled modern CGI films, games, and AI models. Similarly, coprocessor teams aim to bring this paradigm to Web3: blockchains act as the CPU (L1 or L2), inherently ill-suited for heavy data processing or complex computations. A blockchain coprocessor handles these workloads, dramatically expanding what blockchain applications can achieve.
To summarize, a coprocessor does two things:
-
Fetch data from the blockchain and generate a ZK proof verifying its authenticity—no tampering;
-
Perform computations on that data and generate another ZK proof confirming the correctness of the result. The final output can then be used by smart contracts in a low-cost, trustless manner.
Recently, Starkware popularized a concept called Storage Proof (or State Proof), which essentially covers Step 1. Projects like Herodotus and Lagrange fall into this category. Many ZK-based cross-chain bridges also focus primarily on Step 1.
A coprocessor simply adds Step 2—performing verifiable computation after trustlessly extracting data.
More technically speaking, a coprocessor is a superset of Storage Proof/State Proof and a subset of Verifiable Computation.
One key point: A coprocessor is NOT a Rollup.
Technically, a Rollup’s ZK proof resembles Step 2 above. However, Step 1—fetching data—is handled directly by the Sequencer. Even decentralized sequencers rely on consensus or competition mechanisms rather than ZK-based proofs like Storage Proof. More importantly, ZK Rollups require a persistent storage layer akin to an L1 blockchain, while ZK Coprocessors are stateless—they discard all intermediate states after completing computations.
From an application perspective, a coprocessor acts as a service plugin for any L1/L2, whereas a Rollup creates a new execution layer to scale settlement capacity.
2. Why ZK? Can We Use OP Instead?
After reading the above, you might wonder: Must coprocessors use ZK? Doesn’t this sound like “Graph with ZK”? And we don’t seem to distrust Graph’s outputs too much.
True—but only because typical Graph usage doesn’t involve real financial stakes. Indexing serves off-chain services: front-end displays of trading volume, transaction history, etc., can pull from multiple providers like Graph, Alchemy, or Zettablock. But feeding this data back into smart contracts introduces additional trust assumptions. When data affects real money—especially large TVLs—this added trust becomes critical. Lending someone $100? No big deal. What about $10,000 or $1 million?
That said, must every coprocessor scenario require ZK? After all, Rollups have both OP and ZK paths. Recently, even ZKML has inspired proposals for OPML. So could there be an OP-based coprocessor branch—say, OP-Coprocessor?
Actually, yes—it exists. But we’ll keep specifics under wraps for now. More details coming soon.
3. Which Coprocessor Stands Out? A Comparison of Major Technical Approaches
Brevis
Brevis’ architecture consists of three components: zkFabric, zkQueryNet, and zkAggregatorRollup.
Below is a diagram of Brevis' architecture:
zkFabric: Collects block headers from all connected blockchains and generates ZK consensus proofs verifying their validity. This enables multi-chain interoperable coprocessing—allowing one blockchain to access arbitrary historical data from another.
zkQueryNet: An open marketplace of ZK query engines that accept and process data queries from dApps. Queries are processed using verified block headers from zkFabric and produce ZK query proofs. These engines support both specialized functions and general-purpose query languages to meet diverse application needs.
zkAggregatorRollup: A ZK aggregating blockchain that serves as the aggregation and storage layer for zkFabric and zkQueryNet. It verifies proofs from both components, stores validated data, and submits zk-verified state roots to all connected chains.
As the core component generating block header proofs, securing zkFabric is crucial. Below is its architecture:
zkFabric employs a zero-knowledge proof (ZKP)-based light client, making it fully trustless without relying on external validators. Its security stems entirely from the underlying blockchain and mathematically sound proofs.
The zkFabric Prover Network implements circuits for each blockchain’s light client protocol, generating validity proofs for block headers. Provers can leverage accelerators like GPU, FPGA, and ASIC to minimize proof generation time and cost.
zkFabric relies on the security assumptions of the underlying blockchain and cryptographic protocols. To ensure validity, at least one honest relay must sync the correct fork. Thus, zkFabric uses a decentralized relay network instead of a single relay, leveraging existing infrastructures like Celer Network’s State Guardian Network.
Prover Assignment: The prover network is a decentralized ZKP network that selects provers for each proof-generation task and pays them accordingly.
Current Deployment:
Light client protocols have been implemented for various blockchains—including Ethereum PoS, Cosmos Tendermint, and BNB Chain—as examples and proofs of concept.
Brevis is currently collaborating with Uniswap Hooks. While Hooks greatly expand custom pool functionality, Uniswap still lacks efficient data processing features comparable to CEXs—such as loyalty programs based on trading volume.
With Brevis, this challenge is addressed. Hooks can now read complete historical chain data for users or LPs and run customizable computations in a fully trustless manner.
Herodotus
Herodotus is a powerful data access middleware that enables smart contracts to synchronously access 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 introduced the concept of Storage Proof, combining inclusion proofs (confirming data existence) and computation proofs (verifying execution of multi-step workflows) to prove the validity of one or more elements within large datasets—such as an entire Ethereum blockchain or rollup.
At its core, a blockchain is a database secured via cryptographic data structures like Merkle trees and Merkle Patricia trees. Once data is committed securely, evidence can be generated proving its inclusion in the structure.
Merkle and Merkle Patricia trees enhance Ethereum’s security. By cryptographically hashing data at each level of the tree, altering data undetected becomes nearly impossible. Any change requires updating corresponding hashes up to the root hash, which is publicly visible in the block header. This fundamental feature ensures high data integrity and immutability.
Moreover, these trees allow efficient data verification through inclusion proofs. For instance, verifying a transaction’s inclusion or a contract’s state doesn’t require scanning the entire blockchain—only validating the relevant path within the Merkle tree.
Herodotus defines Storage Proof as a fusion of the following:
-
Inclusion Proofs: Confirm the presence of specific data within encrypted structures like Merkle or Merkle Patricia trees, ensuring the data truly exists in the dataset.
-
Computation Proofs: Verify the execution of multi-step workflows, proving the validity of one or more elements within vast datasets (e.g., the entire Ethereum blockchain or a rollup). Beyond mere existence, they validate transformations or operations applied to the data.
-
Zero-Knowledge Proofs: Reduce the amount of data smart contracts need to interact with. ZKPs allow contracts to confirm claim validity without processing all underlying data.
Workflow:
1. Obtain Block Hash
Every piece of data on a blockchain belongs to a specific block. The block hash uniquely identifies the block and summarizes its contents via the block header. In the Storage Proof workflow, identifying and verifying the block hash containing the desired data is the first step.
2. Retrieve Block Header
Once the relevant block hash is obtained, the next step is accessing the block header. This involves hashing the block header associated with the retrieved block hash, then comparing the computed hash against the known block hash.
Block hashes can be obtained in two ways:
(1) Using the BLOCKHASH opcode to retrieve it
(2) Querying the Block Hash Accumulator for historically verified block hashes
This step ensures the block header being processed is authentic. Once completed, smart contracts can access any value within the block header.
3. Determine Required Root (Optional)
With the block header, we can examine its contents in detail:
stateRoot: A cryptographic digest summarizing the entire blockchain state at the time of the block.
receiptsRoot: A cryptographic digest of all transaction outcomes (receipts) in the block.
transactionsRoot: A cryptographic digest of all transactions included in the block.
These roots can be decoded to verify whether a specific account, receipt, or transaction is included in the block.
4. Validate Data Based on Selected Root (Optional)
With the selected root and given Ethereum’s use of Merkle-Patricia Trie structures, Merkle inclusion proofs can verify the presence of data in the tree. The verification process varies depending on the data type and depth 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 enables developers to query block headers, account balances, or storage values from Ethereum’s entire history. All results returned by Axiom are verified on-chain via zero-knowledge proofs, meaning smart contracts can use them without additional trust assumptions.
Axiom recently launched Halo2-repl, a browser-based Halo2 REPL written in JavaScript. This allows developers to write ZK circuits using standard JavaScript—no need to learn Rust, install proof libraries, or manage dependencies.
Axiom consists of two main technical components:
- AxiomV1 — An Ethereum blockchain cache starting from Genesis.
- AxiomV1Query — Smart contracts that execute queries against AxiomV1.
(1) Caching Block Hashes in AxiomV1:
The AxiomV1 smart contract caches Ethereum block hashes since genesis in two forms:
First, it stores Keccak Merkle roots of consecutive 1024-block hash batches. These Merkle roots are updated via ZK proofs, verifying that block header hashes form a commitment chain ending in either one of the EVM-accessible latest 256 blocks or a block hash already present in the AxiomV1 cache.
Second, Axiom stores a Merkle Mountain Range (MMR) of these Merkle roots, built on-chain by updating the first part’s Keccak Merkle roots.
(2) Fulfilling Queries in AxiomV1Query:
The AxiomV1Query smart contract enables batch queries for trustless access to arbitrary historical Ethereum block headers, accounts, and storage data. Queries are executed on-chain and finalized via ZK proofs against block hashes cached in AxiomV1.
These ZK proofs verify whether the relevant on-chain data resides directly in the block header or within the block’s account or storage trie, using Merkle-Patricia Trie inclusion (or non-inclusion) proofs.
Nexus
Nexus aims to build a universal platform for verifiable cloud computing using zero-knowledge proofs. Currently machine architecture agnostic, supporting RISC-V, WebAssembly, and EVM. Nexus uses the Supernova proof system; the team reports that proof generation currently requires 6GB of memory, with plans to optimize further so that average consumer devices can generate proofs.
Specifically, the architecture has two parts:
-
Nexus Zero: A decentralized, verifiable cloud computing network powered by zero-knowledge proofs and a general-purpose zkVM.
-
Nexus: A distributed, verifiable cloud computing network driven by multi-party computation, state machine replication, and a general WASM virtual machine.
Nexus and Nexus Zero apps can be written in traditional programming languages—currently Rust, with more to follow.
Nexus applications run on a decentralized cloud network—a kind of general-purpose “serverless blockchain” directly connected to Ethereum. Thus, Nexus apps do not inherit Ethereum’s security. In exchange, they gain higher computational power (computation, storage, event-driven I/O) due to smaller network scale. Nexus apps run on dedicated clouds that reach internal consensus and provide verifiable computation “proofs” (not full proofs) via threshold signatures verifiable on Ethereum.
Nexus Zero applications do inherit Ethereum’s security, as they are general-purpose programs with zero-knowledge proofs, verifiable on-chain over the BN-254 elliptic curve.
Since Nexus can run any deterministic WASM binary in a replicated environment, it’s expected to serve as a source of validity, decentralization, and fault tolerance for proof-generating applications—including zk-rollup sequencers, optimistic rollup sequencers, and even Nexus Zero’s own zkVM.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
ABCDE
