Unpacking zkVMs
You are probably thinking, why should I care about zkVMs?
For one, across the board, crypto people who normally can’t agree on much at all, have come to the conclusion that Zero-Knowledge cryptography is our best bet for scaling blockchains.
Zero-Knowledge cryptography, as the name implies, verifies that a prover has a piece of knowledge or has executed a task without revealing the actual details, and then generates a (Zero-Knowledge) proof that can be used to verify that all has been done as instructed.
As an idea, they’ve been around for a while, first implemented in privacy coins such as Zcash. More recently, as we realized that they’re useful for scaling as well, the focus has shifted toward building zkVMs that’d allow developers to bring about the zk-enabled future.
With all the excitement around zkVMs (and EVMs as a subsection thereof), it’s easy to start focusing on doing the same thing as the others, with slight modifications on where to optimize to speed up the infrastructure.
We beg to differ. But to explain why, we must start with what zkVMs are. Before we do that, a few words of caution to safeguard yourself against hype, and unnecessary implementation of ZK where it is not warranted.
When don’t I need ZKPs…
Quite simple. There is no reason to add zero-knowledge proofs to an application in:
- High trust environments
- When there’s only one verifier: outsourcing your compute to an untrusted server and then using ZKP to verify it was done correctly is nonsensical when you end up paying twice as much. The benefits gained must offset the additional computational costs.
- Realms with sufficient other alternatives, with strong enough other incentives to avoid wrongdoing.
As so often, once a word becomes hyped, it’ll be used by marketers left, right ,and center to increase the perceived attractiveness of their product. It’s gone so far that even in academic papers we find references to this reality.
“Numerous applications highlight ZKPs as a groundbreaking technology. However, we observe that recent applications misuse the term zero-knowledge, such that some applications do not demand zero knowledge at all, but rather rely on other properties such as non-interactivity and succinctness to facilitate the use case in question.”
(https://eprint.iacr.org/2024/050.pdf)
Zero-Knowledge cryptography is about revealing nothing, and still proving something. That’s why using it just to compress is, as some might say, not very zero-knowledge at all.
Terminological feuds aside, the above leaves plenty of use cases where zero-knowledge cryptography does make a whole lot of sense.
When do I sensibly use Zero-Knowledge?
Here are a handful of scenarios where it makes sense to rely on zero-knowledge cryptography:
- Outsourcing computation to others you don’t trust
- Verifiable credentials, and KYC (you go through verification once, then only present the proof going forward)
- Cross-chain bridging
- For networking: to prove, for example, data provenance, a potentially useful thing for AI companies to start doing to prove the sets their models were trained on at the risk of exposing their copyright violations.
In the crypto context, the first scenario is particularly relevant to how decentralized systems work. There are thousands of nodes contributing to them, and no guarantees that each single one has been executing programs correctly.
At the same time, as Dr. Gabbay pointed out in a podcast, we cannot expect all nodes to be supercomputers, allowing them to re-run the entire computation to verify. Instead, what’s needed is a way to input information from such powerful servers and prove its correctness. As such, ZK helps maintain the crypto maxim of “trust, but verify”, even for those with less powerful nodes.
Sounds great in theory, but still begs the question:
How did we end up with zkVMs?
zkVMs are not, despite what you’d assume looking at Crypto Twitter, the only way to code zero-knowledge proofs. Yet, they’ve become the dominant approach because the other one was very optimized, but a skill the vast majority of crypto devs lacked. Before crypto x zk took off, the way cryptographers proved zero-knowledge was the circuit approach.
And the language of cryptography is math. That’s why all logic is turned into mathematical expressions, in a process called arithmetization. It makes further sense when we think about how computers work deep down: it’s all just 0s and 1s.
The way to prove anything then becomes a question of establishing whether it’s a valid bit, meaning whether it translates to 0 or 1, the electric flows inside the machine. That’s the math part.
To do so, cryptographers enforce so-called constraints that represent a program. The most basic one is to verify that a value is actually 0 or 1.
0 = x(x-1)
The only values that resolve this equation are 0 and 1. Naturally, the real proving constraints are much more complex. Assuming you’d want to prove that three numbers add up to 10 without revealing what they are.
You’d write:
Get Modulus ZK’s stories in your inbox
Join Medium for free to get updates from this writer.
a+b+c = 10
That’s not enough, though, as there remains the need to prove that every variable is valid (a bit or field element), so each would come with its own set of constraints. You can see how this quickly spirals into thousands of constraints working together.
Arithmetic Circuits
All these constraints aren’t just thrown into one big field; instead, they are combined in what’s called an arithmetic circuit. It’s similar to a flow chart where at each stop (they call them gates) a mathematical operation is performed, and each line carries a value.
The constraints enforce that the in- and outputs at each gate follow the rules, and when correct values are entered, all constraints are fulfilled, and the computation is provably correct.
With thousands of constraints, this would appear to be quite an arduous task. That’s why cryptographers combine them into polynomials, allowing them to represent hundreds of constraints with one single polynomial equation.
We’ll dwell on the importance of polynomials in the next post; just know that they are a key element of cryptography, and the reason we can run verifications relatively efficiently.
Reading about these equations can make the average person with nightmares from high school math feel like:
As such, you can imagine how many crypto developers don’t feel up to the task of coding their own arithmetic circuits. They still don’t want to miss the perks of ZK, so they came up with zkVMs.
How zkVMs work
zkVMs pitch is that they allow anyone to code zk-proven programs without needing to know zero-knowledge cryptography themselves. Instead, they can use high-level programming languages, and the VM handles the rest.
Since the first practical implementation of a zkVM in 2013, the space has come a long way, with the latest iteration integrating the RISC-V architecture and parallelizing proving efforts to speed up computation.
Compared to the approach of directly writing circuits, zkVMs offer benefits such as a shallow learning curve (if any, when common programming languages are supported) and reduced need to create dedicated constraints for each program.
Naturally, moving further away from the machine comes with downsides, too, as VMs require translating high-level programming languages into all the things we just discussed.
- The compiler turns the source code into VM bytecode.
- This is then executed, resulting in an execution trace.
- In the next step, it’s handed off to the prover, which represents it as a set of polynomials, once again translating, this time from computation into algebra.
- The provider then runs a polynomial interactive proof protocol on it (usually a STARK or a SNARK)
- The proof is thus generated, and can now be verified by the verifier using the verification protocol.
In the end, the VM outputs a final-state commitment and the proof.
While this approach has been great for furthering zk adoption and enabling more builders to leverage zk, it’s also highlighted the potential challenges yet to be overcome. One of the largest looming threats is security. zkVMs are prone to bugs affecting their security and soundness.
Therefore, it’s not uncommon for zkVM builders to add additional layers using Multi-Party-Computation or TEEs to the mix. This, then again, heightens the complexity.
“Not elegant”
— Henderson sensei (Spy x Family)
Not that this would ever deter crypto builders from using a technology. For those especially inclined toward building on Ethereum, a subsection of zkVM has been developed, the zkEVMs. They’re just another flavor of zkVMs designed to cater to Ethereum.
They’re everywhere these days and are becoming increasingly indistinguishable. Yet one thing they all share is the complexity and computational overhead introduced by their approaches to make ZK easier to use for anyone.
Ultimately, Modulus is not here to completely replace zkVMs.
But we’re here to introduce a new way to more elegantly, more efficiently go from business logic to zk proving onchain.
We believe this will unlock a new range of use cases, while offering institutions with much higher security demands than the average crypto degen dev, the necessary tools to enter this industry.
“Tell me, Simon. Do you know why people have eyes in front? It’s ’cause you have to move forward to see the landscape in the distance.“
— Kamina
