You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
ZK-Rollups
Entities
In today’s rollup world, the L2 teams building rollups (zkSync, Starkware, Arbitrum, Optimism, etc.) still play a critical, centralizing role in the L2 process. At a high level, there are three entities involved in a rollup transaction: the user on the rollup, the rollup operator, and the Ethereum L1. The rollup operator between the user and Mainnet has tremendous responsibility and some power
Understanding rollup economics from first principles
Within this framework, there are also three crucial actors in the collection, execution, and finalization of a ZKR block: sequencers, provers, and validators. Sequencers are a small set of nodes that run this specialized hardware, receive, order, and compute the transactions. Typically, they aren’t very transparent and/or auditable and are run by the L2 team. Provers are the nodes, also generally run by the L2 team, that generate the validity proof. Sequencers and provers can generally be lumped together in rollups’ early days. Validators are a much larger set of L1 nodes that verify the validity of the ZK-proofs submitted by the provers. This group serves to hold the provers accountable and ensure censorship resistance.
To describe the process in further detail:
-
A highly-compressed batch of L2 transactions is combined with the current state root (sequencers)
-
The combination is sent to an off-chain prover
-
The prover computes the transactions, generating a validity proof of the results
-
The prover sends the validity proof to on-chain validators (Ethereum L1 nodes)
-
The validators confirm the validity proof
-
The smart contract on Ethereum's L1 that maintains the state of the rollup is updated to the new state
Trade-offs in Rollup Solutions. Source: Kyber Network
Limitations
ZK-rollups are (theoretically) faster and more efficient than Optimistic rollups (ORs), but they suffer from friction and compatibility issues with the Ethereum L1 versus ORs. The main reason for this: ZKRs face computational difficulties when composing smart contracts over ZK circuits. Validity proofs are mathematically complex and data-heavy, adding some upfront complexity compared to ORs that don’t use validity proofs. Currently, for ZKRs, time to finality is constrained by the ZK prover and how quickly it can generate the transaction proofs. The ZK proving process is relatively slow compared to other steps in the process, and under times of heavy congestion, the prover may struggle to keep up and serve as the bottleneck. However, it’s also highly parallelizable, which promises excellent improvements in the future.
Additionally, provers are the bottleneck (so to speak) in the data availability requirements for rollups. This is because, while validators don’t need access to all the transaction data (just the proof), provers do. They need all of the data to generate the validity proof initially. Also, if the provers in the system ever went down, new provers would need access to all data to come online and resume operations. Making all of the data available on the Mainnet lets anyone reconstruct the state, even if the sequencers or provers disappear.
Despite rollups providing superior security guarantees to many alternative scaling solutions, the risk of a smart contract bug persists. Rollups are still relatively new and pushing the EVM design's boundaries. New code always runs the risk of having errors/bugs.
Consequently, many rollup operators maintain upgrade keys, meaning they can change the code. In many cases, there’s a multi-sig with an upgrade threshold time, whereas, in others, the team can arbitrarily alter the code. Rollup teams hold on to this centralizing power to strike a balance between safety and trust minimization. If a catastrophic bug is uncovered in their nascent implementation, the upgrade keys can be used to fix the bug. For a rollup to be genuinely secure and decentralized, the protocol must mature and the upgrade keys removed.
Risk Framework in Ethereum Smart Contract Rollups. Source: Delphi Digital
The other disadvantage innate to early ZKRs is the reduced compatibility with the Ethereum Virtual Machine (EVM). Optimistic rollups sacrifice some scalability for increased compatibility with the EVM, even reaching EVM equivalence. This is exceptionally critical as composability is paramount in the Ethereum ecosystem and enables developers to deploy code and projects on the secondary chains easily.
Moreover, most ZK-rollups are often incompatible with EVM due to their inherent complexity, making them a challenge to work with and design general-purpose apps to be built atop them. This complexity has led many teams, such as Scroll, Polygon, and zkSync, to work towards a zkEVM.
