L2 synchronous composability is the property that lets a single transaction atomically call across multiple Layer 2 rollups (and L1) as if all state lived on one chain — a smart-contract call from base into Arbitrum that itself calls back into base, with the entire bundle reverting if any sub-call fails. As of May 2026, ETHPrague’s headline proposal for this is EZ (formerly “Aggregation Layer”), led by Jordi Baylina and debuted in a fireside chat with Vitalik. The technological precondition — real-time ZK proving — is now in place; what remains is coordination, smart-contract scaffolding, and the social work of getting L2s to share a settlement abstraction.

Key Ideas

EZ’s design

The headline talk is the Vitalik–Baylina fireside (→ ETHPrague 2026 — Overview). EZ’s design choices:

  • Ethereum is the common trust root. Each rollup keeps its own sovereignty, state-transition function, and proof system (ZK, OP, multisig, TEE-based — anything that can attest to correctness). EZ does not mandate a shared proof system.
  • Outbox / inbox interface. From EZ’s perspective, each rollup is just a state-transition function with two arrays — outbox calls and inbox calls. Rollups talk via simple call/return semantics; the inbox on one side must match the outbox on the other.
  • Composers + builders. A new role: composers collect transactions across chains and bundle them. Builders then build the L1 block containing the bundle. Validators retain ultimate authority — they choose the composer and the builder, identical to today’s MEV-Boost flow.
  • Proof aggregation per system. A single L1 transaction proves all the cross-chain interactions. If three rollups use two proof systems, you get two proofs (one per system) that together prove every cross-chain call. Each rollup chooses which proof systems it trusts.
  • Hash-bound assume/prove records. Each chain emits a record of “things I assume vs. things I prove”; the hash is passed to both proof systems, and both must agree. Tampering or misalignment breaks the proof.

Why it’s possible now

Baylina’s key admission: for years he believed this was impossible, asynchronous bridges were the only way. The change is the maturity of ZK proving — sub-12s real-time proofs (→ ZK Proving Infrastructure) — that makes per-block aggregated cross-chain proofs feasible inside one Ethereum slot. EZ couldn’t have shipped in 2024.

What it enables

The canonical use cases (Baylina’s framing):

  • Atomic multi-chain commerce — Buy a plane ticket on base, book a hotel on L1, get insurance on another rollup, all in one revert-if-anything-fails transaction.
  • DeFi liquidity routing — Flash-loan on one chain, swap on another, repay on a third — atomically.
  • Specialized chains — Identity chain, voting chain, custom-precompile chain — all callable from any other chain in the EZ as if local.
  • Extending Ethereum without forking — Sovereign rollup with novel precompile, exotic ZK primitive, or different VM (WASM, Stylus, even non-EVM like Bitcoin); the rest of Ethereum can still call into it.

Block-time tradeoff

Baylina’s most honest answer: synchronous composability across chains forces blocks to be at least one L1 slot (12s today, eventually shorter). Sub-second L2s like Arbitrum-with-centralized-sequencer give up synchronicity. Possible middle grounds: partial-lock approaches (lock specific accounts/contracts but keep the rest of the L2 live), or dual-chain architectures (one fast sovereign chain + one synchronous chain) under shared sequencer control. Open research.

Failure modes are application-level

The walk-through (Vitalik attack-testing): if base’s proof system breaks, malicious calls leak into Arbitrum’s inbox. But Arbitrum’s own state is fine — only contracts that trust the call are compromised. Each contract decides whether to trust each other rollup’s proof system. The EZ layer is minimal; trust decisions are pushed up to applications.

Details / Subtopics

Status as of ETHPrague

  • Working on the core smart contract (the “EZ contract” and standard interface). Targeted experimental release in coming months.
  • Mainnet experimental deployment planned — not production-ready, but mainnet to test bundling and real-world UX.
  • Devcon Berlin (late May / June 2026) workshops planned for spec discussion.
  • Several rollups expected to join initial test: Gnosis-chain-like fork; possibly Polygon zkEVM (Baylina background); base evaluated.

Adjacent projects

  • Synchronously composable L2s today, not tomorrow (David Leonardi) — same conference; a parallel attempt at the architecture using fast-finality + co-operative sequencing rather than ZK proof aggregation. Shorter time horizon, weaker security guarantees, simpler to deploy.
  • EthCC[9] coverage — Native interoperability via EIL (Yoav Weiss / EF) and the Open Intents Framework (Devconnect Argentina) tackle the asynchronous version of the same problem. EZ vs. EIL is the synchronous-vs-asynchronous fork in the road.

Relationship to The Ethereum Kernel framework

Martin Hansen’s Ethereum Kernel & Public Goods Funding talk argued that the Ethereum kernel ($18M/yr minimum to fund) should include the small set of L1-coordination infrastructure that EZ would sit alongside. If EZ becomes the canonical cross-rollup interop layer, its coordination work is kernel-adjacent.

Connection to programmable block construction

Will Papper (EthCC[9], Syndicate, “Why Programmable Block Construction Matters”) provides the complementary lens: customized execution on L2s requires the block builder level to be programmable, not just the smart-contract level. EZ’s composer role is one of the first concrete payoffs of this thesis.

Connections

Open Questions

  • Does EZ achieve genuine multi-proof-system support, or do network effects collapse the ecosystem onto a single proof system (likely ZisK or SP1) as the lowest-coordination-cost equilibrium?
  • Who actually runs the composer role? Baylina’s honest answer is “this is the hardest question.” Block-builder centralization on L1 (Titan ~50%) suggests the composer role will inherit the same dynamics.
  • Can EZ ship a sufficiently minimal smart contract that L2s adopt it without forking? Baylina’s stated goal is maximum flexibility; the social cost of any specific architectural constraint is high.
  • Is the EZ approach compatible with sub-second L2s like Arbitrum Nova or with sequencer-marketplace designs? The 12s lower bound on synchronous block time is a major constraint for use cases like prediction-market settlement or HFT-style DeFi.