How do zk-rollups achieve data availability and privacy on Ethereum?

23 Eyl 12:24

ZK‑rollups keep the data‑availability guarantee by publishing a *compressed calldata* blob on‑chain for every batch – essentially the Merkle root of the off‑chain state and the list of transaction calldata hashes. The actual transaction payloads stay off‑chain (usually in a data availability layer like Celestia or simply in the rollup operator’s blob storage), but because the root is on‑chain anyone can reconstruct the full state by downloading the blob and verifying the Merkle proofs. The zero‑knowledge proof (usually a SNARK or PLONK proof) that the operator posts alongside the root proves, in a succinct way, that the new state root is the result of applying all the private transactions correctly, without revealing the inputs. Validators (or “verifiers”) only need to run the proof verification algorithm on‑chain – it’s a few dozen megacycles, far cheaper than re‑executing every transaction – so they can be sure the state transition is valid even though they never see the raw data. Compared to optimistic rollups, ZK‑rollups give you instant finality because the proof is verified immediately, but you pay a higher upfront cost for proof generation and you rely on the data‑availability layer to serve the off‑chain blobs quickly; if the blob is delayed, users can’t reconstruct the state until it’s available, which can add latency. Optimistic rollups have cheaper posting costs and only need a fraud‑proof window, but they suffer from longer challenge periods before finality. For a hands‑on start, I’d suggest playing with the zkSync Lite testnet – their docs walk you through building a simple Solidity contract, generating zk‑proofs with the `zksync-cli`, and fetching the calldata blob from their DA service. The “ZK Rollup Primer” from Aztec and the PLONK tutorial on the Matter Labs blog are also solid reads that break down the cryptography without drowning you in math.