ZKapps
Last updated
Last updated
Today all cryptocurrency services function exclusively on-chain. The division of functions between data storage, block production and ZK-proof makes Mina a succinct and lightweight blockchain. Mina team decided to expand the function of ZK-proof performed by ZK-snarks, or snark workers, outside and provide it to the market by introducing ZKapps. Simply put, a ZKapp connects to the source website and produces proof of data on that website. The proof reveals only the fact, not the data itself. The zkApp shares the proof with the Mina network and then sends the verified proof to the counterparty via an encrypted transaction (see Figure 1). In fact, Zkapps are implementation of smart contracts in the Mina blockchain, an extension of the ZK-proof mechanism (see Appendix 1).
Smart contract - computer algorithm designed to generate, manage and provide information about the ownership of something, used in decentralized autonomous organizations, banking and insurance sectors, securities markets, etc.
Snark proof (ZK-proof) - a cryptographic proof that allows one party to prove it possesses certain information without revealing that information.
Snark (snark work) - a cryptographic proof that allows one party to prove it possesses certain information without revealing that information.
Snarker (snark worker) - a network node that provides ZK-proof (snark-work).
ZKapp - a web application that is based on smart contracts and provides ZK-proof for the market.
For more information see Mina Glossary.
ZKapps are web applications like Daemons, written in TypeScript using the Mina zkApp CLI that allow to use ZK-snarks to validate the input data in various applications. ZKapps are used off-chain, and they allow to sell ZK-proof services to external users anywhere where some data needs approval without disclosure of details.
Daemon - the process in the Mina Protocol operating in the background waiting for a specific event or condition in order to be activated allowing a local client or wallet to talk to the Mina network.
TypeScript - the function which executes a smart contract’s custom logic. For this, it requires input from the users. It runs in a user’s web browser.
CLI - a text-based user interface that connects a user to a computer program or operating system. Through the CLI, users interact with a system or application by typing in the text (commands).
See Mina glossary.
A ZKapp consists of a smart contract and a user interface. Because ZKapps are based on ZK-snarks, a ZKapp developer uses a circuit - which is the method from which a prover function and a corresponding verifier function are derived during the build process. To do this private inputs and public inputs are needed.
Circuit - the method from which a prover function and a corresponding verifier function are derived during the build process in ZKapps.
Private input - the data that is entered in a ZKapp for ZK-proof. It’s not needed for the verifier function.
Prover function - the function which executes a smart contract’s custom logic. For this, it requires input from the users. It runs in a user’s web browser.
Public input - the data that is entered in a ZKapp for ZK-proof and is needed for the verifier function.
Verifier function - the function that validates whether a zero-knowledge proof successfully passes all the constraints defined in the prover function.
See Mina glossary.
A ZKapp runs simultaneously on-chain, or within Mina, and off-chain, in an external system. Within the Mina network, Mina acts as the verifier and runs the verifier function. A ZKapp performs data verification via a smart contract. Literally, a ZKapp deploys a smart contract on Mina. To do this, the developer uses Mina zkApp CLI. The deployment process sends a transaction containing the verification key to an address on the Mina blockchain. When a Mina address contains a verification key, it acts as a ZKapp account. Whereas a regular Mina account can receive any transactions, a ZKapp account can only successfully receive transactions containing proof that satisfies the verifier function. Any transactions that do not pass the verifier function will be rejected by the Mina network (see Figure 2).
Address - the function which executes a smart contract’s custom logic. For this, it requires input from the users. It runs in a user’s web browser.
Verification key - The public address of a private key that serves as an identity of the subject of an account.
See Mina glossary.
When a smart contract is executed and a ZK-proof is done, the new state has to be stored. Two different types of state exist on Mina: an on-chain state and an off-chain state. If the new state is stored on-chain, it can be used as a snark for block production. Each ZKapp account provides 8 fields of 32 bytes each of arbitrary storage. If a state requires more memory, an off-chain option then is in place. For larger data, it’s possible to store the root of a Merkle tree (or similar data structure) within the ZKapp’s on-chain storage that references additional off-chain state stored elsewhere, in any external data storage, e.g. IPFS. When a ZKapp runs in a user’s web browser, it may insert a state to an external storage.
When a ZKapp runs in a user’s web browser, it may insert a state to an external storage. When a transaction is sent to the Mina network, if it accepts this ZKapp transaction, i.e. if the proof and the state are valid, then the transaction would update the root of the Merkle tree that is stored on-chain.
Merkle tree - A data structure in which every node is labeled with the cryptographic hash of a data block, and every node that is not a leaf (called a branch, inner node, or inode) is labeled with the cryptographic hash of the labels of its child nodes.
On-chain state - describes a state that lives on the Mina blockchain and is stored within a ZK-app account.
Off-chain state - describes a state stored anywhere else.
See Mina glossary.
ZK-proof-based smart contracts, aka ZKapps, have the following properties:
ZKapps preserve users’ privacy. They use cryptographic algorithms to prove that something is true without unveiling the context or any other extra information around this fact. This literally means that zkApps end users interact using proofs of their personal data without having to share the data itself. For instance, zkApps can connect to a credit score provider to prove that your credit score is above a certain threshold.
ZKapps can execute unlimited off-chain computations at a flat fee. Other blockchains normally use a variable gas fee-based model which is dependent on the network supply and demand at any given moment. ZKapps, on the contrary, can perform complex computations off-chain while charging only a flat fee to send the zero knowledge proof to the chain for verification of this computation work.
ZKapps can connect Web2 to Web3. Currently, other blockchains cannot seamlessly bring information on the Internet on-chain, which is a limitation to the utility of blockchain applications. zkApps, however, can privately communicate with any website, proving facts about APIs and webpages on the Internet, and access verified real world data that’s going to be used on-chain. This is possible due to zkOracles, which uses HTTPS to connect real world data to a blockchain in a trustless manner.
ZKapps can be accessed from other chains and devices. Due to Mina’s succinct design, Mina’s zero-knowledge proof programmability can be reached from other chains and ultimately even end user devices via a special blockchain bridge.
ZKapps are written in Typescript. ZkApps are programmed using SnarkyJS, which is a Typescript-based library. This greatly expands the pool of developers who can easily get started building zkApps.
zkOracle - a Polkadot-based privacy-preserving oracle network, aiming to expand the application areas of Web3 applications in real business environments. It is used for ZKapps in Mina.
SnarkyJS - describes a state that lives on the Mina blockchain and is stored within a ZK-app account.
For more information see Mina Glossary.
Essentially, there are 3 main directions where ZKapps can be useful:
Ensuring user data will remain private while moving from online to on-chain.
Permissionless verifiable web Oracles to allow the transition of decentralized information.
Providing access to any website or service privately without handing over personal data.
There is a number of real-life use cases where ZKapps may be applied, where it’s required to verify data without disclosing them (see Figure 3). Those include, but are not limited to the following:
Verifying credit histories for banks and non-bank financial organizations.
Providing medical history.
Checking debit-credit and payment history for plastic cards.
Secure log-in.
Identity verification systems.
Insurance.
Auctions.
Contracting.
Managing NFTs.
Communication with public agencies and organizations to prove personal identity or other important personal data.
Neural network identification.
Games and quizzes.
Exchange.
Web wallets.
Booking services.
Voting.
Brokerage.
Accounting.
Testing and examinations.
Notary services.