Synchronously composable L2s today, not tomorrow

Transcript

Testing. Hello. GM ECC. I am David Leonardi, also known as Duct Tape Gen, and I'm with Nethermind. Today, I'll be talking about Surge, our real-time proven L2 framework, uh and specifically about how we have synchronously composable L2s today and not tomorrow. So, what I want to do is walk through why this matters, what is still broken in the current model, and how we're approaching solving it. Just over a week ago, the Ethereum Foundation published a post that laid out very clearly what they think the L1 to L2 relationship needs to go. And what was useful about it is that it moved the conversation away from scale in the abstracts and towards a more aligned Ethereum ecosystem uh should actually look like.

Three ideas they called out were stage two, so that user funds are secure, synchronous composability, so that the user doesn't feel pain every time they want to switch from L1 to L2, and native native roll-up readiness, so they can remove governance and become part of the Ethereum L1. What stood out to us is that this is not some vague long-term aspiration. It's a very concrete architectural direction, and so we built it. Uh but let me tell you first about the current situation with roll-ups. So, what's broken today? At a very basic level, L2s are still islands. And what this means, the moment you cross the L1 to L2 boundary, Ethereum stops feeling like one coherent system and starts feeling like a set of environments connected by additional infrastructure. The first

problem is time. If you want trustless movement, you have to wait. In optimistic systems, that can mean days. In traditional ZK systems, it is better, but you still have delayed proving and delayed finality, which means that you're still waiting minutes or hours. The second problem is counterparty risk. Because users and protocols do not want to wait, the market fills that gap with bridges, relayers, liquid graded networks, fast withdrawal systems, and so on. These can be useful, but they introduce new trust assumptions, new operational overheads, and new failure modes. And the third problem is broken composability. You cannot really treat L1 and L2 as one atomic execution environment. So, liquidity ends up fragmented, and cross-domain interactions become awkward, and a lot

of product designs end up compensating for that boundary instead of benefiting from it. So, the real issue is not just latency. The real issue is that the boundary breaks atomicity, and once atomicity breaks, the ecosystem starts layering trust, cost, and complexity on top to make the experience a bit better. If you compare the main roll-up models, I think the story is actually quite straightforward. Optimistic roll-ups were a pragmatic response to world where proving was still too expensive and too immature. At that point, it made sense to assume correctness first and allow disputes later. But that was a reasonable That was a reasonable trade-off then.

But it was never really the end state. Then, traditional ZK roll-ups improved the trust model significantly, but in most cases, the sequencing is still delayed. You sequence, you post, and then you prove later. And although the system is stronger cryptographically, the proof still arrives after the fact. And because that proving step is delayed, the composability remains broken. So, what Surge does differently is it collapses the sequencing steps into one uh into one step. And this is the architectural shift. Um on the left is the status quo uh where the sequencer builds the blocks, posts the data to L1, and then the system waits, right? Uh later, the prover picks up that block, generates the proof, and posts the proof to the L1 roll-up contract. So, there are multiple

waiting points in the pipeline. And on the right is the Surge flow. Uh the sequencer builds the block and immediately requests the proof of the state transition. And once the proof is available, the block and the proof are submitted on the L1 together as a single transaction. That changes the properties of the system in a meaningful way. First, it's trustless because the block is ZK proven right before it lands on the L1. Second, it's atomic because the execution path is all or nothing. And third, it's fast because we have compressed what used to be a delayed multi-step settlement flow into a single event.

And that's not just nicer design technically, it also matters operationally and commercially because it reduces reliance on extra infrastructure that exists mainly to compensate for delay. Of course, this only works if proving is generally fast enough. And that is where this becomes both a hardware and a software problem. If either side is not good enough, the whole model just falls apart. So, we tried this with eight Nvidia 5090s, and we got 11 seconds average proving time per block, which is lower than the L1 block time. >> [snorts] >> As a practical note, just to set expectations correctly, our current production system just runs eight Nvidia L40s, so it's a bit slower. But the important part is uh the important point is not to benchmark for its own sake. The important point is that the architecture

now crosses a threshold where real-time proving now supports synchronous settlement. We describe this as the native roll-up vision running today. You have stage two running as uh running the security direction. You have synchronous composability as the execution property, and you have native roll-up readiness as the architectural path. Now, to be precise, the broader blocker for stage two across the ecosystem is still prover maturity. So, audits and formal verification and confidence in the full proving stack is still like a critical path and still matters a lot.

So, this is not the claim that everything and every issue has been solved and disappeared. What it is is a claim that the architecture itself is now concrete. Um as the EF mentioned, L2s need to be composable with their ones. And this is what we brought today. Our implementation is native roll-up ready, and whenever native roll-ups launch in L1s, we'll directly integrate into the native roll-up precompile. But enough words, let's check it out. On the screen, we've got a pretty much basic-looking swap UI, so XDI to USDC and other way around. But what is actually going on is using liquidity that sits on a Surge roll-up on Gnosis.

So, when I hit swap, and >> [clears throat] >> sign a smart contract wallet app, the the op gets sent to the sequencer, Catalyst, and then Catalyst picks that up and builds a transaction bundle, which includes the user op execution, the L2 block, and that contains the swap and the L1 settlement of the token outputs. And the sequencer talks to the prover and generates the proof for that state transaction and transition in real time. And in the last step, and this is by the way like an actual video of the thing. And in the last step, the sequencer posts the bundle of the proofs in chain together.

So, if you're looking at Gnosis Scan, >> [clears throat] >> Yes. If you're looking at Gnosis Scan, there No. Oops. Damn it. Um if you look at Gnosis Scan, fundamentally, what you see is that we send funds to the L1 uh and the execution is we retrieve funds from the L1 from Gnosis, send them to the Surge L2, and execute the DEX swap there, and then send the funds back uh to uh to the Gnosis L1, right? So, it's it's fully done. It's a on the L2, which then returns the funds atomically.

And >> [clears throat] >> so, the nice part is that from the outside, this feels like a simple swap, but under the hood, you are seeing this the full Surge flow in action. So, what does this actually unlock? For application devs, it opens the door to experiments that are difficult or impractical in the usual model. So, shared L1 and into L2 liquidity, or cross-chain smart contracts uh without relying on trusted bridges or external coordinators, or user experiences where the L1 to L2 boundary becomes much less visible. For chains and roll-up operators, this is more of an infrastructure story.

You can deploy your own synchronous composable roll-up using the Surge framework, and it is fully open source and built in Nethermind's production-tested execution client. But let's keep it grounded a bit. Like, not every feature use case have been fully solved. The important point is that the Ethereum roadmap is being buildable in a way that can compound. Application teams can start designing for it, operators can start deploying for it, and the ecosystem can start treating synchronous composability as an emerging primitive rather than a distant abstract goal. So, if I had to compress this whole thing into four properties, it would be these. It's fast, it's atomic, it's trustless, and it's native roll-up ready.

Fast because we're talking about seconds. Atomic because the full execution path is all or nothing. Trustless because the block is proven before it reaches the L1. There's no optimistic assumptions, no challenge periods, no additional trust layer inserted over the path over delay. And native roll-up ready because this is the direction Ethereum is very clearly moving towards. The broader reason is to care that this is not just about one framework. It is about making Ethereum less fragmented, less dependent on workaround infrastructure, and easier to build serious products on top of.

If we want the ecosystem to accelerate, it needs to more examples of things that are not just directionally right, but mechanically correct and actually running. This is what we've been trying to contribute here. Um as part of this effort at Nethermind, uh sorry, as part of this as part of this effort, Nethermind is joining the Ethereum Economic Zone as a launch partner in making this feature happen. Um you can check out the docs, uh and if you want to experiment with the DEX, you can find it here uh on uh DEX real-time surge. What the Uh and if you have any questions, you can come and reach out to me or the Nethermind booth.

Um and yeah. Um so, >> [clears throat] >> if this is relevant to what you're building, come talk to us. Check out surge.wtf. Try the alpha. Come and find us, especially if you're working on roll-up infrastructure, DeFi, cross-chain applications, settlements, institutional products. I would be very happy to talk. Uh because I think this is one of those areas where the gap between roadmap and implementation is starting to close, and that tends to create a lot of opportunity very quickly. So, thank you very much. Uh I'll gladly and take any questions uh here or at the booth. We're just around the corner.

Thank you very much. >> [applause] >> First, fantastic. But, one question is how much does it cost to settle on L1? Because in this case, each of your proofs has to pay the cost of, I guess, not verification plus potentially the the blob cost, right? If you're sending call data. So, what what about the costs? I don't have an exact figure for you, but they're pretty low right now. So, it's it's actually cheap and definitely achievable because of gas prices on L1.

So, that is now like the shift. Before gas prices were probably expensive and now that Ethereum L1 is like much cheaper, you can actually do this in a very cost-effective way. I think L1 transfer will be even cheaper, right? Yeah. Anyone have a question? Hi. Um if you if you have multiple positions on different layer twos that are all connected, and let's say there's a liquidation on liquidation event across all of them at once, what do you need to what needs to happen at the block building level for that to be processed through layer one back up to the

uh you know, back up back up to the native roll up. Is there any differences there? So, the liquidation is an L2, you mean? In multiple layer twos at once, like how It doesn't matter because the transaction is atomic, right? So, if there's no liquidity because like the position is no longer there, it just can't execute. And this is the beauty of it that there's no delay, there's no like bridging or relaying or messaging in between. It just it just takes the state of the L1 and then uses the state on the L2 and branches out to the all the other networks that are like part of this quote-unquote liquidity pool of different networks from which you can source from. And if it's there, it's there. And it's literally at smart contract level. So, that is like the backstop. And this is pretty much the

say final destination where we want ultimate security originating from the protocol itself. Cool. Um so, looks like this solved the L1 to L1 to L2 liquidation fragmentation problem. And is there any plan to solve between L2s? Um which specific problem? Like L2 L2 like liquidation liquidity fragmentation. >> All right. So, I mean, I guess the idea is that if something is part of the Ethereum economic zone, then everything is a native roll up from a mentality, which is composable synchronously, right? So, um

you can literally send out and fan out requests to different networks. And they >> a kind of super cluster or something. >> acts as one big cluster of let's say be it positions, be it liquidity, be it be it DEX pools, be it whatever. And you can just compose on top of that however you wish. And it just works out of the box. More question? No. So, as I said, you can check it out at search.wtf. That's our official website.

And we have this DEX demo, which is currently an experiment. I want to emphasize this. We've limited on the UI available amount that you can put into it to a dollar because, yeah, this is an experiment we're running. Um so, come and try it out. And yeah, looking forward to building together with all of you. Thank you. >> [applause] [music] >> Thanks.