Maybe you know how Zero Knowledge Proofs (ZKPs) enable devs to programmatically manipulate privacy. But, did you know that some of their most interesting applications have NOTHING to do with privacy at all? Let's talk about how ZKPs scale and augment on-chain computing!👇
1/ Though ZKPs are commonly associated with blockchains, they're technically a completely separate technology. So why then are so many applications of ZKPs in the blockchain space???
2/ To understand this, let's deconstruct the acronym "ZK-SNARK".ZK-SNARK stands for "Zero Knowledge Succinct Non-interactive Argument of Knowledge".Because researchers (mostly) name things descriptively, we can break down what this means to understand ZKPs:
3/ "Zero Knowledge" - The proof doesn't reveal anything about its private inputs to the verifier (the recipient of the proof).
"Succinct" - The proof is small. (In some proof systems, like groth16, it's a constant size!)
4/"Non-interactive" - The verifier doesn't need to interact with the prover to check the proof. "Argument of Knowledge" - The proof probabilistically argues with EXTREMELY high probability that the statement it wraps is true. (This property is also known as "Soundness".)
5/ If you want to dig deeper into what these definitions mean, I recommend checking out
@varunshenoy_'s thread where he deconstructs ZKPs in greater detail:
6/ For this thread, let's hone in on the "Succinctness" and "Soundness" properties of ZKPs.Because of these properties, ZKPs can wrap expensive computations such that verifying the ZKP on-chain verifies the computation was computed correctly in a relatively gas cheap fashion.
7/ As proof systems advance, the limits of what can be wrapped in this way continue to be pushed.
(Read the "Various approaches to frontends" section of @SuccinctJT's @a16zcrypto blog post for more info)
Sounds great! Though there's a catch I haven't talked about yet.
8/ A common misunderstanding about ZKPs is that they can attest to statements in a vacuum, proving things out of thin air.
However, the circuits of protocols like @PrivacyScaling's Semaphore often include an on-chain commitment, such as a merkle root, in their public signals.
9/ What gives? Let's run a thought experiment. Say I wrote membership proof circuits like Semaphore's but without committing to an on-chain merkle root. Proofs generated from the circuits would attest to me owning a commitment in some tree...but I could just fake the tree.
10/ ZKPs can prove statements about their inputs by constraining them, but in practice, the prover also needs to provide some way to verify that the inputs weren't bogus. This means providing some trusted public signal against which the ZKP constrains the inputs.
11/ In this way, ZKPs inherit the trust of the public signal, and they can only be as trusted as the signal is.
Analogously, the constraints of a ZKP are similar to logical reasoning, in that you need a premise you trust to base your deduction off of.
12/ Wouldn't it be nice if there were a trusted source of accessible data that ZKPs could base their arguments of knowledge off of? Well, yeah, we have blockchains.Providing decentralized, sybil resistant public ledgers in trustless environments is what they do.
13/ Though blockchains also have issues - values used in on-chain computation as well as the resulting state transitions must be public, so that they can be verified.Also, computation can't get too complex due to mechanisms like gas, which are needed due to the halting problem.
14/ Luckily, ZKPs and blockchains complement each other naturally. Blockchains provide ZKPs with trusted data to constrain and be verified against.ZKPs can both improve end-user privacy and cheaply verify the otherwise untrusted results of large off-chain computations.
15/ @VitalikButerin and @gubsheep discussed these complementary properties at @EFDevcon.
(I highly encourage checking the talk out, lots of interesting greenfield ideas are discussed.)
16/ Once you understand the synergistic properties of ZKPs and blockchains, you'll start to recognize how all ZK-infra projects have to use some blockchain state as an axiom/premise to inherit the blockchain's security and trust guarantees.
17/ For example, all ZK-EVMs are some variation of wrapping EVM computations in a ZKP. This ZKP exposes a merkle root as a public signal which is posted alongside the ZKP to the ZK-EVM's beacon chain.
Verifying the ZKP enables the merkle root to be settled relatively cheaply.
18/ Each batch, the ZK-EVM uses the previous merkle root as a premise for proving the next, resulting in a familiar interleaving of onchain state and ZKP.
(I prefer to call ZK-EVMs validity rollups or succinct rollups, as they can be built with SNARKs/don't need ZK per say)
19/ A ZK-EVM is just one example of running an expensive computation wrapped in a ZKP off-chain using on-chain data. What other cases follow this pattern?
Instead of an L2, maybe I want to verifiably run an process off-chain to calculate credit scores, like
20/ Or maybe I want to consume historical RANDDAO randomness, but I want to go back in time farther than is possible in a smart contract, like @chainlink and @paradigm?
21/ Maybe I want to go as far as wrapping a ML model for processing biometric data in a ZKP, like
@DCbuild3r at @worldcoin?
22/ Or perhaps I want to pass messages from mainnet Ethereum downstream to a smart contract on another chain, like @arbitrum or @optimismFND ?
(Note: I'm glossing over a lot here, but I'll save @SuccinctLabs's Telepathy protocol for a future thread.)
23/ Seems like wrapping off-chain computation in a ZKP premised on on-chain data is a pretty common pattern.
We can make a religi - I mean company out of this!
Enter the team at @axiom_xyz.
24/ Axiom is an extremely fitting name - a mathematical axiom is a fundamental premise from which theorems are proved. Likewise, Axiom is building a system for ingesting historical on-chain state into a ZKP, processing it, and then consuming the ZKP and its output back on-chain.
25/ Axiom calls this system a ZK coprocessor, as it's similar to a GPU. A CPU sends draw instructions to a GPU, then waits on the GPU to return rendered graphics. Similarly, contract devs can dispatch ZK instructions to Axiom, and Axiom returns them ZKP verified output.
26/ Axiom's demo currently only supports reading and verifying via ZKP the historical storage slots at an address.
However, the team is working on allowing devs to apply and compose primitives like basic analytics (sum, max) to cryptography (signature verification) and even ML.
27/ ZKP development is currently an entire can of worms, as I've written about before.
But, in the future, provided Axiom is sufficiently composable and expressive, devs could use it to leverage ZKP-verified computation off-chain without having to write circuits directly!
28/ In short, ZKPs require premises/axioms, and blockchains trustlessly provide such premises. Given such, ingesting blockchain state into a ZKP-wrapped computation and verifying it back on-chain is a powerful, common pattern for scaling and augmenting on-chain compute!
29/ Want to chat more about ZK, whether for privacy or for infra? My DMs are open! Thanks to @nonieengel and @sebastienladuca for proofreading this thread.
30/ Want to learn more about ZK, scaling blockchains, infra, and even more? Check out the rest of the @chapterone research group posts here: twitter.com/i/lists/162053…