Original author: mo

Original translation: Luffy, Foresight News

Specialization or generalization, which one is the future of ZK? Let me try to answer this question with a picture:

As shown in the figure, is it possible that we will converge to a magical optimal point in the trade-off coordinate system in the future?

No, the future of off-chain verifiable computation is a continuous curve that blurs the lines between specialized and general purpose ZK. Allow me to explain the historical evolution of these terms and how they will converge in the future.

Two years ago, "dedicated" ZK infrastructure meant low-level circuit frameworks such as circom, Halo 2, and arkworks. ZK applications built using these frameworks are essentially handwritten ZK circuits. They are fast and cheap for specific tasks, but are generally difficult to develop and maintain. They are similar to the various dedicated integrated circuit chips (physical silicon chips) in today's IC (integrated circuit) industry, such as NAND chips and controller chips.

However, over the past two years, dedicated ZK infrastructure has gradually become more "general purpose".

We now have ZKML, ZK coprocessor, and ZKSQL frameworks that provide easy-to-use and highly programmable SDKs for building different categories of ZK applications without writing a single line of ZK circuit code. For example, ZK coprocessor allows smart contracts to access blockchain historical states, events, and transactions in a trustless manner and run arbitrary computations on this data. ZKML enables smart contracts to leverage AI inference results in a trustless manner to process a wide range of machine learning models.

These evolved frameworks significantly increase programmability within their target domains, while still maintaining high performance and low cost due to the thin abstraction layer (SDK/API) and close to bare metal circuitry.

They are similar to GPUs, TPUs, and FPGAs in the IC market: they are programmable domain experts.

ZKVM has also come a long way in the past two years. It's worth noting that all general-purpose ZKVM is built on top of the low-level, specialized ZK framework. The idea is that you can write ZK applications in a high-level language (even more user-friendly than the SDK/API), and these applications can be compiled to a combination of specialized circuits and instruction sets (RISC-V or something like WASM). They are like CPU chips in the IC industry.

ZKVM is an abstraction layer on top of the low-level ZK framework, just like ZK coprocessors etc.

As a wise man once said, one layer of abstraction solves every computer science problem, but it also creates another. Tradeoffs, that’s the key. Fundamentally, with ZKVM we’re making a tradeoff between performance and generality.

Two years ago, ZKVM's "bare metal" performance was really bad. However, in just two years, ZKVM's performance has improved significantly.

Why?

Because these "general" ZKVMs have become more "specialized". A key reason for the performance improvement is "precompiles". These precompiles are specialized ZK circuits that can calculate commonly used high-level programs, such as SHA 2 and various signature verifications, much faster than the normal process of breaking them down into instruction circuit fragments.

Therefore, the trend is now very obvious.

Dedicated ZK infrastructure is becoming more general purpose, and general purpose ZKVM is becoming more specialized.

Over the past few years, optimizations on both solutions have achieved better trade-offs than before: making progress on one point without sacrificing another. That’s why both sides feel like “we are definitely the future.”

However, computer science wisdom tells us that at some point we hit the “Pareto optimality wall” (green dashed line), where we cannot improve one property without sacrificing another.

So, the million-dollar question arises: Will one technology completely replace the other in due course?

To put this in context with the IC industry: CPUs are a $126 billion market, while the entire IC industry (plus all "specialty" ICs) is $515 billion. I'm sure that history will repeat itself here at a micro level, and they won't replace each other.

That being said, no one today would say, “Hey, I’m using a computer that’s powered entirely by a general-purpose CPU,” or “Hey, this is a fancy robot powered by a specialized IC.”

Yes, we should indeed look at this issue from a macro perspective. In the future, there will be a trade-off curve that allows developers to flexibly choose according to their needs.

In the future, dedicated ZK infrastructure and general-purpose ZKVM can work together. This can be achieved in many forms. The simplest approach is already possible today. For example, you can use a ZK coprocessor to generate some computational results in the blockchain transaction history, but the computational business logic on top of this data is very complex and you cannot simply express it in the SDK/API.

What you can do is get high-performance and low-cost ZK proofs of the data and intermediate computation results, and then converge them to a general-purpose VM via proof recursion.

While I think this debate is interesting, I know we are all building this asynchronous computing future for blockchains, driven by off-chain verifiable computation. As use cases for mass user adoption emerge in the coming years, I believe this debate will eventually come to fruition.