Realizing the rollup centric roadmap with rollup-boost

Hello, hello, can you hear me? Sweet. Well, let's get started. I'm Dan. I also go by DMARS as there's quite a plethora of Dans in the space right now.

Yeah, got to rep for the Dans. If you're Dan, woo! Cool. Let's get into it. Yeah, so realizing the role of centric roadmap with the role of boost, I try to use alliteration with multiple R's multiple times throughout this presentation, see if you can spot it.

So this talk will have three sections. I'll talk about some reflections on the rollup-centric roadmap. We'll go through a layer two tech tree and sort of identify some key areas of the rollup technology stack that we can focus on for innovation, and then I'll talk about how Rollup Boost can unlock innovating in those areas. Sweet, so let's get into the first section. Yeah, so we're four years into the roll-up-centric roadmap.

If you were around at the time, there was a lot of discussion and development around something that was called Ethereum 2.0. And the idea was to try to like increase the transactions per second on Ethereum, now known as Ethereum Layer 1. And there was a very significant amount of work that went into it, sharding and all these things were being discussed. But then there was like a semi-controversial strategic shift to basically abandoning the idea of scaling just the layer one and focusing on scaling blockchains on top of the layer one known as layer twos.

Yeah, this approach let us meet global demand for blockchain applications and scale sustainably while trying to create an ecosystem where Ethereum can support a vast number of use cases without compromises. A lot of use cases wanted to do things that the underlying blockchain couldn't enable. And then another of the big benefits here is that by switching to layer twos, we can innovate on them instead of the layer one, which avoids the whole core dev process and the very long multiple dev net and test net testing process, which is justifiably slow on the layer one, but if we're experimenting and trying to innovate and move fast, it's a little too slow. So we're four years into this. How are we doing?

We roughly had three goals. Increase transactions per second of Ethereum, reduce transaction costs, and then also innovate on a more experimental layer. So according to L2Beat, we've scaled Ethereum layer one by 26x, which is kind of insane in four years. That's more than a 2x every year. Yeah, and so that's really great.

On top of that, in this journey, we learned, okay, maybe transactions per second aren't the main metric. So we also started looking at GPS. And so this is from rollup.wtf by Conduit. And you can see actually a slightly different TPS number than L2 beat.

But what's interesting is megagas per second is 55x of the layer one. And so you can see here Ethereum is doing around 1.25 megagas per second. And we even see base going up to 15. Proof of play by conduit is also 18.

So we're doing pretty good there. GPS is through the roof. The other thing we wanted to do was reduce transaction costs. And if you go to L2B, it kind of speaks for itself. It's 0.

2 cents to transact on Arbitrum 1 and not that far for the rest of them. So that's pretty good. I think we achieved our goal there of reducing transaction costs. But what about outsourcing innovation to the Layer 2 ecosystem? Now that is a much more complicated thing that there are no dashboards for.

So I think there's three ways of looking at it. You may not be able to see this down here, but I'll walk you through it. So we can look at it from innovations on the layer one, which are ported to layer twos. We can also look at it as innovations from layer twos, which are ported back to the layer one. And then the one you can't see down here is we could look at it as innovations ported between different layer twos.

So let's go through each of those. What innovations from L1 were ported to L2? Well basically everything. So a couple of the rollup stacks actually use the exact same blockchain clients with basically state minimized diffs on top of them so that they actually inherit all of the innovation that happens on the layer one. So when 1559 went live, I think Optimism had it in like a month or two after.

Blobs are also now in the Optimism code base as well. And there's some roll-up stacks that also operate slightly similarly. The more interesting question is, what innovations from layer 2 are ported to the layer 1? I would say almost none, which is kind of something to take a pause at. I think, you know, one of the big ideas here was we were bottlenecked on innovation on the L1, so we decided to stop focusing on it as much and gave all the credibility to these Layer 2 communities to bring the innovation to Ethereum and enable new capabilities.

And I would say most of the innovations that have happened on Layer 2s, we have not actually seen port to the Layer 1s. I will say the one exception is ZK has absolutely exploded and accelerated past our imagination, and so I think that will actually be something that does port back to the layer one. And then on top of that, what innovations from L2s are ported between L2s? And so if you're building on the same stack, like the optimism stack, then all the chains and optimism get to benefit from these innovations. But if you're on a different stack, which uses a different set of software and rules, then those innovations don't actually port to each other.

And so I have a graphic down here, which is, you know, chat GPT generated of a bunch of roll-ups that are these awesome, flourishing gardens, but they're walled off. They're not talking to each other. And so one of the things we want to do is bring back sort of like innovation between these different roll-ups. So yeah, this is a problem and something we need to debug. I think I came up with two quick reasons I'll go through, but there's probably way more.

One is peripheral tooling lock-in. A lot of roll-ups, they want to do different things. They want to experiment with new VM types, new transaction types, new mechanics. And it's kind of hard to do that when you want all your users to use the same wallet they use on all the other layers, and they can't because something is slightly different, and you need to go lobby MetaMask, and they already have 100 rollups and a queue that they are trying to serve. On top of that, SDKs as well.

If you're using some Rust-based SDK or Golang, it's typed very specifically to the chains it works with. And it's kind of hard to add that back in, to add those features in. But then on top of that, the core devs of that library now need to maintain the tooling for your chain, which is kind of like there's a little bit of incentive misalignment there. Indexers are another example as well. Everything you change now makes it much harder for EtherScan or Alchemy or any of your other service providers to integrate.

And then the last thing is maybe opinionated take of I think tokens and tribalism created an innovation death loop, and I'll get into that a bit. So I think the story is roughly, you know, there's an app that was very successful on the L1, or there was a team that decided to build some cool new application that they thought was worthy of a roll-up. They launch a token. All those tokens then are distributed to the community and the developers. And now we end up with like a tribe you know it's if you develop something on your roll-up stack then that is like something for your group not necessarily someone else's group otherwise you know your tribe is now not as good as another tribe or you're helping another tribe get ahead and you may not have like the incentives and so I think that's led to a lot of gatekeeping of innovation.

And you can kind of tell a tribe by the presence of like in-group versus out-group comments. So right now we actually see a lot of roll-ups kind of bickering on Twitter between each other about ways to do things when really we should be working towards a similar thing. But yeah, it's you know, I can sit here and whine all day about why all these teams aren't collaborating but I kind of want to get into four areas which I think can help and so that just leads me you know for the rest of this talk I will talk about these four key areas and I hope that next year someone in the audience watching this will present about how their journey to improving layer one or layer two to layer two innovation started with this talk. So I think it's really important to remember that the edge in Ethereum is innovation and there are many, many heroic opportunities to help move this forward. Cool.

So let's get into a layer two tech tree. So what is a tech tree? So in strategy games or in like some video games like Civilization, a tech tree. So what is a tech tree? So in strategy games or in like some video games like Civilization, a tech tree or a research tree is a hierarchical representation of the possible sequence or upgrades a player can make, usually to unlock something.

So there's like, you know, I think Civilization-based games where, you know, you can imagine like the Iron Age and you need to develop the capabilities to mine iron, you need to be able to melt iron, mold it, and then you need to do that at scale to successfully reach the Iron Age. So I set out a task with a bunch of people last week to try and map out what technologies we need to enter the golden age of Layer 2s. And also here's some examples of tech trees. This is my favorite one by the Foresight Institute where you can see one of the goals is like body replacement and in order to enable that you need like head transplant, brain tissue replacement, all these things. You can look that up on the Foresight Institute.

We needed a Layer 2 tech tree, so we built one. Yes, this is the tech tree we created last week at sequencing week at Edge City with the help of Ian from Polymer Labs, Lily from Astria, as well as Stanley from Luban. I'm going to go through every single leaf of this. No, just kidding. I'm just going to go over some high-level ones.

If you want to access this tech tree, you can scan this QR code or just go to tinyurl.com slash L2 dash tech dash tree. We may end up turning this into a website if it's useful. I'll get out of the way. Cool.

All right, I'll move on. Yeah, so this is layer two tech tree. There's roughly four subtrees. Funds are safe. This is probably the most important thing to enable for rollups.

We want to make sure that rollups are safe and live and also the operational risks are mitigated. And then we also have web 2 scalability, seamless interop, and plentiful compute environments. They're mostly self-explanatory, but the one that probably needs most explaining is Web2 scalability, where the idea is like we want to approximate the holy grail of everything on one computer, but we can't actually put everything on one computer. And so if you've ever used AWS or GCP, you know that all of your back end doesn't live on one server. And you also know that your back end communicates with other back ends that people have written and those don't all live in one server either.

Cool. So we're going to start with here with this bottom left portion of the tree under censorship resistance. And so censorship resistance is broken down into two things, inclusion guarantees and execution guarantees. One of the cool things about the optimism stack is that we already have forced L1 to L2 transactions. But there's still a lot to do.

And so a very hot topic on layer one has been multiple concurrent proposers, or I call it sequencers in this case. And the idea is to try to get sub L1 block time inclusion guarantees on the layer two. Then there's also a bunch of other things like an encrypted mempool, which you could do like TEEs, FHE, or witness encryption. And yeah, so there's a whole lot of things here, and there isn't really one group that's focused on it on layer two. So I think heroic opportunity number one is to just skip the politics, build multiple concurrent proposes on a layer two, write about it, put a tweet thread, discuss what went wrong with the implementation, what goes right.

There's also other examples. You might not be able to see this, but like Fossil is an ETH research post. And as well, encrypted mempools. There hasn't been a public standard for an encrypted mempool on layer twos. So the next part of the tech tree I'll get into is under safety, and it's this subtree called validity.

And so when rollups are posting to the Ethereum layer one, there is no way, unless there's basically an on-chain light client, for the chain to know that the state transition function is valid. So one of the techniques is to use proofs. ZK proofs are one of the most talked about things. But I think one thing we'll probably start realizing in the next few years is that rollups should probably never trust just one proving system. Some of these proving systems are like 80K lines of assembly code and good luck auditing that for bugs.

Especially when there's billions of dollars on the line. On top of this, there are multiple teams developing them, but none of them are talking about them. Or none of them are talking to each other. On top of that, we recently at Flashbots in collaboration with Automata dropped a design for TE validity proofs, and then there's also been significant research on fraud proofs and attestations. So I think heroic opportunity number two is align proof system development teams under one multi-prover interface and market structure.

They should all use the same interface for submitting and accepting requests for proofs. And then we should have like a standardized approach for how we're able to pay provers and what a prover market structure should look like, and I see no one in the market working on this. I think there's even a lot of opportunity for basically analyzing where MEV creeps into the prover supply chain. Cool. So the next part I'll go through is the Web2 scalability and seamless impropriability part of this tree.

So at the high level, as I mentioned, we want this to feel like an AWS or Cool, so the next part I'll go through is the Web2 scalability and seamless improperability part of this tree. So at the high level, as I mentioned, we want this to feel like an AWS or GCP server. You should be able to deploy something, hit a button to press auto scale, and you should just be paying the ETH chain to scale up or down based on the demand of your application, and we're not really anywhere close to that. So there's vertical web2 scalability, which is just make one machine super performant, and the Chad's and Chadette's at the Reth and Nethermind team are working on that. On top of that, horizontal scalability is something that's going to be a very new and hot topic.

Mark Tyneway from Optimism has been talking a lot about it recently. So in order to scale horizontally, we need seamless interoperability. And if you look at this, this is a mess. There are so many different things you can do to achieve interoperability. I'm going to just focus on this very high level of these ideas of out-of-cluster, in-cluster, and then UX standards.

Out-of-cluster is what you can think of as like your backend communicating with someone else's backend. You wrote a Twitter bot, it needs to pull the weather application. So those two talk to each other and they're not in the same set of servers. In cluster is defined by like a shared settlement layer on top of shared infrastructure. So you can think of this as having like maybe a shared sequencer or some other guarantees across the different roll-ups in that cluster so they can do things like native interoperability in the Optimism stack.

Yeah, so I think heroic opportunity number three is communicate to standardized communication. There are multiple standards being developed, but they are all in their own ecosystem. And I think one of the first out-of-cluster cross-chain standards was actually just written. And also, there was the first layer two cross-chain standards working group that was launched last week. But there's still so much to go.

Like none of these teams are really talking to each other. And so we need people force functioning, talking to these teams, figuring out what is common amongst all of their needs and developing standards for it. And that's something I think anyone can do. It doesn't really require you to be like a core dev. You just sort of need to talk to people at this point.

Cool. And then the last part of the tech tree is plentiful compute, and so there's two sections here, which I'll go through really quickly. We have virtual machines and compute models, and so we have EVM over here, but I think we need more, like Wasm, the Cosmos ecosystem has Wasm. There are some rollups that have Wasm, but they're under restrictive licenses and we can't use them on the layer one or any other layer two. So it sort of defeats the purpose of why we have been doing this innovation.

So I think there's a lot of room for developing open source versions of Wasm. On top of that, a RISC-V based VM, it's becoming increasingly clear that that is the most likely architecture we're gonna be doing, proving from, because it's, you know, there's not a ton of code there, so it's much easier to secure, and then we can build an EVM on top of that. And in fact, the Ethereum Foundation has started a moonshot project to create a formally verifiable RISC-V VM. And on top of that, I think there's a lot of room to experiment with open standards for FHE, ZK, or TE-based VMs. So yeah, heroic opportunity number four, experiment with new VMs on RETH and rollup-geth.

Those are both extremely open source and contributor-friendly repos that also are L1 clients. So the innovation is a full loop, which I think is the key here. Cool. So yeah, areas for improvement, experiment with inclusion and execution guarantees, build a multi-prover interface and market, help coordinate interop standards, and then open source and license blockchain code bases. If you're an allocator, you can help there the most, but please don't make the licenses restrictive.

Cool. And now I'll quickly just touch on Rollup Boost. So Rollup Boost is something you can't see this either, but we launched in collaboration with OP Labs and the Uniswap Labs to power the Unichain. And the idea is it's a very simple sidecar that sits in between the Optimism consensus client, the OP node, and the execution layer, OP Geth. And the really cool thing is that we don't need to fork the client at all.

And this lets us experiment. And so, for example, with Unichain, we're experimenting with 250 millisecond block times and T proofs to ensure the ordering, but there's way more that you can do on top of this. So yeah, I think Rollup Boost is the new innovation hub for Ethereum Layer 2s. Any chain that uses the engine API is able to benefit from any innovation on top of it. And I think that will create really cool positive feedback loops for the ecosystem.

I think even today, you could build a CR committee, you could build a multi-chain builder using this. You could even do a multi-prover interface and market structure. Cool. Yeah. So in conclusion, some of the innovation loops are broken in Ethereum.

There's four areas that we as a community can tackle that should not be owned by any single rollup, but that we are able to push forward. And then using Rollup Boost, you can basically start hacking on any of these four areas today. Cool. Thanks. Thanks.