The Art of Secret-Keeping
On supercharging blockchain projects with zero-knowledge
Contents
Zero-knowledge: But ser, I went to school (Introduction)
We set the stage regarding rollups in the previous article and covered the forever idealistic optimistic rollups. Now we are going to meet its more pessimistic cousin, ZK-rollups. It’s going to be a journey. First stop - zero-knowledge proofs.
Zero-knowledge: But ser, I went to school
Let’s get a working understanding of just what zero knowledge (ZK) means. Just to clear the air, it definitely does not mean the lack of knowledge; well, kind of.
Zero-knowledge proof (ZKP) is a fairly new cryptographic mechanism that allows a party (prover) to prove to another party (verifier) that they have knowledge of a specific piece of data without revealing the data in question. This may be a lot of jargon for some, so let’s break it down.
Imagine you have a secret word, and you want to prove to your friend that you know the word, without actually telling them what the word is. With ZKPs, you could prove to your friend that you know the word by giving them a series of clues or hints that only someone who knows the word would be able to give. For example, you could tell your friend the number of letters in the word, or give them the first letter of the word. Through these hints, your friend can become convinced that you really do know the secret word, without you ever having to reveal the word itself.
This whole zero-knowledge concept is especially important now that we’re all in the digital age. With all the shady shenanigans that go on, there is now more than ever a need to keep our communication and transactions safe and private. And that’s where ZKPs come in!
It can be used to prove that you know a password or other secret information without actually sending the actual details over the internet, making digital interactions more secure and private. There are also other cool use cases, like:
Verifying your identity without having to share your entire profile
Creating immutable digital signatures
Keeping your transactions private
All this means that the sender, receiver, and how much moolah is being moved around is kept hush-hush. This is super helpful when you want to keep things on the down low, especially during times when you are making big ticket purchases.
Practical applications of ZK proofs
Privacy-preserving authentication: Authenticate a user without revealing their identity or any other sensitive information.
Use case: any situation where privacy is paramount, such as online voting systems.
Secure online transactions: Enable private transactions between parties, without revealing transaction amounts or other sensitive information.
Use case: Financial transactions or medical records
Digital signatures: Sign your authorisation in a secure manner that is difficult to forge
Use case: Document verification, contract signing
Password security: Verify that a user knows a password without actually transmitting the password over the internet, preventing data breaches and protecting sensitive information
Use case: Password reset, multi-factor authentication, password storage
Cryptocurrency transactions: Secure privacy and security while transacting digital assets and tokens
Use case: Massive private transactions, fraud detection
Zero-knowledge rollups
Now that we have a fairly working understanding of ZKPs, let’s orient ourselves to zero-knowledge in the context of rollups.
Like other rollups, zero-knowledge rollups (ZK-rollups) batch transactions and execute them off-chain within their own Layer 2 environment. This boosts efficiency and throughput without sacrificing security or decentralization.
The key feature of ZK-rollups is the use of ZKPs to validate the compressed transactions. When the compressed transactions are submitted to the blockchain, they are accompanied by a zero-knowledge proof that serves as evidence that the transactions are valid. And it does so without revealing any details about the transactions themselves!
How do ZK-rollups work?
Broadly speaking, the primary components of zero-knowledge rollups are:
Smart contracts on Ethereum
Prover
Verifiers
Transactions are submitted to the prover for batching and generating their corresponding zero-knowledge proof, rubber stamping their validity. The verifiers are a group of nodes (managed by developers) responsible for checking these proofs, and submitting them to the contracts. No information is shared between the prover and verifiers.
With regards to the smart contracts themselves, they act as entry points in the execution cycle and serve various functionalities. These range from saving rollup blocks to tracking fund deposits and withdrawals.
The second layer of a ZK-rollup is powered by a virtual machine, called zkVM. This is the off-chain environment that we previously referred to. Similar to how Ethereum has the EVM (Ethereum Virtual Machine), the rollup has its own computation engine to process state changes as a consequence of transactions. This helps take the load off the base layer.
The accounts and balances of the ZK-rollup are represented by two Merkle trees. Merkle roots reflect the state changes resulting from transactions. These are subsequently published to the smart contracts sitting on the base layer.
Two types of ZKP systems
We should be aware that there are variations of ZKP systems used in rollups: zkSNARKs and zkSTARKs. While both aim to provide efficient and secure solutions for ZK rollups, they differ in their underlying techniques and characteristics.
zkSNARKS
Short for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, zkSNARKS are based on the idea of non-interactive proof. This means that the prover and verifier do not communicate with each other during the proof process - a suitable attribute for blockchains applications.
💡 The succinctness property of ZKP refers to the fact that the proof size, or the amount of information required to prove the statement, is very small compared to the size of the statement itself. Thus proofs can be verified with a relatively small amount of computation and memory, even for very complex statements.To create a proof using zkSNARKs, a prover uses a private key to generate a proof of the statement they want to make. This proof consists of a series of mathematical equations that demonstrate that the statement is true. The verifier, who has access to the corresponding public key, can then use this proof to verify that the statement is indeed true without gaining any knowledge of the statement itself.
The cornerstone of a zkSNARK system is the trusted setup ceremony - a process in which a group of participants contribute randomness that is used to generate a pair of public and private keys. It should only be run once by a trusted third party.
During a standard trusted setup ceremony:
A group of participants work together to produce a set of cryptographic parameters. Each participant uses their own locally generated secret information to create data that contributes to these parameters.
A reliable setup will guarantee that the secret information remains undisclosed, used solely as prescribed by the protocol. The secret information will also be entirely destroyed once the “ceremony” concludes.
As long as at least one participant is honest (i.e. remain uncompromised and destroy their own secret data), the entire setup can be deemed secure. Even if the rest of the participants aims to reconstruct the final setup, no one will be completely sure about the missing information.
If the secret information used to create the keys during the event are not destroyed, they can be used to create false proofs through insider collusion. Participants could share their secret information and coordinate to forge transactions that would indistinguishably be genuine. This is a key drawback with zkSNARKs.
Other possible failures with a trusted setup ceremony:
A common bug that leaks the randomness of information
Procedural weaknesses such as insufficient verification mechanisms, flawed randomness generation, or insecure communication channels
Inadequate destruction of secrets that allow remnants of the information to persist, potentially allowing unauthorised access to the system or compromising its security
Another commonly touted disadvantage is that zkSNARKs are not quantum resistant (i.e. secure against an attack by a quantum computer). But let’s be honest; when quantum computing becomes mature enough to challenge zkSNARK systems, we would have much more pertinent problems to address with modern cryptography.
Example of a zkSNARK-based protocol: zkSync.
zkSTARKS
Brought to you by the same group that delivered zkSNARKs, zkSTARKs (Zero-Knowledge Scalable Transparent Argument of Knowledge) is meant to be an improvement. How you might ask?
zkSTARKs have similar properties as zkSNARKs, but there are a few differences:
zkSTARKs do not require a trusted setup process. The randomness used by the verifier is publicly available, making them more secure.
zkSTARKs are quantum resistant.
zkSTARKs generate proofs quicker. Verification of these proofs are also faster, at scale, compared to zkSNARKs as shown in the charts below.
For clarity, while zkSTARKs generate proofs quicker, the proof generated is of much larger size than SNARK proofs, making it more gas-intensive to verify on Ethereum.
In a nutshell, SNARKs and STARKs come with different advantages depending on the user’s specific requirements. SNARKs are considered faster and more efficient. However, they rely on a trusted setup ceremony, which can potentially compromise security. In contrast, STARKs offer enhanced security by not requiring a trusted setup. Still, they are slower to verify and have larger proof sizes. Despite potential security drawbacks, SNARKs have been more widely adopted due to being developed earlier than STARKs.
Example of a zkSTARK-based protocol: Starknet
Enhancing Ethereum’s privacy with zkEVM
So ZK-rollups didn’t use to be compatible with EVM (Ethereum Virtual Machine) - meaning you can’t simply deploy your Solidity contract onto the Layer 2 and roll out your dApp. For obvious reasons, this held ZK-rollups back in terms of utilisation.
Well, till recently that is.
ZK-EVMs are built on top of the EVM, which means that they can execute smart contracts in a manner compatible with ZK cryptography. Additionally, they provide a layer of privacy by allowing users to perform transactions and execute smart contracts without revealing any sensitive information.
With the magic of ZK-EVMs, we can enjoy all the benefits of a ZK Rollup together with the same developer experience of building on an EVM chain.
💡 The EVM was not designed to support zero-knowledge proofs. This made the construction of ZK-EVMs difficult. Not all ZK-EVMs are the same - different approaches have different tradeoffs.Not all ZKs are created equal
Now that you have gained a sufficient appreciation of the various concepts and terminologies surrounding zero knowledge and their rollups, we shall inject some necessary contract at this juncture.
Most ZK-rollups are actually validity rollups; they primarily use the succinctness property of ZKPs. What this means practically is that most ZK-rollups do not automatically propagate privacy features - with the exception of Aztec Network.
Moreover, ZK-EVMs have varying degrees of EVM compatibility. There are two main approaches:
Bytecode compatibility
Language compatibility
What are the actual differences between the various types of compatibility?
Bytecode compatibility
High-level languages like Solidity are compiled into bytecode which is low-level, machine-readable code. For simplicity, you can assume that the bytecode is a sequence of 1s and 0s. ZK-EVMs that can execute the same bytecode as the EVM are referred to as bytecode-compatible.
How it works:
Developers can use the exact same Solidity (or other high-level language) code, compiler, and bytecode while drawing on the scalability and security of ZK circuits
The behaviour of the EVM is replicated by mapping the same opcodes onto ZK circuits. This is something of an engineering feat. While it leads to more computationally heavy proof generation, it does result in a simpler experience for developers.
This approach means that these types of rollups will be seamless as there are no changes to the developer experience. Both Scroll and Polygon are examples of bytecode-compatible ZK-EVMs.
Language compatibility
In contrast, language-compatible ZK-EVMs support EVM-friendly languages (e.g. Solidity, Yul). They do so by either translating them to a zk-friendly language (e.g. Zinc, Cairo) or compile them to produce bytecode that is dissimilar to EVM bytecode. Hence, they are not bytecode compatible.
This approach allows for better performance and efficient proof generation, overcoming the EVM’s limitations. The drawback is that developers may require to learn additional languages to better appreciate how Solidity gets compiled down in a non-EVM native fashion.
Starknet and zkSync are classified as language-level compatible. They argue that being incompatible with superior optimisations is far more sensible than being compatible to a sub-optimal design.
💡 Read more on EVM’s inherent limitations with ZKPs here. All in all, the future of ZK-rollups looks bright. As more developers and projects begin to adopt ZK-rollups, it is expected that the technology will continue to evolve and improve. There is also ongoing research into further optimising ZK-rollups for even greater scalability and privacy benefits. The rise of L2 solutions and interoperability protocols may also help to increase the adoption and use of ZK-rollups. As ZKPs continue to gain traction as a leading scaling solution for blockchains, it’s definitely a space to keep any eye on!