Recursive Proof Systems: Compressing Entire Blockchains into One Proof

Posted on by uplatzblog

Executive Summary

The proliferation of decentralized ledger technologies has introduced a fundamental tension between scalability, decentralization, and security—the classic “blockchain trilemma.” As blockchains grow, the history of transactions that must be verified by a full node expands linearly, creating an accumulation of state that eventually precludes participation by consumer-grade hardware. This report explores the cryptographic breakthrough of recursive proof systems, specifically Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) and recursive STARKs, which offer a solution to this scalability crisis by compressing the verification of an entire blockchain’s history into a single, constant-size proof.

This analysis examines the theoretical underpinnings of Incrementally Verifiable Computation (IVC) and Proof-Carrying Data (PCD), tracing the evolution from “naive” recursion to advanced accumulation and folding schemes like Nova, SuperNova, and HyperNova. We provide a detailed technical dissection of production-grade implementations, including the Mina Protocol—which maintains a 22KB fixed size—Polygon Zero’s Plonky2, and StarkNet’s shared proving architecture. By evaluating performance benchmarks, cryptographic primitives (such as the move toward small fields like Goldilocks and M31), and the implications for mobile-native decentralization, this report asserts that recursive proving is not merely an optimization but a requisite architectural paradigm for the next generation of global, trustless computation.

1. The Scalability Crisis and the Imperative for Compression

The defining characteristic of a blockchain is its “trustlessness”—the ability for any participant to independently verify the integrity of the ledger without reliance on a third party. However, this property has historically come with a prohibitive cost: the necessity to re-execute or verify every transaction from the genesis block to the current state.

1.1 The State Bloat Phenomenon

In traditional architectures like Bitcoin or Ethereum, the blockchain is an append-only log. As the network processes transactions, the size of this log grows indefinitely. This phenomenon, known as state bloat, imposes severe requirements on network nodes.1

  • Storage: Nodes must store hundreds of gigabytes, potentially reaching terabytes, of historical data.
  • Bandwidth: The initial block download (IBD) process for a new node can take days or weeks, consuming massive amounts of bandwidth.
  • Computation: Verifying the chain requires re-executing signatures and smart contract logic for millions of past transactions.2

This resource intensity creates a centralization vector. As the requirements to run a “full node” increase, fewer individuals can afford to participate. The network becomes reliant on a shrinking class of institutional node operators and centralized infrastructure providers (e.g., Infura, Alchemy), undermining the censorship resistance that defines the technology.4 Users are forced to rely on “light clients” or “ultralight clients” which do not verify the chain themselves but trust the majority of miners or a specific server, reintroducing trust into a trustless system.5

1.2 The Concept of Statelessness

To combat centralization, researchers have proposed “stateless” blockchains. In a stateless model, validators do not need to store the full state (e.g., the complete list of account balances). Instead, transactions come attached with “witnesses”—cryptographic proofs (often Merkle branches) that attest to the correctness of the specific state being accessed.6

However, statelessness introduces its own complexities. Witnesses must be updated frequently as the state changes, pushing the burden of data availability onto users or “state providers.” Recursive proof systems offer a superior form of statelessness (or “semi-statelessness”) where the witness is not a large Merkle path for every account, but a single, succinct cryptographic argument that verifies the transition of the global state itself.8

1.3 The Recursive Solution: Constant-Size Verification

Recursive proving fundamentally alters the relationship between chain length and verification cost. By employing cryptographic recursion, a blockchain protocol can generate a proof $\pi_i$ at block height $i$ that attests to the validity of the state transition at $i$ and the validity of the proof $\pi_{i-1}$ from the previous block.9

Through mathematical induction, verifying the proof at the tip of the chain ($\pi_n$) implicitly verifies the entire chain of causality back to the genesis block ($\pi_0$). The verifier does not need to know $n$ (the block height); the computational work required to verify $\pi_n$ is constant ($O(1)$), regardless of whether the chain is ten blocks long or ten million blocks long.10 This paradigm enables the creation of a “succinct blockchain”—a ledger that never grows in verification complexity, effectively compressing an infinite history into a kilobyte-sized artifact.12

2. Theoretical Foundations: IVC, PCD, and ZKP Primitives

The realization of constant-size blockchains rests on advanced concepts in computational complexity theory and cryptography, specifically Incrementally Verifiable Computation (IVC) and Proof-Carrying Data (PCD).

2.1 Zero-Knowledge Proofs (ZKPs): The Building Block

At the core of recursive systems are Zero-Knowledge Proofs, specifically zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge).

  • Succinct: The proof size is small (often a few hundred bytes to a few kilobytes), and verification is fast (milliseconds).
  • Non-Interactive: The prover sends a single message (the proof) to the verifier, who can check it without further communication.
  • Argument of Knowledge: The proof convinces the verifier that the prover knows a “witness” (e.g., the transaction data) that satisfies the computational constraints.9

In the context of blockchain compression, the “Zero-Knowledge” aspect (privacy) is sometimes secondary to the “Succinctness” aspect (scalability), although privacy is a natural byproduct. The critical feature is that verifying the proof is exponentially faster than running the original computation.14

2.2 Incrementally Verifiable Computation (IVC)

IVC allows a computation that proceeds in steps to be verified incrementally. Let a computation be defined by a step function $F$ applied repeatedly to a state $z$:

 

$$z_{i+1} = F(z_i, w_i)$$

 

Where $w_i$ is non-deterministic input (witness/transaction data) at step $i$.

In an IVC scheme, at each step $i$, the prover produces a proof $\pi_i$. This proof asserts:

“I know a witness $w_i$ and a previous proof $\pi_{i-1}$ such that $F(z_{i-1}, w_i) = z_i$ AND $\text{Verify}(\pi_{i-1}, z_{i-1}) = \text{True}$.”

The verification circuit for the proof system is embedded within the step circuit of $F$. This creates a recursive structure where the current proof wraps the previous proof. The verifier only needs to check the final proof $\pi_n$ to be convinced that the function $F$ was applied correctly $n$ times starting from a valid base case.9

2.3 Proof-Carrying Data (PCD)

Proof-Carrying Data generalizes IVC from linear chains to Directed Acyclic Graphs (DAGs). In a distributed system, a node might receive messages from multiple sources, each carrying a proof of its validity. The node processes these messages and produces an output message carrying a new proof that aggregates the validity of all inputs.

PCD is defined by a “compliance predicate” $\Pi$. A message is valid if it complies with $\Pi$, which checks the validity of the input messages’ proofs and the local transformation. This is essential for sharded blockchains or systems where state updates merge (e.g., aggregating multiple transaction rollups into a block).13

2.4 The Recursion Barrier: Cycles of Curves

Implementing recursion with SNARKs faces a significant algebraic hurdle known as the field mismatch problem.

  • Elliptic curve cryptography operates over two fields: the Base Field ($F_q$), used for coordinate arithmetic, and the Scalar Field ($F_r$), used for the group order.
  • A SNARK circuit proving statements about curve operations works over the scalar field $F_r$.
  • However, the verification algorithm for that SNARK involves operations over the base field $F_q$.

To verify a proof inside a circuit, one must perform $F_q$ arithmetic inside a circuit defined over $F_r$. Since $F_q \neq F_r$, this requires expensive “non-native” field arithmetic, introducing massive overhead (often $1000\times$ slower).11

The Solution: Cycles of Curves

To solve this, cryptographers utilize a cycle of elliptic curves. A 2-cycle consists of two curves, $E_1$ and $E_2$, where:

  • The scalar field of $E_1$ is the base field of $E_2$.
  • The scalar field of $E_2$ is the base field of $E_1$.

This arrangement allows efficient “ping-pong” recursion. A proof generated over $E_1$ is verified by a circuit defined over $E_2$, and vice versa. This eliminates the need for non-native arithmetic. The most famous example is the Pasta Curves (Pallas and Vesta), utilized by the Mina Protocol and the Nova proving system.18

3. The Evolution of Recursive Architectures

The methodology for achieving recursion has evolved rapidly, moving from computationally expensive “naive” recursion to highly optimized folding schemes.

3.1 Naive Recursion: The “SNARK of a SNARK”

In the earliest recursive designs, the goal was to fully verify the inner SNARK proof within the outer SNARK circuit. This approach, while theoretically sound, was practically difficult due to the “Trusted Setup” problem. Systems like Groth16 require a setup phase for every circuit. If the recursion depth is infinite or the circuit changes, managing these setups is impossible.

Furthermore, the verification circuit for pairing-based SNARKs is complex. Encoding a pairing check (a heavy algebraic operation) inside a circuit results in a massive number of constraints, making the prover time prohibitively slow.15

3.2 Accumulation Schemes: Halo and Halo 2

The breakthrough enabling practical recursion came with Accumulation Schemes, introduced in the Halo protocol (and later refined in Halo 2).

The Concept of Deferred Verification:

Instead of fully verifying the proof $\pi_{i-1}$ at step $i$, the prover verifies only the “cheap” parts of the proof in the circuit. The “expensive” parts—specifically the hard cryptographic checks like polynomial commitment openings—are not verified. Instead, they are accumulated.

The circuit outputs an “accumulator”—a cryptographic object that represents the claim “If this accumulator is valid, then all previous proofs are valid.” At step $i+1$, the old accumulator is combined with the new claims into a new accumulator. The expensive verification is deferred until the very end of the chain, or performed continuously outside the SNARK by the node, but mathematically linked to the proof.20

Advantages:

  • No Trusted Setup: Halo uses the Inner Product Argument (IPA) with Bulletproofs, which requires no trusted setup (it is “transparent”).
  • Efficiency: By avoiding the full verification cost at each step, recursion becomes feasible on standard hardware.

3.3 Folding Schemes: The Nova Paradigm

The current state-of-the-art in recursive proving is Folding, pioneered by the Nova proving system. Nova redefines IVC by operating on the mathematical structure of the constraints themselves (R1CS) rather than the proofs.

3.3.1 The Mechanics of Folding

Nova introduces a primitive called a Folding Scheme. Given two instances of a constraint system (e.g., two steps of a computation) that are both satisfied by their respective witnesses, a folding scheme allows the prover to combine them into a single instance.

 

$$\text{Instance}_{folded} = \text{Instance}_1 + r \cdot \text{Instance}_2$$

 

where $r$ is a random scalar provided by the verifier (or obtained via Fiat-Shamir).

If the prover can find a witness for this folded instance, it implies with high probability that they knew witnesses for both original instances. Crucially, the cost to verify the folding step is negligible (dominated by two Multi-Scalar Multiplications, or MSMs), whereas generating a full SNARK is expensive.

In Nova-based IVC, the prover repeatedly “folds” the current step’s instance into a running accumulated instance. No SNARK is generated during the intermediate steps. A SNARK is only generated at the very end to prove the validity of the final folded instance. This reduces the per-step overhead by orders of magnitude compared to Halo or Plonky2.22

Comparative Performance:

  • Recursion Overhead: Nova has a recursion overhead of ~10,000-20,000 constraints.
  • Prover Speed: Benchmarks show Nova can be significantly faster than Halo2 for large recursive tasks (e.g., recursive hashing), particularly when memory is constrained, as folding is extremely memory-efficient.25

3.4 Handling Heterogeneity: SuperNova and HyperNova

Standard IVC (Nova) works best when the same function $F$ is repeated (Uniform IVC). However, real-world applications like Virtual Machines (VMs) execute different instructions (opcodes) at each step (e.g., ADD, MUL, JUMP). This is Non-Uniform IVC (NIVC).

  • SuperNova: Generalizes Nova to NIVC. It maintains separate running instances for each instruction supported by the VM. At each step, it folds the execution into the specific instance corresponding to the opcode used. This avoids the cost of a “universal circuit” that embeds all opcodes, making it ideal for zkVMs.26
  • HyperNova: Addresses the limitation of R1CS. R1CS is not efficient for all types of arithmetic (e.g., bitwise operations in SHA256). HyperNova generalizes folding to Customizable Constraint Systems (CCS), which unifies R1CS, PLONK, and AIR. This allows for high-degree gates and lookups (essential for efficient VMs) while maintaining the low overhead of folding.28
  • Sangria: A folding scheme specifically for the PLONK arithmetization, allowing the use of custom gates and high-degree constraints within a folding framework.24

4. Case Study: The Mina Protocol

Mina Protocol is the canonical implementation of a “succinct blockchain.” While Bitcoin’s history is hundreds of gigabytes, Mina’s proof stays fixed at roughly 22 kilobytes.

4.1 Architecture: Kimchi and Pickles

Mina achieves this via a dual-layer proof system operating on the Pasta curves:

  1. Kimchi: This is the underlying proof system for transactions. It is a PLONK-ish system (a variation of PLONK) that uses 15 registers (columns) to optimize for circuit efficiency. Kimchi supports “custom gates” (e.g., for efficient Poseidon hashing), which significantly speeds up the proving of basic operations.11
  2. Pickles: This is the recursion layer. Pickles is responsible for the “Proof of a Proof” logic. It uses the Halo 2-inspired accumulation scheme to verify Kimchi proofs inside other Kimchi proofs. Pickles handles the “Step” (proving a statement) and “Wrap” (recursion/compression) circuits, managing the cycle of curves to avoid field mismatches.18

4.2 The “Scan State”: Parallelizing Proofs

A naive implementation of a blockchain SNARK would require sequential proving: Block $N$ cannot be proven until Block $N-1$ is proven. This would create massive latency.

Mina solves this with the Scan State, a parallel tree-based data structure.

  • Transactions enter the system and are picked up by Snarkers (proof workers).
  • Snarkers generate proofs for individual transactions in parallel.
  • These proofs are then merged in pairs: Proof(Tx1) and Proof(Tx2) are merged into Proof(Tx1+Tx2).
  • This creates a tree of proofs. The Block Producer effectively includes the root proof of this tree in the block.
  • This decouples transaction throughput from block latency, as the work of proving is distributed and pipelined.12

4.3 Node Hierarchy and Decentralization

Mina’s architecture creates unique roles:

  • Block Producers: Analogous to miners/validators. They select transactions and the corresponding SNARKs from the “Snarketplace” to construct blocks.
  • Snarkers: Specialized provers who generate proofs for transactions. They bid to have their proofs included, creating a market for efficient proving hardware.12
  • Archive Nodes: While the protocol is secure with just the 22KB proof, Archive Nodes store the full history (all transaction data) for applications that need to query old data (e.g., “what was my balance 3 years ago?”).36
  • Web Nodes: Because verification is so lightweight, Mina is developing full nodes that run entirely in a web browser using WASM. These nodes can verify the chain and broadcast transactions via WebRTC, bypassing centralized RPCs. This represents a significant leap in censorship resistance.37

4.4 Roadmap and Future Upgrades

Mina’s roadmap includes the “Berkeley Upgrade” (bringing full zkApp programmability) and the move toward Rust-based nodes for higher performance. The roadmap also emphasizes “DAOification” and trust minimization, leveraging the recursive architecture to allow governance decisions to be verified on lightweight devices.40

5. High-Performance Recursion: Polygon Zero & StarkNet

While Mina optimizes for constant size (succinctness), other protocols leverage recursion for throughput and latency in the context of Layer 2 scaling.

5.1 Polygon Zero: Plonky2 and the Speed of Goldilocks

Polygon Zero’s Plonky2 is engineered for raw speed. It is claimed to be the world’s fastest recursive prover, capable of generating recursive proofs in ~170ms on a consumer laptop.42

The Goldilocks Field:

Standard SNARKs use large 256-bit fields (like BN254) to ensure security. Plonky2 uses the Goldilocks Field, a prime field of order $p = 2^{64} – 2^{32} + 1$.

  • Why? This fits perfectly into the 64-bit registers of modern CPUs. Arithmetic operations (addition, multiplication) are native CPU instructions, avoiding the complex “BigInt” software libraries required for 256-bit math. This results in a ~40x speedup in field arithmetic.43

FRI-based Recursion:

Because the Goldilocks field is too small for standard elliptic curve security (Discrete Log Problem), Plonky2 cannot use KZG or IPA commitments. Instead, it uses FRI (Fast Reed-Solomon Interactive Oracle Proofs), a hash-based commitment scheme typically used in STARKs.

  • Plonky2 uses recursion to shrink the large FRI proofs. It generates fast, large proofs for internal steps and then “wraps” them in a final recursion layer to compress the proof size before posting to Ethereum.43

5.2 StarkNet: SHARP and S-Two

StarkNet uses STARKs (Scalable Transparent Arguments of Knowledge) to scale Ethereum. STARKs are quantum-resistant and fast but produce large proofs.

SHARP (Shared Prover):

StarkWare introduced the Shared Prover (SHARP) to aggregate computations from multiple distinct applications (e.g., dYdX, Sorare, StarkNet).

  • SHARP acts as a massive “train” that collects transactions from various dApps.
  • It uses Recursive STARKs to verify the validity of previous batches.
  • A “Recursive Verifier” written in Cairo (StarkNet’s language) verifies the proofs of incoming transaction batches.
  • This creates a tree of proofs, where a single final proof submitted to Ethereum attests to the validity of millions of transactions across different applications.14

S-Two Prover (Circle STARKs):

The next generation of StarkNet’s proving tech is S-Two. It utilizes Circle STARKs over the M31 Field (Mersenne 31, $2^{31}-1$).

  • Like Goldilocks, M31 is a small field optimized for CPU/GPU efficiency (fitting in 32-bit registers).
  • S-Two is designed for client-side proving. Benchmarks suggest it is 100x faster than the previous Stone prover, enabling proofs to be generated on mobile devices in real-time.
  • This enables “privacy at the edge,” where a user’s phone generates a proof of their transaction locally, ensuring data never leaves the device.46

6. Comparative Analysis: Architectures and Trade-offs

The choice of recursive architecture dictates the performance profile of the blockchain.

6.1 Performance Benchmarks

Metric Mina (Kimchi/Pickles) Polygon Zero (Plonky2) StarkNet (S-Two) Nova (Folding)
Recursion Type Accumulation (Halo-style) Layered Recursion (FRI) Layered Recursion (Circle) Folding Scheme
Prover Time Moderate Fastest (~170ms) Extremely Fast Fast (Low per-step cost)
Proof Size Smallest (22KB) Larger (~45KB) Logarithmic (Large) Constant (Small)
Field Size 256-bit (Pasta) 64-bit (Goldilocks) 31-bit (M31) Curve Scalar Field
Memory Usage Moderate High (at scale) Moderate Lowest (Constant)
Primary Goal Decentralization/Size Latency/Throughput Throughput/Client-Side IVC Efficiency

Table 1: Comparative Analysis of Recursive Proof Architectures.11

6.2 The Trade-off Space

  • Mina optimizes for Verifiability. Its 22KB proof allows anyone to verify the chain, prioritizing decentralization over raw throughput.
  • Plonky2 optimizes for Latency. Its use of Goldilocks and FRI allows it to generate proofs incredibly fast, essential for a zk-Rollup that needs to settle on Ethereum quickly.
  • Nova optimizes for Memory and Overhead. By avoiding the “SNARK of a SNARK” cost via folding, it is the most efficient theoretical approach for long-running computations (IVC), though it requires managing R1CS constraints (or upgrading to HyperNova for CCS).25

6.3 Hardware Implications

  • CPU: Plonky2 and S-Two heavily favor modern CPUs with AVX-512 instructions to exploit their small field arithmetic.
  • RAM: Nova is unique in its constant memory requirement. Plonky2 and standard SNARKs (Halo2) can require hundreds of gigabytes of RAM for very large circuits ($k>20$), making them harder to run on consumer hardware for heavy proving tasks.25

7. Implications: The Singularity of Proofs

The convergence of these technologies points toward a “Proof Singularity”—a state where the cost of proving computation becomes negligible, and the size of the blockchain history becomes irrelevant.

7.1 Mobile Nodes and True Decentralization

The “holy grail” is the mobile full node. Current mobile wallets are SPV (Simple Payment Verification) clients or rely on centralized APIs. Recursive proofs enable a mobile device to be a first-class citizen.

  • With Mina’s Web Node, a smartphone can verify the entire network state in milliseconds without trusting a third party.
  • With S-Two, a smartphone can generate proofs for its own transactions locally, preserving privacy.
  • This shifts the topology of the blockchain network from a “hub and spoke” (servers and light clients) to a dense mesh of fully verifying peers.37

7.2 Interoperability and Bridging

Recursive proofs solve the bridging problem. A “light client bridge” between Chain A and Chain B usually requires verifying Chain A’s consensus on Chain B. If Chain A’s history is compressed into a single proof, Chain B can verify the state of Chain A by checking one proof inside its own smart contract. This enables trustless, low-cost bridging without multi-sig committees.21

7.3 Privacy and Data Sovereignty

Recursive proofs facilitate “Programmable Privacy.” Users can prove statements about their data (e.g., “I have a credit score > 700” or “I am over 18”) without revealing the data itself. The proof of this statement can be recursively aggregated into the blockchain’s state proof. This allows compliant interaction with public blockchains while maintaining user confidentiality.31

8. Conclusion

Recursive proof systems represent the most significant architectural advancement in blockchain technology since the invention of the consensus mechanism itself. By transforming the blockchain from a linear log of data into a recursive cryptographic induction, protocols like Mina, Polygon Zero, and StarkNet have decoupled security from resource consumption.

The evolution from naive recursion to the elegance of folding schemes like Nova and HyperNova suggests that the efficiency of these systems will continue to improve, likely adhering to a “Moore’s Law” of ZK proving. As hardware acceleration (ZK-ASICs) catches up with these software breakthroughs, we approach a future where “stateless” blockchains are the standard. In this future, the “full node” is no longer a server in a data center, but a background process on billions of mobile devices, each independently verifying the integrity of the global ledger through the mathematics of recursion. The “Proof of Everything” is not just a compression technique; it is the foundation for a truly decentralized, infinitely scalable digital economy.

Works cited

  1. How Blockchain Scalability Impacts Adoption & Efficiency – Webisoft, accessed on December 21, 2025, https://webisoft.com/articles/blockchain-scalability/
  2. Why Running a Bitcoin Full Node Still Matters (and How to Do It Right) – South Alabamian, accessed on December 21, 2025, https://www.southalabamian.com/2025/01/30/why-running-a-bitcoin-full-node-still-matters-and-how-to-do-it-right/
  3. To anyone that runs a bitcoin full node. why do you do it? What are the benefits? Where can I learn to do it? – Quora, accessed on December 21, 2025, https://www.quora.com/To-anyone-that-runs-a-bitcoin-full-node-why-do-you-do-it-What-are-the-benefits-Where-can-I-learn-to-do-it
  4. The hidden danger of re-centralization in blockchain platforms – Brookings Institution, accessed on December 21, 2025, https://www.brookings.edu/articles/the-hidden-danger-of-re-centralization-in-blockchain-platforms/
  5. Decentralized Cryptocurrency at Scale – Mina Docs, accessed on December 21, 2025, https://docs.minaprotocol.com/assets/technicalWhitepaper.pdf
  6. Stateless Light Clients — Enabling Trustless Blockchain Interaction (3 of 9) | by Steffen Kux, accessed on December 21, 2025, https://medium.com/@steffen.kux/stateless-light-clients-enabling-trustless-blockchain-interaction-3-of-9-934ffd0e050c
  7. On the impossibility of stateless blockchains – a16z crypto, accessed on December 21, 2025, https://a16zcrypto.com/posts/article/on-the-impossibility-of-stateless-blockchains/
  8. Zero knowledge Proofs for Rollups & Stateless Clients – Harmony’s Open Development, accessed on December 21, 2025, https://open.harmony.one/team-founding-story/founding-team-core-members/ganesha-upadhyaya/zero-knowledge-proofs-for-rollups-stateless-clients
  9. Recursive SNARKs and incrementally verifiable computation (IVC) | Smart contract audits from Veridise, accessed on December 21, 2025, https://veridise.com/blog/learn-blockchain/recursive-snarks-and-incrementally-verifiable-computation-ivc/
  10. Recursive Zero-Knowledge Proofs – sCrypt – Medium, accessed on December 21, 2025, https://scryptplatform.medium.com/recursive-zero-knowledge-proofs-27f2d934f953
  11. Proof Singularity and Mina Kimchi Proof System | by Alperen Tunçkıran | Medium, accessed on December 21, 2025, https://blockofchain.medium.com/proof-singularity-and-mina-kimchi-proof-system-b5833e18c31a
  12. What Is Mina Protocol? – CoinMarketCap, accessed on December 21, 2025, https://coinmarketcap.com/academy/article/what-is-mina-protocol
  13. Trustless Recursive Zero-Knowledge Proofs – Tari Labs University, accessed on December 21, 2025, https://tlu.tarilabs.com/cryptography/trustless-recursive-zero-knowledge-proofs
  14. What’s Starknet: a diffirent zkVM tech stack – Foresight News, accessed on December 21, 2025, https://foresightnews.pro/article/detail/28146
  15. SNARK Recursion, Folding, and IVC | by Luca Franceschini | Medium, accessed on December 21, 2025, https://medium.com/@Luca_Franceschini/snark-recursion-folding-and-ivc-135b98458a4d
  16. lurk-lab/awesome-folding: A curated list of zero-knowledge folding schemes – GitHub, accessed on December 21, 2025, https://github.com/lurk-lab/awesome-folding
  17. Recursive SNARKs: A Comprehensive Primer – Michael Straka, accessed on December 21, 2025, https://www.michaelstraka.com/recursivesnarks
  18. Overview of Pickles – Mina book, accessed on December 21, 2025, https://o1-labs.github.io/proof-systems/pickles/overview.html
  19. The zero-knowledge attack of the year might just have happened, or how Nova got broken, accessed on December 21, 2025, https://blog.zksecurity.xyz/posts/nova-attack/
  20. Intro to Nova & ZK folding schemes: Halo and accumulation | Smart contract audits from Veridise, accessed on December 21, 2025, https://veridise.com/blog/learn-blockchain/intro-to-nova-zk-folding-schemes-halo-and-accumulation/
  21. From Recursive SNARKs to Halo 2 and the Path to Stateless Clients – Level Up Coding, accessed on December 21, 2025, https://levelup.gitconnected.com/from-recursive-snarks-to-halo-2-and-the-path-to-stateless-clients-421a7ab744be
  22. Understanding Nova: Friendly Recursive Zero-Knowledge Arguments from Folding Schemes – ZKP Labs, accessed on December 21, 2025, https://zkplabs.network/blog/understanding-nova-friendly-recursive-zero-knowledge-arguments-from-folding-schemes
  23. Intro to Nova & ZK folding schemes: Folding and nova | Smart contract audits from Veridise, accessed on December 21, 2025, https://veridise.com/blog/learn-blockchain/intro-to-nova-zk-folding-schemes-folding-and-nova/
  24. Sangria: A PLONK-ish folding scheme | by Taras Shchybovyk …, accessed on December 21, 2025, https://medium.com/@cryptofairy/sangria-a-plonk-ish-folding-scheme-2271204d2285
  25. Nova benchmarks – HackMD, accessed on December 21, 2025, https://hackmd.io/0gVClQ9IQiSXHYAK0Up9hg
  26. Towards a Nova-based ZK VM – General, accessed on December 21, 2025, https://zkresear.ch/t/towards-a-nova-based-zk-vm/105
  27. zkvm-ideas/zkvm-spec.md at main · privacy-ethereum/zkvm-ideas – GitHub, accessed on December 21, 2025, https://github.com/privacy-scaling-explorations/zkvm-ideas/blob/main/zkvm-spec.md
  28. HyperNova: Recursive arguments for customizable constraint systems – Microsoft Research, accessed on December 21, 2025, https://www.microsoft.com/en-us/research/publication/hypernova-recursive-arguments-for-customizable-constraint-systems/
  29. HyperNova: Recursive Arguments For Customizable Constraint Systems | PDF – Scribd, accessed on December 21, 2025, https://www.scribd.com/document/641161187/HyperNova-Recursive-arguments-for-customizable-constraint-systems
  30. Sangria: Advancing IVC in PLONK Innovation – ZKP Labs, accessed on December 21, 2025, https://zkplabs.network/blog/Sangria-Advancing-IVC-in-PLONK%20-Innovation
  31. Mina Protocol | Zeko Docs, accessed on December 21, 2025, https://docs.zeko.io/background/mina-protocol.html
  32. Mina Under the Hood: A Technical Introduction – DEV Community, accessed on December 21, 2025, https://dev.to/babalasisi/mina-under-the-hood-a-technical-introduction-4j7i
  33. Recursion | Mina Documentation, accessed on December 21, 2025, https://docs.minaprotocol.com/zkapps/o1js/recursion
  34. What Makes Mina So Special? Whiteboard Session 2024 – YouTube, accessed on December 21, 2025, https://www.youtube.com/watch?v=-fG0JLtYlJE
  35. Guide to Mina | Coinbase, accessed on December 21, 2025, https://www.coinbase.com/developer-platform/discover/protocol-guides/guide-to-mina
  36. Archive Nodes Getting Started | Mina Documentation, accessed on December 21, 2025, https://docs.minaprotocol.com/node-operators/archive-node/getting-started
  37. Introducing the Web Node — an in-browser Mina node that verifies blocks and transfers funds | by Juraj Selep | OpenMina | Medium, accessed on December 21, 2025, https://medium.com/openmina/introducing-the-web-node-an-in-browser-mina-node-that-verifies-blocks-and-transfers-funds-ebc59a57e79a
  38. README.md – The Mina Web Node – GitHub, accessed on December 21, 2025, https://github.com/openmina/webnode/blob/main/README.md
  39. Retro: Mina Web Node Testing, accessed on December 21, 2025, https://minaprotocol.com/blog/retro-mina-web-node-testing
  40. Roadmap | Mina Protocol, accessed on December 21, 2025, https://minaprotocol.com/roadmap
  41. Mina Roadmap, accessed on December 21, 2025, https://minaprotocol.com/mina-roadmap
  42. Polygon’s Transition to ZK-Rollups & Plonky2 – MLQ.ai, accessed on December 21, 2025, https://blog.mlq.ai/polygons-transition-to-zk-rollups-plonky2/
  43. Plonky2: A Deep Dive – Polygon Technology, accessed on December 21, 2025, https://polygon.technology/blog/plonky2-a-deep-dive
  44. Recursive STARKs – Starknet, accessed on December 21, 2025, https://www.starknet.io/blog/recursive-starks/
  45. Prove It In SHARP To Save Costs and Enhance Ethereum’s Scalability – StarkWare, accessed on December 21, 2025, https://starkware.co/blog/joining-forces-sharp/
  46. Introducing S-two: The fastest prover for real-world ZK applications | StarkWare, accessed on December 21, 2025, https://starkware.co/blog/s-two-prover/
  47. S-two Is Live on Starknet Mainnet: The Fastest Prover for a More Private Future, accessed on December 21, 2025, https://www.starknet.io/blog/s-two-is-live-on-starknet-mainnet-the-fastest-prover-for-a-more-private-future/
  48. Mina Protocol: Lightest Blockchain for Secure DApps, accessed on December 21, 2025, https://minaprotocol.com/