IOSG Ventures: ZK coprocessor goes from 0 to 1, what can it do?
Original author: IOSG Ventures
Thanks to Mr. Mo Dong from Celer Network and Brevis for his in-depth discussions on the core concepts and use cases of the ZK coprocessor. These thoughts inspired the creation of this series of articles.
The ZK coprocessor is an exciting innovation in the blockchain space. Pioneered by projects such as Brevis, Axiom, Lagrange and Herodotus, it promises to revolutionize the way we develop applications on the blockchain. With the ZK coprocessor, developers can create data-driven dApps that can leverage the history of omnichain data to perform complex calculations without relying on any additional trust assumptions. More importantly, it leads to a new development model: asynchronous application architecture, which brings unprecedented efficiency and scalability to the Web 3.0 software framework.
In this series of articles, we will demystify the ZK coprocessor. Whether you are interested in its concepts, practical applications, basic mechanisms, challenges, or market strategies, or want to compare different projects, we hope these articles can bring you new inspiration.
The case for missing VIP trader programs on DEX
To understand the basic idea of the ZK coprocessor, we need to start with motivating real-world examples.
One clear difference between centralized exchanges (CEX) and decentralized exchanges (DEX) is the existence of volume-based fees, commonly known as “VIP trader loyalty programs.” These programs are powerful tools for retaining traders, increasing liquidity, and ultimately increasing exchange revenue.
Interestingly, while every CEX has at least one such project, DEX has none at all. why?
This is because implementing this functionality in a DEX is more challenging and costly than in a CEX.
In CEX, implementing a loyalty program requires:
Recording the transaction history of all users in a centralized database – a task that facilitates reducing the cost of future queries.
Direct queries are executed monthly in a high-performance centralized database to determine each users transaction volume and fee tier based on historical data.
However, DEXs face significant challenges when trying to follow the same steps:
Due to the high storage cost of blockchain, it is not feasible to directly store each user’s transaction history in smart contracts. Implementing this logic means that users pay 4x higher fees per transaction.
Even if we have data storage of transaction records, the cost of statistical queries and calculations on this data is higher. For example, calculating the transaction volume data for 10 K transactions for a single user will cost 156 M Gas (yes! we calculated it).
You might be saying “Wait, what the hell are you talking about? On the blockchain, every transaction for every user is automatically stored (because it’s a blockchain!).” Homegrown Intelligence on the Blockchain The contract, should have ready access to all this data, right?
Sorry, no!
The data stored in the blockchain and the data accessible by smart contracts in the blockchain virtual machine are completely different things.
For the full/archive nodes of the blockchain, they store a large amount of data from the history of the blockchain. These nodes provide you with easy access to:
The state of the entire blockchain at any given time in history (e.g., who was the first owner of Cryptopunk).
Transactions and events resulting from transactions at any given time in history (for example, Charlie exchanged $1,000 for 0.5 ETH).
In fact, popular off-chain data indexing or analysis tools such as Nansen and Dune Analytics can leverage this extensive data set for in-depth analysis.
However, for smart contracts embedded in blockchain virtual machines, data access restrictions are much greater. They cannot use data generated by off-chain indexing solutions as this would create additional trust issues for these external and often centralized indexing solutions.
In fact, smart contracts can only easily and trustlessly access the following data:
Data stored in the virtual machine state (not including transaction or event data).
Data in the latest block (historical data access is restricted).
Data from other smart contracts exposed through the View function (excluding private or internal contract data).
A key nuance in the above statement is the word easy.
Smart contracts are not completely unaware of all data on the blockchain. In the EVM, smart contracts can access the block header hashes of the latest 256 blocks. These block headers include all activity on the blockchain up to the current block, condensed into a 32-byte hash value through Merkle trees and Keccak hashes.
Compressed stuff can be decompressed...its just not easy😂
Imagine if you wanted to trustlessly access specific data in the previous block using the most recent block header. This approach involves obtaining off-chain data from archive nodes and then constructing Merkle trees and block validity proofs to determine the authenticity of the data in the blockchain. The validity proof is then processed by the EVM for verification and interpretation. Such an operation is cumbersome and arduous, and may consume tens of millions of Gas just to retrieve the past few token balances.
The root of this challenge is that the blockchain virtual machine itself does not have the ability to handle large amounts of data and intensive calculations (such as the decompression task mentioned above).
ZK coprocessor architecture
(Source: Brevis’ presentation slides at ETHSG)
It would be ideal if there was a magic that allowed the blockchain to delegate such data-intensive and tedious calculations and get the results quickly, at low cost, and without any additional assumptions of trust.
Friends, thats what the ZK coprocessor is for.
The name coprocessor is inspired by the history of computer architecture. For example, the GPU was introduced as a co-processor of the CPU because the CPU must delegate certain important computing tasks (such as graphics computing or artificial intelligence training) that are expensive and difficult to run on its own to the auxiliary processor, that is, the GPU.
But what does the ZK in ZK coprocessor mean? Before we dive into the complex technical details, let’s take a look at the broader implications and potential of this innovative technology.
We need data-driven dApps in Web 3.0
Trading fee rebates are a good example. Following this idea, with the ZK coprocessor, various loyalty programs can be seamlessly introduced into many DeFi protocols.
However, this is much more than a DeFi loyalty program. You can probably see by now that the same problem exists in other areas of Web 3.0. If you think about it, all modern Web 2.0 applications are data-driven, but Web 3.0 applications are no exception. This data-driven approach is indispensable if we want to create a killer application and make the user experience comparable to traditional Internet applications.
Let’s look at another example from the DeFi space: improving liquidity efficiency by redesigning the liquidity mining reward mechanism.
Currently, the liquidity incentive mechanism on AMM DEX adopts a “pay-as-you-go” model. In this mode, Farming rewards are immediately distributed to LPs when they contribute liquidity. However, this model is far from optimal. Professional Farmers can quickly withdraw liquidity when they sense market fluctuations to avoid impermanent losses. In this way, they provide minimal value to the protocol but still receive significant returns.
An ideal AMM liquidity incentive mechanism would retrospectively evaluate the LPs firmness, especially during periods of significant market volatility. Those who always support the pool in this situation should receive the highest rewards. However, obtaining historical LP behavioral data, which is crucial for this model, is still not feasible today.
To do this, you need the ZK coprocessor.
In the DeFi space, we can cite many similar examples, whether it is using predetermined algorithms and rules for active LP position management, using non-token liquidity positions to establish credit lines, or determining dynamic liquidation preferences for loans based on past repayment behavior .
However, the potential of the ZK coprocessor is not limited to DeFi.
Use ZK coprocessor to create on-chain games with excellent user experience
Web 2.0 game real-time operation function example
When you enter a newly installed Web 2.0 game, your every move will be recorded in detail. These data will not be idle, but will greatly affect your gaming journey. It decides when to offer you in-game purchase options, when to launch bonus games, when to send you carefully worded push notifications with opponents you’re matched with, and more. These are all components of what the gaming industry calls real-time operations (LiveOps) and are the cornerstones of increasing player engagement and revenue streams.
These LiveOps features are needed to make the user experience of fully on-chain games comparable to Web 2.0 classic games. These features should be based on players’ historical interactions and transactions with the game’s smart contracts.
Unfortunately, in blockchain games, such functionality is either completely missing or still driven by centralized solutions. The reason is the same as the DEX example: it is difficult to mine and calculate historical game data on the blockchain.
Yes, again, you need the ZK coprocessor to achieve this.
Web 3.0 social and identity applications are another area that cannot run without ZK coprocessor support.
In the blockchain world, your digital identity is a web woven from your past actions.
Want to prove that you are an NFT OG? You have to prove that you are one of the original miners of Cryptopunk.
Bragging about being a great trader? Prove to me that you paid over $1 million in trading fees on DEX.
Close relationship with Vitalik? Prove to me that his address sent funds to your address.
Off-chain systems, whether humans or Web 2.0 applications, can easily generate such proofs because, like the transaction volume example, they have access to archive nodes that contain all this data.
Proof of identity based on this direct data access requires strong wallet address association and therefore suffers from the disadvantage of sacrificing privacy, but it is feasible.
However, just like in the transaction volume example, if you want the smart contract to trust your OG identity and get early access to some new stuff without introducing additional proof of trust, there is no good way at all.
With the ZK coprocessor, you can weave a reliable proof of identity, a proof of your past actions, a proof that any smart contract will accept without question. Your interactions across different applications and even different blockchains can be neatly combined to form this proof.
What is even more attractive is the inherent privacy of ZK. Your wallet address does not have to be publicly associated with your identity. For example, you can prove that you own a Cryptopunk NFT without revealing a specific wallet address. Alternatively, you can prove that you performed 10,000 transactions on Uniswap without disclosing the exact number.
The ZK coprocessor opens up a whole new realm of data-driven dApp building, but it’s much more than that.
Beyond the data-driven paradigm: Using ZK coprocessor to create asynchronous mode for Web 3.0
The data-driven dApp model, while attractive, is just the tip of the iceberg.
The emergence of the ZK coprocessor will completely change our view of blockchain computing and create an era in which asynchronous processing becomes a Web 3.0 standard. This shift redefines how tasks are handled, with specialized processors able to operate independently, increasing efficiency.
Let us first understand what asynchronous processing is.
Imagine a synchronized restaurant where one person plays the role of chef and waiter at the same time. When you order something, he starts preparing it and makes you wait. He can only wait for another customer after serving you. While this setup may suit your needs, it may be difficult to be efficient for others.
In contrast, in an asynchronous restaurant, different chefs and different servers work together. After the waiter takes your order, he will quickly transfer it to the chef while serving other customers. When the dish is done, the chef signals to the waiter, who then serves you the dish.
In a computer system:
Synchronous architecture is like the first restaurant where one person waits for each task to be completed before continuing. This architecture is simple and straightforward, but can be slow because it only handles one task at a time. Also, this person may be a good waiter but not a good cook.
Asynchronous architecture is like a second restaurant where there are decoupled and specialized system components that send information and tasks to each other as a way of coordination. This allows each component to manage its own line of tasks simultaneously. Although it may require more complex management methods, this architecture is faster and more efficient.
Every modern internet application is built on an asynchronous architecture for efficiency and scalability, and we think Web 3.0 should be too.
The ZK coprocessor will be the harbinger of this change. For dApp developers, the blockchain is like the waiter in our asynchronous restaurant. It mainly handles computations that directly change the state of the blockchain, such as contingent asset ownership changes. All other calculations are handled by the robust ZK coprocessors, which, like master chefs, use the power of asynchronous processing to efficiently cook up the results and send them to the waiter.
Specifically, if the calculations in blockchain applications meet one of the following two feasibility conditions, you should consider using the ZK coprocessor.
ZK coprocessor executable conditions:
On-chain computing cost > (off-chain ZK coprocessor calculation (including proof generation) + on-chain verification cost)
On-chain calculation delay > (off-chain ZK coprocessor calculation (including proof generation) + on-chain verification delay)
Even if they only qualify for one of these, its worth considering!
Now you can see that its not just data-driven dApps! It is a completely new way to bring high-level general-purpose computing such as ML to the blockchain, but more importantly, it introduces a paradigm-changing asynchronous architecture for building dApps that was simply not possible before.
Next chapter….
If weve successfully convinced you that ZK coprocessors are an idea that will have far-reaching consequences, it might be time to talk about how they work. In the next blog, we will explore the key architecture of the ZK coprocessor and discuss the biggest technical challenges that remain in this area.
