Isomorphism

"Specialized" vs. "Generalized" ZK: Which One is the Future? Let me attempt to answer this with one figure: Is it possible that we will converge on just one magical optimal point in the tradeoff plane? No, the future of off-chain verifiable computing is a continuous curve that blurs the line between specialized and generalized ZK. Allow me to explain how these terms have evolved historically and how they will converge in the future. Two years ago, "specialized" ZK infrastructures meant low-level circuit frameworks such as circom, Halo2, and arkworks. ZK Apps built with these were essentially hand-written ZK circuits. They are fast and low-cost for very specific tasks but are generally difficult to develop and maintain. They are analogous to various specialized integrated circuit chips (physical silicon), such as NAND chips and controller chips, in today’s IC industry. Over the last two years, however, "specialized" ZK infrastructures have evolved to become much more "generalized." We now have ZKML, ZK Coprocessor, and ZKSQL frameworks that provide easy-to-use and highly programmable SDKs to build different classes of ZK Apps without writing a single line of ZK circuit code. ZK Coprocessors, for example, allow smart contracts to trustlessly access historical blockchain states/events/transactions and run arbitrary computations on that data. ZKML enables smart contracts to trustlessly utilize AI inference results for a broad class of machine learning models. These evolved frameworks have significantly improved programmability within their target domains, while still maintaining high performance and low costs because the abstraction layer (SDK/APIs) is thin and close to the bare-metal circuits. They are analogous to GPUs, TPUs, and FPGAs in the IC market: they are programmable and domain experts. ZKVMs have also evolved considerably in the last two years. It’s important to note that all generalized ZKVMs are built on top of low-level, specialized ZK frameworks. The idea is that you can write ZK Apps in high-level languages (even more user-friendly than the SDK/APIs), which can be compiled down to a combination of specialized circuits of instruction sets (RISC-V or WASM-like). In our analogy of the IC industry, they are like CPU chips. ZKVMs are a layer of abstraction on top of low-level ZK frameworks, just like ZK Coprocessors and etc, albeit a much thicker layer. As a wise man once said, one layer of abstraction can solve every computer science problem but creates another problem at the same time. Tradeoff, my friend, is the name of the game here. Fundamentally, with ZKVMs, we are trading off between performance and generalization. Two years ago, the “bare-metal” performance of ZKVMs was truly horrible. However, in just two short years, the performance of ZKVMs has improved significantly. Why? Because these "generalized" ZKVMs have become much more "specialized"! One key area of performance gain comes from "pre-compiles". These pre-compiles are specialized ZK circuits that can compute commonly useful and high-level programs, such as SHA2 and various signature verifications, much quicker than the normal flow of decomposing them into bits and pieces of instruction circuits. Thus, the trend is quite clear now. Specialized ZK infrastructures are becoming increasingly generalized, and generalized ZKVMs are becoming more specialized as we speak! For both solutions in the last couple of years, the optimization is achieving strictly better tradeoff points than before: getting better on one point without sacrificing the other. This is why both sides feel that “we are absolutely the future.” However, computer science wisdom tells us all, at one point, we will hit the “Pareto optimal wall” (green dashed line) where we cannot improve one trait without sacrificing another. So, the million-dollar question arises: will one completely replace the other in due time? If the IC industry analogy can be of any help: the market size for CPUs is $126 billion and the entire IC industry, adding all “specialized” ICs, is $515 billion. I do believe, on a micro-level, history will rhyme here and they will not replace each other. Having said that, today no one says, “Hey, I am using a computer powered exclusively by generalized CPUs,” or “Hey, look at this fancy robot powered by specialized ICs.” Yes, we should really view this whole matter at a macro level, where the future is to provide a tradeoff curve for developers to flexibly choose based on their individual needs. In the future, domain-expert ZK infrastructures and generalized ZKVMs can and will work together. This can happen in many forms. The simplest way to do this is already possible today. For example, you might use ZK Coprocessors to generate some computation results over a long history of blockchain transactions, but the computation business logic on top of this data is so complex that you cannot easily express it in the SDK/APIs. What you can do is to get high-performance and low-cost ZK proofs of the data and intermediary computation results and then funnel these to a generalized VM through proof recursion. While I do think these types of debates are fun, I know we are all building this async computing future for blockchain powered by off-chain verifiable computing. As we see use cases with large-scale user adoption emerge in the next years, I am sure this debate can be easily resolved.