# L2 Interoperability via Collaborative SNARKs by Ben Fisch | Devcon SEA

- Speakers: Ben Fisch
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 25:31
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-Et58V-0FYsE
- YouTube: https://www.youtube.com/watch?v=Et58V-0FYsE

## Description

Can contracts across rollups interact synchronously while maintaining horizontal scalability? The L2 interoperability problem can be viewed through the lens of collaborative SNARKs, where a coordinator splits a witness over N provers who collectively generate a proof, and the work each prover does should decrease linearly in N (horizonal scaling). This talk presents a solution for the special case of L2 interoperability and motivates new design constraints for SNARKs.

Speaker(s): Ben Fisch
Skill level: Intermediate
Track: Layer 2
Keywords: Fragmentation, Zk Rollups, Cryptography, interoperability

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] all right thanks for coming to my talk so this is a talk on L2 see so so L2 L2 composability from uh from CL snarks or in other words how do we synchronously compose uh but also retain horizontal scalability at the same time um so web 3 is all about composability at least in my view um it's about composable money Legos traditional web applications have you know been you know they're independently operated they need you need you need to trust an operator they communicate and interact asynchronously um and you know a lot of what we think about in ter of web 3 is the security or the decentralization but in my view the the thing that comes from decentralization is enabling everyone to trust a common uh distributed virtual machine that the entire world can use and what is the consequence of that what is the benefit of that well the benefit of that is that all applications can run um on the same system and they can compose with each other and that's like the meaningful difference to an end user or one of the meaningful differences to an end user and that's what enables um you know so much Innovation to thrive uh and as we call it ethereum's infinite Garden to to thrive um and so um you know the the it even enables new applications that just never existed in the world of uh of asynchronous systems before such as a flash loan um where you can you can have a lending application that is designed completely independently of these decentralized exchanges even two different decentralized exchanges and now suddenly you can have a user create a single transaction that interacts with all these applic ation to borrow money do some things with it and return it all in the same transaction um and obviously there's so much more that you can do besides flash loes but it this is what i' like to use as the example of what we can do with composability that we just couldn't do in the world before uh now of course rollups have been amazing for uh for scaling ethereum making it more performant uh they horizontally scale ethereum a multi-chain world was born out of this need to scale and uh what the advantages that it bring are one charting of computation across different applications um it also allows powerful nodes because the the internet is uh not homogeneous but heterogeneous and if you have you know millions of nodes participating in a system then uh there's going to be more powerful ones and weaker ones well rollups enable powerful nodes to help weaker nodes verify State and it'll also also allows for virtual machine diversity so there are many many many benefits um but uh the one of the things that came out of a multi-chain world on ethereum uh is that we no longer have composability of applications across these different chains so what is composability composability isn't something that is perfectly well- defined I take sort of a holistic view on composability it could refer to uh you know things like bridging of assets like moving eth from one chain to another um there are higher forms of composability that can be enabled by sending cross-chain messages and having depend encies between actions on different chains and um you can have even cross-chain function calls which are the way that applications interact within the same virtual machine and one application can actually call a function on another application um and one way to look at how to define the highest form of composability which I call synchronous composability is through the framework of um of acid transactions in traditional database systems so in a synchronously composable cluster of chains users should be able to express cross-chain transactions or intents such as their intent to atomically swap something or borrow funds from one chain do something another chain and return the money um that have this assd property which is uh atomicity all parts of the transaction complete or n do there's no in between State that's reached or observable um consistency so the roles of each chain are preserved isolation different cross-chain transactions or transactions to Independent chains they don't interfere with each other and so in particular what this means is that if you're in the middle of executing an atomic swap another transaction shouldn't be able to observe the fact that that Atomic swap hasn't completed yet uh so in traditional Atomic swaps do not have this isolation property because they involve locking an asset on one chain waiting a long time for something to happen on the other chain and then eventually resolving it um in fact Atomic swaps have this liveness risk where um if one of the chains loses liveness you can even break the atomicity um and of course durability which is uh basically just that there's consensus on a persistent Global transaction block so consistency and durability are just inherited from the fact that we're running on blockchains but the two key things are atomicity and isolation and those are not achieved uh by sort of asynchronous ways of composing different chains so the I what is the easiest way to asynchronously pass messages uh between chains well it's via the the layer one um so this is the rough idea you have a rollup a rollup um can have basically a mailbox I like describe it as an as an outbox and an inbox and it can write messages to its outbox that should be read by the other chain um and you can actually uh have you know the sequencer of the chain basically just fill the inbox of one chain by uh reading from the outbox of the other chain and providing a proof to its inbox uh that can be verified against the uh Merle rout of the outbox of the other chain uh of course there's different ways you can actually implement this this would just be one way of implementing it uh but this is you know essentially if you're familiar with like uh rip 7755 or other things that are being discussed like this is rough L you know the the the the most straightforward way of passing messages between rollups um without introducing additional assumptions on uh on offchain oracles or anything just using the L1 um now the the downside of this of course is that in order for rollup B to read a message from rollup a it needs to wait for rollup a to uh not only finalize its transactions uh by posting to ethereum and waiting for for ethereum finality which is about 12 to 15 minutes um but it needs to be able to trust that Merkel route uh and so that uh requires waiting the settlement time of rollup a which could be multiple days if rollup a is an optimistic rollup so this way of passing messages via the L1 takes a very long time and can take multiple days um so cross-chain transactions they have you know they have very high latency long wait before a chain chain can you know read a message from another chain um the other thing that asynchronous message passing view the L1 doesn't achieve is it doesn't achieve um it doesn't achieve this assd property for cross-chain transactions one sec so there's an there's another one way of passing messages potentially faster um and so this is a slight change what we're going to do here is we won't wait for verifying a message um against a Merkel rout but rather the sequencers will just be allowed to fill the inboxes um with messages from uh that are you know were allegedly written to the outboxes of the other chains and just sort of optimistically accept them uh process them and only at settlement time will we do anything to to check that the messages that were written to the outbox of the first chain are consistent with the messages that were written to the inbox of the second chain uh so this requires a a change in the way that rollup settle it requires this coordinated sement or aggregated settlement as some people call it uh and this could for example be just implemented as a cross check on the L1 between the uh barkel roots of the two different mailboxes um or we could involve some kind of aggregator that creates uh you know ZK proofs of the two different chains and actually proves the consistency of the mailboxes as well um now the advantage of this is that um the rollups don't have to wait for uh multiple days in order to ingest a message from the other chain of course if they're given an incorrect message uh then they will experience I mean when they go to settle it won't work so it's sort of like when you create an invalid block for a ZK rollup and then the proof can't be created and then you would have to you know go back uh to where you were before it's not technically a reorg but uh you know but if the full noes could become confused for some period of time um but optimistically you would just be able to make progress really fast right and you still have the security of the L1 um now you when you're passing uh messages this way um you're still not able to achieve um acid cross-chain transactions um because you know let's say you were trying to uh you know use this in order to achieve some kind of atomic swap um you would send a message to another chain that you locked an asset uh you would wait for a message back um you know verifying some event on the other chain um in that interim time you're in these locked intermediary States that's observable so you're you don't really have have this aciid property for this acid property to hold you need something called synchronous composability okay so why are ACI cross-chain transactions so hard to achieve well you need to be able to emulate multiple rounds of communication right you need to be able to do something send a message to another chain and wait for a response back and that all needs to happen within one block that can't happen across uh multiple blocks um there's also an inherent dependency on the global ordering of transactions across all chains of the individual transactions on those chains the if you're sending multiple rounds of communication then uh you know the the relative ordering of these different transactions on the different chains will have an impact on what happens um now of course there's a naive solution which is just to merge all chains into one and that would certainly achieve this acid uh property right that that's a naive straw man but the reason why this is hard to do in this m in this uh you know is because of the very much because of the constraint that we want to retain efficiency we want to preserve horizontal scaling so on its own acid is not hard to achieve it's hard to achieve it in a way that preserves scalability um and so one way to uh sort of make this a bit more precise is to view this through the lens of uh collaborative snarks um snarks for those of you who aren't familiar with the term are just the technical term for ZK proofs uh I ZK proofs the one at least the ones that we use in the blockchain world are succinct non-interactive proofs of of knowledge um we rabs don't even use the zero knowledge property so it's just sort of a misnomer that we ended up calling them ZK proofs but snarks are the same things as ZK proofs um so there's this implicit when whenever you have chains interacting there's this implicit unified virtual machine in which the cross cross chain transactions it's a tongue twister take place um and so the goal is uh really to create some kind of single ZK proof of a state transition for a distributed system of virtual machines with with this inner process communication where we introduce one PR per virtual machine and the total work done for PR should remain near constant as the number of interacting virtual machines grows so that's sort of the goal of being able to preserve the scalability the fact that the total work done per prover per chain remains near constant it doesn't grow um you know as linearly as the number of chains growth and U in other words the total amount of work being done in the system is linear and the number of Prov is not quadratic so we actually can apply generic solutions to this uh we could we could there are generic ways of uh just having all the provs for the different chains collaborate on on creating a distributed snark for the unified VM that uh you know is their composition uh you can use snark recursion for this there's other ways of doing it through distributed snark protocols like something called distributed Su Che distributed ffts um so uh you know it's not typically the way that we think about it uh we think about provs being sort of their job is to be just create proofs for their own rollup but maybe the goal should actually just be that the overall work should you know be horizontally scalable um but I'm going to present today sort of uh what you can be viewed as like a special case of this but it's a lot closer to the model in which rollups inter um you know interoperate and and and act today and it can it's just a simple extension of the asynchronous message uh mailbox design that I presented at the beginning um so we still have the outbox and inboxes on the two different chains um but the key difference here is that instead of chains writing to their outbox and then in the next block being able to read a bunch of messages that were populated to their inbox a sensibly that should match the messages written to the outbox of the other chain in the previous block that's how we did it before there's going to be a coordinator that can just figure out okay these are the messages that this other chain is writing to its outbox right by simulating the execution and I'm going to provide you with those messages and so these two blocks are constructed at the very same time chains are really just verifying execution they're not they don't need to carry out the execution themselves the execution is carried out by uh Builders who are building the blocks or in this case a coordinator this coordinator simulates the execution uh so I can walk through an example you can have a transaction on rollup a that basically borrows funds from some contract um it burns him it writes a message to his outbox that they were burned and then immediately reads a message from its Ino box that something happened on the other side I mean a lot of things happened in that in the middle over there but they just weren't observable to this chain so immediately read that messages were then minted on the other side in the in the meantime what happened was on rollup B there was a message that was provided in the inbox it said oh funds were burned on rup Bay it then did a bunch of things maybe multiple swaps at desired prices made some profit and then burned the funds wrote that message to his outbox that message was provided by the coordinator to the box of R aay causing uh this transaction to complete the funds were return now if there was any inconsistency if some message was written to the outbox B but that wasn't put uh in the inbox a then that would be caught uh that would be caught at settlement time right as we showed that when the rollups settle all we need to do is make sure that the outboxes of the two of of chain a matches the inbox of chain B and and vice versa the outbox of chain B matches is the inbox of chain a um so that provides you the intuition we have a full protocol on this called coordinated inter rollup communication it's not fully General but it covers most practical use cases of synchronous composability among independent chains like flash loans uh which I just showed the example of asset swaps limit orders basically anything that we can really think of it would be interesting to see if people come up with use cases that are practical that aren't covered it doesn't require any VM modifications to the chains you just need to implement these contracts as uh these mailboxes as contracts and it enables parallel proving so each L2 prover just independently proves its own state it proves um what the Merkel root of its mailbox is and then there's an aggregator that creates a simple aggregated proof uh whose complexity is completely independent of the complexity of each chain um these mailboxes are implemented as contracts um they use authenticated key value maps and and uh you know any contract can basically write to the appbox or read from the inbox um but it will you can in you index it by which contract wrote so it doesn't allow contracts to sort of conflict with each other and override each other and then you have the settlement layer contract that basically just verifies the correctness of State updates from each rollup and checks uh the mailbox consistency by verifying this aggregated proof um so this is what it looks like right we have this aggregator just like before is exactly like the asynchronous setting it's just that we have a coordinator which could be for example a shared sequencer that figures out what messages are being communicated between the two chains could be multiple rounds of messages and provides those messages ahead of time prepopulates the inboxes of the two different chains with the messages that they should be receiving over multiple rounds of communication now one important variant of uh rollups is that full know should always know the state right once a sequencer posts the transaction ordering fulln notes uh should be able to immediately calculate the rollup State they shouldn't have to wait for L1 settlement uh waiting for L1 finality of the sequence or published blocks is generally sufficient um and in if the sequencer is trusted not to change its mind about what it's going to post then fulln should be able to trust a pre-confirmation from the sequencer within seconds now the problem is that uh you know this protocol Circ sort of breaks that property unless uh you know if done naively and the issue is that because the rollups are now interacting the full nodes of rollup a who are ostensibly only executing for rollup a they don't really know the state of rollup a until they can trust that the messages the coordinator uh provided are correct and it won't really know that until settlement time uh so how do we yeah how do we solve that issue that's problem number one and problem number two is that um you know normally you can trust a sequencer for fast confirmations here this coordinator which is going to be coordinating the mailbox constructions across many many different chains becomes a single point of failure uh and so you know maybe the full nodes of arbitrum can trust the arbitrum centralized sequencer um and the optimism full notes can trust the the optimism sequencer but it's hard to trust one sequencer for confirm confirmations when multiple chains are interacting um the solution is to fold one make ZK Prov faster that can be communicated um offline really fast and two used a fast confirmation layer uh so a fast confirmation layer is basically a bft consensus protocol that reaches faster finality faster than the L1 and ensures that whatever uh the rollup whatever was finalized by the consensus protocol you know has to be what's eventually posted to the L1 fast offchain ZK proofs are interesting because the goal here is to optimize the endend latency of proving uh uh you know and proving proof aggregation verification given the constraints on the bandwidth and compute power of each full node um and so it motivates different design constraints than when we're just trying to have ZK proofs optimized for L1 settlement uh because the bandwidth and compute requirements of L2 nodes could be different um and so we could consider using snarks with larger communication but faster proofs like Orion breakdown bfold Blaze or uh a number of other systems um so anyways this is you know what it looks like putting it all together you have some shared sequencer that coordinates the mailbox construction the blocks are sent to a confirmation layer they're confirmed rollup a and rollup B provs and create these proofs and then you have some kind of aggregated settlement and this is how you enable chains to uh either have very fast asynchronous communication or even synchronous communication that enables synchronous composability so thank you very much and I will take go on to the questions good stuff Ben uh very technical I think we got time for a few questions uh so the first one that's on there is uh the coordinator of two rollups needs to be sync to both of them right in other words he needs to be executing both rollups himself that's correct okay well that was an easy one easy uh um and what happens if the message box say fork before settlement wouldn't the nodes be reading just one roll it be lost until settlement what where which one is this oh now it's number two okay what happens if the boxes fork okay wants to be the shared for um I I think I'm seeing different questions than you are which one the second one what happens with the message boxes oh what happens with message box is Fork before settlement um so you you the the message boxes don't Fork before settlement uh I mean so you the chains need to have something that is used for their uh you know as their sort of finality layer um you can of course wait for L1 finality on the blocks that were published so you publish the blocks to the L1 that's presettlement time um or if you have a fast confirmation layer um such as the one that espresso Network provides right then uh you would be posting those you would be publishing those blocks to that fast confirmation layer and uh and then you know you would ensure that whatever is posted at settlement time um is consistent with that um ultimately you know you can Define the rules of or constraints of uh what constraints uh rollups before before settlement time but at settlement time you would be posting a collection of blocks for the different rollups that are consistent with each other in terms of you know these mailbox consistency checks and consistent with the rules of those rollups for what was you know finalized on different various layers before that settlement time okay the next question it voted up while it was up there a little spicy yeah espresso wants to be the shared layer for rollups but lacks credible neutrality how Keen is espresso on jointly designing the shared layer with rollups uh so yeah so espresso is um is has been designing this you know uh sort of confirmation layer as we call it um which it doesn't do everything that I described today it it provides this fast confirmation layer that rollups can use today the espresso network uh in fact is live on mainnet um and we have been you know um building towards creating infrastructure that rollups can use to enhance their composability and uh we've been doing it very much in collaboration and taking feedback from you know from rollups uh just like layers Etc okay the next one um something that I've seen uh when I was briefly working with rollups on the devop side is that how can cross-chain message passing happen if rollups have different latencies and hardly can be viewed as synchronized especially with amm protocols being strictly Arbitrage and asynchronous it's like some that post once a day and some that post once an hour right so how can cross chain message passing happen uh if rollups have different latencies and hardly can be view to synchronize especially so if rollups so first of all I presented two different kind of modes of communication so there's asynchronous communication and synchronous communication um if the if the uh if if the rollups is not about it's not actually it's not the latencies that matters it's the block times of the rollups so the block times are different then you can still communicate asynchronously if the um if the if if the block times are not sync then you can't communicate synchronously so you would have to uh synchronize the block times but you can also have different Siz blocks on the different rollups so if one