Thanks to the Intmax team for their helpful review on this post! Intmax has been pioneering L2 transaction-only constructions based on client-side validation (CSV), where transaction validation relies on cryptographic proofs rather than blockchain consensus rules. Data is intermittently posted on a dedicated blockchain, primarily for deposits, withdrawals, and account checkpoints. The Intmax2 paper is an instantiation of CSV. It consists of two core primitives: a Plasma-like data availability (DA) mechanism and validity proofs. It demonstrated that such a combination can help L2s achieve quite high TPS numbers. In this piece, we will explore why that is the case and how Intmax operates under the hood. Plasma Originally, plasma was considered a strong L2 architecture candidate, distinct from both optimistic and zk-rollups. Its two key differences lay in the role assigned to the block builder (or "aggregator") and the amount of data posted on-chain. Until recently, this data primarily consisted of block hashes produced by plasma aggregators, resulting in a minimal on-chain data footprint for plasma rollups. To enable that DA model, plasma designers assumed that (1) users would stay online and participate in non-trivial challenge games when aggregators misbehave (e.g., using fraud proofs) and (2) mechanisms would be in place to prevent the aggregator from withholding block data (e.g., requiring signatures on blocks submitted by the aggregator).

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.

Incomplete Musings on Applied Cryptography in 2025 This short summary condenses all of the formal and informal discussions I had with teams and colleagues over the second half of 2024 - thanks to all of them! It sometimes touches on areas I am not very familiar with, I might have made mistakes. Also, it’s a bit opinionated and far from exhaustive. For instance, I will not be covering all of the current GKR work and will not be going too much into zkVMs. The order of this note goes from what I feel are low-hanging fruit areas to the least practical/feasible research space (warning: kuiper belt maths at the end). zk-S(N/T)ARKs One area I'm looking forward to is client-side zk proving, where the state remains somewhat underwhelming. Still, there are teams of privacy-focused projects pushing to advance it, such as Aztec or zk-email. I think that folding schemes, with their constant RAM usage per folding step, are an interesting direction since STARKs may be less suitable - mainly due to FFTs. In that vein, Nebula showed that using folding approaches makes it possible to build space-efficient zkEVMs able to run on low-end devices. On a more researchy topic, sumcheck has been (re)gaining attention. Interestingly, this surge in popularity has been witnessed regardless of the type of the proving scheme we talk about - be it ec or hash based. This isn't too surprising given "sumcheck's unreasonable power". For instance, in hash-based land, recent research in polynomial commitment schemes shows that we can achieve convincing improvements in the number of verifier queries (translating in an efficient EVM verifier) when leveraging sumcheck combined with a particular kind of reed-solomon (RS) codes - i.e. WHIR's "constrained RS codes".