2019 was a big year in the Zero Knowledge research space.
Great advancements were made on zkSNARKs, zkSTARKs – both well-known zero knowledge proof cryptography protocols – universal set-ups, optimisations, and more.
Over the course of the year, new protocols like Sonic, Plonk, Slonk, Marlin, SuperSonic, Halo and Fractal were released. The month of September was dubbed SNARKtember only to be followed by SNARKtober, SNARKvember and SNARKcember…the last 2 being ruefully less catchy names, but no less jam-packed with new research.
And in tandem with these technical advancements, a host of new use-cases have emerged. Long heralded primarily as a method for enabling privacy in crypto networks, Zero Knowledge Proofs (ZKPs) are proving to be useful in solving a number of the ‘Big Blockchain Challenges’. In fact, today we are seeing ZKPs being proposed as a key to building effective scaling solutions, as validity proofs, for cryptographic verification or certification, as well for providing possible improvements to cross chain interoperability, storage and a host of other decentralized web components.
On the Zero Knowledge Podcast, we interview the practitioners, researchers and engineers working on these systems on a weekly basis. Below are a few of the use-cases that have begun to emerge through these conversations.
ZKPs for privacy
I think by now, we all agree that true privacy is central to blockchain adoption, especially if the goal is to have enterprise, small business or even individuals use cryptocurrencies in their daily lives.
ZKPs are well-known for providing real cryptographic privacy to otherwise non-private blockchains. The first popular use of ZKPs in blockchain was to make private token balances, as well as shield transaction and general blockchain activity from outside observers. The Zcash shielded token model is probably the most well-known version of this. In Zcash, zkSNARKs allows you to move your tokens from transparent state to a shielded private state, where only you will be able to track your activity and see your balance. Within the shielded accounts, you can also transfer tokens privately.
Another more recent example is ZKP-powered mixers that live on another existing blockchain, such as Tornado.cash and Miximus built on Ethereum. In the Miximus case, a user makes an ETH deposit into a Smart Contract, creating a unique commitment in a Merkle tree. To withdraw the user provides a proof of their knowledge of his unique commitment (the secret) using a ZKP but does not reveal this commitment.
ZEXE, another purpose-built privacy protocol which also has zkSNARKs at the core of its construction, is both private and programmable and makes transaction verification constant-time. Unlike Zcash, there is no transparent (or non-private) state. A key introduction with ZEXE is the ability to offer data privacy as well as what they describe in the paper as ‘function privacy’ - that is privacy about the purpose of a transaction. With most existing ZK constructions built on Ethereum using smart contracts, it is easy to see if a particular transaction is for a private token versus for a private DAO - thus there is no function privacy.
With the Mixmus example above, there may be some additional privacy loss due to using smart contracts which can expose information about a user’s gas payments. ZEXE solves for these and uses ZKPs to attest to the correctness of the transaction without revealing the inner details on the blockchain.
The developers behind AZTEC protocol, meanwhile, are also working towards providing this function privacy on pre-existing non-private networks with their work making smart contracts themselves private. The goal is to make privacy programmable and thus make private the purpose of transactions (as well as the underlying data) – even when this is happening on Layer 2.
ZKPs for scaling/compression
An interesting feature of a zero knowledge proof is its ability to prove the validity of a set of data. With this in mind, new approaches to scaling were explored and attempted in 2019 using ZKPs.
These currently fall into 2 camps: (1) using off chain transaction bundles written to the mainchain using ZKPs or (2) using recursion – aka recursive SNARKs – to make a chain smaller (and thus faster to verify).
In the first category, we find ZK Rollup. In this Plasma-like construction, there is a batch of off-chain transactions that need to be brought on-chain validity. Unlike Plasma (or Optimistic Rollup), where economic stake and game-theoretic mechanisms are used to keep parties acting correctly, the idea here is that the user is forced to prove, using a zero-knowledge proof, that its behavior is correct according to the protocol.
However, the ZK Rollup (along with other ZKP constructions built using smart contracts) does still have the disadvantage of using zkSNARKs over general-purpose computation, such as EVM execution. This is a process which remains difficult and requires a lot of resources. That said, we are already seeing the ZK Rollup model as a basis for Matter Labs’ user-focused zkSync scaling protocol, being used to build decentralized exchanges (DEXs), as well as similar constructions using STARKs (instead of SNARKs) as validity proofs coming from the StarkWare team.
The second type of scaling is done through shrinking the chain using recursive SNARKs – that is SNARKs combined and further shrunk – while being validated - by a SNARK. These SNARKs are then further ‘Snarkified’ until you have a top SNARK that proves the validity of the multitudes of SNARKs within it.
In essence, you can use this technique to compress a blockchain down to a single proof – which proves the validity of the underlying SNARKs (which in turn prove the validity of further underlying SNARKs, and so on...) making it accessible yet space efficient. O(1)Labs is the company working primarily on this technique, but we are seeing this technique also being experimented with at Filecoin and Zcash.
ZKPs as verification/certification
Another property of ZKPs (especially when combined with other techniques such as MPC) is the ability for them to provide ‘selective disclosure’.
ZKPs can prove the existence of a secret without disclosing what the secret is. Put another way, some feature/characteristic of a secret can be disclosed as ‘true’ without revealing anything else. This selective disclosure could be incredibly useful in creating systems that are compliant.
For example, proving that some private information is the correct kind of information, that it falls in a particular range, or that it matches another set of data.
This is key if we are to design compliant cryptographic systems, or, more specifically, systems that follow some set of laws or require some sort of verification/certification.
As a tangible example, you could use a ZKP to prove that some addresses can be found on a whitelist without revealing which addresses are being tested nor those on the whitelist. All that is disclosed is that the addresses match. But this concept can be leveraged beyond cryptocurrencies or financial systems: it could be used to improve or replace real world certification systems as well.
Companies like Qedit and Findora are focused on developing these systems, but we are seeing this use-case pop up across the space - especially in projects that involve more traditional enterprise customers.
ZKPs in interoperability
The least explored (and yet highly exciting) use-case for ZKPs is that of interoperability.
Drawing on some of the features that make ZKPs useful for scaling, these remain primarily research topics at the moment, but also reveal to us an even wider scope of the potential benefits that ZKPs have. To think about how ZKPs could be used for interoperability, we look at compression of key building blocks in cross chain constructions or using the validity proof across chains.
Here are some of the questions and ideas we have been thinking about: could we use ZKPs to provide some privacy in cross chain token movement? Could we take the ‘off-chain to on-chain’ idea from ZK rollup but move tokens from one chain to another chain with ZKPs as proofs of validity? Could you use something like Bolt, which provides a private Lightning-like construction, to move things from one chain to another privately? Could ZKPs be built into a tBTC-like construction?
One of my favorite improved interoperability examples comes from Celo. Drawing on some advancements presented in the Zexe paper, they have used ZKPs and recursion to make lightclients lighter – that is, compressing down the size of lightclient so that they could potentially work on mobile. This would also have really nice benefits for cross-chain constructions, specifically those that depend on lightclients and bridges.
So to wrap up: as we look forward to the new developments in the ZK Space this coming year, we are sure to learn about even more ways we can use ZKPs to add benefits to existing blockchains, and possibly discover new characteristics of this seemingly simple but deceptively powerful cryptography.
Thanks to Tarun Chitra, Rob Habermeier, Christopher Goes and Howard Wu for their input on this article.
© 2022 The Block Crypto, Inc. All Rights Reserved. This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.