Accelerating Ethereum’s rollup roadmap
EthCC[8] · 30 Jun 2025 · 15:02
Marc Harvey-Hill presents Nethermind’s Surge rollup and its relationship to Ethereum’s roadmap. The presentation examines developments in based rollups, performance, security and decentralization.
Speakers
Topics
From EthCC[8], hosted by Ethereum France.
Transcript
Uh hello, my name is Mark and I work as a core developer on Ethereum at Nevermind. Um and today I'm going to be talking about Surge uh which is Nethermind's based rollup template um and how it's accelerating Ethereum's rollup road map. Um and a big thanks to David for the creating the original presentation this is based on and also to Lynn for his feedback. Um, so roll-ups are just fancy multi-IGs. They don't really inherit Ethereum security. Roll-ups are still slow. Um, so I think there's really some legitimacy in these claims. If we look at the state of Ethereum's roll-ups today, um, we don't really see these as um, criticisms, I guess, but more as like a challenge. So, how can we
actually create a rollup which is uh, neutral uh, which is trustless um, and extremely performant? And that's really what Serge is all about. Um, but before I get into Surge, I'm just going to give a quick background on kind of how rollups work today if you're not familiar. Um, so essentially the high level idea is there's a limit to how much we can scale the throughput of the L1. Um, while keeping it decentralized. Um so the idea of the whole rollup road map is that we're going to do a lot of this computation offchain and then we're going to po post a compressed proof to the L1 along with the transaction data.
Um and then that's all going to be verified on the layer one and also the data made available. Um and the way that most rollups work today is with a centralized sequencer. Um so essentially we just have one entity who's going to be responsible for collecting all of these users transactions. um putting them in order and then ultimately posting a batch of transactions to Ethereum L1. Um and this works but it has several problems, right? So we have just one single point of failure. Um so if this centralized sequencer goes down, it becomes very difficult to actually get your transaction on chain. Um and this is also a censorship vector. So we just have one entity who's able to just emit your transactions or just prevent
them getting on chain if they decide to. uh which concentrates power with this one entity um and relies on the reputation of this organization company whoever is running the sequencer. Um I mean one caveat to mention here is um you can have forced inclusion mechanisms. So this is a way where instead of going through the centralized sequencer you can just actually bypass that and post directly to the L1. Uh but there's several kind of negative parts to this. So it's going to take longer to go on chain. uh you're going to pay more potentially and be exposed to toxic ME.
Um so really the solution to this is based rollups. Um so with based roll-ups is the idea the idea is we're essentially just getting rid of the L1 proposer. Oh sorry not the L1 proposer. We're getting rid of the centralized sequencer and we're going to replace it with the Ethereum L1 proposer that we already have. Um, so instead of introducing new infrastructure like the centralized sequencer, we're just going to reuse the kind of existing Mev Boost pipeline uh that we already have on Ethereum. Um, and kind of to kind of walk through how this would work, like how your L2 transaction ends up on chain. Uh, you're going to send it to a separate mele, so to the L2 mempool, where these transactions are going to be
bundled by the L2 block builders. And these L2 block builders are the same entities as the L1 searches. Um, so then this essentially from here goes through the normal med boost pipeline. So the L1 searches send the bundles to the block builder who sends it to the proposer and then it ends up on chain. Um, and there's several advantages to this. So uh, we're going to inherit uh, Ethereum censorship resistance and and livveness guarantees and hopefully their security depending on a few other factors.
um we're not introducing any kind of additional infrastructure in this centralized sequencer and this results in just generally simplifying everything and making it a lot more cost-ffective um and just aligning everything with the base layer so we don't really introduce these outside incentives um and there's also kind of big uh improvements in terms of composability which I I'll speak about in a little bit um so with Surge what we're really trying to build is a neutral rollup and and what do I mean by that So I would define a neutral rollup as something a rollup that is uh permissionless trustless censorship resistant, open source. Um it's able to be operated and forked by anyone all while remaining performant and reliable.
And these are really what we're going for with Surge. Um so Surge is a a base rollup template. And by template I kind of mean this isn't just kind of another rollup we're deploying, but it's something that can be built on top of. So, it's kind of made to be redeployed, built on top of by other people. Um, it's stage two at launch, um, which I'll speak about in a bit, but this means it has very strong livveness, censorship resistance, security guarantees. Um, it's based as we've just been talking about. Um, it uses only native ETH, so there's no kind of external uh, token which is introduced and 100% of the base fee is burnt at the moment, although this is subject to change on mainet deployment. Um and it has extremely high
like gigas level performance. Um so how did we actually go about building surge? Um so surge is based on the Tao Althia stack which is the most uh mature battle tested base rollup stack at the moment. Uh but we've made several modifications. So we've replaced the finality gadget. Um so now we have a two of three multi-rover uh system which I'll speak about in a bit. We've replaced the bond token. So instead of any Taico tokens as I mentioned it's just pure ETH um changed the fee split.
So as I say at the moment 100% of the base fee is being burnt. Uh we've replaced the execution client. So it's no longer using rollup G but it's based on the Nethermine client. Um and we've also added a lot of um extensive documentation. As I say it's all about people being able to build on top of it. Um and stage two security. What does that mean? So, uh, if you're not familiar, we have this website L2B, uh, which is about classifying different L2s by their, uh, security and trustlessness guarantees. Um, so with Serge, we have a 45day exit window. So that means if there's some kind of upgrade and you you don't like it, you want to exit your funds, you have plenty of time, 45 days to actually exit your funds. Uh, there
are no emergency powers, uh, very limited governance. So unlike some of the roll-ups that exist exist today where they have some kind of uh emergency back door where they could kind of sneak through some last minute upgrade. Um essentially we don't have any of this here. So you don't actually have to trust us. You don't really have to trust anyone. Um it's all kind of smart contracts and and as I say you can exit your funds with plenty of time. Um and yeah so there's no tokens external tokens uh introduced. Um, and this just generally aligns the incentives a lot more with the base L1. Um, it doesn't kind of introduce outside incentives or kind of like uh specul uh speculation.
Um, and just generally removes any kind of uh the uh overhead of like governance, distributing this token, market making, all of this stuff. It's just makes it a lot simpler. Um, and we have giga gas level performance. So this means billions of gas throughput per per second. Uh which is possible thanks to the Nethermine client which has been demonstrated to have this kind of gig gas per second throughput. Um and this is possible all thanks to a lot of uh crazy technical optimizations uh by my colleagues uh working on the Nethermine client with me. Um so we have this two of three uh multi-prover security model.
Um so what this means is um the kind of uh state transition or the the proofs of the state transition are going to require um two out of these three different proof systems to all agree. So we're going to prove um in this TE based system uh using SP1 and risk zero and we have like a modified uh ref kind of state transition function running inside this. Uh but what all this means is uh we kind of avoid having one uh single point of failure in the prover. So you're not depending on one prover that could have a bug and kind of derail everything. And this is really important especially for stage two where it's kind of locked in and you can't change stuff.
So you kind of want to have this uh higher level of fault tolerance where you trust that at least two of three of these systems are going to agree and give the correct answer. Um so what can you do with Surge today? You can check out the website surge.wtf to kind of learn more. You can spin up your own kind of part of the test net if you want to try it out. You can check out our docs or contribute on the GitHub. Um or you can actually start playing around on the test net today. Uh you just need to uh get some hoodie from the faucet and bridge it over to surge.
Um and we have kind of several improvements or power-ups in in the pipeline. Uh the most important of these is pre-confirmation. So this is massively improving the kind of user experience of base rollups by giving pre-confirmations and we're aiming sort of on the latency of uh sort of less than two seconds. So you're not going to have to wait for the full uh 12 second slot to get a confirmation of your transaction. uh we're working on also improving the kind of security the proving ar uh architecture the block building um and also just improving this kind of uh composability which is a big uh benefit of base rollups um so yeah the the plan for what we're
doing next is you continue innovating as I say this is not kind of built as a as a base roll up in itself it's more about this template that people can take and build on top of uh we're improving the prover a finality gadget we're going to release on mainnet. Um, and yeah, we really just want the community to kind of take over this project from us. Um, and one example of this is Ethereum R1. Um, so this is a project which was announced not too long ago. Um, and this is a neutral rollup which is kind of built by the community. Um, and it's planning to be built on on top of the surge stack. Um, so this is funded 100% by donations. I think the plan at the moment is to raise a,000 ETH. Um, and this as well as all of the uh fees
raised are all going to just go to funding the development of of the of the chain itself. And then after 2030, it will be burned. And yeah, it's just community governed. There's no kind of external token or governance. Um, and this is really the the ethos of Surge. Um, I want to just speak briefly on some of kind of how this uh base pre-confirmation system is going to work. Um, so as I said, we're aiming for pre-confirmations on the order of less than two seconds of latency. Um, so the way this works is essentially a pre-confirmation is just a promise from from a future proposer that they're going to um include your transactions.
Uh so what we need for this is that proposers are all going to hold some kind of stake and if they uh don't honor the pre-confirmation they gave. So your transaction was pre-confed in the block then you can expect that someone is going to be slashed. Um and there's a few different ways this can be implemented. So the proposer themselves can issue pre-confirmations. If they're kind of a sophisticated actor, so they have a high kind of bandwidth, low latency connection and can kind of rapidly give out these pre-confirmations. or it could be uh delegated to a pre-confirmation gateway or delegated to the builder through uh MEB boost. Um and one requirement of this is EIP7917 which I think is planning to be included
in Fusaka. Um which allows you to kind of look ahead and see who a future proposer is. So you can see who's the next person I can get a a pre-MP from. Um and also I want to speak a bit about synchronous composability. So this is really I'd say maybe the biggest benefit of base rollups. Um so we get this um instant atomic composability between base rollups and with the L1. Um so by atomic I mean you can have one transaction which is going to like access or do stuff across all the state. Um and yeah it essentially allows for unified liquidity across all of these chains. So between the base rollups and the L1 and essentially making it all feel like one chain again. Um so kind of
to give a brief kind of uh idea of how this would work. So to send a message from the L1 to the L2 uh you would submit a kind of message to a contract on the L1 and then the L2 builder or L1 searcher is going to actually inject this message into the L2 within the same slot. Um and then it's also possible to go the other way. So have a message pass from the L2 back to the L1. Um so this will be kind of trivial in future when we have real-time proving so you can kind of immediately prove what is the current state of the L2. Um but it's actually possible today um through solvers. So solvers can condition their solutions on um actually so they're going to create a batch of transactions
and they condition that this batch is only going to be validly included if this um L2 to L1 withdrawal is going to happen. And this is kind of like a nice workaround that we can use until we have real uh real-time proving. And if you're interested in that, we have um a couple of posts from uh some research at Nethermind um which can give you a bit more information about that. Um and yeah, I have one more slide here which is about kind of another project which we're working on at Nevermind which is slightly separate but I think still related. Um so this is called way. So this is um a project we have which is all about kind of automating core protocol development which is very much kind of in the spirit of accelerating
the road map. The idea here is to have kind of these autonomous agents which are helping to coordinate between uh different Ethereum development channels like understand the EIP process and just generally be able to connect everything. So I think this is going to have kind of a big impact on accelerating both the L1 as well as the the rollup road map. So, I just wanted to kind of give that a quick mention. Uh, but yeah, so you can check everything out here and um, yeah, thank you very much for listening. Yeah. Any questions?
Okay, I guess not. Thank you.