Synchronous Composability Between Rollups via Realtime Proving

1. Based Rollups and Realtime Proving

A based rollup is a rollup where anyone can propose a new block, there is no privileged sequencer. Any participant can take the current state of the rollup, apply a set of transactions, and produce a new block.

A key design advantage emerges when we require that the data availability payload and the validity proof are submitted together, as a single atomic unit. In traditional rollup designs, data is posted first and the proof comes later, which introduces a gap that complicates the incentive design: who generates the proof? When? How do you ensure they are compensated fairly and promptly?

By posting data and proof simultaneously, we collapse this gap entirely. The block proposer is responsible for both execution and proving. If the proof is invalid or missing, the block simply does not exist. This dramatically simplifies the incentive mechanism, the block proposer is the prover, and their reward comes from the same source (e.g., transaction fees) without the need for separate proof markets or challenge periods.

This is made possible by realtime proving , the ability to generate validity proofs fast enough that they can be produced alongside block construction, rather than as an asynchronous afterthought.

Realtime proving is rapidly becoming practical. As of today, proving a full Ethereum block requires around 12 GPUs with an average proving time of ~7 seconds. There is still significant margin to improve and push latencies lower, both through hardware improvements and proving system optimizations, though it is difficult to predict exactly where the limit will be. Prover centralization is a valid concern: the hardware requirements are non-trivial, and not every block builder will have access to the same proving infrastructure. However, proving is inherently parallelizable and commoditizable, and the trend is clearly toward faster proofs on cheaper hardware.

2. What Is Synchronous Composability?

Synchronous composability means that within a single transaction, a smart contract on one chain (L1 or a rollup) can CALL a smart contract on a different chain (L1 or another rollup) and receive the result back in the same execution context, just as if both contracts lived on the same chain.

Today, cross-chain interactions are asynchronous: you send a message on chain A, wait for it to be relayed to chain B, and then separately handle the result. This breaks the composability model that makes Ethereum’s DeFi ecosystem so powerful. Protocols cannot atomically compose across rollup boundaries.

Synchronous composability restores this. From the developer’s perspective, calling a contract on another rollup looks and behaves exactly like calling a contract on the same chain. The transaction either succeeds atomically across all involved chains, or it reverts entirely.

3. The Simple Case: L2-to-L2 Composability

Before tackling the harder problem of L1↔L2 interaction, it is worth noting that composability between L2 rollups alone is relatively straightforward.

If we are only dealing with L2s, we can bundle the data availability for all affected rollups into a single blob. The block builder constructs a combined execution that touches multiple rollup states, proves them all together, and posts the result as one atomic data availability submission. Since all affected state transitions are proven and posted together, composability follows naturally, the transitions either all happen or none of them do.

This observation is the foundation. The harder problem is making this work when L1 smart contracts are part of the interaction.

4. Proxy Smart Contracts

The core mechanism that enables cross-chain calls is the proxy smart contract. A proxy is a smart contract deployed on one chain that represents a smart contract living on a different chain.

When a contract on L1 wants to call a contract on rollup R, it does not somehow execute code on R directly. Instead, it calls the proxy of that R contract, which exists on L1. The proxy contract encapsulates the cross-chain call: it knows what the target contract is, it processes the call, applies the corresponding state changes on the rollup, and returns the result, all within the same transaction execution.

From the caller’s perspective, interacting with the proxy is indistinguishable from interacting with the real contract. The proxy is the local interface to a remote contract.

5. L1 ↔ L2 Interaction Model

When a transaction involves both L1 and L2 smart contracts, the execution follows a structured process:

Step 1: Ensure Proxy Contracts Exist

Before execution, all proxy smart contracts for the L2 contracts that will interact with L1 must be deployed. If a contract on rollup R will be called from L1, its proxy must already exist on L1.

Step 2: Build and Submit the Execution Table

An execution table is constructed and stored temporarily in the L1 state. This table is a sequence of entries, where each entry describes an action and its consequences. Each entry contains:

• Action: Primarily a CALL or a RESULT.
• A set of L2 state transitions: Which rollups are affected, and what their state roots transition from/to.
• nextAction: What comes next, either a RESULT (with return data) or another CALL (to a different L1 smart contract).

The table captures the full trace of cross-chain interactions. For example, consider a nested call scenario:

A (on L1) calls B (on Rollup 2)→ B (on Rollup 2) calls C (on L1)→ C (on L1) returns→ B (on Rollup 2) returnsA (on L1) continues execution

In this case, the execution table would contain two entries:

| # | Action                | L2 State Transitions          | nextAction          ||---|-----------------------|-------------------------------|---------------------|| 1 | CALL B (on Rollup 2) -| Rup2: stateRoot₀ → stateRoot₁ | CALL C (on L1)      || 2 | RETURN from C (on L1) | Rup2: stateRoot₁ → stateRoot₂ | RETURN to A (on L1) |

The first entry says: “when A calls B on Rollup 2, the rollup transitions from stateRoot₀ to stateRoot₁, and the next thing that needs to happen is a call to C on L1.” The second entry says: “once C returns, Rollup 2 transitions from stateRoot₁ to stateRoot₂, and the final result is returned to A.”

The execution table encodes this entire call/return sequence, together with all the rollup state transitions that occur at each step. Crucially, the table is accompanied by a single validity proof that guarantees the correctness of every execution step in the table. This proof is verified once when the table is submitted.

Step 3: L1 Execution with Proxy Resolution

Now L1 transactions execute normally. When execution reaches a point where an L1 contract calls a proxy contract, the proxy does the following:

1. Looks up the corresponding CALL action in the execution table.
2. Verifies and applies the state root changes for the affected rollups.
3. If there are nested L1 calls in the sequence, executes them.
4. Removes the consumed entries from the execution table (to avoid wasting L1 storage).
5. Returns the RESULT to the calling L1 contract.

From the L1 execution environment’s perspective, the call happened normally and returned a result. The complexity of the cross-chain interaction is entirely abstracted away by the proxy and the execution table.

Step 4: L2-Initiated Transactions

A transaction originating on L2 that interacts with L1 follows the same model, but the first action in the execution table is an L2TX rather than a CALL. The L2 transaction kicks off execution, and any calls to L1 contracts become nested entries in the table, resolved in the same way.

Step 5: Handling Reverts

Two special actions: REVERT and REVERT_CONTINUE handle reverts across chain boundaries in a way that mirrors how reverts work within a single chain.

When a revert occurs during execution on L2, a REVERT action is sent to L1. L1 then processes the revert by undoing any nested L1 calls that were part of the reverted execution path and updating the affected rollup state roots accordingly. Once L1 has finished unwinding the reverted calls, a REVERT_CONTINUE action is sent back to L2, allowing execution to resume. The end result is that reverts work the same way they currently work within a single chain.

6. Additional Notes

Account Abstraction and Incentive Alignment

Ensuring that proxy contracts are deployed and that incentives between the user and the block builder are properly aligned can be handled using existing Ethereum standards — specifically EIP-7702 (set EOA account code) and EIP-4337 (account abstraction). These standards provide the flexibility needed to coordinate the setup phase without requiring changes to the core protocol.

Rollups Are Not Limited to the EVM

Rollups participating in this system do not need to be EVM-native. Any rollup that can accept and generate `CALL`s to other rollups can participate. Each rollup defines its own state transition function via a zkVerification key. A rollup could even have an owner with full control over its state root.

The only constraint the main system imposes is Ether accountability: the system must track how much Ether each rollup holds and must not allow a rollup to make a `CALL` with a value higher than its total Ether balance.

Native Tokens and Value Transfers

Rollups can define their own native token. The only restriction is that the state transition function should not accept or make CALLs with a non-zero Ether value from or to an external rollup if the rollup uses a different native token. This prevents accounting mismatches between the rollup’s internal token and the Ether tracked by the L1 system.

No L1 Fork Required

This entire mechanism can be implemented without forking L1. Everything operates through smart contracts deployed on the existing Ethereum network.

Orthogonal to Preconfirmations

This proposal is fully orthogonal to preconfirmation mechanisms. It neither depends on nor conflicts with preconfirmations. In fact, it can benefit from L1 preconfirmations once they are available, as faster L1 finality would reduce the latency of cross-chain interactions.

Reference Implementation

A first draft of how these smart contracts would work is available at: https://github.com/jbaylina/sync-rollups