By Jason Borseth, PM for zkApps at O(1) Labs, a Mina ecosystem partner
As SnarkyJS Week gets underway, we want to begin by sharing more about zkApps to give insight into why we made some of the design decisions we did, the unique advantages they provide for Mina, and the vision for their future.
Zero-knowledge proof powered smart contracts
As fans of Mina know well, Mina Protocol is built on zero-knowledge proofs, and is the only layer-1 blockchain built on recursive zero-knowledge proofs (“ZKPs”), which are even more powerful.
These enable Mina Protocol to have the world’s-lightest blockchain and are the foundation upon which we can entirely rethink how to design a modern, smart contract platform, such as Mina’s zkApps.
For anyone new to zero-knowledge proofs, let’s give a brief summary, so the rest of this post will make more sense:
ZKPs enable you to perform a computation (of any kind, size, & duration) that generates a zero-knowledge proof as its output. This proof contains none of the private data used in the computation and can be presented to a 3rd party (such as a blockchain) who can run an associated verifier function that returns a true/false to indicate “yes this proof was generated using the expected computation/program” or “no it wasn’t”.
Interestingly, a developer could write a ZK program that takes seconds, minutes, hours, or even days to run–doing anything that a developer desires–but the proof generated will always be fast to verify (on the order of tens or hundreds of milliseconds) irrespective of how complex the original computation was.
This characteristic is the key upon which we built zkApps.
How this works
zkApps on Mina execute off-chain, privately in a user’s web browser, and generate a zero-knowledge proof.
When a user sends a zkApp transaction containing this proof to the Mina network, the zkApp account on Mina will only accept the transaction if the proof is valid, indicating the user ran the computation expected for this smart contract. If it is valid, then the transaction is accepted and any state that the developer has chosen to store on-chain is updated. All other private inputs from the user are never sent to or seen by the network. A developer must explicitly indicate which data they want to be public state in order for it to be stored on-chain. On-chain state is most often useful to allow coordination between different users or a given user over time; there are additional uses but we’ll get to that later.
In this way, the user’s privacy can be maintained, the network remains highly scalable due to off-chain computation, and developers have powerful smart contracts with unlimited off-chain computation that support both private data inputs and optional public state!
Early blockchain architectures
Early blockchains supporting smart contracts, such as Ethereum, were built on the concept that every node in the network must both: 1.) store all data on-chain, and 2.) run every computation that the network has ever seen, in order to verify the current consensus state of the network. This is incredibly inefficient and has major downsides:
- First, requiring every node to run every computation is highly inefficient and bad for network scalability.
- Second, it imposes a gas-based fee model on users, where transactions running more complex computations require higher transaction fees.
- Third, storing all data on-chain data is harmful for user privacy.
- Lastly, storing all data on chain harms decentralization by accumulating over time and creating a very large blockchain (in GB to TB) such that fewer and fewer network participants will be willing to pay the costs to operate a full consensus node (Ethereum is 755 GB and growing).
Building a more ideal blockchain architecture
Now, let’s envision a more ideal architecture using zero-knowledge proofs:
- First, we want a lightweight (in KB size) way to represent and verify the blockchain’s current consensus state, from the present back to the genesis block. Keeping this consensus “source of truth” small ensures we maintain a high degree of decentralization. Mina’s constant size, 22 KB consensus proof, serves this perfectly!
- Next, we want to offer unlimited computation for users at no additional transaction cost. We can do this by running computations off-chain and sending a ZK proof that cryptographically proves the expected computation was run. If the computation exceeds the maximum constraints allowed by the ZK proof, Mina’s proof system will use its infinite recursion to accommodate as much computation as desired in exchange for extra recursive steps. So now we have unlimited off-chain computation!
- We also want privacy for users. By executing smart contracts off-chain, we’re able to process private data in a user’s web browser such that it can always remain on the user’s computer and never sent to the blockchain. Users end up attesting to facts about their data, rather than sharing their private data itself. So now we have powerful privacy for users!
- We also want optional public data (a.k.a. “state”), so that a developer can store the current state of their application. This is useful to enable coordination between different users or a single user over time, among other reasons. Mina has 8 fields of on-chain storage per zkApp account.
- Lastly, let’s dream big and allow developers to store larger data off chain. We can store larger data structures, like a Merkle tree, off chain and we only need to store the root hash of the tree on chain. Because of how Merkle trees work (hashes of hashes), this provides data authenticity even though the bulk of the data is stored off chain. What this achieves is a good separation of concerns–the bulk of our data can be stored off-chain using ideal infrastructure for this need and is flexible to adapt to newer, better, more efficient data storage mechanisms over time. Most importantly, the ability to verify the consensus state of the network is not impaired by data accumulation over time like occurs on Ethereum!
This is zkApps!
Off-chain storage is planned, but the rest is available today on Mina’s Berkeley QANet and soon on Berkeley Testnet!
Advantages of zkApps
To summarize the advantages, we now have:
- Unlimited off-chain computation
- Predictable, flat transaction fees for users (not gas-based)
- Privacy for user data
- Optional, public on-chain state
- Off-chain storage for large data (planned)
- Infinitely recursive ZKPs (enabling easy rollups & more)
This flexibility creates a powerful toolset for developers to build a new generation of blockchain apps powered by zero-knowledge proofs, which we call zkApps!
We haven’t even touched on the advantages of zkApps’ developer tooling yet–the Mina zkApp CLI and SnarkyJS, a TypeScript library for writing zkApp smart contracts. But we’ll save that for another blog post!
Vision for the future
In addition to the zkApp features mentioned above, both Mina Foundation, and Mina ecosystem contributors such as O(1) Labs, Nil Foundation, & more are building other fundamental building blocks for the Mina ecosystem. These include a zkBridge to bridge Mina zkApps and other blockchains such as Ethereum, and zkOracles to consume data from external sources inside zkApps (such as price feeds & more Web2 APIs and websites).
With zkApps, zkBridge, and zkOracles, a powerful zero-knowledge ecosystem lies ahead for Mina Protocol. zkApps are only the first step!
Wrapping up & getting you started
Mina Protocol’s zkApps based on zero-knowledge proofs create a powerful smart contract platform, allowing devs to create apps in ways never before possible.
We’re excited to see what you build! To get started:
- Remember to sign up for SnarkyJS Week events to learn & meet other zkApp devs!
- Join us in #zkapp-developers on Mina’s Discord.
- Apply for the upcoming 2022 zkApps Builders Program Cohort 2 where you can get hands-on support from the team at O(1) Labs working on zkApps and work alongside other developers who are building zkApps.
Building a breakthrough application platform such as zkApps is a monumental team effort. O(1) Labs, Mina Foundation, & Mina ecosystem partners are always looking for friendly, brilliant people who love Web3. If that’s you, come join one of the teams working on Mina:
Now, let’s build!