Patents Wiki
Back to briefings
InfoBlockchain

The 200-byte proof that lets a rollup inherit Ethereum's security

If you have sent a transaction on zkSync, Scroll, Polygon zkEVM, Linea, or Starknet, you have used Groth16. The proof attached to the batch of L2 transactions you signed is a Groth16 SNARK, and the gas the rollup pays to verify it on L1 is the same roughly 200,000 gas that every other Groth16 verifier on Ethereum has paid for the last seven years. The proof itself is a few hundred kilobytes of preprocessed material plus a 200-byte blob that lands on-chain. That is the interface.

This explainer walks through Groth16 in the context of a zk-rollup: what the proof is, why it has the shape it does, and how an L1 verifier checks it. A new explainer of Groth16 by the zkSecurity team circulated on Hacker News at the end of May 2026 and is the technical anchor for this piece. The diagram at the end is the part worth saving.

Briefing registry

  • Topic: Groth16, the most widely used zk-SNARK in production, and how a zk-rollup uses it to inherit L1 security
  • Anchor source: zkSecurity, "Explainer of the most widely used zero-knowledge proof system" (May 30, 2026, Hacker News discussion)
  • Adjacent context: Starknet's STRK20 privacy framework with shielded transactions using zk proofs (May 2026, Reddit r/getblockio); a practitioner writeup of zk proofs in r/ethereum (June 2026)
  • Type: technical explainer, not a single new patent or paper
  • Date: June 05, 2026

Why a rollup cannot just post its transactions to L1

A rollup's economic promise is that it inherits the security of its parent chain. To do that, it has to convince L1 that the L2 state it is committing to is the result of correctly applying a batch of L2 transactions to the previous L2 state. There are two ways to do this.

The optimistic way is to assume the rollup operator is honest, post the new state root to L1, and let anyone who disagrees submit a fraud proof during a challenge window. That window is typically seven days, which is why withdrawing from an optimistic rollup is slow. The security argument is also fragile: if the fraud proof system has a bug, the system can be drained. This has happened. Multiple optimistic rollups have shipped with serious soundness issues that took months to fix.

The zero-knowledge way is to attach a SNARK proof to the batch. The proof says, in cryptographic form, that there exists a witness (the transaction batch) such that the rollup's state transition function, evaluated on the previous state root and that witness, yields the new state root. The L1 contract does not re-execute the L2 transactions. It verifies the proof. If the proof verifies, the new state root is canonical. There is no challenge window and no soundness gap. The cryptographic argument is what finalizes the state.

This is the design the zk-rollup ecosystem is built on. Groth16 is the proof system that makes it cheap.

A pairing-based proof that fits in three group elements

Groth16 was published in 2016 by Jens Groth. It is the proof system that nearly every production zk-rollup verifier contract on Ethereum uses. The reason is the verifier. A Groth16 proof is three group elements: A in G1, B in G2, and C in G1. The verification equation is a single pairing-product check.

e(A,B)=e(C,δ)⋅e(publicx,γ)e(A, B) = e(C, \delta) \cdot e(\text{public}_x, \gamma)

That is the whole verifier. It requires two pairings on the right and one on the left, which in EVM precompiles costs roughly 200,000 gas, give or take the precompile version. Other proof systems in the same family, like PLONK, require many more pairings, which is why they cost several hundred thousand gas. STARKs avoid pairings entirely but pay for it with much larger proofs (tens to hundreds of kilobytes) and a verifier that runs in logarithmic time over the trace. Groth16's 200-byte proof and its 200,000-gas verifier are not free, but they are the cheapest verification cost in the SNARK family.

Two properties matter for rollups. The proof is a constant size: it does not grow with the number of transactions in the batch. The verifier does not need to know the circuit, only the verifying key. The rollup operator can change the L2 execution trace, batch more transactions, swap out the EVM-equivalent logic, and the L1 verifier contract stays the same. The verifying key is a fixed description of the rollup's state transition function, and the operator must run a proving key that matches it.

The cost of those properties is the trusted setup. That is what most people have heard about Groth16 even if they have not heard of the verifier equation.

How a Groth16 zk-rollup works end to end

Core Architecture/Flow

The diagram above walks the full loop. The off-chain side is the prover. The on-chain side is the verifier. The trusted setup in the middle is a one-time, per-circuit ceremony that produces the proving and verifying keys.

Step by step:

  1. Trusted setup. Before the rollup ever processes a batch, a multi-party computation produces a structured reference string (SRS) specific to the rollup's circuit. The setup has two phases: a "powers of tau" phase that is universal across circuits of bounded size, and a per-circuit phase that turns the universal SRS into a proving key pk and a verifying key vk for the specific state transition function. The honest-participant guarantee is that as long as one contributor in the per-circuit phase destroys their secret randomness, the system is sound. A compromised setup would let the prover forge proofs of false state transitions. The major Groth16 rollups (zkSync Era, Polygon zkEVM, Scroll, Linea) have all run these ceremonies with public, auditable contributions.

  2. Off-chain L2 execution. A sequencer collects a batch of L2 transactions. The current L2 state root s_in is public. The rollup's state transition function f takes the witness w (the batch plus auxiliary state) and s_in, and produces s_out (the new state root plus auxiliary outputs).

  3. Circuit and witness. The function f is compiled into an arithmetic circuit, then into a rank-1 constraint system (R1CS), then into a quadratic arithmetic program (QAP). This compilation is the bulk of the engineering work in a zk-rollup. The witness w is the concrete input to the circuit for the current batch.

  4. Proving. The Groth16 prover, running on a server (sometimes called the prover, sometimes the relayer), takes the proving key pk, the public input (s_in, s_out), and the witness w, and produces the proof π = (A, B, C) in roughly a second on a fast machine, or minutes on a smaller one. The proof π plus the public input is what gets posted to L1.

  5. L1 verification. The verifier contract on L1, written once at deploy time, takes π, the public input, and the embedded verifying key vk, and runs the pairing check. The precompile cost is fixed; the math is one pairing-product equation. If it returns true, the new state root s_out becomes canonical for the L2.

  6. Finality. Once the L1 transaction containing the proof and the new state root is finalized, the rollup state is final. There is no challenge window and no assumption about operator honesty. The cryptographic argument is the finalization.

That is the whole protocol. The rest is engineering: reducing the L2 state transition to a circuit that can be proven in reasonable time, batching efficiently, and keeping the proving hardware cheap enough that the rollup does not have to be run by a single centralized sequencer forever.

What the proof buys you, and what it costs

The proof buys cryptographic finality. A zk-rollup that uses Groth16 has finality as fast as L1 finality. On Ethereum, that is roughly 12 to 15 minutes, depending on how you count slot time and safe block depth. The same security budget as L1, paid for in L1 gas, and a proof that the L2 state transition was correct. Compared to an optimistic rollup, the trade is flipped: the rollup pays a high per-batch proving cost (typically tens of thousands of prover-machine seconds, on GPU or FPGA hardware), but L1 verification is cheaper and finality is immediate. The optimistic rollup pays nothing in proving, but the user pays a week of waiting.

The proof also buys a clean soundness story. The argument is: the proof verifies, therefore the statement is true. There is no need to argue that the fraud proof system is not bugged, that the challenge period is long enough, or that the watchers are economically incentivized to watch. zk-rollups have started to displace optimistic rollups in 2025 and 2026 for this reason, even though the engineering cost is higher.

The Groth16 trusted setup is the big cost. A compromised setup means a compromised rollup. The prover could produce a valid proof of an invalid state transition and steal everything in the L2 bridge. The mitigation is multi-party computation with public, audited contributions, and the assumption that at least one contributor was honest. Modern Groth16 setups (the Aztec ceremony, the Semaphore ceremony, the Tornado Cash ceremony, the Hermez ceremony, and the per-rollup ceremonies built on top of the Perpetual Powers of Tau) have run with hundreds of participants. The 1-of-N honest assumption is strong, and it is the only thing the protocol has to lean on.

A second cost is circuit specificity. A Groth16 proving key and verifying key are tied to a specific circuit. If you want to change the rollup's state transition function, you need a new trusted setup. Most Groth16 rollups are conservative about upgrading their circuits for this reason, and some have moved toward PLONK-style proof systems or Halo2-style recursive proofs, where one proof can verify other proofs and the universal setup can be reused.

A third cost is the prover. Groth16 provers are memory-heavy. The proving key for a non-trivial rollup circuit is hundreds of gigabytes, and a single proof takes hundreds of millions of multiplications over an elliptic curve. The hardware is a serious line item in the rollup's operating cost. zk-rollups have been slow to fully decentralize their sequencer and prover for this reason: it is cheaper for one operator to run a single machine than to spin up a market for proving.

Limits, risks, and what to watch next

The limits of Groth16 show up in three places. The first is the trusted setup itself. The honest-participant assumption has been audited to the point of being a community standard, but it is still a trust assumption, and the ZK community has been investing heavily in transparent-setup proof systems like PLONK, Halo2, and STARKs for this reason. The second is proof-system upgradability. A Groth16 rollup that wants to change its state transition logic must re-run a ceremony. That is a multi-month coordination problem, and Polygon zkEVM and Scroll took so long to ship after their initial announcements partly for this reason. The third is the prover's cost. The economics of running a Groth16 prover at rollup scale are non-trivial, and the rollup's prover is usually a single entity. No amount of cryptographic soundness fixes that.

The protocol itself does not have a limit on block time. The prover does. Proving time for a rollup-sized batch is still in the minutes on commodity hardware and seconds on custom hardware, which means the rollup cannot post a new state root every L1 slot. Block time on the rollup is bounded by the prover, not by L1. Several teams are working on hardware acceleration, recursive proof aggregation (a proof that verifies other proofs), and specialized compilers that produce smaller circuits. Each of these changes the cost calculus.

The things worth watching in the next year are the first Groth16 rollup that fully decentralizes its prover market, the first widely-used recursive-aggregation scheme that aggregates Groth16 proofs across rollups, and the first production migration of a rollup from Groth16 to a transparent-setup proof system.

Sources