Realizing the Rollup Centric Roadmap with Rollup-Boost by Daniel Marzec | Devcon SEA

[music] Hello, hello. Awesome. Wow, cool to see so many people turn out to discuss the roll-up centric roadmap. Um, it's a pretty full house. So, I'm going to have to ask everyone to really just squish in.

I think there's a lot of people standing in the back. Um, for anyone watching the live stream. Um, cool. Well, let's get into it. Uh, I'm Dan, also uh, D Mars online.

Um, and I'll be talking about how we can turbocharge the uh, roll-up centric roadmap with roll-up boost. I'll be using a lot of uh, triple R alliteration. If you see any of those, uh, talk to me afterwards and uh, I'll I'll give you a special prize. Cool. Uh, so this will be structured in three parts.

I'll go over a little reflection on the roll-up centric roadmap. I'll then talk about what a uh, a layer two technology tree looks like. And then I'll discuss how we can use roll-up boost to um, accelerate innovation on the layer two technology tree. Cool. So, let's get into the first section.

So, yeah, we're four years into the roll-up centric roadmap. If you're unfamiliar with what that is, the roll-up centric roadmap was Ethereum's strategic shift towards scaling the network by embracing roll-ups as a primary solution. Uh, you know, if if you're unfamiliar with roll-ups as well, they are a way which we can process transactions off-chain and submit compressed proofs to Ethereum mainnet, which allows us to increase throughput of these off-chain components without necessarily sacrificing the decentralization of the underlying layer. Um, in this vision, Ethereum becomes a more like robust and uh, secure settlement layer while most activity happens on these layer two roll-ups. And we've already seen that a lot of activity has shifted to a lot of layer two rollups.

Um yeah, and there's a lot of benefits to this and we'll we'll be going into a lot of details, but one of the biggest benefits in my opinion is that we can innovate on a separate layer than the layer one, which doesn't need to go through the entire core dev process or have, you know, tons and tons of like research and formal analysis before we ever actually start to like create a proof of concept or ship something. Um because a lot of the times when you are trying to build innovative features, you typically don't discover uh or there's a lot of unknowns unknowns you don't discover until you start building. And we've seen that uh many such cases of that uh with MEV on Ethereum. Um yeah, cool. So, let's go into it.

So, we're 4 years in. How are we doing? Um well, we had roughly three goals. One, increase the transaction per second of Ethereum. Two, reduce transaction costs.

And three, outsource innovation to the layer two ecosystem. So, let's go through each of those. First, how are we doing on TPS? Well, if you look at L2Beat, uh we have scaled Ethereum 26x uh in transactions per second, which is no small feat. That's more than double per year since we've announced the rollup-centric roadmap.

So, that's pretty awesome. We can check that off. Um oh, and on the way to scaling transactions per second, we also discovered maybe that's not the best metric uh as there's a lot of uh activity on chains which aren't just uh which can't just be basically categorized via a transaction. So, a lot of chains simply just have an a transfer, and that's like very simple. It only touches the part of the chain associated with your balance and someone else's balance.

But when you look at more complex activity, uh it could be touching hundreds or thousands of accounts doing very complicated computation. And so, we also started to look at GPS as a metric, which is gas per second. And uh this is a bit small, but if you can see on uh conduits uh roll up.wtf, we have increased the gas per second by almost 55x compared to the Ethereum layer one. So, uh even more great progress.

Cool. So, we've checked that off. What about transaction costs? They should be lower um just because we're also scaling. And yeah, this slide basically speaks for itself.

Most of the top roll ups are less than uh you know, a cent sometimes to transact on. Cool. And so, the last one, which is much more complicated and will be the segway into the rest of this talk, is how are we doing on outsourcing of innovations the layer two ecosystem. And I think this is really important because with the roll up centric road map, we essentially said, "Hey, you know, everyone focusing on layer one, um you know, you you keep doing that, but we are going to push the boundaries and the the next version of Ethereum will be built on layer twos. And so, it's really important that that actually succeeds.

And we as a community lended all of our credibility um to these layer twos. And so, you know, we should be checking in on how they are doing." So, it's a little bit complicated to look at how innovation is transferring between these layers, but there's roughly three um ways we can look at it. It's innovations ported from the layer one to the layer two, innovations from the layer two back to the layer one, and then innovation between the layer twos. And so, we'll go through each of them.

So, yeah, what what's been ported from layer one to layer two? Well, basically everything. Um most of the popular blockchain clients, layer two blockchain clients, with the exception of some, actually use a minimized uh a a version of the Ethereum one blockchain clients that has like a very uh minimum diff to it. And so this means anytime there's an upgrade to the layer one client, the layer twos can easily pull it in. And you can see this with with chains like optimism where after EIP-1559 went live, they had it very soon after.

And and all other upgrades. But this is not true for all chains. Um Yeah, layer two to layer one. Uh basically nothing. If you know of any improvements to the layer one that have been made because as a result of research from layer twos, please let me know, but there there really haven't been any EIPs driven through the layer two process that have gone into the layer one.

There is one you know, large notable exception that ZK proving and ZK technology has like massive massively been accelerated by the fact that layer twos have poured tons of research in usually through the support of a token. But again, none of that has actually gone live on the layer one yet. Uh and then layer two to layer two, there's almost nothing. We are now starting to see some collaboration. I think I just saw the first cross L2 EIP / roll up improvement proposal like yesterday, which is pretty cool, but it was only two roll ups.

So we still have a lot a lot of room to go. Um Yeah, and I think that just brings me to the sort of the the main point of this is we have a lot of flourishing gardens on layer two ecosystems, but because of coordination failure and you know, the the lack of incentives for these layer twos to collaborate with each other, uh we've we've essentially had coordination failure where we haven't been transferring innovation between each other. Um yeah, and this is my this is my chat GPT rendition of of scenario. We have we have a lot of, you know, awesome spaces um to do cool things, but none of them are really helping each other out. Um Yeah, so that's like a pretty serious concern because this is the future of the ecosystem and the future How how can we have How can this be the future of the ecosystem if none of these participants are talking to each other?

Um well, I So, I think we can start debugging a few things. Like one is peripheral tooling lock-in. And so, a lot of layer twos have complained that they can't do anything very customizable or unique because they need to satisfy the existing wallet API standards, the existing indexers. If you spin up a new type of block, now integrating with Blockscout or Etherscan is suddenly much harder. Um all of the tooling, like the SDKs that front-end developers use to integrate with these chains also become much harder.

Um and on top of that, you know, it's one thing for a layer two to to modify the tooling to make it work with like say a popular SDK, but then now the maintainers of that SDK need to also maintain this modified version of a of the SDK. And so, the incentives also aren't great there. Um and what I think is potentially another reason for this is uh what I call uh an innovation death loop because of tokens and tribalisms. Uh I I think it roughly goes like people launch a token. Tokens tie the incentives of groups and individuals together.

These shared incentives create the appearance of in-groups and out-groups, which you can see on Twitter when we have a roll-up teams fighting against each other about very small details, um and then going separate ways and not creating standards to um address these differences. Um that that then leads to all of our tooling being for a specific L2. Um yeah, and I think because of this tribe tribal rivalry, innovations are gate kept. Um and and like even the extreme of this is it manifests itself in restrictive licenses. Some of the most popular L2s today, you're not even allowed to fork or you are allowed to use them, but you need to give a certain percentage of sequencer fees back to the um to to the like basically the creators of the chain.

And I get that incentives are very hard in open-source ecosystems, but I think we should hold ourselves to a higher standard because we gave our credibility to these layer 2s. Um yeah. So, I think for the rest of this talk, I'll identify four key areas to help improve Ethereum's innovation on layer 2s. Uh and I hope that next year someone or or in 2 years someone will give a a talk addressing one of these areas as I think they're critical. Cool.

So, let's go into it. A layer 2 tech tree. If you're unfamiliar with what a tech tree is, uh it's you know, you can see them in strategy games. A tech tree or a research tree is a hierarchical visual representation of the possible sequences or upgrades a player can unlock. Um you can think of this in like civilization games where if you want to you know, like reach the iron age, you need to be able to mine iron.

You need to be able to melt it. You need to be able to do that at scale. Um and there's another uh so, there's there's an institute called the Foresight Institute which solely uh is focused on basically creating these tech trees and then allocating funding to areas of the tech tree that are under uh developed. And here's an example of one which is very fun of a longevity tech tree where one of the top things is body replacement and in order to do that, we need head transplants. We need brain tissue replacement.

We need organ replacement. And so, we set out to do this for Ethereum layer 2 to try and help us get to the golden age of of layer 2s. Um so, this is the tech tree. I'm going to go through every single leaf. Uh no, just kidding.

There's there's way too much. If you want to follow along, uh there is a URL and a QR code you can scan to reach it. If if this is like very interesting to people, we may end up um turning this into like a website that you could easily modify and and add to. Cool. So, let's get into it.

So, this is the high-level tech tree. There's four subtrees in here. There's funds are safe. This deals with the safety properties of the rollup um in that uh you know, basically if the rollup were to go away, if it was to die, if the software was to go down, we want to make sure that the funds inherit the liveness of the layer one. Um there's web two scalability.

And so, this is the idea here is that we want to approximate like the holy grail of everything on one computer, but obviously we can't put everything on one computer. Don't let anyone uh let you think that. And um yeah, it it should be as easy as you going to a cloud provider and, you know, hitting the auto scale button and now you have compute for all of your use cases as long as you keep putting money in or there's long as there's someone sort of funding this software, then it should be able to grow and have abundant compute space. Um a big requirement of that is seamless interoperability. That means you don't need to think about the fact that you're on one chain and your asset your assets are on one chain, but you want to do compute on another.

Uh and then another one is also um like plenty of compute environment. So, we don't want to just have the EVM. There's you know, by developers, the largest ecosystem in the world is JavaScript. There's like hundreds of millions of JavaScript developers. There's like only a couple million Solidity developers.

So, if we really want to reach the next billion, we need to expand. Cool. So, let's get into it. I'm going to go into the left side of this funds is safe subtree first. Um and then I'm going to focus on uh the censorship resistance portion of liveness.

Um and so under that under liveness there is censorship resistance and ledger progression. Ledger progression is just the idea that the blocks keep coming. They keep going. The system doesn't go down. Um and censorship resistance is really about getting either inclusion guarantees or execution guarantees.

And so um some stacks actually already have a very basic version of inclusion guarantees where you can force include your transaction on the L2 from the L1. The only problem with that is it's actually at a greater than the um L2 or even L1 block time granularity. So you only get the guarantee that your transaction will be included in the uh like you know like in an epoch of L2 blocks which could be you know tens, hundreds of blocks. Um yeah. And so there there's a lot of areas here as well.

A very popular topic is multiple concurrent proposers on Ethereum L1 right now uh as well as pre-confirmations, confirmations, encrypted mempools. These are all things we need to improve these inclusion and execution guarantees, but uh we we actually have no one working on them on L2s. Uh and and then specifically no one is creating shared standards across L2s to uh to enable these. So I think yeah, I think there's a heroic opportunity here where just you can just skip the politics. Just go build multiple concurrent proposers on a layer two.

Um yeah, you can also experiment with fossil other censorship resistance um uh research proposals uh as well as encrypted mempools. Cool. The next part of the tree, the right side of this funds is safe, is uh under validity. Um and this one is also very exciting. Um yeah, cool.

So under validity uh I have mul- we we developed multiprover. Uh we we developed this term multiprover. It's it's been a known term, but the idea is no rollup will likely ever trust a single proving system. Um and so the idea here is rollups want a proving system so that they can have faster finality. Right now most rollups are optimistic rollups, meaning they get pushed to the L1 and you know, it it takes some amount of time which is very annoying to users for someone to say like ah there's no fraud here.

The state transition was good. You didn't have your funds stolen. Um but validity proofs allow us to be confident in that state transition. And so the thing is a lot of people have developed validity proofs, but none of these teams are talking to each other. Um and on top of that, it's very unlikely that we will ever trust just a single proving system because of how new this crypto and technology is.

Some of these proving systems are 80K lines of circuit code and uh good luck auditing that. Um yeah. So I think probably for the next two to four years we will not trust a single proving system, so we need multiple. And under that family there are ZK proofs and then also very recently uh there's been a lot of teams developing TE proofs. Um one specifically is we've been collaborating with Automata to develop TE validity proofs um and the performance [clears throat] is looking pretty good actually.

Um we've been able to prove uh in TDX in 0.2 milliseconds uh a specific blocks. And so we think this can this should be an additional layer of of proving. But yeah, I I think the main thing here is there's a lot of teams and none of them are talking to each other. So we need a standardized interface to align proof system development teams under one multi-prover and also we need this to enable prover markets so that anyone is able to provide these proofs for these layer twos.

Um cool. We'll get into the next part of this tech tree which is web two scalability. Um as I said, the ideas here is you want auto scaling on these servers. You don't want to think about it. I don't want to you know, get woken up by devops at 2:00 a.

m. and like, oh, we need more capacity and I need to go like manually deploy a script to launch another chain and, you know, all of the configurations associated with that. Um, but in order to get there in this world where we could have multiple chains for a single application, um, we need seamless interoperability and this is just a massive mess. Um, there are so many things here. Uh, this this tree is broken up into out of cluster and in cluster.

Um, the idea here is that stacks like optimism are creating like a cluster, meaning they have multiple rollups that are have some type of shared settlement and shared infrastructure and governance that allow them to make assumptions which make it easier for them to communicate with each other. And this doesn't mean you can't communicate with the outside world, but what it does mean is if I'm developing an application and I have a neighbor that I need to interact with frequently, sort of I can put the walls down a little bit and transact with them more easily. And then if I need to call out to some more advanced or or some like other specialized use case, then I can just like go through the regular internet. Um, yeah, so that's out of cluster and in cluster. Um, I think honestly the biggest thing here is like literally just getting the the layer twos to talk to each other.

This doesn't even need to require like you don't need to develop anything for this opportunity or spec anything. Like just go talk to all of them, figure out what they want, write that down somewhere. Like that would already be a huge improvement. Um, and then lastly I'll go through punchable compute environments. Um, and so this one's pretty fun I think because recently the Ethereum Foundation has launched a Manhattan project to formally verify a risk-5 VM.

Um, and so I think that's something you could easily do on like top of the OP stack or any other stack is start experimenting with different VM types. On top of that, uh, we could be experimenting with other privacy-enhanced computation as well, such as like FHEVMs, ZKVMs. There are some experimenting, but there's no open standards. They're all either partially closed source or in a very like obfuscated code base that you need to be like an engineer on the team to understand. Cool.

And so that's opportunity number four, experimenting with virtual machines on open source and open license. Don't be fooled by open source being the only requirement. Some are open source, not all of them are open license. And two popular ones here are like Reth and Rollup Geth. Cool.

So those are the four areas of improvement I think we can make today is experiment with inclusion and execution guarantees, build a multi-prover interface, help coordinate interop standards, and build open-source and open-license code bases with different VMs. Cool. And so I'll get into the last section on Rollup Boost. So this is something This is a product we've been developing at Flashbots. It's open source, open license.

And so I'll start with the basics. So in Ethereum, there is something called the engine API. It's how the consensus layer and the execution layer talk to each other. In order to be the like maximally Ethereum-compatible, you actually also ideally are using this engine API in your layer two architecture. And so yeah, the ideal scenario is that we also use this in the CL and EL, and there are some stacks that do.

And so we at Flashbots developed this software to just sit in between the CL and the EL. It uses the additional API that these two clients use to talk to each other, and we're able to send these requests between each other. We're able to proxy them to other components in the ecosystem. The example we've built today is a block builder, so you can add customizations to your chain like revert protection or faster pre-confirmations all through this block builder, but in the future, we also see this component as being critical in outsourcing proof production to like prover markets and and even multiple different types of prover markets. Um so yeah, I think the the really cool thing about this is you don't need to fork the OP stack or the other stacks you're dealing with.

If they use the engine API, this works out of the box and you can start adding customizations to the chain and it's permissionless to innovate. And I think if um yeah, if if we're if we're able to innovate without these like, you know, you know, if I go to the the the repo and I don't need to sign a contract to uh advance the code base and the code base is also maximally compatible with the layer one code bases, then this is like how we recreate this innovation Um yeah, also on top of this Rollup Boost is powering the latest Unichain launch. Uh and then on top of that, Worldcoin also recently announced that they're using it to enable a a new type of block building algorithm that prioritizes humans. So there's already a ton of innovation happening in the space on Rollup Boost and I think it's going to be one of the new innovation hubs for Ethereum layer two. So if you see me later, uh chat with me how we could build CR committees, multichain block builders, and multiprovers on Rollup Boost today.

Thanks. All right. Thank you so much, Dan, for a very thorough presentation. We do have a few minutes to answer maybe a couple of questions. Oh yeah.

Um so let's start with has it ever happened that innovation at Rollup or layer two was later on adopted on layer one? And I don't know of any scenarios this has happened. So yeah, I think that's the that's the big problem right now. Great. All right.

Next is what do you think about the fractional liquidity from L1 to L2? Would that be the main issue? Interesting. Fractional liquidity. Yeah, I I guess it's like yeah, the idea of fragmentation.

So, if my liquidity is on one roll-up, it doesn't work on the other roll-up. I think if we solve the seamless operability interoperability subtree, then you you won't even notice this. All right. We do have still a few more minutes. We'd like to end Does Arbitrum need a boost?

Does Arbitrum need a boost? I think they're they're they're boosting time is what I've heard, which is a joke. I think they have an algorithm called time boost. I I don't totally know what this question means. [laughter] Okay.

Let's see what is next. Is it this What about new innovations on L2s? Not transferred. Yeah, there there are some cool innovations on layer 2s. I I think as I mentioned like ZK ZK tech is like by far the coolest.

Yeah, there's there are some people deploying like Solana like the SVM in their architecture as a layer 2, which I I also think is cool. I think we should keep pushing the window on different blockchain clients and architectures on layer 2. All right. Last few seconds. What do you think of Solana?

What do I think of Solana? Solana's pretty cool. I I think Solana is what it looks like if you try to optimize a blockchain client for performance to the max. But, I don't think it's what it what a blockchain client that optimizes for innovation looks like. Interesting take.

And one last is what is roll-up boost? Okay, what is roll-up boost? Yes. It is a sidecar you can use on layer 2 blockchain clients to enable features without having to fork the underlying blockchain stack. Amazing.

Thank you so much, Dan. And please give him a round of applause.