Embedded Rollups: A New Paradigm for Cross-L2 State Sharing

Embedded Rollups: A New Paradigm for Cross-L2 State Sharing Lin Oshitani, Conor McMenamin (Nethermind Research)

Background: Rollups

Before Rollups L1 State 1. Submit tx Users 2. Update

L1 is great! You get synchronous composability. L1 State Smart Contract read SC Users SC read write SC

However, updating L1 state is expensive L1 State 1. Submit tx Users 2. Update

However, updating L1 state is expensive L1 State 1. Submit tx Users 2. Update

Rollups 3.Update L2 State Introduce a separate "L2" state. 2.Read txs tx data is posted to L1, but executed in L2! L1 State Inbox Contract Sequencers/Users 1.Submit txs

3.Update L2 State 2.Read txs L1 State Inbox Contract Sequencers/Users 1.Submit txs Rollups "derive" their state from L1.

Independent => Horizontal scaling! Rollup B Rollup A 3.Update 3.Update 2.Read txs 2.Read txs L1 Rollup A Inbox 1.Submit txs Sequencers/Users Rollup B Inbox 1.Submit txs

Rollup B Rollup A 3.Update SC SC Cannot read/write => Not shared state in L2 => Fragmentation! 2.Read txs 2.Read txs L1 Rollup A Inbox 1.Submit txs Sequencers/Users Rollup B Inbox 1.Submit txs 3.Update

You can have shared state in L1 Rollup B Rollup A 3.Update SC 2.Read txs SC 2.Read 2.Read 2.Read txs L1 Rollup A Inbox 1.Submit txs Sequencers/Users SC Rollup B Inbox 1.Submit txs 3.Update

But L1 is expensive to update! Rollup B Rollup A 3.Update SC 2.Read txs SC 2.Read 2.Read 2.Read txs L1 Rollup A Inbox 1.Submit txs Sequencers/Users SC Rollup B Inbox 1.Submit txs 3.Update

Recap - Rollups scale blockchains - Rollups can share state via L1, but it is expensive - How can we enable shared state cheaply?

Embedded Rollups

Embedded Rollups (ERs) - Embedded Rollups (ERs) are rollups that are embedded within and shared among other rollups - When embedding an ER, the rollup stores and updates a local view of the ER’s state alongside its own - If multiple rollups embed the same ER, they can share this read-only state without relying on L1 execution.

Rollup A ER 2.Read txs 2.Read txs L1 A Inbox ER Inbox 1.Submit txs Sequencers/Users 1.Submit txs

Rollup A Embed ER L1 A Inbox ER Inbox

A<ER> = A embeds ER Rollup A<ER> ER L1 A Inbox ER Inbox State of A<ER> "embeds" the state of ER. I.e., It maintains a "local view" of ER

Rollup A<ER>'s Execution 4.Update A<ER> state Rollup A<ER> ER 3.read A txs 1.read ER txs A Inbox ER Inbox L1 2.Update local view of ER

Contracts in A<ER> can directly read state of ER Rollup A<ER> ER SC read SC L1 A Inbox ER Inbox

4.Update B<ER> state Can do exact same thing for rollup B and get B<ER> Rollup B<ER> ER 1.read ER txs 3.read B txs L1 ER Inbox B Inbox

ER acts as read-only shared state between A and B Rollup A<ER> read SC ER read SC Rollup B<ER> SC read txs L1 A Inbox ER Inbox Local view of ER should be the same between A<ER> and B<ER> as ER execution is B Inbox deterministic & the inputs are the same

Use Case: Key Value Store (KVS)

Rollup A<KVS> read SC KVS ... ... key value ... ... read SC read L1 A Inbox KVS Inbox key, value Sequencers/Users Rollup B<KVS> B Inbox

Rollup A<KVS> read SC KVS ... ... key value ... ... read Rollup B<KVS> SC read E.g., ENS, Keystore L1 A Inbox KVS Inbox key, value Sequencers/Users B Inbox

Use Case: Shared Bridge (SB)

Shared Bridge (SB) - We can implement a shared bridge rollup to track token balances across rollups. - This rollup enables slow L2→L2 transfers without requiring costly L1 transactions. - Additionally, it supports fast and efficient solver-based transfers by concentrating solver liquidity within a single shared bridge layer. - Liquidity fragmentation of solvers is a huge pain point of any solver-based solution.

Deposits Rollup A<SB> Bridge 10 ETH SB read Rollup B<SB> ... ... A +10 ... ... User read L1 Shared Bridge (SB) 10 ETH User

Transfer Rollup A<SB> Rollup B<SB> SB ... ... Bridge Suppose UserA in Rollup A 10 ETH A<SB> wants to ... ... send 3 ETH to UserB in Rollup B<SB> 3 ETH UserB UserA L1 Shared Bridge (SB)

Transfer (Slow) Rollup A<SB> 1.send 3 ETH SB Bridge 4.update ... ... A -3 B +3 Rollup B<SB> 5.read Bridge 6.receive 3 ETH UserB UserA 3.read L1 2.settle A<SB> state root Shared Bridge (SB) Can transfer from A<SB> to B<SB> with mimimal L1 execution (no ETH transfer in L1)

Transfer (Fast) Rollup A<SB> 1.send 3 ETH SB Bridge solver A B -3 +3 Rollup B<SB> 3.read Bridge 4.receive 3 ETH 2.update UserB Solver UserA observe Solver enable fast transfer L1 Shared Bridge (SB)

Transfer (Fast) Rollup A<SB> 1.send 3 ETH SB Bridge solver A B -3 +3 Rollup B<SB> 3.read Bridge 4.receive 3 ETH 2.update Solver UserA observe L1 UserB Solver can also "condition" their solutions on this observation (omitted in this presentation) Shared Bridge (SB)

Transfer (Fast) Refund slover via slow path. Rollup A<SB> Rollup B<SB> SB solver Bridge A B +3 -3 Bridge 7.update Solver UserA 6.read L1 5.settle A<SB> state root Shared Bridge (SB) UserB

Transfer (Fast) Rollup A<SB> Rollup B<SB> SB solver Bridge 7.update A B +3 -3 Bridge Solver UserA 6.read L1 5.settle A<SB> state root Shared Bridge (SB) UserB All solver liquidity can be in the SB rollup => No fragmentation of solver liquidity

Conclusion - Embedded Rollups enable read-only shared state between rollups. - Read-only shared state can be used for shared KVS , shared bridge, etc. - Rollups derive their state from L1. Other interesting things may be possible by playing around with derivation.