Next Generation Based Rollups: A Practical Approach to Unifying Ethereum

Hello, DevCon. All right, so we're going to talk about next generation base rollups today. There are some base rollups that are next generation. There are some base rollups that are last generation. You guys just learned about some.

I'm going to tell you more about how you can become a next generation base rollup, kind of what the definition is, and then a little bit more about how I see the future of based rollups evolving. Cool, so this first section we're just going to go through some of the traditional based rollup research, talk about the the based rollups that have been, you know, explored in the past, some of the designs have been proposed, and then we're gonna understand some of their flaws, some of their weaknesses. So one of the very first designs that is used by Tycho today on mainnets is total anarchy based sequencing. This is like kind of letter of the law, exactly what Justin Drake proposed in last year, right? And it's very simple, very basic, right?

It's called total anarchy because it uses a election system that is permissionless and allows anyone, that's the anarchy bit, to propose a block. So one key point here is that the sequencer is not elected beforehand. You don't know who the sequencer will be beforehand. You might know the Ethereum proposer because you can look at the Ethereum look ahead, we know 32 in advance, but the sequencer of the base roll-up might not be the proposer. In Tyco's case, it is Tyco Labs for the majority of blocks.

One other thing to note is that layer 2 block proposing is completely permissionless, right? There's no permissions involved. The way that this ends up playing out in practice is that we have this is we have a bunch of proposers in Tycho's system that give their blocks to the builder, that would be Titan, Wintermute, et cetera. And they would take these blocks, order them in the layer one block, each block proposal is a layer one transaction, and then send this completed block to the proposer through a relay and through the MevBoost auction, right? And then eventually the proposer would propose this to Ethereum once they've selected the block with the highest bid.

So it's up to the proposer and the builder to choose which block created by these Layer 2 sequencers or proposers actually gets onto the chain. Now, one design that aims to solve a few of the problems of the previous design is vanilla-based sequencing. So Limechain, George Spasov put out this excellent bit of research that explained how we can actually solve a few of the foundational problems with total anarchy-based sequencing, the TECO model. So the first thing that we try with vanilla-based sequencing is a simple sequencer election, right? That gives us the ability to choose a sequencer based on some rule, have a primary rule, and then we have a fallback as well.

So the fallback in vanilla-based sequencing case is just total anarchy. So there's still some total anarchy here. And the primary sequencing is based on some election mechanism that is not clearly defined and kind of left to implementation in the initial research. So the other thing that vanilla-based sequencing includes is kind of very basic primitive support for delegation, which is allowing the Ethereum proposer to give the rights to their base drawout block to an external builder without directly going through MevBoost. It's like external to the MevBoost auction.

Vanilla-based sequencing also included basic support for pre-confirmations, which gives the, you know, we heard about it last talk, but it gives the proposer the ability to promise things about the block that they will eventually propose. It does require some sort of delegation or some increased hardware constraints on the proposer. And so the design for pre-confirmations has kind of wide-reaching implications for centralization vectors for stake and also for pre-confirmations in real time. Now, the other thing that vanilla-based sequencing introduced that really caught my eye was revenue generation from a percent of congestion fees. And you'll hear Justin Drake talk about this all the time.

You'll hear me talk about this. Base rollups can capture revenue from congestion trivially, right? These base fees, if you're doing EIP-1559 EVM, right, they are represented on-chain and are kind of understandable from within the EVM, within the state transition function. So you can view things about the fees, you can take these and you can do things with them, right? You can direct them to a treasury, you give some of them to the proposer, or you could return them back to users.

So kind of the problems with these that are actually really big problems, like Tyco on mainnet live is extremely inefficient. All forks of Tyco without major changes will continue to be extremely inefficient. One other problem with kind of total anarchy and vanilla-based sequencing is that there's kind of no built-in composability. Any composability is on a layer above the sequencing. And that's really unfortunate because whenever you have to build kind of another layer, you introduce complexity and centralization vectors of some sort.

In the case of base rollups, that's quite possibly around pre-confirmations, which means we could have centralized Ethereum stake, which we will want to avoid. The other thing is MEV revenue. So lots of people still have this misconception that base rollups leak MEV revenue, and that's true for traditional base rollups, because they do not use an auction of any sort to kind of get an Oracle into MEV. So if we look into layer one MEV research, we'll see things like execution tickets and execution auctions that are all designed to get some Oracle price essentially of the MEV in a block. Now the other thing to note about based relapse like I mentioned before is inefficiency.

So Tycho has a about a $10,000 a day cost to do their sequencing. Before Blobs, they had about $100,000 a day. This is a lot of money, clearly, and the kind of thing that you need a massive amount of users and network effects to actually be sustainable. And that's something we obviously want to avoid. But there is a solution.

For some of these Tyco forks, we've been looking at doing slower block time. So Tyco now has a block time of 33 seconds instead of 12 seconds, which is of course Ethereum block time. That is, you know, that doesn't allow their cost to come down by about a third, which is good for them. But it's also really bad for users. You get a worse user experience.

So the way we can patch over this is with pre-confirmations. Just throw some pre-confs on top. The downside of that is that without doing your pre-confirmation designs in a clever way, you're going to end up with limited benefits. So your users are going to get very limited availability of pre-confirmations and of course limited composability. So unless you're using a shared pre-confirmation protocol, you're not going to have composability.

So we start breaking a lot of things when we add pre-confirmations. The other thing that, you know, specifically Tycho's case, you lose composability with layer one because pre-confirmations happen, you know, over a course of an entire epoch, perhaps, and during that time, layer one state could change a ton. And so the kind of current layer one proposer is very different than who's actually sequencing the rollup. That's not shared sequencing. That's not based.

But we can do better. Traditional designs are not good enough. We have, over the past two years, we have new research. We have new teams. We have a lot more data about base rollups because we have one live, and we have a lot better technology.

So one of the big things that we'll be talking about in the next section is ZK, using snarks to save costs and improve efficiency. So let's kind of take a step back, let's think from first principles with all the data, with all the research, and with all the teams that we have now, what are the things that we really want to get out of base sequencing? The first thing is, in my mind, the most important, which is synchronous atomic composability. And this is a buzzword for sure. What I think that means is atomic cross-chain contract calls that are sufficient enough for Flash Loans.

And the reason for that is because flash loans are a foundational tool for doing atomic arbitrage between domains. So once you have cross-chain contract calls, you can do arbitrage. You can do flash loans for arbitrage. And this gives you the ability to essentially arbitrage prices on different domains, giving users kind of the best prices across chains. You can also use that for doing like a swap that uses multiple chains liquidity.

If I'm on Arbitrum, I could directly use Ethereum Layer 1 liquidity without waiting for a service provider or some collateral. Now, that's pretty straightforward. The other thing to look at is a seamless user experience and developer experience. So anyone who's ever tried making an asynchronous application will know that it's ten times easier, I'm not joking, to build a synchronous application. If it's asynchronous you have to deal with the case where something goes wrong and you have a desync.

Now the other thing is of course network effects, right? Once we have the efficient synchronous composability between chains, we have the ability to build network effects on one chain and use that on another. And because Ethereum already has massive network effects, that means base rollups can use that, those network effects, those liquidity users, protocols, et cetera, to directly improve the user and developer experience on their rollup. Now, the other thing that we want, of course, all the time is faster things and cheaper things. On the faster side, we're looking at good pre-confirmations that don't break things and that are fulfilled 100% of the time.

Frequent block proposing. The more we talk to Ethereum, the more we can compose with Ethereum. Custom frontends. So this is kind of changing the Uniswap style swap interface to something that actually represents what a pre-confirmation might look like. So that's a green check mark, some confetti of some sort.

It doesn't seem like a lot technically, but it's actually really important to improving the user experience materially. One thing is getting rid of the approvals and then swaps. You can get rid of that completely with pre-confirmations. Another thing is of course cheaper things, which is better execution. So just writing your smart contracts better and not making the mistakes that we've made in the past when we were rushing to get code out.

Aggregate everything. There's a slide on that, so I'll wait. And of course, efficiency of all shapes and sizes. Now, we want to do all of these things, and both of these things, I guess, without sacrificing decentralization and censorship resistance, liveness, and sustainability. So this is where you can get faster and cheaper.

If you go to all layer one, you can do it on a centralized sequence or layer two. What you can't do is faster and cheaper with decentralization, censorship resistance, liveness, and sustainability without some form of base sequencing is my opinion. So we know what we want, it's not that complicated, we want fast things, we want cheap things, and we want everything to feel like one chain for developers and for users. Getting there. Next generation base sequencing.

This is the subject of these three companies up here, this is kind of the industry that we're in, RISE, Spire Labs, and Tycho Gwyneth. And we're taking a very practical approach to unifying Ethereum. So we're trying to avoid the kind of discussions where we get into the ivory tower semantics and actually build tangible, useful products that are good for users and developers. So let's get into the specifics. This is an intermediate talk, so we're going to get a little bit technical here.

We're going to share literally everything. So when it comes to things we share, like if the answer is no, then you're probably lying. We have deposits, proposing blobs, proving network effects, assets, contract calls, off-chain infrastructure, security, economies of scale, et cetera, et cetera, et cetera. So shared deposits, that's AgLayer. These are teams that are working to reduce costs of posting ZK proofs to mainnet by aggregating ZK proofs.

Also has the excellent benefit that you can do interrupt between layer twos without ever touching layer one. So you save a lot of costs with that as well. Shared proposing saves a lot of costs and enables atomic composability, again, between base rollups if we can share blobs So if you're a base rollup and you're frequently checkpointing or posting to aetherium you're gonna be purchasing a blob for da in most cases and Well, they're pretty big and most base rollups do not use 100% of the blob space in a single blob. So there's a lot of empty space And there's a whole bunch of teams, Spire's kind of leading some of the research on this side, to figure out how we can have multiple rollups use the same blob. So we build some crypto economic system to make everything a little more efficient and a lot cheaper for base rollups.

We also look at things like shared proving to save costs, shared network effects. So we want the canonical ledger of last resort for every asset to be on layer one. We want fungibility between these. That's something we get with shared deposits, but it's a big priority in and of itself. Contract calls, of course.

We want to do contract calls. We want to batch those. We want to make sure that we have a good balance between the two. So we want to have a good balance between the two. that's something we get with shared deposits, but it's a big priority in and of itself.

Contract calls, of course, we want to do contract calls, we want to batch those, you know, that's pretty obvious, security, that makes sense, and then of course economies of scale in everything we do. So one of these kind of tools is pre-confirmations. We have a, over here in number one, we have a centralized sequencer that gives out pre-confirmations. This is what every layer two does today except for Tycho. And number two, we have some proposed models for based pre-confirmations where the layer one proposer, I mean, you know, the guy running on a Raspberry Pi with a dial-up, is the sequencer and they're the one directly giving out pre-confirmations and directly interacting with the people who are requesting pre-confirmations.

So obviously a pretty huge bandwidth and compute resources cost. And number three is the design being explored today, which is some form of delegation. That's that purple line to a gateway who actually gives out pre-confirmations to users. And then they create some builder constraints, some set of rules that builders must build blocks that comply to, right? So the gateway is acting somewhat like a relay in this case, but with a little bit more constraint around the builders.

So we still have an auction taking place, very similar to Metaboost. And of course the builder gives the block to our Ethereum proposer who goes and gives that out to layer one. Now the other thing that we want to do is MEV retention, censorship resistance being included here, and of course doing this all with pre-confs, which turns out to be a really difficult problem, but we have some excellent research from the Ethereum layer one about execution tickets. So we've kind of extended this to layer two on base relapse. We have these things that look very similar to execution tickets.

We distribute these in an auction, and then you must burn a ticket to propose a layer 2 block, although we do some of the burning and kind of registration early in the epoch and off-chain optimistically so that it's not an expensive thing to do on-chain. And of course with this, we can throw in some no delay forced inclusion. So every rollup today has a drift where you can deposit, make a deposit transaction on layer one, and then you might wait a few layer one blocks before that's included in layer two. In a base rollups case, you can pretty straightforwardly build no delay forced inclusion right into a base rollup, which gives you excellent central persistence equivalent to that of Ethereum. Now, one other important thing about next-generation based relops is checkpointing.

So whenever we, TychoCos is proposing by the way, but whenever we want to kind of put our sequence onto layer one we need to make a checkpoint here. And this is little red flag on my diagrams but what we're actually doing is making kind of a point of atomicity. A layer one EVM transaction is atomic. You can't revert part of it. And because of this, you can do cross-chain contract calls based on that atomicity.

You can also checkpoint together. That's this bottom left diagram where we share lots of checkpoints in one, which saves a ton of costs. The other thing we can do, of course, is other things while we checkpoint. bottom left diagram where we share lots of checkpoints in one which saves a ton of costs the other thing we can do of course is other things while we checkpoint so we can use layer one liquidity during our checkpoint make this available on layer twos we can also you know save the states of things on layer one we could change the state of a layer one contract to simulate layer one execution but actually doing the execution on layer two. Cool.

So one important kind of piece of technology, and probably the most important for the base roll-up teams to compete on and be the first to, is validity-proving and fast validity-proving and shared deposits. So there's a whole bunch of ZK teams working on this. Succinct and RISC-0 are two examples. And the goal is to take fast-float d-proofs for a whole bunch of layer twos, combine these, aggregate these into one fast-ZK proof, and then put this onto Ethereum in a shared deposits bridge contract that has funds for lots and lots of roll-ups. Now, this has security kind of concerns.

You have to trust your ZK, so we probably want multi-proving. And it's also, today, really slow. So the biggest competitive advantage of Bayes-Scalops in the future will be how fast is your proving. So this is the magic of Bayes sequencing that we've been working on at Spire to some extent, of course. And that is using a sensory resistance committee to sacrifice liveness for sensory resistance.

You can read more about this in our light paper. And then forward-based sequencing, which is using a sequence posted in a layer one slot to affect a future layer one sequence. This enables you to do based sequencing and traditional shared sequencing at the same time, which is obviously super powerful. So if anyone from Espresso is in the room take a look at this Cool. So after we've done all this, what do we get?

Harmony and more specifically deconstructing economies of scale to enable parallel innovation while maintaining network effects I've said this in all of my talks so far this week and it's so important, right? We don't want economies of scale to introduce centralization risks, and we want to promote parallel innovation as much as possible. The other thing, one of our important goals for the user and developer side is a monolithic experience, right? Nothing monolithic in practice. We want to have the ability for users and developers to feel like they're on one chain just to get that clearly better user experience.

And, of course, doing all this while establishing infinite expressivity, giving builders the direct ability to customize whatever they want about their roll-up, including execution environments, gas fees, et cetera. Infinite gardens, break walls. Next generation-based roll-ups actually solve problems. Stay based. Oh, here's a quote from Heraclitus Drake.

Stay based for one man's liquidity is another man's liquidity. Thank you. Okay, thank you a lot. So we have a few questions. So, first question, what can Tyco do to become a next generation based rollup?

Well, first of all, upgrade their bridge contract so it can share proposals and deposits and ZK proofs with other rollups and then add actually good pre-confirmations. Yeah, they have a lot to do. Yeah, same question. As someone new to the space, I find it hard to factor out the marketing. How does your approach compare to Espresso?

Sounds similar at least. That's a same question. As someone new to the space, I find it hard to factor out the marketing. How does your approach compare to Espresso? Sounds similar, at least.

That's a good question. So Espresso is building a shared sequencer, and they're building a form of what they call based Espresso, which is not actually based sequencing. They just call it that. It's a marketing thing. And the goal of Espresso is to unify layer twos.

The goal of next-generation base relapse is to unify Ethereum and layer twos, so we're involving Ethereum in the equation. But to get there, you can do shared sequencing. You can even involve the layer one sequencer, but that doesn't mean anything unless you do this checkpointing, unless you do this atomic synchronous composability. So base espresso will not allow you to do cross-chain contract calls. Okay, thank you.

the same thing. So, I think that's the main thing. I think that's the main thing. So, I think that's the main thing. So, I think that's the main thing.

Thank you. Do we have any other questions? We still have time. So, this is something that every base rollup must do, which is reorg with Ethereum. So, in the case of an Ethereum reorg, then your base rollup must always reorg.

It doesn't have to change anything, but it will reorg. And this is something that is very hard to fix in protocol. We need an Ethereum upgrade to reduce the risk of reorg or decrease time to finality. But there are a lot of other protocol things we can do. If you get lots of proposers opted in, in the look ahead, you can just ask them not to reorg, have them put up some collateral, and you'll be able to reduce the risk of reorgs.

You can also paste over it on the user experience side. You can have a solver or somebody take a duration risk. The user never has to experience a reorg. And then Spyro's also working on an RPC that's custom, kind of retrofit, to deal with common reorgs. One thing I would add is that base drops will reorg as much as Ethereum does now.

So I don't know how much you use Ethereum, but if you do a lot of DeFi or trading, you've still probably never experienced a reorg that has affected your life. So I wouldn't expect that it's a massive user experience problem. Yeah, we would have to reorg. Okay, thanks. And then, sorry, just another question.

I thought cross-chain contract one was very interesting, but I still can't imagine how it works across, let's say, a bunch of different chains that all operate at a different speed. So could you maybe provide some practical examples with a bit more details? Come talk to me afterwards, because that's a longer discussion. So all base rollups have a batching time of 12 seconds and a block time of theoretically less. This means that the composability you do between them can only happen at batching time because that's the only time we have atomicity and synchronicity.

We can compose every 12 seconds, we can do a cross-chain contract call every 12 seconds, and then within that boundary We can't do any composability that is enforced by cryptography. We can still do intents or other kinds of interop.