ZK-rollups have long been regarded as the endgame of Ethereum scaling. However, despite their importance to the Ethereum scaling roadmap, there is still widespread uncertainty about several key points:

1. What exactly is a zk-rollup?
2. What differs between application-specific and general purpose rollups?
3. What is a zk-EVM rollup? What do terms like EVM-equivalent and EVM-compatible actually mean, and how do they apply to rollups?
4. What is the current state of the zk-rollup ecosystem, and what does that mean for my project?

If you’re a developer looking to understand the next phase of Ethereum scaling, this article will (hopefully) help.

ZK-Rollups

ZK-rollups are made possible by a simple observation: proof systems like STARKs or SNARKs allow for a linear number of statements to be verified with sub-linear processing (e.g. 1000 statements → 10 verifier checks, 10,000 statements → 11 verifier checks). We can use this property to create massively scalable blockchain transaction processing as follows:

1. Users lock their assets in a zk-rollup smart contract on L1
2. Users submit transactions involving those assets to an L2 sequencer, which gathers them into ordered batches, and generates a validity proof (e.g. a STARK/SNARK) and aggregated state update for each batch
3. This state update and proof are submitted to and verified by our L1 zk-rollup smart contract, and used to update our L1 state
4. Users can use this L1 state (subject to different data availability mechanisms) to retrieve their assets, allowing for full self-custody and “Ethereum security”

Simplified ZK-Rollup Architecture

The gas cost of verifying the proof is sublinear to the number of transactions being proven, allowing for vastly more scale compared to direct usage of L1. To understand this process in more granular detail, I’d recommend Vitalik’s Incomplete Guide to Rollups or Delphi’s newly released Complete Guide to Rollups.