Understanding zero-knowledge layer-2 scaling
There has been a lot of focus on layer-2 scaling solutions recently and it would be fair to say that 2022 will be the year of layer-2 scaling solutions. There are so many competing solutions in this space and so much new terminology to keep up with, that it can quickly get confusing for someone who is beginning to delve into this space.
In this post, my goal is to categorise this information into easy to understand points. We will unpack all the complex jargons used in the layer-2 scaling space.
Note: This document will be updated with time.
So, what exactly is a rollup?
The word rollup here refers to a batch of transactions which are processed together on layer-2. So essentially multiple transactions are “rolled up” in a batch.
The two main types of rollups are:
- Optimistic rollups
- zkRollups based on zero-knowledge proofs
Optimistic rollups are used by:
- Optimism
- Arbitrum
zkRollups are used by:
- zkSync
- Starkware
- Mir protocol (Polygon Zero)
- Polygon Miden VM
- Polygon Hermez
I created the following diagram to summarise all the types of rollups and the projects building using these rollups.
In this post, we will focus on the zero-knowledge proof-based scaling systems only.
At a high-level, we can say that the design of all zero-knowledge proof-based L2 scaling systems share some similarities such as the following:
1. There is an on-chain verifier contract on layer-1.
2. There is a prover on layer-2 which generates a mathematical proof for a batch of transactions (also known as rollups)
3. There is a sequencer on layer-2 (mostly centralised at the moment) which includes incoming transactions in a block which are submitted to the prover for generating the proof.
4. The on-chain verifier will verify the proof submitted by L2 prover and if it is accepted, the new state changes are committed to the L1 blockchain.
5. They benefit from the security of layer-1 aka mainnet aka Etherum blockchain.
Types of ZK proof systems
Interactive vs Non-interactive
Interactive: messages are exchanged back-and-forth between the prover and verifier. This is expensive to do on a blockchain due to the cost involved in interacting with the Ethereum blockchain.
Non-interactive: messages are sent only one way from the prover to verifier. The ZK-based scaling solutions used in layer-2 are non-interactive.
Zero-knowledge proof system names
zkSNARK — used in zkSync and Polygon Hermez
zkSTARK — used in Starkware and Polygon Miden
PLONK and Halo variants — used by Mir protocol (Polygon Zero)
plonky2 — used by Mir Protocol (Polygon Zero)
Types of proof
validity proof vs fraud proof
validity proof: These proofs essentially attest to the fact that there is a set of transactions which when applied to a previous state will result in the new state thereby confirming that all the transactions in the block are valid. Since Ethereum blockchain has information about both the previous state as well as the new state (submitted by L2), it can verify this validity proof.
These validity proofs are used in the following:
zkSync
Starkware scaling solutions such as StarkEx and StarkNet
fraud proof:
They are used in the following:
Optimism
Arbitrum
Different ZK-based layer-2 scaling solutions can be compared with each other based on specific metrics which are important from various perspectives (performance, cost, usability, developer-friendly, compatibility)
- Withdrawal time
- Proof size
- Security
- EVM compatibility
- Ethereum signature compatibility
- Blockchain composability
- Wallet support
- DEX support
- Transactions per second
- Gas fee
- Proof generation time
- Verification time
- Quantum computing resistant cryptography
- Data availability modes
We will discuss some of the above metrics in this post.
Withdrawal time
This is the time taken to move the assets from L2 to L1. In order to use the layer-2 scaling solution, users have to deposit their crypto assets on layer-2 and trade on it. They can request a withdrawal to move the assets back to L1 however this does not happen instantly.
Optimistic rollups (Optimism / Arbitrum) — 1 to 2 weeks. This duration is also called the challenge period during which any observer can submit a fraud proof to invalidate a block which contains invalid transactions.
Faster withdrawal on zkSync — 30 minutes to 7 hours
proof size
big proof vs small proof
Proof sizes are an important metric to pay attention to when comparing layer-2 scaling systems. There is a trade-off between the proof size and security.
zk-STARK — they have a bigger proof size (40KB to 50KB) and as a result the verification time is more.
zk-SNARK — smaller proof size (approx. 280 bytes) but they use a trusted setup. These systems usually try to decentralise the “trusted setup” by using multi-party computation systems.
Ethereum signature compatibility
By default, layer-2 scaling solutions such as StarkNet do not support Ethereum signatures (which use ECDSA). They use their own cryptographic primitives. Due to this, each account address on layer-1 has a corresponding StarkNet account address.
zkSync 2.0 will add native support for Ethereum addresses.
EVM compatibility
Zero-knowledge proof-based scaling systems do not benefit from EVM compatibility unlike Optimistic rollup solutions such as Optimism and Arbitrum.
Scaling solutions from StarkWare such as StarkNet and StarkEx provide their own turing-complete language called Cairo which can be used to write StarkNet contracts.
There are transpilers such as Warp being developed by Nethermind which will allow porting solidity-based smart contracts to Cairo.
zkSync has its own virtual machine called ZincVM and its own programming language called Zinc.
However, it supports porting solidity-based contracts to ZincVM as well.
Blockchain composability
StarkNet’s scaling solution StarkEx is a single app-rollup solution and does not support composability.
StarkNet on the other hand supports composability, which means smart contracts can invoke each other.
zkSync 2.0 adds support for composability as well.
Post-quantum secure
Post-quantum secure means whether the cryptographic primitives used in the zkRollup scaling solutions are resistant to quantum computing attacks.
zk-SNARK uses cryptographic primitives such as ECC and ECDSA which are vulnerable to quantum computing attacks.
zk-STARK uses cryptographic primitives such as collision-resistant hashes which are post-quantum secure.
Data availability
Data availability is very important in layer-2 scaling solutions because the verifier needs to have some information about the previous state and the new state of the system in order to verify the validity proof submitted by L2 to L1.
This data usually refers to “state delta” which is the difference between the new state and the previous state. Such minimal data on L1 is sufficient to validate the proof and commit the changes to L1 chain if the proof is accepted.
There are different data availability modes such as following:
Validium: In this data availability mode, the data is stored on third party providers such as the Data availability committee (DAC) in the case of StarkWare scaling solutions.
Voilition: This is a hybrid between zkRollup and Validium data availability modes.
