Introduction
Zero-knowledge proofs↗ (ZKPs) represent a family of cryptographic protocols that enable one party (denoted the prover) to produce proofs of knowledge for a set of values denoted witness values. The proofs allow the prover to prove knowledge of the witness values to another party (denoted the verifier) without disclosing any additional information about the values themselves.
The aforementioned mechanism extends quite naturally to proving computational integrity — in other words, a particular computation has been performed correctly and honestly. Every operation in a computation may be represented as a constraint on the inputs and outputs of the operation. If a prover presents the output for a computation, along with a proof that they know has valid state values for every constraint in the computation, verifying the proof is equivalent to verifying that the output was computed correctly for some inputs. Therefore, the verifier is assured of the validity of the output without having to perform the computation.
Most notably, ZK proofs are used in cryptocurrencies to improve trust, privacy, and stability on the blockchain. By increasing the level of security without compromising the integrity of transactions, ZK proofs play a crucial role in these decentralized systems. In this blog, we will take a surface level walk-through of the landscape and real-world applications of zkSNARKs.
What Are zkSNARKs?
Specifically, zkSNARKs↗ is an acronym for zero-knowledge succinct noninteractive argument of knowledge.
ZK: ZK stands for zero-knowledge. As explained above, it allows a verifier to verify that a proof made by a prover is valid. Also, the verifier does not learn anything about the specific information in the proof. This characteristic ensures a high level of privacy as it allows sensitive information to remain hidden while still providing sufficient proof of its legitimacy.S: S stands for succinct. This means that the length of the proof has to be relatively small. How small? Usually, these proofs are only a few hundred bytes in length. The small size of the proofs allow for blazing fast verification in only a few milliseconds.N: N stands for noninteractive. This property is by far the most important property of zkSNARKs. A noninteractive proof means that the proof can be generated without any interaction from the verifier. Once the proof is created, it can be sent to a verifier, who can then confirm or refute the proof. The lack of interaction means that the proof can be publicly posted for anyone to verify without the need to communicate to the original prover.AR: AR stands for argument (of) and goes along with the next letter.K: K stands for knowledge. Combining with AR, the letters “ARK” stand for argument of knowledge. An argument of knowledge is a type of proof where a prover convinces a verifier that they have knowledge of a certain piece of information. This is done under a computational assumption; it’s computationally infeasible for a dishonest prover to convince a verifier of a false statement. This is different from the zero-knowledge property since it focuses more on the soundness of the proof.
zkSNARKs are important mostly due to their noninteractive property. On the blockchain, it is infeasible to communicate with every user and have each verify a proof. It is much easier for the prover to post a proof to the public and have anyone verify it without having to communicate back to the prover.
Applications Into Blockchains & Real World
zkEVMs
Due to the increasing popularity of Ethereum, transaction times have been longer, fees have increased, and scalability has become a challenge. A solution to these challenges is by using zkEVMs↗ along with zkRollups to help solve these problems. A zkEVM is a combination of zero-knowledge proofs with the Ethereum Virtual Machine. It essentially uses ZKPs to prove that a transaction happened in the zkEVM.
More specifically, the zkEVM lives on a Layer 2, a separate blockchain that utilizes and extends the main Ethereum chain. Now, smart contracts can be uploaded and the EVM runs the smart contract byte code. To prove that a state change occurred when interacting with a smart contract, the ZK part of the zkEVM creates a noninteractive proof that anyone can verify on that transaction.
As the blockchain increases in the number of blocks, it becomes computationally infeasible to go through every block. zkRollups come to the rescue. Put simply, zkRollups take a large chunk of user transactions and squeeze them into one mega block. It also attaches a proof onto this new block, which allows anyone to verify that the new block was made up of a large chunk of transactions. zkRollups↗ offer a solution to the ever-increasing number of blocks on the blockchain.
By “rolling up” a large number of transactions into a single block, it greatly reduces the amount of data needed to be stored on the blockchain, increasing scalability and efficiency. Instead of having each transaction directly uploaded to the blockchain, transactions are bundled up first and then uploaded.
This is Polygon’s↗ solution:
Polygon is one of the first creators of zkEVMs. Polygon is a Layer 2 scalability solution that uses a zkEVM for users to interact with to increase the speed of transactions and lower transaction fees. Right now, the main Ethereum chain can handle around 30 transactions per second (TPS). By uploading transactions to Polygon, they can be processed at speeds of up to 2,000 TPS. To achieve this speed, Polygon uses a side chain where lots of transactions are bundled up through a zkRollup before being sent to the main Ethereum blockchain to reduce the total communication to the main chain.
Along with faster transaction speeds, the cost per transaction is also reduced↗. Polygon achieves this in the same way by using zkRollups. Since the interaction with the main Ethereum blockchain is minimal, the gas fees for each interaction is shared across all the transactions that were rolled up. This splits a normal gas fee of about $20 to a few pennies for every user.
zkBridges
As more and more cryptocurrencies are created and the blockchain ecosystem diversifies, the demand for communicating and exchanging different coins increases. Given that each cryptocurrency is on its own blockchain, crypto bridges are used to transfer coins from one blockchain to another. Right now, two popular ways that people trade cryptocurrencies are through a centralized trusted party or by verifying consensus.
A centralized party for exchanging different cryptocurrencies is the same as currency exchange in the real world. A bank or a trusted party allows one to deposit some coins in exchange for other coins. This trusted party acts as a market maker. However, there are a few problems with this. First, in order for this exchange to occur, the market maker must have enough of both coins (i.e., liquidity) to perform a trade. Using Ethereum and Polygon MATIC as an example, if one wants to exchange their Ethereum for MATIC, the centralized trusted party must have enough MATIC coins to meet the value of the Ethereum coins being traded. If no one is trading from MATIC back to Ethereum, then the process stops: there isn’t enough MATIC to cover for the Ethereum coins. Second, if the central party is untrustworthy, they could steal all the deposited coins and disappear into thin air (i.e., a rug pull).
The zkBridge between Ethereum and Polygon MATIC.
Another solution to the crypto exchange problem is through zkBridges↗. It brings ZK proofs with crypto bridges to provide exchanges between different cryptocurrencies that use the EVM without the need of an intermediate trusted party. Let’s use a transaction between Ethereum and Polygon as an example.
When a transaction is made and a block is created on the main Ethereum blockchain, it needs to be validated. To accomplish this, validators create a proof of consensus↗ by using their own keys to sign the block. After a certain number of validators have signed the block and the signatures are verified, there becomes a consensus that the block is indeed valid.
After achieving a proof of consensus, a Merkle proof is created for the specific block and transaction and sent to a smart contract on the Polygon chain. Since smart contracts cannot communicate with each other cross-chain, a middle party is still used. However, these middle parties are more trustworthy since they can’t mess with the proofs without invalidating them.
Succinct Labs takes advantage of this and uses a modified proof of consensus and Merkle proofs to achieve a zkBridge on cryptocurrencies that use the EVM. For Succinct Labs↗, a proof of consensus is formed by using 512 validators that are rotated every 27 hours to sign all new block headers on the main Ethereum chain with Groth16↗ (used by Tornado Cash). These proofs can be validated very efficiently on chain due to the constant-time proof verification of Groth16. When the validity of the proof is determined, a Merkle proof is used to relay the transaction across the cross-chain completing the zkBridge and allowing coin exchange.
zkProgramming Languages
In the development of ZK proofs or ZK circuits, Rust is typically chosen as the language to write them in. However, this requires both an understanding of the Rust language and an understanding of ZK circuits and libraries. Right now, most ZK libraries are quite bare. Developers are required to read large amounts of documentation just to find out how to use a function safely.
Due to this, the innovation of ZK technologies has been quite slow. The goal of a ZK programming language↗ is to simplify the development of ZK circuits. By moving all the complex math behind the scenes, writing ZK circuits can be treated as writing conditionals in a normal programming language. It would allow regular software engineers without a deep understanding of how ZK circuits work to create them efficiently.
The need for ZK programming languages arises from the fact that coding
up ZK circuits involves lots of math and cryptographic operations.
Understanding these concepts require specialized knowledge in areas like
cryptography and number theory. This creates a barrier for software
engineers who may not have a strong background in these domains. Instead
of using a ZK library to create constraints for a conditional statement,
an if statement written in Noir is automatically converted to a circuit
conditional. For example, to set a value a that depends on a boolean
b without Noir,
let a = b*f(x) + (1-b)*g(x);
With a ZK programming language, it’s as simple as
if b {
let a = f(x);
} else {
let a = g(x);
}
without the boolean algebra behind it.
Noir↗ is a ZK programming language created by Aztec to bridge the gap between software engineers and ZK circuits. By using a Rust-like language and syntax, developers don’t have to relearn a new language and can create ZK circuits easily. Additionally, Noir already implemented a lot of useful ZK gadgets in their standard library including Merkle proofs, ECDSA, field methods, and more. For example, using a Merkle proof is as easy as this:
use dep::std;
fn main(message : [Field; 62], index : Field, hashpath : [Field; 40], root : Field) {
let leaf = std::hash::hash_to_field(message);
let merkle_root = std::merkle::compute_merkle_root(leaf, index, hashpath);
assert(merkle_root == root);
}
However, Noir doesn’t compile code directly to a ZK circuit. During compilation, the written code compiles into an intermediate phase called the abstract circuit intermediate representation (ACIR↗). It compiles all code into R1CS, which allows users to choose the best proving system needed for their use. The ACIR code is then finally compiled with the chosen proving system on the abstract circuit virtual machine (ACVM), which acts as a ACIR compiler.
Conclusion
Overall zk-SNARKs provide a powerful tool for enhancing privacy and trust in blockchain systems. With a diverse range of applications (zkEVMs, zkBridges, zkProgramming languages), they can fit into a wide variety of needs on the blockchain. By allowing parties to prove integrity of computational results, ZK opens avenues for not only privacy applications but delegating computations since off-loaded workloads can be computed verifiably.
Check out Intro to Zero-Knowledge, Part 2↗ for a deeper look into zero-knowledge and applications of zero-knowledge including ZK payments, ZK hardware acceleration, and zkVMs.
Special thanks to fellow Zellic engineer Mohit Sharma for their help and input in this article.
About Us
Zellic specializes in securing emerging technologies. Our security researchers have uncovered vulnerabilities in the most valuable targets, from Fortune 500s to DeFi giants.
Developers, founders, and investors trust our security assessments to ship quickly, confidently, and without critical vulnerabilities. With our background in real-world offensive security research, we find what others miss.
Contact us↗ for an audit that’s better than the rest. Real audits, not rubber stamps.