ZK Coprocessors from 0 to 1: Beyond the Data-Driven Paradigm, Pioneering Web3 Asynchronous Models
TechFlow Selected TechFlow Selected
ZK Coprocessors from 0 to 1: Beyond the Data-Driven Paradigm, Pioneering Web3 Asynchronous Models
ZK coprocessors enable blockchains to delegate such data-intensive and tedious computations, quickly obtaining results at low cost without requiring any additional trust assumptions.
Navigating Web3 tides with focused insightsZK coprocessors represent an exciting innovation in the blockchain space. Pioneered by projects such as Brevis, Axiom, Lagrange, and Herodotus, they promise to revolutionize how we build applications on blockchains. With ZK coprocessors, developers can create data-driven dApps that leverage historical omnichain data to perform complex computations—without relying on any additional trust assumptions. More importantly, they enable a new development paradigm: asynchronous application architecture, bringing unprecedented efficiency and scalability to Web 3.0 software frameworks.
In this series, we will demystify ZK coprocessors. Whether you're interested in their underlying concepts, real-world use cases, core mechanisms, challenges, market strategies, or comparing different projects, we hope these articles will offer fresh insights.
The Missing VIP Trader Program on DEXs
To understand the fundamental idea behind ZK coprocessors, let’s begin with a real-world incentive example.
One clear difference between centralized exchanges (CEXs) and decentralized exchanges (DEXs) is the presence of volume-based fee tiers—commonly known as “VIP trader loyalty programs.” These programs are powerful tools for retaining traders, boosting liquidity, and ultimately increasing exchange revenue.
Interestingly, while every major CEX offers at least one such program, DEXs have none. Why?
Because implementing such a feature on a DEX is significantly more challenging and costly than on a CEX.
On a CEX, implementing a loyalty program requires:
-
Recording all users’ trading history in a centralized database—a straightforward task that reduces future query costs.
-
Running a direct query once per month on a high-performance centralized database to determine each user’s trading volume and corresponding fee tier based on historical data.
However, DEXs face major hurdles when attempting the same approach:
-
Due to prohibitively high storage costs on blockchains, storing every user’s trading history directly in smart contracts is impractical. Implementing such logic would increase transaction fees per trade by up to 4x.
-
Even if transaction records were stored, the cost of querying and computing statistics over that data would be even higher. For instance, calculating trading volume across 10K transactions for a single user would cost 156M gas (yes, we’ve calculated it).
You might ask, “Wait, what are you talking about? On a blockchain, every transaction for every user is already automatically stored (it’s a blockchain!). Native smart contracts on-chain should be able to access all this data anytime, right?”
Unfortunately, no!
The data stored on a blockchain and the data accessible within blockchain virtual machines (like EVM) are entirely different things.
Full or archival nodes store vast amounts of historical blockchain data. Through these nodes, you can easily access:
-
The complete state of the blockchain at any given point in history (e.g., who was the first owner of a Cryptopunk).
-
Transactions and events generated by transactions at any point in time (e.g., Charlie exchanged $1,000 for 0.5 ETH).
Indeed, popular off-chain data indexing or analytics tools (such as Nansen and Dune Analytics) leverage this extensive dataset for deep analysis.
However, smart contracts embedded within blockchain virtual machines face far greater data access limitations. They cannot rely on data generated by off-chain indexing solutions because doing so introduces additional trust assumptions involving external—and often centralized—indexing systems.
In fact, smart contracts can only easily and trustlessly access the following types of data:
-
Data stored within the virtual machine state (excluding transaction or event data).
-
Data from the latest block (historical data access is restricted).
-
Data from other smart contracts exposed via "view" functions (excluding private or internal contract data).
A key nuance in the above statement lies in the word “easily.”
Smart contracts are not completely blind to all blockchain data. In the EVM, for example, contracts can access the block header hashes of the most recent 256 blocks. These headers encapsulate all activity on the blockchain up to the current block, condensed into 32-byte hashes using Merkle trees and Keccak hashing.
Compressed data can be decompressed... it's just not easy 😂
Imagine trying to trustlessly access specific past data—say, a particular token balance from two blocks ago—using only recent block headers. This method involves retrieving off-chain data from archival nodes, constructing Merkle proofs and block validity proofs to verify that the data existed on-chain, and then having the EVM verify those proofs. Such operations are extremely cumbersome and expensive—retrieving just a few historical token balances could consume tens of millions of gas.
The root of this challenge is that blockchain virtual machines themselves lack the capability to handle large-scale, computation-intensive tasks like the decompression described above.
ZK Coprocessor Architecture
(Source: Brevis presentation slides at ETHSG)
What if there were a way for blockchains to delegate such data-intensive, tedious computations—quickly receiving results at low cost, without introducing any additional trust assumptions?
Well, friend, that’s exactly what ZK coprocessors are for.
The term “coprocessor” draws inspiration from computer architecture history. For example, GPUs were introduced as coprocessors to CPUs because CPUs needed to offload certain expensive but critical computations—like graphics rendering or AI training—to auxiliary processors, i.e., GPUs.
But what does the “ZK” in ZK coprocessor mean? Before diving into technical details, let’s explore the broader significance and potential of this innovation.
We Need Data-Driven dApps in Web 3.0
Fee rebates are a perfect example. With ZK coprocessors, various loyalty programs could be seamlessly introduced across DeFi protocols.
But it goes far beyond DeFi loyalty programs. You may now see that similar problems exist across other areas of Web 3.0. Consider this: all modern Web 2.0 applications are data-driven, yet Web 3.0 applications are universally not. To build “killer apps” with user experiences comparable to traditional internet apps, such data-driven approaches are essential.
Let’s examine another example in DeFi: improving capital efficiency through redesigned liquidity mining incentives.
Currently, liquidity incentives on AMM DEXs follow a “pay-as-you-go” model. Liquidity providers (LPs) receive farming rewards immediately upon depositing liquidity. However, this model is far from optimal. Sophisticated farmers can quickly withdraw their liquidity when sensing market volatility, avoiding impermanent loss. As a result, they provide minimal value to the protocol while still earning substantial rewards.
An ideal AMM liquidity incentive mechanism would retrospectively assess LP commitment—especially during periods of significant market fluctuation. Those who consistently support the pool during turbulent times should receive the highest rewards. Yet, accessing the historical behavioral data required for such a model remains infeasible today.
To achieve this, you need a ZK coprocessor.
In DeFi alone, we can cite numerous similar examples—ranging from proactive LP position management using predefined algorithms, establishing credit lines based on non-tokenized liquidity positions, to dynamically adjusting loan collateral preferences based on repayment history.
Yet, the potential of ZK coprocessors extends well beyond DeFi.
Building Chain-Based Games with Superior UX Using ZK Coprocessors
Example of Real-Time Operations in Web 2.0 Games
When you start playing a newly installed Web 2.0 game, every action you take is meticulously recorded. This data isn’t idle—it shapes your entire gaming journey. It determines when to offer in-game purchases, when to launch reward events, when to send carefully crafted push notifications, and which opponents to match you with. These elements form what the gaming industry calls LiveOps (Live Operations), a cornerstone of player engagement and monetization.
To make fully on-chain games competitive with Web 2.0 classics in terms of user experience, such LiveOps features are essential. And these features must be based on players’ historical interactions and transactions with game smart contracts.
Unfortunately, in blockchain gaming, such capabilities are either entirely missing or still driven by centralized solutions. The reason is the same as in the DEX example: difficulty in mining and computing historical gameplay data on-chain.
Yes, again—you need a ZK coprocessor to make this possible.
Web 3.0 social and identity applications are another domain that cannot function effectively without ZK coprocessors.
In the blockchain world, your digital identity is a web woven from your past actions.
-
Want to prove you’re an NFT OG? Prove you were one of the original minters of a Cryptopunk.
-
Boasting about being a big trader? Prove you’ve paid over $1M in trading fees on DEXs.
-
Claiming closeness to Vitalik? Prove his address has sent funds to yours.
Off-chain systems—whether human analysts or Web 2.0 apps—can easily generate such proofs because, like the trading volume example, they can access archival nodes containing all relevant data.
Such direct data access enables strong wallet-address associations, though it comes at the cost of privacy. But it works.
However, just as in the trading volume case, if you want a smart contract to trust your OG status and grant you early access to new features—without introducing third-party attestations—there’s currently no viable way.
With a ZK coprocessor, you can generate a credible proof of identity—a verifiable claim about your past behavior—that any smart contract will accept without question. Interactions across different apps and even different blockchains can be elegantly aggregated into a single proof.
Even more compelling is the inherent privacy offered by ZK. Your wallet address doesn’t need to be publicly linked to your identity. For example, you can prove ownership of a Cryptopunk NFT without revealing your wallet address. Or prove you’ve executed 10,000 trades on Uniswap without disclosing the exact number.
ZK coprocessors open up an entirely new frontier for building data-driven dApps—but their impact goes much deeper.
Beyond the Data-Driven Paradigm: Pioneering Web 3.0 Asynchronous Architectures with ZK Coprocessors
The data-driven dApp paradigm, while compelling, is merely the tip of the iceberg.
The emergence of ZK coprocessors will fundamentally shift how we think about blockchain computation, ushering in an era where asynchronous processing becomes the standard for Web 3.0. This transformation redefines how tasks are handled—enabling specialized processors to operate independently and dramatically improving efficiency.
Let’s first understand what asynchronous processing means.
Imagine a synchronous restaurant where one person acts as both chef and waiter. You place your order, and they start cooking, making you wait. Only after serving your meal can they attend to the next customer. While this setup might work, it’s inefficient for handling multiple customers.
In contrast, an asynchronous restaurant employs separate chefs and waiters. After taking your order, the waiter immediately passes it to the kitchen and moves on to serve others. When the dish is ready, the chef signals the waiter, who then delivers it to you.
In computing systems:
Synchronous architectures resemble the first restaurant—one process waits for each task to complete before proceeding. Simple and straightforward, but potentially slow, as only one task is processed at a time. And that person might be a great server but a poor cook.
Asynchronous architectures resemble the second restaurant, with decoupled, specialized components communicating via messages. Each component manages its own queue of tasks concurrently. Though requiring more sophisticated coordination, this architecture is faster and far more efficient.
Every modern internet application is built on asynchronous architecture to achieve efficiency and scalability—and we believe Web 3.0 should be no different.
ZK coprocessors will lead this transformation. For dApp developers, the blockchain acts like the waiter in our asynchronous restaurant—it handles computations that directly alter blockchain state, such as conditional asset transfers. All other computations should be delegated to robust ZK coprocessors, which act like expert chefs, efficiently preparing results asynchronously and delivering them back to the waiter.
Specifically, ZK coprocessors should be considered whenever a computation in a blockchain application meets either of the following two “viability conditions.”
ZK Coprocessor Viability Conditions:
-
On-chain computation cost > (Off-chain ZK coprocessor computation (including proof generation) + On-chain verification cost)
-
On-chain computation latency > (Off-chain ZK coprocessor computation (including proof generation) + On-chain verification latency)
Meeting just one of these conditions is enough to warrant consideration!
Now you can see—it’s not just about data-driven dApps! It’s a completely new way to bring high-level general-purpose computation like ML onto blockchains. More importantly, it introduces a transformative asynchronous architecture for building dApps—something previously impossible.
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
IOSG Ventures
