The Key to Ethereum's Transformation: The Future of STARK Recursive Proofs in the Next Decade

In the next decade, Ethereum must meet three major requirements: post-quantum security, privacy protection, and scalability.

Written by: _deanstef

Ethereum is approaching a turning point.

Its first decade validated a hypothesis: public blockchains can support meaningful applications at scale. Smart contracts, DeFi, stablecoins, appchains, and tokenization have transformed Ethereum from an experimental decentralized computing platform into the settlement layer of a growing digital economy.

The second decade brings different challenges. Ethereum must support economic activities that society relies on. Stablecoins are becoming payment rails, tokenized assets are moving beyond pilot phases, and institutions are building directly on public rails.

As Ethereum becomes critical infrastructure, it must be reinforced for the coming years to become a robust, secure, and efficient computing system that operates at (decentralized) scale. Specifically, Ethereum must:

• Withstand threats that do not yet exist, particularly cryptographic-related quantum computers (CRQCs).
• Provide sufficient privacy to meet the confidentiality requirements of real economic activities.
• Achieve scalability without sacrificing the neutrality, openness, and censorship resistance that initially made it successful.

The Ethereum Foundation's mission has recently clarified this vision through CROPS.

Ethereum must "above all maintain censorship resistance, open-source, privacy, and security."

As adoption grows, these conditions will not become less important; they will become the foundation upon which adoption relies. Two of them—privacy and security—are precisely at the forefront of current research, and this is no coincidence.

The Ethereum strawmap outlines a gradual, multi-year evolution path towards Lean Ethereum—a system relying on concise cryptographic proofs, scaling the network to 10K TPS, and upgrading to post-quantum primitives, all while not sacrificing the decentralized protocol redesign. This tech stack is largely built around STARKs (Scalable Transparent Argument of Knowledge). STARKs are hash-based, transparent proofs that require no trusted setup; notably, they can be aggregated, folding many different computations into a single proof.

Along this trajectory, I see three major research pillars:

• Post-quantum security, ubiquitous: Preparing every layer of the protocol vulnerable to quantum attacks for CRQC before migration pressures arrive.
• Programmable privacy: Providing confidentiality that coexists with verifiability and compliance, built into the infrastructure itself.
• Scalability: Maintaining consensus, finality, and verification efficiently enough for the first two to be deployed without degrading network performance.

The cryptographic costs of the first two are higher, and their adoption success depends on the system's ability to bear this complexity. The third track is the glue. Post-quantum primitives and privacy primitives already exist, but the research question is how to make them usable at scale. In fact, even the most optimized post-quantum and privacy primitives will be heavier than the traditional cryptography they replace, making them difficult to adopt into a complex system like Ethereum. To make them affordable, there is ultimately only one lever: using STARK proofs for recursive proofs. The remainder of this article will unfold along this chain.

Post-Quantum Security

The transition to post-quantum (PQ) Ethereum must cover every component in the existing protocol that is vulnerable to quantum attacks. As summarized in Vitalik's roadmap and a recent Nethermind article on quantum risk, these components include ECDSA signatures, BLS consensus proofs, KZG commitments for blobs, and pairing-based SNARKs used for rollups to settle on L1. Their commonality lies in the difficulty of the elliptic curve discrete logarithm problem, which can be solved in polynomial time on a CRQC using Shor's algorithm.

Alternative candidates are distributed across a spectrum:

• Lattice-based signature schemes (e.g., ML-DSA, Falcon) keep signatures relatively small but have high on-chain verification costs, exceeding one million Gas, and their aggregation theory is still immature.
• Hash-based signature schemes rely solely on the security of the underlying hash function but at the cost of size: signature sizes reach several KB, and current verification costs can be in the hundreds of thousands of Gas. They are divided into stateful variants, such as XMSS, which are smaller but require the signer to track key states; and stateless variants, such as SPHINCS+, which are larger and more expensive to verify but do not require state management.
• STARK proof systems are based on hash functions in the random oracle model. They are transparent, inherently post-quantum, and require no trusted setup. Their trade-offs are size and verification costs. A STARK carries thousands of Merkle path hashes, resulting in proof sizes reaching tens to hundreds of KB; using today's provers, on-chain verification costs can reach millions of Gas units, an order of magnitude higher than pairing-based SNARKs.

Overall, adopting PQ primitives at different layers of the Ethereum protocol faces challenges from larger signatures and proofs, more expensive verification, and more complex protocols:

Consensus

The size of the Ethereum validator set is dynamic, with about 1/32 of validators attesting in each slot. BLS aggregation compresses their votes on-chain to as few as 8 signatures of 96 bytes each, and it is this aggregation that makes such a large validator set feasible. However, in the face of CRQC, a validator's private key can be derived from their public key, allowing an adversary who knows the validator's public key to forge their proofs and finalize an invalid chain. A natural post-quantum alternative is stateful hash schemes like XMSS, as validators can securely manage their key states when signing consensus. However, XMSS cannot aggregate like BLS; with around one million validators, each slot would need to carry approximately 31,000 PQ signatures individually. Assuming each signature is about 3 kB, the data volume per slot would be around 90 MB, several orders of magnitude higher than what current aggregation can achieve. In scenarios of single slot finality, the situation worsens. To finalize each block within their respective slots, the entire validator set would need to attest in each slot, resulting in signature data volumes reaching GB levels.

Accounts

User accounts authenticate using ECDSA. Once an account initiates a transaction, its public key is exposed, allowing CRQC to recover the private key and sign transactions on behalf of the owner, draining funds at will. Replacing it is inevitable, but externally owned accounts (EOAs) cannot manage signature states like validators, so they require stateless schemes, pushing signature verification costs onto the execution layer. Currently, there is no clear winner. EF's work focuses on the stateless hash scheme SPHINCS+, although lattice-based schemes are still under consideration, largely depending on verification costs. SPHINCS+ has high verification costs on EVM, which is why some efforts are dedicated to making stateless schemes themselves cheaper: SPHINCS-minus is a keccak-native verifier; while other work bypasses it, using account abstraction to rotate one-time keys, allowing each signature to use a much cheaper one-time scheme.

Rollups

Rollups settle by publishing validity proofs on L1. The cheapest verification method today is pairing-based SNARKs: proofs are only a few hundred bytes, with verification costs around 200–500k Gas. CRQC would undermine the pairing assumptions they rely on, allowing attackers to forge validity proofs of state transitions that never occurred, which L1 would accept, finalizing fraudulent rollup states and their underlying withdrawals. It also invalidates many tricks that rollups rely on to maintain low costs, such as wrapping large STARKs in a small final SNARK for settlement, as that outer wrapping is also pairing-based. Without it, rollups would need to verify STARKs directly on L1, costing millions of Gas units, an order of magnitude higher than SNARKs. Maintaining the affordability of STARK verification is currently an open research question.

Data Availability

Ethereum blobs use KZG commitments, a polynomial commitment scheme that generates a 48-byte commitment for each 128 kB blob. KZG facilitates data availability sampling because it provides (i) constant-sized openings, making verification costs low for each sample, (ii) linearity, supporting 2D sampling, and (iii) repairability, allowing corrupted encodings to be repaired based on the same commitment. Unfortunately, KZG is also pairing-based, so CRQC can forge openings, misrepresenting unavailable data as available data. Quantum-safe alternatives must come from hash-based commitments, with the question being how much of KZG's guarantees can be retained. Existing post-quantum candidates face different trade-offs in computational and network efficiency, with larger commitment sizes and increasing proof and verification costs. FRIDA is a transparent DAS scheme based on FRI, built on 1D Reed–Solomon codes, whose sampler tests proximity to the codeword. Its cost is bandwidth: KZG samples only need to carry a constant-sized opening, while each FRIDA sample comes with a full proximity proof, making each sample much larger. ZODA is another alternative for 2D encoding, allowing each sampled row and column to self-authenticate, achieving precise binding to the committed data, but this guarantee is per-sample and local (it only covers the positions queried by the node), and sampling requires downloading the entire row and column of the encoding. A third approach wraps the encoding in STARK. The idea is to prove in zkVM that the committed data is a valid Reed–Solomon codeword. Then a proof can precisely authenticate the entire encoding—not proximity, nor per-sample—and without requiring a trusted setup. The trade-off is proof throughput. EF's leanDA design and benchmarking research have measured this approach: on today's high-end CPU, throughput is about 0.9 MiB/s, occasionally reaching about 1 MiB/s. Current research is focused on making it fast enough.

Research Directions

Bridging the gaps in PQ primitive adoption will be a focus of research work in the coming years. We can categorize relevant research efforts into three cross-disciplinary directions:

Protocol Efficiency, in two aspects:

• PQ Signature Aggregation. The goal is to fold many large PQ signatures into a single proof, keeping costs low on the critical path of the protocol, especially in consensus. EF's leanVM has been able to aggregate XMSS into proofs smaller than 200 KiB at a rate of about 1,480 signatures per second, and these proofs can be recursively recombined, allowing signatures to be aggregated in parallel and then merged together. The open question is whether a protocol can be designed to remain feasible while moving towards single slot finality (i.e., proving for the entire validator set at each slot) and within the shortest possible slot time; additionally, who generates these proofs and the corresponding incentives.
• Transaction Authentication. Frames (EIP-8141) allow accounts to carry their own code to authorize transactions, moving signature verification out of the protocol layer and into the account's custom logic. Authentication is no longer tied to fixed ECDSA signatures, and each account can choose its own scheme. The direction to explore is how this verification operates: whether it is done on-chain through precompiles set for each scheme or through post-quantum, aggregatable proofs. The latter is explored by EIP-8288, which folds the signature proofs of many transactions into one, allowing the proof size per block and mempool bandwidth to remain stable even as the number of PQ transactions grows.

Cryptographic Efficiency. Reducing the size and verification cost of PQ signatures themselves; for example, the verification cost of SPHINCS-minus on EVM is about 94k Gas. Ideally, the research community should design zk-friendly signatures that can be efficiently proven in zkVM (EF's work on leanSPHINCS is progressing in this direction).

Proof Infrastructure. The proof cost of PQ primitives is mainly determined by the underlying hash operations. Standard hash functions for proofs (e.g., Keccak, SHA) are non-native operations that must be arithmetized, leading to computational overhead. Two avenues are being explored: SNARK-friendly hashes, like Poseidon (fast but less battle-tested), and proof systems that directly handle non-native operations, allowing standard cryptography to be proven without expensive field simulations. For the latter, research is advancing rapidly, with recent works like Zinc+ and modular commitments over integers.

Post-quantum primitives already exist, but they come with larger data sizes and higher verification costs. The research goal is to make them practical at the current protocol layer. For instance, publicly exposing very large signatures in the mempool would cause an explosive increase in the amount of data each client must store and verify, and verifying these signatures would cost more Gas, burdening both users and validators. Key technologies focus on STARK proofs, which can be efficiently aggregated, pushing data overhead and verification complexity from O(n) to O(1). Clients no longer handle and verify n different PQ signatures but only need to deal with a single aggregated proof. It is precisely this property that unlocks scalability, which we will discuss next.

Programmable Privacy

Ethereum is built on complete transparency, but as global finance moves on-chain, privacy becomes non-negotiable, and this has not yet been achieved. Existing solutions fall short in two areas. Some lack the programmability required for institutional use cases, where strong confidentiality must coexist with provable compliance, as both are complementary rather than opposing for institutions. Others are too cumbersome to adopt: poor user experience, higher costs, and sometimes requiring additional trust assumptions.

Consumer-facing shielded pools, such as RAILGUN and Privacy Pools, bring confidentiality to ordinary wallets; while enterprise platforms, like Paladin, offer programmable, compliance-ready privacy for institutions. However, there is currently no solution that achieves both institutional-grade privacy and the ease of use of ordinary wallets; moreover, using any of them still means dealing with off-chain states (like Merkle trees, invalidators, and cryptographic keys) and generating zero-knowledge proofs for each operation. Vitalik's maximal simplicity L1 privacy roadmap and pcaversaccio's privacy roadmap summarize the existing privacy research directions on Ethereum well. These directions can be categorized into four higher-level dimensions:

Usability

There are two issues here. First, constructing a privacy transaction should feel as straightforward as sending a regular transaction, but today it requires specially constructed transactions, off-chain state tracking, and zero-knowledge proof generation. Second, it should be cost-effective, but a privacy transfer bundles a SNARK, thus carrying more data and higher verification costs than a public transfer, and once post-quantum signatures and proofs are added, this gap will only widen. Standardized frameworks like Kohaku and Paladin, which can hide this complexity, are beginning to address the first issue, although both are still in early stages and actively being developed. The key to the second issue lies in proof aggregation (proposed as EIP-8288), an economically efficient way to combine the proofs of many transactions into one and share the verification costs.

Trustlessness and Censorship Resistance

Many shielded protocols today rely on relayers to submit transactions on behalf of users, which is a trusted intermediary that can censor, delay, or deanonymize. Eliminating this dependency is the goal. Frame transactions (EIP-8141) are a stepping stone: they decouple "who authorizes the transaction" from "who pays Gas and how it is executed," allowing the payer to be different from the signer, and shielded spending no longer requires a well-funded, identity-associated account to go on-chain. Two complementary parts fill this gap. The key-based random number EIP-8250 provides an independent random number domain, so shielded operations from the same sender do not conflict with each other; the recent root (EIP-8272) allows transactions to declare the Merkle root on which their proof is based, so as the tree progresses, the proof remains valid. Together, they provide a stable, protocol-internal verification reference for shielded transactions, so their validity does not depend on rapidly changing states, and anyone can check asynchronously. As for the forced inclusion list FOCIL (EIP-7805), includers can independently verify the validity of the transaction and request its inclusion, providing censorship resistance guarantees that relay-based methods cannot offer.

Data Retrieval

Reading is as difficult as writing. Private states (more technically, the encrypted notes used by privacy protocols) do not indicate the recipient in plaintext, so clients must scan and store large amounts of data just to find the payments they received; and each time an RPC query is made, it leaks what data it cares about, thus revealing who those data belong to. The same no-intermediary principle applies. Private Information Retrieval (PIR) would allow clients to read from RPC without leaking the queries, while oblivious message detection schemes would allow them to find their notes without scanning everything. However, the trade-offs in efficiency and limited maturity mean that the adoption of these solutions remains an active area of research.

Protocol-Level Privacy

The most ambitious direction is to embed privacy transfers into the protocol itself, incorporating PQ design constraints from the outset so that shielded balances are not exposed to the risk of "collect first, decrypt later." The challenges are daunting—from reconstructing the entire cryptographic stack (commitments, invalidators, key encapsulation, signatures) on a PQ basis to generating proofs on hardware wallets—these challenges are well outlined in the journey towards native post-quantum private ETH.

Like post-quantum security, all four directions rely on cheap proofs and aggregation, and once PQ constraints are applied, each becomes more difficult. Privacy is becoming a capability of the infrastructure itself, rather than an application layered on top after the fact.

The Dilemma and the Third Pillar

These two pillars share a common tricky characteristic: they are cryptographically expensive.

1. PQ signatures are larger and more costly than the elliptic curve schemes they replace.
2. Privacy protocols end-to-end rely on heavy proofs, increasing user complexity and costs.

If deployed at the protocol scale, both will raise the verification costs for each node on the network.

The same answer keeps emerging. Post-quantum signatures folded into recursive STARKs, quantum-safe data availability encoding wrapped in a STARK, privacy transfers batching their proofs into another STARK, while rollups have already settled in this way. The recurring question is: how can we afford stronger cryptography? This question always boils down to a more focused one:

How low can we aggregate and verify STARK at low cost and high efficiency?

Scaling the Base Layer

The rollup-centric roadmap has moved execution off L1, allowing Ethereum to focus on consensus, settlement, and data availability. But scaling cannot end at Layer 2. Each rollup inherits everything provided by the base layer: its consensus, finality, verification, and data availability, so improving the base layer improves everything built on top of it.

We focus on scaling along two axes: execution and consensus *, and on both, the decisive leverage is the same. Recursive proofs and aggregation can represent a large number of proofs or a large number of expensive cryptographic checks as a single concise proof. Because STARK can verify other STARKs, these aggregations can be combined infinitely; and because recursion folds each layer into a fixed-size check, the verification cost of the final proof does not grow with the number of proofs folded into it, so each node only needs to check one proof instead of thousands.

Execution

Execution is about processing more transactions in less time. Proof aggregation allows execution clients to compress the verification of a large number of transactions into a single STARK, and these transactions do not have to belong to the same type. Post-quantum signature verification, privacy transfers, and rollup settlements can all be folded into the same aggregation. This is why Frame transactions—allowing accounts to define their own transaction verification logic instead of hardcoding signatures—are crucial to the execution layer when combined with proof aggregation. Each transaction declares the required checks as an obligation through Frame, and builders handle the entire batch in a recursive STARK rather than having each node inline verify each check. The proposed Frame type for PQ signatures and STARK aggregation (EIP-8288) makes this concrete, with costs "paid only by builders and the mempool, not by all validating nodes"; the same idea also keeps mempool bandwidth constant as proof volumes grow.

Consensus

Consensus itself encompasses multiple issues, and STARK helps with each of them.

Throughput

Generate larger blocks without increasing validation costs. Once validators check validity proofs instead of re-executing blocks, builders can publish valid proofs while withholding underlying data, thus ensuring data availability must be explicitly guaranteed. The blocks-in-blobs approach packages transactions into blobs, allowing validators to sample availability rather than downloading the full payload; the proposer’s STARK aims to prove that blocks are executed correctly and encoded faithfully. This way, validation costs scale with proof expansion rather than block size.

Slot Time

Shorten the intervals between blocks by decoupling the available chain from the finality mechanism. A randomly sampled small committee continuously generates blocks on the critical path, as presented in the rapid LMD-GHOST layer with hundreds of validators and the decoupled consensus design; while the complete set of validators completes finality in parallel off the critical path. Fewer validators involved in each step means less STARK aggregation on the hot path and shorter slot times.

Finality

Reduce the current finality time of about sixteen minutes, for example, through single-round finality, removing a round of voting from the critical path.

These three conflict with PQ requirements. Once attestations shift to hash-based signatures that cannot aggregate like BLS, any of the aforementioned improvements will become extremely difficult to achieve within reasonable bandwidth budgets.

STARK again provides a way out: compressing and aggregating the proofs of the entire validator set within the target slot time. The minimalist chain design advances the same technology to the consensus state itself: allowing each validator to prove their balance and state, reducing each validator's state to a few bytes, paving the way for millions of validators.

This is where recursive STARK becomes foundational to the protocol. Combining these components—execution aggregation, blocks-in-blobs proofs, and aggregated post-quantum proofs—is the direction research must take next.

• The third axis is the expansion of the data layer, but this is strictly related to PQ DA research work.

Looking Ahead

The roadmap is uncertain, and research is never linear. However, some dependencies appear solid.

Recursive STARK aggregation makes stronger cryptography affordable. Stronger cryptography makes post-quantum security and privacy-preserving transactions practical on Ethereum. Thus, Ethereum becomes infrastructure usable for real economic activities without sacrificing its openness. However, whether these stronger primitives can become practical is not guaranteed.

Whether STARK aggregation can support Ethereum depends on a few specific and still open questions:

• Aggregating heterogeneous signatures. Proving and combining different PQ signatures in the same aggregation, such as aggregating hash-based signatures and lattice-based signatures in the same STARK. The account layer will not select a single scheme, so aggregation must be scheme-agnostic.
• Efficiently proving hashes. Proof costs are dominated by the underlying hash, and throughput still falls short of demand. This trade-off lies in: proving battle-tested hashes (like Keccak and SHA) on non-native fields incurs arithmetic overhead; while zk-friendly hashes (like Poseidon2) have lower proof costs but are less subjected to cryptanalysis.
• Cross-domain aggregation. Folding different kinds of STARKs into a single recursive proof—from PQ signature verification, privacy transfers to rollup state transitions—allows the entire stack to share the same verification.
• Adapting aggregation to consensus. Directly facing the timing requirements of consensus: aggregating the complete validator set within a single slot, with continuously shortening slot times, and finding the optimal balance between committee size, slot length, and finality.
• Protocol readiness. Ensuring that the infrastructure supporting these aggregations exists simultaneously at the mempool level (e.g., using Frame and EIP-8288) and at the consensus level: at a million validator scale, each validator's PQ signature STARK proof must also be aggregated, just like today’s BLS signatures.
• Aligning incentives. Aggregation merely shifts costs rather than eliminating them: proof work gets concentrated on block builders, raising real questions about incentives and centralization.

Building this infrastructure is not a side task but a main task. The primitives already exist, and transforming them into something that protocols can truly operate on, ahead of the migration pressure that will eventually force us to confront this issue, is what is needed in the coming years.