Leveraging Folding Schemes in 2025: Scaling with Plasma and Folding Schemes

Introduction

The canonical Nova paper introduced folding schemes, a cryptographic primitive that helps build efficient Incrementally Verifiable Computation (IVC). With the lowest recursive overhead and inherently low memory requirements, these schemes initially garnered significant attention.

Researchers expected folding schemes to permeate much of today's applied cryptography tooling and power things like zkVMs, rollups or identity protocols. However, we still observe today a disconnect between the early enthusiasm for the efficiency of folding schemes and their current rate of adoption. We would like to help bridge this gap.

Our work is driven by the belief that folding schemes can help spur the design of a new generation of scaling solutions, combining plasma and zk. Projects like intmax have shown promising TPS numbers. But their design and subsequent possible TPS and UX relies on efficient client-side proving. This supposes proving schemes with low RAM usage and fast proving speed, which libraries like plonky2 - used today by intmax - can have trouble providing on day-to-day low end devices. We would like to show how folding schemes can help deliver this novative scaling architecture. We believe that the design space consisting in combining plasma with zk/snarks remains underexplored and would like to demonstrate the efficiency of folding schemes to realize such constructions.

Goal

Our goal is simple: we would like to deploy folding schemes in the wild through designing an innovative scaling solutions for Ethereum.

Objectives

We have a single objective to achieve this:

Design and benchmark a client-side friendly zk/plasma scaling solution for Ethereum

Ethereum's current L2 TPS numbers are not where they should be if we are to welcome the world's financial system. In 2017, VISA estimated its current transaction message per second (basically card payments) to be at 65k. We think that the combination of plasma's low onchain data footprint with folding schemes' efficient recursive client-side proving can offer an underrated opportunity for designing a highly scalable L2.

We hover today at an average 200 TPS, a somewhat meager amount compared to VISA's processing speed - and without talking about NASDAQ's peak capacity, able to process up to 250k TPS.

We will design and benchmark a folding scheme based plasma rollup. Assuming 0.375mb of D.A. per block and a block time of 12s, intmax, one of today's main project exploring this combination of plasma and plonky2-based client-side proving, estimated a 90k TPS theoretical limit. However, client-side proving using plonky2 has proven to be a bottleneck. We believe that only the client-side efficiency of folding schemes will make it possible to achieve this theoretical TPS while remaining low-device friendly.

Beyond simple transactions, we also think that folding schemes, due to their lightweight memory footprint and recursive speed, are the only way to go to achieve Vitalik's idea of combining plasma designs with a client-side running EVM.

Vitalik's succint description of how to build an evm plasma chain using a parallel UTXO tree.

Milestones

A folding schemes based plasma rollup

This milestone is concerned with designing and benchmarking a folding-schemes powered plasma L2. We would like to know the feasibility of client-side proving (speed, RAM usage, …), run benchmarks against plonky2 and derive an estimated TPS. On top of that, we would also like to contribute to the research ecosystem in producing meaningful writeup and reports on considered architectures and schemes. We summarize the required work into 2 sub-milestones:

1. A technical write-up, in the form of a research paper or lengthy blog/ethresearch post. Our results will be presented at conferences and meetups. We want our writeup to feature details of the account balance proof (a proof attesting to the balance of a plasma user) in the setting of IVC schemes. Also, we would like it to feature specific benchmarks against plonky2, with respect to client-side proving speed and RAM usage. Finally, it will feature the estimated possible theoretical TPS and information on which low-end hardware running such scheme is possible. We will collaborate with similar plasma projects like intmax and will leverage Sonobe's Nova implementation for prototyping. Our R1CS will be arkworks based.

Nebula, a folding based memory checking argument, demonstrated a VM design with a pay-per-use cost profile. It is able to generate proofs of ERC-20 transactions in 5s on a 2.4Ghz 8-core Intel Core i9 processor, but has not been open-sourced yet.

2. Literature review and blog posts or intra-PSE technical notes describing the various alternatives and the current state of the art while carrying out our research effort. We want it to contain descriptions of the various IVC schemes (Nova, Nebula, Micronova) and plasma architectures (the canonical plasma paper, Plasma Cash, Intmax2) considered.

Expected delivery time:

1 - 2 weeks to investigate intmax's paper, architecture and code
3 - 4 weeks of literature review + writeups/blog posts/notes for outer comms
4 - 5 weeks of writing basic circuits + benchmarking
1 week for final writeup
= approx. 9-11 weeks of work.

Why now

It is clear to us that current L2s face scaling challenges. Blobs have not fully addressed the issue of affordable DA on L1, limiting the number of transactions rollups can post there. With a target blob size of 16mb, using the 5bytes/user model of intmax, only plasma could help us reach (in theory) NASDAQ's peak 260k TPS. In addition to this, the cambrian explosion of zk/snark implementations which happened in-between makes us believe that a very interesting design space exists here.

Why PSE

We observed that the plasma ecosystem lacks research today and think that it is a unique opportunity (combining a matured zk ecosystem and what this means for plasma) for PSE to invest in it, in order to advance Ethereum's scaling toolbox.

Team Members

Team Lead: Pierre (100%)
Contributors: Chengru (100%)