# New Directions in Synchronous Composability

Vitalik' recent [ethresearch post](https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863) on Synchronous Composability is significant for two reasons. It marks a major shift in [his stance](https://x.com/VitalikButerin/status/1803459217933623418?lang=en) around the subject, and it injects a new perspective into a research subject that has somewhat staled.

In this article, we'll deep dive into the post, compare and contrast it with existing designs, and try and outline what's needed for the idea to become a reality. But first, let's get some definitions out of the way:

#### What is Synchronous Composability?
Synchronous composability in a single domain, such as the L1 EVM, is something we are all familiar with. It is the ability to stitch together multiple smaller actions or contract calls into a single larger transaction. Execution is synchronous and atomic: every call sees the effects of the previous ones, and either the entire transaction succeeds or the whole thing reverts. There is no need to reason about intermediate states or partial failure.


This is one of Ethereum’s core superpowers. It allows complex applications to emerge by composing *permissionless* money Legos, where independently deployed contracts can be combined safely and predictably without prior coordination.

#### What Happened to Synchronous Composability?
The [rollup-centric roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) scaled Ethereum’s aggregate throughput, but it did so by fragmenting state across many execution environments. By default, contracts that live on different chains cannot interact synchronously. Calls across domains incur delays and must be handled asynchronously, often across multiple blocks. In this world, it is usually easier to redeploy the same DEX or lending protocol on each rollup and build liquidity locally than it is to tap into existing liquidity on L1.

Intents have emerged as a partial interoperability solution in response to this fragmentation. They allow users to express desired outcomes and rely on third parties to execute them across chains. In practice, however, intents are primarily used for cross chain token transfers and often introduce additional trust assumptions. While useful, they fall short of delivering the same user and developer experience as synchronous composability, where interactions are atomic, state is shared, and execution can be reasoned about as a single transaction.

#### Requirements L1<>L2 Synchronous Composability
For the rest of this post, we'll focus specifically on synchronous composability between the L1 and rollups, which is notably harder to achieve than rollup to rollup.


1. **Real-Time Proving**
L1 actions should only succeed if the corresponding L2 actions succeed. The only way to enforce this synchronously is for the L1 to verify a validity proof of the L2 execution. As a result, *optimistic rollups are incompatible with this model*. To preserve synchronicity, the rollup state transition must be proven within a single L1 slot, which requires real-time provers.
In the diagram above, the proof encapsulates the L2 swap. If the proof is invalid, the call to `borrow()` reverts and atomicity is preserved. Conversely, if `borrow()` fails on L1, the `swap_l2()` call never happens, so the L2 swap must not exist in the rollup’s history. If the sequencer tries to include it, the proof will fail and the entire transaction reverts.
2. **Reorging with the L1**
If an L1-initiated action is removed due to an L1 reorg, the corresponding L2 action must also be removed or atomicity is broken. For example, an L1 deposit should not be reorged out while still crediting the user on L2. This is why rollups typically delay processing L1-initiated actions until the L1 block is sufficiently confirmed or finalized. Synchronous composability requires rollups to instead reorg in lockstep with L1.
3. **Coordinated Sequencing**
For contracts to compose successfully, all execution must occur against an agreed upon pre-state. If `borrow()` fails on L1 or the swap fails on L2, then all subsequent actions must fail to preserve atomicity. While this behavior is safe, it is not useful for users unless success can be reliably achieved.
Practical synchronous composability therefore requires coordination between the L1 proposer and the L2 sequencer. Both sides must provide guarantees about the pre-state they are executing against so that each leg of the transaction is expected to succeed.
4. **Single L1 transaction**
Atomicity cannot span multiple L1 transactions. Once an L1 transaction succeeds, it cannot be reverted by the protocol. As a result, a synchronously composable operation must be contained entirely within a single L1 transaction.
If the rollup settles in a later transaction, atomicity is lost. For example, if `borrow()` succeeds in one L1 transaction and the rollup later settles without including the corresponding L2 swap, the rollup state transition may be valid in isolation but the overall operation has violated atomicity. There is no way to roll back the already successful L1 action.
Therefore, a synchronously composable transaction must include all L1-initiated actions, the rollup’s data submission, the corresponding validity proof, and verification of that proof within the same L1 transaction.

#### What About Based Rollups?
Based rollups and synchronous composability are often discussed together because based rollups naturally two of the required properties. In particular, they trivially solve the coordination requirement: the entity sequencing the rollup is definitionally the L1 proposer. There is no separate sequencer to coordinate with, and the rollup’s execution is inherently aligned with the L1 pre-state.

Additionally, because based rollups are sequenced directly by the L1, they naturally reorg with the L1. If an L1 block is reorged out, the corresponding rollup block is reorged as well, preserving atomicity without requiring special handling.

That said, based rollups are not sufficient on their own. To achieve synchronous composability with the L1, a based rollup must still be able to produce and verify its validity proof in real time. This requirement has only become practical very recently.

#### Synchronous Composability Without Based Rollups?
This is the approach outlined by [SCOPE](https://ethresear.ch/t/scope-synchronous-composability-protocol-for-ethereum/22978/3). Instead of making the rollup fully based, the L1 proposer sells a portion of their blockspace to the rollup sequencer. This allows the sequencer to obtain strong guarantees about the L1 pre-state, which is sufficient to execute synchronously composable transactions successfully.

A key advantage of this design is that rollups do not need to give up sequencing autonomy to L1 proposers. Rather than changing their execution model, rollups can opt into an additional service provided by the L1 when synchronous composability is needed. This helps mitigate MEV concerns and significantly reduces the amount of work required for existing rollups to approach based like behavior.

The main downside is that this approach relies on deeper coordination within the L1 supply chain. In particular, L1 preconfirmations are required to sell the blockspace, and these introduce their own adoption and operational challenges.

Vitalik’s approach inverts this model. Instead of the rollup sequencer purchasing blockspace from the L1, the rollup makes a portion of its own blockspace available to the L1 proposer. The L1 proposer can then guarantee the L1 pre-state as usual, and, by being granted control over part of the L2 blockspace, also guarantee the L2 pre-state. With both pre-states aligned, synchronously composable execution across L1 and L2 becomes possible *without* requiring L1 preconfs.

### Stepping Through Vitalik's Design
**Source: [Combining preconfirmations with based rollups for synchronous composability ](https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863)*

#### Certificates and Regular Blocks
We make no assumptions about the rollup sequencer’s topology or leader election mechanism. Instead, we define a *regular* block (shown in light green) as one that is accompanied by a valid certificate.

The rollup’s state transition function only processes regular blocks with valid certificates. This abstraction cleanly generalizes across different sequencing models, including centralized sequencers, decentralized committees, and shared sequencers, where a certificate may consist of a single signature, a quorum of signatures, or a signature plus proof that the signer is the current leader.

#### Slot-Ending Blocks
Like today, the sequencer’s primary role is to frequently publish regular blocks off chain. In this design, however, a block may also serve as a special *slot ending* block (shown in dark green).

A slot ending block does not differ in content from a regular block. Instead, it simply denotes the final block for which sequencer certificates are required within a given L1 slot. After this point, the rollup permits based blocks to be built on top.

In the original post, a block is designated as slot-ending when the sequencer attaches a special certificate. However, this designation does not need to be explicit. Any rule is acceptable as long as it can be verified by the rollup’s state transition function. For example, if the sequencer’s certificate includes the L1 slot number, then every `N`th regular block within a slot could be implicitly treated as the slot ending block.

#### Based Blocks
Blocks that appear after a slot-ending block and before the end of the corresponding L1 slot are called *based blocks* (shown in red). They are called “based” because, as in based rollup designs, anyone can attempt to publish them and no sequencer certificate is required for validity.

As in [vanilla based rollup designs](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016), however, permissionless publication does not imply guaranteed inclusion. The L1 proposer ultimately decides which blocks are included on chain. Accordingly, we treat the L1 proposer, together with the surrounding PBS pipeline, as the effective sequencer of based blocks.

#### Synchronous Composability Window
Once a slot-ending block is broadcasted, a sliding window opens that lasts until the end of the current L1 slot. During this window, the L2 pre-state is fixed: the L1 proposer knows exactly which rollup state they are building on and, critically, that it will not change beneath them. At the same time, as the current proposer, they also control the L1 pre-state.

With both pre-states fixed, the L1 proposer can safely construct synchronously composable transactions during this window, confident that execution across L1 and L2 will succeed atomically.

#### Rollup Settlement
It is the L1 proposer’s responsibility to batch and publish regular, slot-ending, and based blocks to L1. If no based block is produced, either because no one attempts to build one or because the proposer chooses not to include it, the rollup sequencer simply resumes building regular blocks on top of the last slot-ending block during the next slot.

Notably, submitting a validity proof is not strictly required to settle the rollup. Validity proofs are only necessary to enable synchronous composability. A rollup may still use based blocks without real-time proving as a mechanism to partially decentralize sequencing. This approach is compatible even with optimistic rollups, though it does not provide atomic L1–L2 composability.

#### Timing Games
The sequencer must carefully time when it releases the slot-ending block. If it is published too early, rollup users may experience a brief period of downtime while the L1 proposer builds based blocks, since we assume the L1 proposer is not preconfirming L2 transactions.

If the slot-ending block is published too late, the L1 proposer may not have sufficient time to construct a based block, batch the blocks into blobs, generate and verify the state transition proof, include the transaction, and publish the L1 block before the slot ends.

As a result, the sequencer is forced into a timing game, balancing rollup liveness and user experience against the narrow window required for synchronous composability.

### Step-by-step Example

1. Sequencer observes L1 confirmation
The sequencer waits until the previous L1 block is attested and sufficiently known, ensuring it is safe to build against.
2. Sequencer produces regular blocks
During the L1 slot, the sequencer continuously publishes regular L2 blocks off chain, each accompanied by a valid certificate.
3. Sequencer publishes the slot-ending block
Near the end of the L1 slot, the sequencer releases a slot-ending block. At this point, the L2 pre-state for the current slot is fixed.
4. L1 proposer builds based blocks
After observing the slot-ending block, the L1 proposer begins constructing based blocks:
a. The proposer updates their local view of L2 state to reflect the slot-ending block.
b. The proposer simulates the L1 leg of `depositAndSwap()`, inserts the corresponding L2 transaction using the simulated inputs, receives the L2 execution result, and continues execution on L1.
c. The proposer repeats this process for additional calls such as `withdrawAndLend()`, interleaving L1 and L2 execution synchronously.

5. L1 proposer proves the rollup state transition
a. All regular, slot-ending, and based blocks are batched into one or more blobs.
b. A real-time prover generates a validity proof covering the certificate chain, the rollup state transition function, and any rollup specific validity rules.
6. L1 proposer builds a single L1 transaction
a. The transaction includes all L1 user actions, such as `depositAndSwap()`.
b. It includes the rollup blobs and the corresponding validity proof.
c. It calls the rollup’s inbox contract to submit the blobs.
d. It calls the rollup’s bridge or settlement contract to finalize the state transition.
7. L1 transaction is sequenced
The proposer or builder ensures that the L1 pre-state is correct for the synchronously composable transaction before sequencing it into the L1 block.
8. L1 block is broadcast
The L1 block containing the composable transaction and rollup settlement is published to the network.
9. Repeat for the next slot

### Weaknesses / Open Questions
#### Proving Time
Generating and verifying a validity proof within a single 12 second L1 slot is extremely demanding and has only become feasible very recently. In this design, the L1 proposer often has even less time, since proof generation can only begin after the slot ending block is known.

One way to reduce proving latency is for the rollup to lower its gas limit, but this directly reduces throughput and may harm the rollup’s competitiveness. A more attractive approach is for the L1 proposer or preconfer to pipeline proof generation by proving sequenced blocks incrementally as they become available. In that case, the critical path is proving the proposer’s own based block within the remaining slot time.

#### L1 Timing Games
L1 timing games have pushed block publication increasingly close to the attestation deadline. This negatively impacts UX by extending the period during which the rollup sequencer must wait before safely producing the first regular block of the next slot.

Fortunately, proposals such as reducing the L1 slot time to 6 seconds would also reduce this sequencer downtime proportionally, helping mitigate the worst UX effects without changing the underlying design.

#### Permissionlessness
This design is permissionless in a narrow sense: anyone may attempt to submit a based block, and no sequencer certificate is required for its validity. However, the existence of a based block still depends on a slot-ending block being produced first. A sequencer can therefore prevent synchronous composability entirely by refusing to publish slot-ending blocks.

While this behavior can be disincentivized, it raises an open question: is there a rule for defining slot-ending blocks that the sequencer cannot game?

### Modifications to Rollup Stacks
Fortunately, this design requires relatively few changes to existing rollup stacks. At a high level, an implementation may include the following components:
1. Permissionless Inbox Contracts
The inbox contract does not whitelist sequencers. Instead, anyone may submit rollup data, provided they can supply a valid certificate chain. Submissions that fail verification simply revert, making invalid or junk publications harmless.
2. Instant Settlement
The inbox contract should only accept blobs if a validity proof is verified within the same L1 transaction.
3. Mailbox Based Accounts
To simplify cross-chain accounting and execution, mailbox abstractions, such as those used in [SCOPE](https://ethresear.ch/t/scope-synchronous-composability-protocol-for-ethereum/22978/3), are useful. These provide a clean interface for synchronously passing inputs and outputs across domains.
4. State Transition Function Updates
The rollup’s state transition function must be extended to verify certificate chains, enforce block validity rules, and ensure mailbox equivalence between L1 and L2 execution.