In the evolving blockchain landscape, zero knowledge proofs have emerged as the most powerful cryptographic technology allowing more privacy and scalability. Also known as arguments of knowledge, they generate proof that some computation has a particular output while verifying that proof very quickly. The zero knowledge (ZK) part is an additional privacy bonus that keeps some inputs of the computation hidden.
ZK-SNARK is the first and most popular implementation of this cryptographic technology, but modern ZK-EVMs also employ zk-STARK for better efficiency. In this article, weβll review and compare these two ZK-protocols β zk-SNARKs vs. zk-STARKs β shedding light on how they tackle blockchainβs scalability trilemma.
Brief Intro To Zero Knowledge Proofs
Zero-knowledge protocol, a method that uses ZK-proofs, allows one party to quickly prove that a computation has a particular output without revealing specific inputs to that computation. The secret information to be proved and validated is called a witness.
Sometimes, complex concepts are better understood with simpler, everyday analogies:
Imagine youβre a baker claiming you know a secret ingredient that produces a unique gold crust when added to a basic bread recipe and baked 100 times in a special oven. Instead of making someone bake it 100 times to verify, you provide a quick method to confirm the crust without revealing the secret ingredient. Like the bakerβs method, the proof confirms the statement about the secret number without revealing it or undergoing a lengthy process.
In the realm of blockchain, consider the process akin to mining a block:
Imagine a miner claiming, βI have found a nonce that, when appended to a specific blockβs header and hashed through SHA256, produces a hash value starting with a certain number of zeros.β Instead of having every participant in the network compute the hash to confirm its validity, which would be immensely time-consuming and energy-draining, the miner provides a succinct proof. This proof allows anyone to rapidly validate the claim without redoing the extensive hashing or discerning the exact nonce used.
Just like in the original scenario, the core idea is verifying a statement quickly without unveiling the specific secrets or redoing all the work.
How Does It Even Work?
ZK-proofs are powered by some really clever but very complex math, which we will only outline here. Consider a massive computation where we encode something with an input number and hash it one million times. A βsuccinctβ proof aims to verify a certain output will come out of the computation without mirroring every step. Instead of checking each computation piece, a verifier, through random sampling, examines only a small share of the total parts. If these checks pass, itβs assumed that the entire computation is likely correct.
The Immense Value Of ZK-Proofs For Blockchain
ZK-proofs bring two crucial benefits:
Scalability: For a block that takes ages to verify, only one person can do the computation and produce proofs, like zk-SNARs or zk-STARKs. Other network participants only have to verify the proof.
Privacy: Leveraging ZK to conceal computation inputs enables parties to transact with enhanced privacy, preventing the disclosure of extraneous information to the public. For instance, you can validate having sufficient ETH in your balance to purchase without exposing the original sender of the cryptocurrency.
Owing to these powerful advantages, cryptographic tools like zk-SNARKs and zk-STARs are ideal for layer 2 scalability β reliably confirming off-chain transitions without re-execution on the main network.
ZK-SNARKs vs. ZK-STARKs
Both zk-SNARKs and zk-STARKs refer to the same cryptographic technology of validating proofs in a really efficient and private way. However, these two tools are different in their implementation. SNARKs produce succinct and non-interactive proofs, while STARKs produce scalable and transparent ones. Weβll cover the difference next.
What Are ZK-SNARKs?
ZK-SNARK Definition
ZK-SNARKs, or βZero Knowledge Succinct Non-Interactive Argument of Knowledge,β are cryptographic proofs that allow one to validate the claim without repeating lengthy computations and keeping some inputs private.
Inner Workings & Principles
The Succinct part ensures that the verification process doesnβt take as much time as the computation. Otherwise, the verifiers would compute the output themselves. You can achieve this with random sampling, but the process will be fragile: a random check would never spot a deliberately inserted error. The answer to the problem is polynomial commitments, and the three main ways theyβre implemented are FRI, bulletproofs, and Kate. We wonβt go into details because itβs really heavy in the math department, but you can read Buterinβs article.
An important feature of SNARKs is the Non-Interactive part, where thereβs no need for constant interaction between the prover and verifier. Interactive proving requires both parties, which limits its power. Any generated proof couldnβt be independently verified without initiating a new conversation between the prover and verifier, which is not cost-effective.
With a shared key (a.k.a public parameters) between the prover and verifier, these proofs allowed the prover to establish knowledge of certain data without actually revealing it. Non-interactive proofs streamlined the process, necessitating just one round of communication. The prover inputs the secret data into an algorithm to generate a zero-knowledge proof, which the verifier then checks using another algorithm. Once established, this proof can be verified by anyone with a shared key.
Importance Of A Trusted Setup In ZK-SNARKs
ββThe shared key used for non-interactive proofing, known as the Common Reference String (CRS), is crucial for the protocolβs security. Any compromise in CRS can enable dishonest provers to fabricate false proofs. Multi-party computation (MPC) is utilized to counteract these threats, with multiple participants contributing random values during a trusted setup ceremony.
The zk-SNARK protocolβs integrity relies heavily on this trusted setup phase. Any missteps can threaten the security of all circuits of the ZK-EVM. Given its importance, we recommend undergoing a blockchain protocol audit to ensure the setup is executed correctly.
Applications & Use Cases
The first real use case of zk-SNARK in Web3 is Z.cash β a cryptocurrency that utilizes ZK-proofs for enhanced transaction privacy. Before its launch in 2016, zk-SNARK was just academic research.
Z.cash has contributed to the widespread use of this concept in ZK-rollups to enhance scalability. ZK-SNARKs have been applied in layer 2 protocols known as ZK-rollups to enhance scalability. Popular ZK-rollups include Loopring, zkSync, ZKSpace, Aztec, etc.
What Are ZK-STARKs?
Definition
ZK-STARKs, or βZero Knowledge Scalable Transparent Argument of Knowledge,β are a specific type of zk-SNARKs. STARK protocols are ideal when working with witnesses of large size. They also provide higher transparency.
Inner Workings & Principles
ZK-STARKs have higher verification overhead than zk-SNARK, but they are way more cost-effective when working with big witnesses. In other words, STARK is a great solution when you need scale.
Another important feature of the STARK protocol is no need for a trusted setup because it uses publicly verifiable randomness to generate public parameters. Hence, itβs considered more transparent for situations where the credibility of the CRS process is unknown.
Applications & Use Cases
Like zkSNARKs, zkSTARKs are used for generating validity proofs to confirm the integrity of all the computations and transactions for ZK-Rollups. The pioneer project in zk-STARKs is Starkware. The company has developed its ZK-friendly language Cairo and the Starknet layer 2.
Comparing ZK-SNARKs vs ZK-STARKs
ZK-SNARK
ZK-STARK
Proof Size
Low. Allow for EVM data availability
High. Driving the costs up
Trust Setup
Requires a trusted setup
Does not require a trusted setup
Verification Time
Fast verification times
Faster times only with large datasets
Quantum Security
Not quantum-resistant
Quantum-resistant
Transparency
Less transparent due to trusted setup
More transparent using public verifiable randomness
Scalability
Less scalable, linear increase
Highly scalable
Use Cases
Best for systems where proof size and speed are key
Best where transparency and quantum-resistance are priorities
Differences:
Data Availability: The largest advantage of zk-SNARK over zk-STARK is data availability, which explains why they are more popular, especially in L1 rollups.
Security: ZK-SNARKs require a trusted setup involving the creation of a Common Reference String (CRS). If malicious actors access this setup data, they could produce false proofs. One potential solution is an MPC ceremony that relies on honest participants. Conversely, zk-STARKs donβt rely on such setups, making them quantum-resistant and less susceptible to potential threats.
Transparency: ZK-SNARKβs trusted setup might be perceived as less transparent due to its reliance on a CRS and the need for trust in participants to act honestly. In contrast, zk-STARKs are innately more transparent, depending on public randomness to establish parameters, which ensures open and trustless verification.
Scalability: Both cryptographic methods offer scalability for blockchains. ZK-SNARKs scale linearly with the size of the underlying computation, while zk-STARKs, although having larger proof sizes, are better suited for larger computations. Their proving and verification times increase quasilinearly, which can make them faster than zk-SNARKs for extensive datasets.
Use Cases: ZK-SNARKs are commonly used in privacy coins, identity verification, and decentralized finance (DeFi), benefiting from their compact proof sizes and consistent verification times. Meanwhile, zk-STARKs, due to their transparency and scalability benefits, are prominently utilized in Layer-2 solutions.
SNARK and STARK in ZK-EVM
A critical and emerging transition in the block validation process is the rise of ZK-EVMs.
ZK-EVM enables EVM (Ethereum Virtual Machine) execution for layer 2 protocols known as ZK-rollups. Some of these rollups are already in progress: ZK-EVM Community Solution, Polygon zkEVM, ZKSync Era, Scrollβs ZK-EVM, and others.
There are generally four types of ZK-EVM depending on the level of compatibility and equivalency with EVM. For example, Ty[e 1 ZK-EVM permits a 1:1 EVM compatibility: smart contracts written for Ethereum can be deployed as it is on ZK-EVM-based layer 2. So, Solidity can be used instead of dedicated languages for ZK-proofs like Circom and Cairo.
Here, itβs important to mention that modern ZK-EVMs employ both SNARK and STARK for higher efficiency. Another caveat is that βzero knowledgeβ is not used in existing ZK-Rollups, only succinctness (computation compression).
Conclusions & Final Thoughts
Key Features Of ZK-SNARKs:
High data availability but linear scalability.
Possibility of a non-interactive computation.
The security of zk-SNARKs hinges on the CRS setup. An error here would affect all circuits and allow false proof generation.
ZK-SNARKs are preferred for their compact proof sizes and consistent verification time, making them cost-effective for L1 verification in ZK-rollups.
Key Features Of ZK-STARKs:
No need for the initial trusted setup.
Very salable. Especially when handling extensive data, as their proving and verification times increase slower than zk-SNARKs.
Larger proof sizes result in higher verification costs.
ZK-STARKs are resistant to quantum computing threats.
ZK-SNARKs and ZK-STARKs are groundbreaking cryptographic tools that can revolutionize how we view scalability and privacy in blockchain systems. Many believe that ZK-STARKs is an improvement from zk-SNARKs because of its quantum-resistance, scalability, and transparency. Yet, the current downside with STARKs is larger proof sizes and higher costs. Hence, SNARKs wonβt go anywhere anytime soon.
As research progresses, itβs clear that both will continue to play pivotal roles in shaping the future of decentralized systems and ensuring cheap, swift, and private transactions.
Resources
Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). βScalable, transparent, and post-quantum secure computational integrity.β https://eprint.iacr.org/2018/046
The blockchain industry has been grappling with scalability issues, which have hindered widespread adoption due to its technical constraints. As the demand for blockchain, decentralized applications (dApps), and transactions increases, the limitations of existing networks become increasingly apparent. High transaction fees and network congestion have plagued platforms like Ethereum, hampering their ability to support large-scale
The experimental semi-fungible token standard, ERC-404, combines elements from ERC-20 and ERC-721 tokens. Despite rising popularity, it has yet to secure an official Ethereum Improvement Proposal (EIP) designation. However, its unique attributes, such as enabling fractional ownership of NFTs and enhancing liquidity, coupled with the potential for automated NFT minting and burning processes, suggest a
Decentralized applications (dApps) are software that run on a decentralized network, often using blockchain technology. These applications can serve various purposes for end users, such as brokers, art collectors, traders, investors, and documents of public trust. However, their functionality and value attract malicious groups aiming to exploit vulnerabilities for financial gain. This article explores real-world examples of dApp security breaches, their attack vectors, and the lessons learned.