Misc
Plonky2 Explained: Recursive ZK Proofs for Rollups
October 23, 2026
12 mins read
Plonky2 is Polygon's recursion-first proving system. See how it uses FRI and the Goldilocks field to merge many ZK proofs into one Ethereum-ready proof.
Plonky2 is a proving system from Polygon Zero, written in Rust, that generates Zero-Knowledge Proofs (ZKPs) quickly and verifies proofs inside other proofs. That recursion lets a system merge many proofs into one constant-size proof, which cuts the cost of settling on Ethereum. Teams no longer debate whether ZKPs work; they debate whether proofs are fast, cheap and portable enough to become infrastructure. Rollups need a proof system that settles to Ethereum without making verification the main cost, and real-world asset (RWA) platforms need evidence they can hand to auditors without putting sensitive off-chain data on a public chain.
One status note matters: the official Plonky2 repository carries a deprecation notice and recommends Plonky3 as Polygon's next-generation proving system. Plonky2 is still a useful reference for Recursive Zero-Knowledge Proofs, ZKP aggregation and hardware-aware recursion design. Teams building on it should plan for long-term support and migration, especially for long-lived Verifiable Data workflows.
Key Takeaways
- Plonky2 treats Recursive Zero-Knowledge Proofs as a pipeline: many proofs in, one Ethereum-ready proof out.
- The Goldilocks field and 64-bit arithmetic directly shape Plonky2's performance on ordinary hardware.
- A FRI-based SNARK design gives Plonky2 a flexible time and space trade-off, which matters for Ethereum ZK scaling when calldata dominates costs.
- The same aggregation pattern applies to RWA evidence: many proofs about data and computations, compressed into one proof a counterparty can check.
Plonky2 as a recursion-first proving system
Plonky2 is a proving system from Polygon Zero built to generate Zero-Knowledge Proofs (ZKPs) efficiently and to verify proofs inside other proofs. This is what makes Plonky2 recursion-first: it turns verification itself into a provable computation. Polygon's own technical write-ups frame Plonky2 as a way to combine scaling properties associated with both SNARKs and STARKs through recursion and performance-focused engineering.
Plonky2 makes ZK proof aggregation practical under Ethereum constraints, so a ZK rollup can post one compact proof rather than a large amount of evidence.
What problem do Recursive Zero-Knowledge Proofs solve?
Recursive Zero-Knowledge Proofs solve the "too many proofs" problem that real systems create by default. In production, correctness is rarely a single statement. It is thousands of statements: per transaction, per batch, per circuit, per compliance rule, per update.
- Batch thousands of proofs into one: Instead of verifying N proofs, you verify one recursive proof that covers all N. This compresses verification work, not just bytes.
- Scale ZK rollup proof systems: A ZK rollup is only as scalable as its settlement cost. Recursion flattens that cost by collapsing evidence.
- Reduce on-chain verification cost: Less verification on-chain means less overhead and a shorter path to Ethereum settlement.
This is why Zero-Knowledge Proof recursion comes up so often in rollup design reviews. It is a cost model, not an academic trick.
How Plonky2 differs from traditional Zero-Knowledge Proofs
Plonky2 differs from many earlier ZKP systems because it was designed around recursive composition and performance constraints from the start.
- FRI-based SNARK approach: The Plonky2 paper emphasizes that FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity, a hash-based commitment scheme) does not require a large-characteristic field and uses that freedom to encode the witness in a 64-bit field for speed.
- No trusted setup: Many teams treat transparency as a governance requirement. Plonky2's design avoids ceremony-dependent assumptions.
- Hardware-optimized recursion: Plonky2 is engineered to run recursion efficiently on standard machines, which changes who can operate provers.
Zero-Knowledge Proof recursion in Plonky2
Here is how Plonky2 works from an operator's point of view: it verifies proofs inside proofs, fast enough that recursion becomes a routine pipeline step rather than a rare event. The Plonky2 paper describes using recursion to shrink arbitrarily large proofs to a constant size, which is the mechanical reason ZK proof aggregation matters.
ZKP aggregation as a production pipeline
A practical Plonky2 pipeline usually looks like this:
- Generate many small proofs in parallel (for transactions, constraints or subcircuits).
- Recursively merge proofs in layers (tree-style aggregation).
- Output one final proof tuned for Ethereum settlement.
You do not prove everything in one go. You prove many small things, then compress the evidence.
Why is recursion critical for ZK rollup proof systems?
A ZK rollup lives under two constraints: calldata and verification. Recursion addresses both.
- Calldata pressure: Posting a compact final proof can matter more than shaving small constants off prover time.
- Gas pressure: Verifying one proof is cheaper than verifying many proofs, even before bandwidth is counted.
- Operator decentralization: If recursion is fast on commodity hardware, proving is less likely to concentrate in a single data center.
This is where scalable ZK proofs become a system property: the system is built to compress its own evidence.
Goldilocks field and the economics of high-performance ZK
Plonky2's performance is tightly coupled to the Goldilocks field, a 64-bit prime field chosen to make arithmetic cheap on CPUs. The Plonky2 paper ties prover performance gains to encoding the witness in a 64-bit field.
Most proving time goes into field operations and hashing inside circuits. Picking a field that fits native machine operations changes the throughput a prover can sustain.
Why does 64-bit field arithmetic matter for high-performance ZK?
Because it makes the machine do less work.
- Native CPU execution: 64-bit operations are fast and available everywhere.
- Lower overhead in inner loops: Field arithmetic dominates proving workloads, so savings compound quickly.
- More practical recursion: When recursion is cheaper, you can afford deeper aggregation trees and more modular designs.
This is why teams chasing high-performance ZK keep revisiting Goldilocks-style field choices. The optimization is about where time goes, not only about the math.
Plonky2 benchmarks: recursion time and proof size
Polygon's "Introducing Plonky2" post (January 2022) states that a recursive proof takes about 170 milliseconds on a MacBook Pro, which makes recursion fast enough to be routine.
Separately, the Plonky2 paper (2022) describes shrinking proofs to a constant size of about 43 kilobytes, depending on security and latency targets, which treats proof size as an engineering target rather than a ceiling.
These are the two numbers operators remember: recursion latency and final proof size. Together they decide whether a ZK rollup can hit a predictable cost per batch.
FRI over KZG as a design choice for rollups
Plonky2 uses a FRI-based SNARK design rather than elliptic-curve polynomial commitments such as KZG (Kate-Zaverucha-Goldberg). The trade is not "better cryptography". It is a tunable time and space trade-off that lets you choose where to pay: during proving, or during posting and verification.
FRI-based SNARK design and ZK proof compression
The Plonky2 paper describes recursion as a way to shrink arbitrarily large proofs to a constant size, with an example target around 43 KB. That is ZK proof compression in the most practical sense: compression that still holds up under adversarial verification.
This matters because calldata is a major cost for a proof as large as Plonky2's ~43 KB, so a rollup that posts compact evidence has better economics.
How FRI shapes Plonky2's cost on Ethereum
Ethereum ZK scaling is ultimately about cost curves. Plonky2's FRI choices aim to improve that curve with compact proofs and practical verification paths, and Polygon's write-ups describe Plonky2 as designed around Ethereum constraints and scaling goals.
Much of the Ethereum ZK scaling discussion comes down to one question: can proofs be compressed enough that posting them is not the bottleneck? Plonky2's answer is to use recursion to move cost to where it hurts less, then compress the final artifact.
Plonky2 compared with Groth16 and STARKs
The useful comparison is architectural: which system belongs at which layer, and what recursion should look like.
Plonky2 vs Groth16 for recursion
When comparing Plonky2 with Groth16, teams usually weigh:
- Setup assumptions: Groth16 relies on a trusted setup ceremony, while Plonky2 avoids that dependency.
- Proof size versus flexibility: Groth16 proofs are extremely compact, which is why systems that verify on-chain often use Groth16 for the final proof. Plonky2 is built around recursion as a first-class feature, which changes how pipelines are structured. Our post on the Groth16 proof system and proof size covers the other side of this trade.
If the core need is fast recursive aggregation, Plonky2 often fits better than systems optimized mainly for single-shot proofs.
Plonky2 vs STARKs
Plonky2 vs STARKs usually comes down to a familiar tension: STARK-style commitments are attractive for transparency and scalability, while Ethereum verification costs push toward SNARK-friendly verification.
Plonky2 takes lessons from STARK-friendly design, including FRI, and uses recursion to shrink the final proof before it goes to Ethereum. Polygon estimated about 1 million gas to verify a size-optimized Plonky2 proof.
This is also why ZK rollup design is moving toward hybrid thinking: the best system is often not one proof system but a pipeline.
Proof size, calldata and Plonky2 Ethereum compatibility
When people ask whether Plonky2 is "cheap on Ethereum", they often mix up three costs: proof size (calldata), verification gas and operational proving cost. Plonky2's design balances all three through recursion and tunable parameters.
Plonky2 proof size in practice
The Plonky2 paper states that Plonky2 can shrink proofs to about 43 kilobytes, depending on security and latency targets. That anchors Plonky2 proof size as a constant-size goal rather than a theoretical bound.
A simple mental model: proof size is the shipping cost of your ZK rollup's evidence. Smaller containers move more cheaply and predictably.
Verification cost drivers on Ethereum
Polygon's "Introducing Plonky2" (January 2022) estimated about 1 million gas to verify a size-optimized Plonky2 proof on Ethereum. Beyond that number, the drivers are stable:
- Calldata pricing: a major cost for a proof of Plonky2's size.
- Verifier complexity: fewer exotic operations generally mean more predictable costs.
- Batch frequency: how often you settle matters as much as how much each settlement costs.
In practice, Plonky2 Ethereum compatibility is less about a single number and more about producing a proof artifact that behaves predictably under Ethereum constraints.
Verifiable data and computation for rollups and RWAs
Rollups are the obvious home for ZKPs, but RWAs are a quieter driver of verifiable computation. RWAs rely on off-chain documents, custodians, pricing feeds and compliance checks. Those dependencies create an integrity gap: the token is on-chain, but the evidence is off-chain.
Proof-based data integrity for queries, computations and updates
This is the bridge from Plonky2 to Verifiable Data:
- Prove queries: show that a query result came from a specific dataset snapshot.
- Prove computations: show that a valuation, net asset value (NAV), eligibility check or reconciliation followed approved logic.
- Prove updates: show that data changes followed policy and were applied correctly.
Each step generates many proofs. ZK proof aggregation compresses them, and recursion makes the final evidence portable.
Why RWAs care about verifiable computation
RWA platforms are not trying to impress cryptographers. They are trying to pass audits and win counterparties.
- Audits: evidence that can be verified is harder to dispute.
- Compliance: a platform can prove a constraint holds without publishing the sensitive inputs.
- Counterparty checks: proofs cut the manual reconciliation that slows integrations.
RWA platforms need scalable evidence, not just scalable proofs.
How Orochi Network and zkDatabase apply recursion to RWA verification
Orochi Network treats ZKPs as a data product, not only a settlement tool. zkDatabase is a verifiable database powered by Zero-Knowledge Proofs: it generates a proof for every update, query and transformation, so partners can check the data was stored and processed as claimed without seeing the raw inputs.
zkDatabase uses Groth16 today, with a proof for every operation. Orochi's research team is investigating proof aggregation and recursive SNARKs, the pattern Plonky2 made practical, to bundle many database queries into a single verification.
A practical deployment pattern for proof-carrying data
A typical RWA workflow includes:
- Policy claims: allowlist checks, reserve coverage, NAV methodology constraints.
- Data snapshots: versioned inputs with clear provenance.
- Computation proofs: outputs bound to inputs and rules.
- Evidence bundle: the claim, the input commitment and the proofs, handed to a counterparty, auditor or regulator.
The proof covers how reserve and NAV data was stored and processed, not whether the custodian's or pricing source's figures are true.
Instead of sending hundreds of pages of PDFs and spreadsheets, the platform sends a verifiable bundle: the claim, a commitment to the inputs and a proof that the computation followed the rules.
Migration reality with Plonky2 deprecation
Because Plonky2 is deprecated and Plonky3 is recommended for new work, the sensible approach is to design systems so the recursion layer can be replaced.
That means treating Plonky2 as a reference implementation of architecture patterns rather than a permanent dependency: clean interfaces, a proof-system abstraction and operational playbooks that assume upgrades will happen.
Conclusion
Plonky2 is a clear lens on what ZK infrastructure needs: recursive Zero-Knowledge Proofs to collapse evidence, recursion to make verification composable and aggregation to turn thousands of proofs into one Ethereum-ready artifact. The Goldilocks field and the FRI-based SNARK design are deliberate engineering choices aimed at faster proving, smaller proofs and a more predictable cost per batch.
For RWAs, the gain is verifiable data and verifiable computation that hold up to audit and counterparty review without exposing sensitive inputs. zkDatabase applies Zero-Knowledge Proofs to off-chain data, so partners can check that data was stored and processed as claimed. Recursive aggregation is a research direction for compressing that evidence further.
FAQs
What is Plonky2 and why do Recursive Zero-Knowledge Proofs matter for rollups and RWAs?
Plonky2 is a recursion-first proving system from Polygon Zero. It uses Recursive Zero-Knowledge Proofs to aggregate many proofs into one Ethereum-ready proof, which lowers settlement cost for rollups and produces compact evidence for RWAs without exposing sensitive off-chain data.
How does ZK proof aggregation in Plonky2 reduce Ethereum costs for a ZK rollup?
ZK proof aggregation compresses thousands of transaction or constraint proofs into a single proof through recursion. That reduces verification overhead and keeps calldata and gas under control, so Ethereum settlement costs are more predictable.
Is Plonky2 still maintained?
No. The official Plonky2 repository says Plonky2 is being deprecated and will no longer receive updates or support, and recommends Plonky3, Polygon's next-generation proving system. Plonky2 remains a reference for recursion design, but new systems should plan for Plonky3 or another maintained proving system.
View Docs: see how Orochi Network builds verifiable data on Zero-Knowledge Proofs.
Related toMisc
