Over the past few weeks, we have covered some of the leading projects trying to help Ethereum scale, including Polygon, Optimism and Arbitrum. Optimism and Arbitrum have used optimistic rollups as a scaling solution, while Polygon has taken a broader approach and allows developers to choose which solution suits them best. Yet, they are all exploring how they could use Zero-knowledge rollups (ZK-rollups) to scale Ethereum in one form or another.
ZK-rollups are touted as the next generation in scaling solutions; however, they still have some limitations in their implementation. Developers across the globe are working to solve these issues and are coming closer to creating a trustless scaling solution that addresses Ethereum’s design tradeoffs.
What Are ZK-Rollups?
ZK-rollups increase Ethereum’s throughput by moving computation and state storage off the mainnet. They do this through a complex piece of cryptography called Zero-Knowledge proofs (ZKPs).
The theory behind ZKPs has existed for over 40 years, first being proposed in 1985 by Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The challenge was to create a technique through which someone could limit the information they provide a malicious verifier by only giving proof of the information itself. Or in other words, it is a method by which one party (the prover) can prove to another party (the verifier) that a given piece of information is true without the need to reveal the information.
The ZKP solution was revolutionary at the time, and they received the Gödel Prize for their work. Unfortunately, the actual practical implementation of ZKPs wouldn’t happen for several decades. As technology has evolved, the ability for us to implement ZKPs meaningfully also has, and they have now started to find a fit in various computer science applications, including blockchain.
There are several analogies that people have used to convey the concept of ZKPs, one of the most famous being the Ali Baba Cave.
The Ali Baba Cave
The Ali Baba Cave analogy was first published in 1990 by Jean-Jacques Quisquater and others in a paper titled “How to Explain Zero-Knowledge Protocols to Your Children”. What is also important to note is that there are two types of ZKPs, interactive and non-interactive. Below is an example of the former.
In the story, there are two people, Bob and Alice. Imagine there is a cave shaped like the one below with a door at the end.
Source: Wikipedia
Paths A and B both lead to the door, but the only way to open it is with the secret password. Bob wants to know whether Alice has the secret password. Alice says she does but that she doesn’t want to tell Bob what it is.
To prove to Bob that she does know the password, they can use the door at the end of the cave to prove it. To do this, Alice enters the cave alone and chooses path B (unbeknownst to Bob) to get to the door. At this point, Bob can come to the entrance and shout a random path for Alice to exit from, either A or B.
Source: Wikipedia
As Alice knows the password, she can pass through the door and emerge from path A. At this point, Bob can start to believe Alice.
Source: Wikipedia
Nonetheless, the chance that Alice chose pathway A initially still exists. Therefore, to rule out any possibility, Bob and Alice can repeat the exercise a number of times until the statistical probability of Alice not knowing the password and just getting lucky is ruled out (20 times would make it roughly one in a million). This makes ZKPs a probabilistic proof rather than a deterministic one. As one can imagine, this was also an early limitation as going back and forth between the two parties used a significant sum of resources, significantly limiting the scope of its implementation. This changed with the introduction of the Fiat-Shamir heuristic, a technique of taking an interactive proof and creating a digital signature based on it, negating the need for the back and forth.
Whether interactive or not, a valid ZKP needs to meet three requirements:
Completeness – a true statement should be provable to an honest verifier by an honest prover.
Soundness – if the statement is false, it is improbable for a dishonest prover to convince the honest verifier.
Zero-knowledge – if the statement is true, then no other information needs to be communicated between the prover and verifier for it to be accepted.
A proof with the three properties listed above creates an efficient and secure system that provides privacy to its end users.
Today there are two primary implementations of ZKPs, zk-SNARKs and zk-STARKs.
zk-SNARKs
Today zk-SNARKs are the most common implementation of the technology in the blockchain industry. SNARK stands for “Succinct Non-Interactive Argument of Knowledge.” It derives its name from one of the core features it uses to provide the proof it does, succinct compression. You may also notice that it uses non-interactive proofs, which differs from the cave analogy, employing a derivative of the more modern version pioneered by Fiat and Shamir and other works by Claus Schnoor. This means that instead of going back and forth between verifier and prover, they limit communication between one another to reduce gas fees and the computational resources required.
Most crypto networks have some form of a check to ensure that those who want to use the network meet specific requirements. Examples include: do they have enough funds to send or whether they have signed the transaction with their private keys. Using zk-SNARKs, a user can prove all this through mathematics without revealing any information, including the address or transaction amount.
One of the most significant drawbacks of using zk-SNARKs is that you generally require an initial trusted setup between the two transacting parties. This step is necessary because it sets the parameters for the proving system used and is called a Common Reference String (CRS). This obviously introduces limitations in how the technology can be implemented on a broad scale and creates additional trust assumptions. Yet, as with all problems, there are solutions, and this has come in the form of PlonK.
PlonK is a zk proving system that can handle universal preprocessed zk-SNARK constructions. In simpler terms, this means that one trusted setup could be used for multiple schemes instead of just one; however, this also has inevitable repercussions, such as an increase in the proof size and verification time. As a result, there are newer innovations that are being pioneered by projects like Polygon, such as Plonky2, that aim to verify proofs more efficiently. We expect this trend to continue as more people try to create effective scaling solutions. Another more recent approach is zk-STARKs which also comes with its own benefits and drawbacks.
zk-STARKs
zk-STARKs are a more recent innovation in the zero-knowledge space. STARKs stands for “Scalable Transparent Argument of Knowledge”. STARKs share several similarities with SNARKs; however, the technology has managed to remove the need for one of the most significant drawbacks of SNARKs, the trusted setup.
Instead of requiring a trusted setup, STARKs rely on publicly verifiable randomness when setting up the parameters for generating and verifying proofs. zk-STARKs also provide greater scalability as the time needed to prove and verify the proofs increases in a quasilinear fashion vs zk-SNARKs that scale in a linear fashion.
The one drawback of zk-STARKs is that the proof size is larger (40-50 kilobytes) than those created by zk-SNARKs (288 bytes) and therefore takes longer to verify. Nonetheless, the distinction between zk-SNARKs and zk-STARKs is beginning to blur as new breakthroughs such as Plonky2 further remove trust assumptions and increase quantum resistance.
zkEVM
ZK technology has been difficult to implement beyond basic transactions, and that is due to them not being inherently Ethereum Virtual Machine (EVM) compatible. The EVM is a virtual environment that takes in smart contracts (written in languages like Solidity) and converts them to EVM bytecode. ZK-rollups that have EVM compatibility have their own execution environment that supports this bytecode and allows smart contracts from Ethereum to migrate onto the roll-up without completely rewriting all the code. This allows developers to build as they would on Ethereum.
This was a monumental breakthrough in zk technology as it greatly expanded what was possible. There are several different types of zkEVMs that vary in their Ethereum equivalence. Vitalking Buterin wrote an excellent piece where he details these. Diving further into this technology is recommended, as it will likely be one of the core ways we scale Ethereum in the future.
Further Resources
Zero-knowledge technology is a highly complex computer science and cryptography topic. When combined with technological constraints, there is no wonder it has taken so long for it to go from a theoretical subject to being implemented practically in our day-to-day lives.
There are a few additional resources we recommend reading if you plan on going further down the rabbit hole:
An Incomplete Guide to Rollups – Vitalik Buterin
The Complete Guide to Rollups – Jon Charbonneau
Zero-Knowledge Rollups – Manik Jain
Conclusion
It is widely believed that ZK-rollups will form a pivotal part of scaling Ethereum in the future. While it is super exciting, it is worth being cognisant of the limitations still associated with the technology. Nevertheless, the technology itself is here to stay, and some of the best and brightest minds in the world are working on solving these issues.
Ethereum developers are making it easier for rollups to provide a viable way for it to scale while delivering almost an equivalent level of security.
We are super excited about how this technology is going to be used and the benefits it provides, such as efficiency and privacy.
–
If you are interested in staying up to date, please subscribe to our newsletter at etherbridge.co
This is not financial advice. All opinions expressed here are our own. We encourage investors to do their own research before making any investments.
