[ethresear.ch] [Layer 2/ZK Rollup] Ephemeral Rollup: The New "L1.5" of Ethereum

Ephemeral Rollup: The New “L1.5” of Ethereum

TLDR;

Ethereum’s core job has always been verifying state transitions. While rollups made that verification succinct, they at the same time hold their users’ state, which is why every rollup needs an exit. Native account abstraction (EIP-8141 and related EIPs) and proof aggregation are making it practical to keep compute and state apart. We call this L1.5, albeit it is perhaps more an architectural pattern than a layer. In the pattern we are talking about: a) The wallet keeps the user’s own state, b) L1 keeps the shared state and verifies every transition, and c) the compute in between is done by whoever takes the job without holding any state the next job needs, and d) state changes settle directly on L1.

The idea is not new: Relayers, builders and keypers have already done parts of this kind of job, and FOCIL’s includers will be next. What is new is the timing, “now and next”, as this becomes practical to build. We aim only to give a rough conceptualization of it in this post.

Introduction

Ethereum first verified state transitions by re-executing them. Rollups added succinct verification, where a fraud or validity proof lets L1 accept a batch without re-executing it. But a rollup also holds its users’ state. The state is kept in the rollup’s contract and only the rollup can change it, so users need an exit to leave. This was a deliberate choice, since rollups were built to scale Ethereum and at the time keeping the state off L1 was the efficient way to do that.

Rollups, as the 2021 rollup guide puts it, “move computation (and state storage) off-chain”. Keeping user state on L1 would have been costly: 1) Each user’s transition had to be verified on L1 one at a time, which was expensive, and 2) only an account’s key holder could send a transaction, so someone (a relayer or a sequencer) had to submit each transition and pay its gas.

EIPs that are scheduled or proposed now address both aforementioned issues: 1) With frame transactions a contract can send and pay for its own transaction, and 2) with proof aggregation each proof is checked once in the mempool and the block carries one proof for all of them. This makes it practical for an application to keep its state on L1 and hand the computation to whoever is available to do it.

We attempt to conceptualize this new pattern in two parts: Part 1 describes the pattern, and Part 2 for its context.

Part 1: the pattern

Three places for state

wallet : the user's own state, in the clear, and the secrets that open it
L1     : shared and global state
         a commitment per piece of user state (its provenance)
         a "used" marker per spent piece (a nullifier)
         the verifier of every transition
L1.5   : f(L1 state, user's inputs) -> (new state, proof)
         for one transaction or one round; keeps nothing the next job needs

This is the commit-and-prove design that L2s use, except that the commitment is on L1 and the opening is in the wallet. L1 keeps only what it needs to check the next transition, the wallet keeps everything else, and L1.5 does solely the computation.

Reality check: Private rollups already keep notes in the wallet. In Aztec, the user’s PXE runs on the client and stores the notes, and a transaction sends “new note commitments and nullifiers” to the sequencer, which adds them to the rollup’s trees.
In L1.5 the commitments and nullifiers go to L1 directly, without a rollup holding them in between.

What L1.5 must guarantee

For the private settlement case we look at in this post, we want a job to have four properties before we call it L1.5 rather than an operator:

• Stateless: once the job is done nobody depends on it, and anyone can take the next one. A worker can keep a cache, as long as it holds nothing the next job needs.
• Checked: L1 verifies its output.
• Paid without linking: the user can pay for it without revealing who they are.
• Landed without an operator: its output reaches L1 without a long-lived account to submit it and pay for it.

The last one used to be the hard part, which native account abstraction makes practical.

Who sends the transition

Under EIP-8141 a transaction is a list of frames. A VERIFY frame can approve execution, payment, or both, and it may use up to 100,000 gas and read only the sender’s own state. So an application contract can check a proof in its own VERIFY frame and pay the fee from the funds it moves. EIP-8250 adds keyed nonces, “for example one derived from a privacy nullifier”, so the chain rejects a double spend the same way it rejects a reused nonce. EIP-8288 lets each mempool node check a proof once, and the block carries “one single recursive STARK” for all of them. With these, only the contract pays for the transaction and any node can relay it, so the user needs no ETH at the address it spends from.

Here is a redemption from a privacy pool as we ran it on the Hegota test network (transaction):

[0] VERIFY   recent roots   the pool's root, by slot             (EIP-8272)
[1] VERIFY   the pool       checks the proof; approves execution and payment
[2] SENDER   the pool       withdraw: pays the recipient, less the fee
[3] DEFAULT  the pool       refunds the unused fee to the recipient
nonce key:   the note's nullifier hash                            (EIP-8250)
signatures:  none

Frame [0] reads a recent root through EIP-8272, and frame [1] is where L1 checks the proof. With EIP-8288, the proof check moves out of this frame into a separate dependency frame. Either way, L1 checks the proof before any funds move.

Part 2: L1.5 in context

Naming, and prior art

This pattern somehow applies at any scale, from one application to an L2 to the protocol itself.

Compared with an L2, an L2 holds its users’ state and so its users need an exit, while, on the opposite, L1.5 holds no state. L1.5 is also independent of based and native, which describe who sequences and who executes, while L1.5 is about who holds the state. We call it “1.5” as we refer to its position, which is between the wallet and L1. If we really need to give it an “X-rollup” name, the X would be ephemeral.

Several roles on Ethereum, existing or planned, already do part of this. In each of them someone computes while the state stays with the user or on L1, though each has only some of the four properties above:

Reality check: Nobody needs an exit from a relayer or an includer, because if one fails the user picks another. However, two of these roles are not yet open to anyone. Privacy Pools’ contract accepts a root from one role only, and the MEV-Boost relay is “a trusted party” in the words of ePBS EIP.

Why now

Efficiency was the main obstacle, and it has been getting smaller with each step. Native account abstraction has been proposed since 2020 (EIP-2938). Frame transactions were created in January 2026, replacing EIP-7701. Keyed nonces followed in April, and frame transactions were Scheduled for Inclusion in Hegota in August. The Strawmap places both in Hegota, and EIP-8288’s STARK aggregation in the fork after it. These STARKs are hash-based, and therefore post-quantum, and recursion lets a node check each proof once while the block carries one proof for all of them.

The Strawmap covers L1 but says little about what applications should do with these changes, and L1.5 is one answer.

Native rollups, the first un-capture

An L2 commits to a state in a contract that users deposit into and withdraw from. It has two independent sets of tools, verification (fraud or validity proofs) and compute (ZK, MPC, FHE or a TEE). Whatever the combination, the users’ state stays in the L2’s contract, so every L2 needs an exit.

Native rollups were proposed in January 2025 with a similar timing argument: “a big idea whose time may have finally come”. A native rollup verifies its state transitions with L1’s own execution engine, through an EXECUTE precompile, “dramatically simplifying synchronous composability”. The proposal is now EIP-8079, the Strawmap’s headliner for L* (December 2029).

Native rollups are mostly seen as a fix for L2 fragmentation, but IMHO they do more. State inside the rollup can be composed with state outside it, which is a first step toward un-capturing state. A user who keeps an ERC-20 on L1 could trade, in one transaction, against a central limit order book kept in the rollup. Native account abstraction goes a step further, since the order book itself can live on L1 as a contract that sends and pays for its own settlement transactions. A matcher in L1.5 proves a batch of matches and any node relays it to the order book, which checks the proof in its VERIFY frame. If the matcher stops, another one takes over.

The next generation of Ethereum applications

This opens up a new kind of applications, where the wallet keeps the user’s state in the clear, L1 keeps the shared state and a commitment to each user’s state and only verifies, and L1.5 computes and proves.

Some applications may get there gradually, starting from a native rollup. Later, the L1.5 part can be an ephemeral layer that is put together on demand. It collects what it needs from L1 and from the users, computes, posts the result to L1 with a proof, and disbands.

Below are three directions which we think can be interesting. We only make rough sketches (and some depend on Ethereum upgrades that are only proposed so far).

Gas-less payments in privacy-preserving applications (for example, a Stealth Address Protocol for assets other than ETH). Blind gas tickets have been proposed before. Vitalik described aggregators that sell a set of tickets up front, each “encoded using a Chaumian blinding scheme”, and in Toni’s Gas Ticketing a coordinator funds an unfunded address when a ticket is redeemed. In both, users trust a single issuer. With L1.5, a committee issues the tickets with a threshold blind signature, so no single member can sign a ticket alone and none of them sees what it signs, and the tickets are redeemed on L1 through native account abstraction. The user buys tickets from any account and later spends one from a fresh account, and the application’s paymaster checks the ticket in its VERIFY frame. Since the issuers cannot link a ticket to its purchase, the user never needs ETH at the address it uses, and never has to fund that address from one linked to it.

Fair exchange for Ethereum services. Suppose a user pays a private RPC with a blind ticket for a PIR query. The server should be paid only if its answer is correct, which a plain payment does not enforce. The user can check an answer against a block header, but a server that takes the ticket and never answers leaves no evidence (the fisherman’s dilemma), and a user who disputes a wrong answer reveals the query. L1.5 can turn this into a fair exchange, similar to zero-knowledge contingent payments for services. The server posts its answer encrypted to the user, with a proof that it is the correct answer to the encrypted query against a recent header’s state root, and the ticket pays out only if that proof verifies in the paymaster’s VERIFY frame. The query stays private and the server is paid only for a correct answer, so there is nothing to dispute. Note that the PIR query does not change the state it reads, and only the verification and the payment settle on L1.

A stealth Privacy Pool. A Privacy Pool is visible on chain, since a deposit into a known contract shows that the user used a privacy tool. We would like to find out whether L1.5 can make the pool stealth, so that users never touch a recognizable pool contract. An L1.5 round shuffles many users’ ETH to fresh stealth addresses, and each leg is an ordinary transfer. The chain would then show no pool contract, deposit or withdrawal, only payments between fresh addresses, and each one could be a payment, a swap or part of a shuffle. Compliance can still be offered if wanted, with an association-set provider (ASP) vouching for the funds each participant brings and giving its proof to the round instead of to a contract. What privacy such a round gives overall, and how input-eligibility proofs carry over to it, we leave for later work.

The protocol is L1.5 at scale and its implications

Looking back and forward, Ethereum’s own protocol already runs short-lived roles over long-lived shared state, at a much larger scale:

• Execution: every node re-executes so that no node has to trust another. With zkEVM proofs (the Strawmap’s “gigagas L1”), one party computes and everyone verifies.
• Consensus: the validator set is shuffled into new committees every epoch. Each committee lasts an epoch while the stake behind it stays, and committees are checked through their signatures.
• Data availability: nodes share the work of serving data, and check it by sampling.
• FOCIL and LUCID work like L1.5 roles built into the protocol, with 16 includers per slot whose lists the block must respect, and a key publisher whose timely key release the network checks.

We see two lines of work here. One is to build new functions as L1.5, such as tickets, shuffles, fair exchange, proving committees and aggregation. The other is to reuse what the execution, consensus and data availability layers already do: draw committees from a seed fixed in advance (studied as fluid MPC and YOSO), make every member’s actions public and signed, post bonds that are burned on failure, force-include L1.5 outputs as FOCIL does for transactions, and publish and sample whatever must be public.

At this point, perhaps one can as well put mempool into the L1.5 class.

From “an L2” to “wallet + an L1.5”

And perhaps we can even make the canonical version a new standard when the native account abstraction EIPs are more matured.

Some L2 applications can move toward this model step by step:

1. Move owned state to wallets. Keep only commitments and nullifiers on L1, as privacy pools already do, and let wallets hold the openings.
2. Let the contract send its own transactions. Check the proof in the contract’s VERIFY frame, pay the fee from the funds being moved, and use the nullifier as the nonce key. No sequencer or relayer is needed.
3. Make proving and submitting open jobs. The user’s device can prove, and stronger nodes can help on public statement, composed in a Lego style, and any node can relay.

Moving state into the wallet also moves responsibility to the wallet:

• One recoverable seed. Derive every secret from one seed. Make it recoverable through guardians plus a phrase the user keeps, with a delay the user can cancel.
• Prove on the device. If a committee must help, give it secret shares (co-SNARK), never the full witness. Proofs can also be composed Lego-style and aggregated.
• Pay blindly (sketch). Buy tickets from one account and spend them from fresh ones. Never fund a fresh address from a known one, and never sweep fresh addresses into one.