Introduction to ZK Co-Processor: Enhancing User Experience of Blockchain Products through Data

EigenLayer is an AVS (Application-Specific Verification System) in the ecosystem, with its highlight being the provision of a decentralized ZK (Zero-Knowledge) coprocessor. But what is a ZK coprocessor? Why is it said to truly enhance the efficiency of blockchain? Aren’t Rollups enough? This article will provide a brief introduction.

Table of Contents
Toggle
What problem does the ZK coprocessor aim to solve?
Use case: Product data collection and computation
Problem 1: Blockchain virtual machines are not suitable for heavy computation
Problem 2: Applying external data has trust assumptions
The dilemma of Web3 data
Introduction to the ZK coprocessor
Separating the computation work from the EVM (Ethereum Virtual Machine)
How does the ZK coprocessor avoid the aforementioned problems?
The efficiency enhancement of the ZK coprocessor differs from Rollups
Introduction to ZK coprocessor implementation projects
Brevis
Axiom
ZK coprocessor is not the only solution
Existing Web3 products always seem to lack certain features compared to Web2 products, such as automated recommendations, loyalty programs, precision marketing, etc. These are standard features that have been in traditional software for years. Why haven’t we seen them in Web3 products?

To give a more concrete example, when a user watches TV series on Netflix, the backend collects all the user’s viewing records and actions. By collecting this data and performing calculations through algorithms, the system can find content that the user may like and provide personalized recommendations and advertisements.

But in the Web3 ecosystem, if a user frequently trades stablecoins on Uniswap, exchanging USDT for USDC, why can’t Uniswap’s interface automatically display this frequently used trading pair for the user?

The problem lies in “data.” Web2 products can systematically collect and process data, such as collecting user viewing records. However, Web3 products cannot do the same, even for simple transaction records.

Some readers may ask, “Aren’t transaction records already on the blockchain? Why can’t they be read?” Actually, it is not possible, or more precisely, it is costly or risky to do so.

To achieve the aforementioned use case, many computational resources are needed. Taking Uniswap as an example, to achieve “displaying historical trading pairs on the homepage for users to complete their goals faster,” the following efforts would be required:

Collecting user transaction records
Comparing usage frequencies of various transaction records and selecting the highest one
Execution

The last step is generally well-implemented in smart contracts now. The problem lies in the first two steps.

Regarding the first step, although transaction records are indeed on the blockchain, the virtual machine and the blockchain’s historical ledger are two different things. The virtual machine requires a significant amount of gas fees to read the historical ledger. And every time it needs to be called, it needs to be reread or stored. But regardless of the approach, it is resource-intensive and not suitable for decentralized virtual machine usage.

The second step involves data processing. Although relatively simple, it also requires a large amount of resources to compute on top of the EVM. If the problem becomes more complex (such as analyzing user viewing records and determining what content to recommend based on viewing time), it becomes a cost that projects cannot afford.

Whether it is Layer1 or Layer2, their original designs are not suitable for tasks that involve reading and computing large amounts of data on the blockchain. Even with high TPS (Transactions Per Second), blockchains do not help with this problem.

“If on-chain computation is not possible, then let’s handle it off-chain!” This is a reasonable train of thought. Services like Etherscan, Dune, and DeBank use this approach and can indeed solve many problems.

However, if the off-chain computation results are related to large TVL (Total Value Locked) or user rights, the trust assumptions and risks associated with this increase.

For example, in blockchain airdrops, even though the rules for determining eligibility are public, the screening process is still carried out by the team, and the results are announced publicly. But there is a trust assumption in between (how do we know the team did not cheat), which is why there is often controversy and complaints in community airdrops. Not to mention the consequences of having problematic data.

Therefore, the road of off-chain computation seems infeasible in many use cases.

This creates a dilemma. If fetching and computing data directly is too costly, but using off-chain computed results increases trust assumptions. It is no wonder that there are currently no services native to Web3 that use Web3 data.

Almost all mainstream Web2 applications and products rely on data to create experiences and maintain advantages. If Web3 truly wants to create “killer applications,” data, although not everything, is absolutely necessary.

Therefore, the concept of ZK coprocessor has emerged in the market to attempt to solve this problem, achieving off-chain computation while avoiding the need for trust assumptions, perfectly addressing this problem.

ZK coprocessor (also known as ZK coprocessor) aims to improve the efficiency of data collection and computation in Web3. It is crucial for enhancing product usage experience and precision marketing.

However, there are other ways to solve the problem of “data computation on the blockchain.” For example, Smart Layer uses external data attachments to achieve the same goals, but the trust assumption risk depends on the security of the Smart Layer network itself.

Recommended reading:
What is Smart Layer? How to integrate Web3 with real-life scenarios?
Reason for recommendation: This article provides a detailed introduction to the design architecture and operation principles of Smart Layer. It is highly recommended to refer to this article for a comprehensive understanding of the problems that ZK coprocessor aims to solve.

If the information is relatively unimportant, relying solely on off-chain computation is also possible, without requiring complete trustlessness for all information. The important thing is to solve the problem at hand.

Brevis
ZK Coprocessor
ZK 協處理器 (ZK coprocessor)
Zero-Knowledge Proof
Further reading
EigenLayer is about to launch its token! What real use cases can the first batch of AVS provide?
What technological innovations does zkSync have? How does it have the potential to impact the existing Rollup ecosystem?