by Phil Kelly
With all the recent news about zkEVMs, you might think that the Web3 world was close to ‘mission accomplished’ on zero-knowledge proofs (ZKP). At O(1) Labs, while we are excited about the pace of progress in the zero-knowledge proof world overall, we view these announcements as only one step on the path towards realizing all of the benefits that ZKPs can bring. Let me explain:
There are essentially two ZKP ‘movements’ underway in the market today, using the same advanced cryptographic principles, but with very different technical approaches and practical goals:
(1) Scalability: The zkEVMs, as well as other zk rollups so far announced, will be useful for scaling ‘normal’ Web3 activity — basically making it cheaper to run smart contracts in their current form, without adding any new functionality, to address challenges with major L1s. (Mina is also relevant to the scalability space, with potential advantages over other approaches — more on this later.)
(2) Privacy and attestation: The broader category could be termed “verifiable off-chain computation”, with privacy and attestation being two key use cases, but for ease of explanation in this post I have narrowed it down. O(1) Labs and a small number of other projects are focused first on delivering a fundamentally new capability to the market. This allows something to be proven without disclosing the underlying information (private, verifiable computation). Some example use cases include:
- Private / anonymous voting, tweeting, chatting etc. restricted to a gated group (e.g., anyone who has owned token x in the last 6 months).
A wide range of identity routines:
- Proving things about your Web3 life without doxxing your wallets and transactions (e.g., proving to a DAO or a potential project partner that you held crypto in 2014)
- Proving things from Web2 sources without doxxing your offchain life — e.g., proving to a defi protocol that you are not a resident of an OFAC-sanctioned country, or that your credit score is over 700
- Proving the provenance of data without the data recipient witnessing it being sourced (zkOracles and attestation of off-chain computation)
These capabilities will, over time, be used with all chains — EVM-compatible and otherwise — and they are not, practically-speaking, a native option in a zk scalability roll up, EVM or otherwise, in the immediate future.
To give you an example of how technically different the two approaches are: Privacy and attestation (verifiable off-chain computation) use cases require some very sophisticated off-chain activity since there are two steps in the lifecycle of a proof:
a. Processing the data that needs to be kept private, and generating proofs client side (in our case via products developed with O(1) Labs’ SnarkyJS library), and
b. Verifying that the proof has integrity, in a second step (in our case on the Mina blockchain).
O(1) Labs’ belief is that efficient (time-wise and cost-wise) processing of zero knowledge proofs for privacy and attestation requires a specialized, dedicated platform for the generation and verification of proofs, hence the focus of our work on the Mina protocol over the last 5 years, and our focus on the development of SnarkyJS.
There are many advantages to SnarkyJS used in conjunction with Mina. These include:
- SnarkyJS allows proofs to be generated on the client-side, inside of a regular browser, so that only the proof, and not the underlying data, leaves the user’s device. This ensures full privacy (most other proof systems require data to be sent to an external proof generator, with impacts on data exposure, cost and speed).
- The proving system (SnarkyJS + Mina) is purpose-built to use a PLONK-based zkSNARK mechanism that requires no set-up ceremonies, is infinitely recursive, and is optimized with techniques such as custom gates.
- Mina has constant, low transaction fees, with no gas fees. This allows arbitrarily complex computations to require the same fees on-chain as the simplest computation.
- Mina has a tiny chain state (they advertise 22kb, but it’s currently closer to 11kb), achieved using infinitely-recursive technology. How does this help?
- Addresses the chain-bloat issue that impact other chains as state accumulates,
- Lowers the barrier to running a node, allowing decentralization to be achieved more easily. To give a practical example: You can stand up a Mina node and have it participate in block production in minutes, because it only needs to verify a constant, set number of recent blocks / proofs of chain state from before it joins. Whereas syncing a new node on other L1s can take days. The ease of setting up and running Mina nodes should reduce the need for the chain on-ramp services that are common in other L1s, and are points of centralization. Over time, personal mobile devices will be able to run nodes.
- Mina’s entire chain state can be recorded directly on other chains. The Ethereum Foundation and Mina Foundation have co-sponsored an Ethereum bridge project from the Nil team to do just this — build a smart contract on the Ethereum Mainnet that maintains an up-to-date record of the entire Mina chain state. This has been commonly referred to as a ‘bridge’, but I would argue that it’s a new approach to sharing data across chains (which does not rely on the approaches that have proved fragile for some bridges recently, such as multiple sharded-key guardians, or token-driven trust) and should either be referred to as a zkBridge or point the way to replace or augment other bridging techniques. Such bridges will allow Mina to accumulate many ZK proofs, and then “roll them up” to other L1s, providing greater efficiency and thereby low transaction costs for users.
Another way to look at this is as Mina becoming a global L2 that provides private zk capabilities to any L1 chain. While Mina is an L1, because of the unique role of privacy and attestation, we expect there to be many cases where a ZKP circuit on Mina is used integrally in the customer or even the transaction lifecycle for a dapp on another L1. For example, an Ethereum mainnet defi protocol might use Mina to let a customer pseudonymously prove their residency and credit score range in customer onboarding and account maintenance. That said, we expect there to be many native Mina use cases, and also to see Mina as an intermediating environment in multi-chain activity.
Does Mina expect to support high scale? Yes per Mina Foundation CEO Evan’s recent tweet. In fact, a roll up project that was initiated as part of our last zkApps Builders Program is now funded by the Mina Foundation, and several dapps are exploring dapp-specific roll ups, rolling up to Mina mainnet.
O(1) Labs will publish some more in-depth views on use-case specific deployments for SnarkyJS and Mina as we move towards zkApps go-live. Meanwhile, please see the links below to join our ZKP movement!
- Learn the basics using the material from our SnarkyJS Launch Week, and get started with building zkApps if you’re a developer here.
- Read the announcement about our Launch Partner program, with Web3 privacy and attestation innovators such as Brave Browser, SISMO, and DIA using SnarkyJS to build ZK smart contract code and provide feedback.
- Apply for the upcoming, O(1) Labs-run zkApps Builders Program for developers.
