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

Transcript

Hello, hello. Perfectly. Wow, it's great to see so many people come to discuss the role- centric roadmap. Um, the hall is quite full, so I'll ask everyone to move a little. I think a lot of people are standing in the back, um, for those watching the live broadcast. Hmm, cool. Well , let's get started. Uh, I'm Dan, also known online as D Mars. Um, and I'll talk about how we can accelerate the rollup-centric roadmap with Rollup Boost. I will use alliteration on the "R" often.

If you spot even one, uh, come up to me after the show , and, uh, I'll give you a special prize. Cool . Uh, the speech will be structured in three parts. I'll analyze the roadmap a bit. Then I will explain what the second level (L2) technology tree looks like and discuss how we can use Rollup Boost to accelerate innovation in this area. Steeply. So, let's move on to the first part. Yes, we have been implementing a role- roadmap for 4 years now. If you don't know what this is, it's Ethereum's strategic move to

scale the network by adopting rollups as a core solution. Uh, you know, if you're not familiar with rollups, it's a way of processing transactions off-chain by submitting compressed proofs to the Ethereum mainnet, allowing for increased throughput without compromising the underlying decentralization. Hmm, with this vision, Ethereum becomes a more reliable and secure layer of payments, while the main activity occurs on the second- level rollups, and we are already seeing that a significant part of the activity has moved to them. Um, yes,

this has many advantages, and we will go into them in detail . But one of the biggest advantages, in my opinion, is that we can innovate on a standalone level without having to go through the lengthy Ethereum core development process or extensive research before launching a prototype. Um, because often when you try to build innovative features, you run into unknown factors that only become apparent during development , and we've seen a lot of that with MEV in Ethereum. Um, yeah, cool.

So, let's get started . We have been working for 4 years. How are we doing? Well, we had about three goals. The first is to increase the number of transactions per second in Ethereum. The second is to reduce transaction costs. And the third is to delegate innovation to a second-tier ecosystem. So let's go through each of the points. First, how are we doing with our TPS? If you look at L2Beat, we scaled Ethereum 26 times in terms of transactions per second, which is quite an achievement. This has more than doubled every year since the rollout-focused roadmap was announced. So, this is just great. We can check the box. Oh, and on the way to

scaling second, we realized that this might not be the best metric, as a lot of activity on networks can't simply be classified as a transaction. Many networks simply make transfers, and it's very simple. This only applies to the part of the chain that is connected to your balance and the other person's balance. But if you consider more complex actions, they can affect hundreds or thousands of accounts, performing extremely complex calculations. So we started using GPS as a metric—gas per second. This is a bit shallow, but as you can see on rolluplab.wtf, we increased the gas volume

per second by almost 55 times compared to Ethereum's first level. So, another great progress. Class. We completed this task as well. What about transaction costs? They should be lower as we scale. This slide speaks for itself. Transaction costs on most leading wallets are sometimes less than a cent. Perfectly. The last question, which is much more complicated and will become the basis for further conversation: how are we doing with delegating innovation to the second-tier ecosystem? I think this is extremely important, because with the focused on

rollups, we essentially said, “Hey, you guys who are doing layer one, keep going, but we’re going to push the boundaries , and the next version of Ethereum will be built on layer two solutions .” Therefore, it is important that this really works, because we as a community have entrusted all these level decisions with our authority. So we should check how they are doing. So it's a little bit tricky to understand how innovation is transferred between these levels, but there are roughly three ways we can look at it. These are innovations transferred from the first level to the second, innovations from the second level back to the first , and then innovations

between the second levels. And so we'll go through each of them. So , what was moved from the first level to the second? Well, practically everything. Most popular blockchain clients, layer two clients, with a few exceptions, actually use a stripped-down version of the layer one Ethereum blockchain clients, which have very minimal differences. This means that whenever there is an update to the first-tier client, the second tiers can easily implement it. And you can see this with networks like Optimism, where after EIP 1559 was launched, they implemented it very soon after, just like all the other updates.

But this does not apply to all networks. Um, yes, the second level to the first. Uh, nothing actually. If you know of any first- tier improvements that were made as a result of tier research, please let us know, but there really weren't any EIPs initiated by the tier process that made it to first-tier. There is one, you know, big notable exception: ZK- proofing and ZK- technologies have been massively accelerated by the fact that second tiers have invested tons of research, usually backed by a token.

But again, none of this has really worked at the ground level yet. Uh, as for the second level to the second, there's almost nothing there. We are now starting to see some collaboration. I think I just saw the first cross-L2 proposal for improving EIP/ rollup yesterday, which is pretty cool, but it only applied to two rollups. So we still have room to grow. Um, yes, and I think that brings me to the main point: we have a lot of blooming gardens in second-tier ecosystems, but because of the failure of coordination and the lack of incentives for these second-tiers

to cooperate with each other, we have essentially failed to coordinate, which is why we are not transferring innovations between each other. Um, yes, and this is mine, this is my version of the script from ChatGPT. We have, you know, a lot of great spaces for interesting things to do, but none of them help others. Um, yes, this is a pretty serious problem because it's the future of the ecosystem. How can this be the future of an ecosystem if none of its members communicate with each other? Well, I think we can start to fix a few

things. For example, linking to third-party tools. Many second-level (L2) solutions complain that they can’t do anything truly unique or adaptable because they need to comply with existing wallet API standards and indexers. If you create a new block type, integration with Blockscout or Etherscan suddenly becomes significantly more complicated. Um, all the tools, like SDKs, that front-end developers use to integrate with these networks are also becoming much more complex. Um, and besides, it's one thing when a second- tier project modifies tools to work with, say, a popular SDK, but now the developers of

that SDK need to support this modified version as well. So the incentives here are not the best either. Um, and another possible reason for this is what I call the “ innovation death loop” due to tokens and tribalism. I think it goes something like this: people launch a token, and tokens link the incentives of groups and individuals together. These shared incentives create a division into “insiders” and “ outsiders,” which can be seen on Twitter when teams of Rolap members argue over trivial matters, disagree, and fail to create standards for resolving these disagreements. This

leads to all our tools becoming tied to a specific L2. Um, yeah , and I think that because of this tribal rivalry, innovation becomes inaccessible. Um, and in extreme cases this is expressed in restrictive licenses. Some of the most popular L2s today even prohibit forks, or allow use on the condition that you give a certain percentage of the sequencer fees to the creators of the network. I understand that incentivizing in open source ecosystems is difficult, but I think we should demand more of ourselves because we have entrusted these second-tier networks with our authority. Um, yes.

So, I think over the course of this talk I'll outline four key areas for improving Ethereum's layer 2 innovation, and I hope that next year or two, someone will give a talk on one of these areas, because I think they're critically important. Steeply. So let's begin. Layer 2 technology tree. If you are not familiar with the concept of a " technology tree", then you may have seen them in strategy games. A technology or research tree is a hierarchical visual representation of the sequences or upgrades that a player can unlock. You can think of it like in the game Civilization: if you want to reach the Iron Age, you need to be able to mine iron.

You need to be able to smelt it. You do this on a large scale. There is an institute called the Foresight Institute that specializes in creating such technology trees and directing funding to underdeveloped industries. Here's an interesting example of a longevity tech tree, where one of the main points is body replacement, and for that we need a head transplant. We need brain tissue replacement. We organ replacement. So we decided to do the same for Ethereum layer 2 to bring the “ golden age” for layer 2 networks closer. So, this is the technology tree. I'm

going to go through every leaf. I'm kidding, of course. There's too much going on here . If you want to follow me, here is the URL and QR code to scan. If it turns out to be interesting for people, we can turn it into a website that you can easily edit and add to. Steeply. So let's get to the point . Here is a simplified technology tree. There are four subtrees here. " Money is safe." This concerns the security properties of rollups: what happens if the rollup disappears, dies, or the software stops working.

We want to ensure that funds inherit layer 1 reliability. " Web2-level scalability"—the idea is to get closer to the holy grail of "everything on one computer ," although of course we can't put everything on one computer. Don't let anyone convince you otherwise. And yes, it should be as simple as going to a cloud provider and clicking the autoscale button, and you already have the computing power for all your tasks. As long as you invest, or as long as someone funds this software, it should be able to grow and have enough space. An important requirement for this is full

interoperability. This means that you don't need to think about the fact that you are on one chain and your assets are on another , but you want to perform calculations on a third. And one more thing —this is, of course, the abundance of environments. We don't want to limit ourselves to just EVMs. You know, among developers, the largest ecosystem in the world is JavaScript. There are hundreds of millions of JavaScript developers. And there are only a few million developers on Solidity. So if we really want to attract the next billion, we need to expand. Steeply. So let's get down to business.

I'll first go to the left side of this " safe funds" subtree. And then I'll focus on the "survivability" part, which is responsible for resistance to censorship. So, by "survivability" we mean resistance to censorship and progression of the register. Ledger progression is simply the idea that blocks continue to be created. They are constantly leaving. The system does not stop. And censorship resistance is really about getting guarantees of enabling or executing transactions . Some stacks already have a very basic version of inclusion guarantees where you can force your transaction to be included in L2 from L1.

The only problem is that this happens with less granularity than L2 or even L1 block time. So you only get a guarantee that your transaction will be included in the L2 block epoch, which could be tens or hundreds of blocks. Yes. And there are many areas here, and a very popular topic right now —multiple simultaneous proposers in Ethereum L1, as well as pre- confirmations and encrypted mempools. These are all things we need to improve inclusion and execution guarantees, but unfortunately no one is working on this for L2. In particular , no one is creating common standards

for L2 to make this possible. So I think there's an incredible opportunity here where you can just put politics aside. Just take and create multiple simultaneous proposers at level 2 (L2). Um, yes, you can also experiment with fossilization and other censorship resistance suggestions, as well as encrypted mempools. Class. The next part of the tree, the right side of this “safe funds” is the “validity” subsection. Hmm, and that's also very exciting. Um, yeah, cool. So, within the framework of validity, we developed a multi-prover, we introduced this term—multi-prover . It's a well-known term, but the idea is that

no rollup will likely ever trust just one proof system. Um, and so the idea here is that the rollaps need a proofing system to ensure faster finalization. Now most rollups are optimistic rollups, meaning they are transmitted in L1, and, you know, it takes a while, which is very annoying for users, until someone says, " Oh, there's no fraud here." This state transition was correct. "Your funds were not stolen." Um, but the validity evidence allows us to be confident in this state transition. The thing is, many people have developed proofs of validity, but none of these teams other. Um, and on top of that, it's highly

unlikely that we'll ever trust just one proof system due to the novelty of this cryptography and technology. Some of these proof systems have 80,000 lines of schema code, and good luck auditing them. Um, yes. So I think that over the next 2–4 years we will not trust proof system, we need several. There are ZK-proofs in this family , and also very recently many teams have started developing TE-proofs. Um, specifically, we're collaborating with Automata on developing TE- proofs of validity.

Um, and the performance actually looks pretty good. We were able to bring individual blocks to TDX in 0.2 milliseconds. So we think this should be an additional level of proof. But yeah, I think the main thing here is the large number of teams that don't interact with each other. Therefore, we need a standardized interface to unite proofing system development teams into one multi-prover. We also need this to create proof markets so that anyone can provide such proofs for these L2 solutions. Class. We will move on to the this technology tree, which is Web2 scalability.

As I said, the idea here is that you want to autoscale these servers. You don't want to think about it. I don't want, you know, DevOps waking me up at 2 a.m. saying, "Oh, we need more capacity." And I have to manually run a script to deploy another chain and, you know, all the configurations associated with that. But to get to a world where we can have multiple chains for a single application, we need seamless interoperability, and right now it's just a huge mess. There is so much here. This tree is divided into " outside the cluster" and " inside the cluster".

The idea is that stacks like Optimism create a kind of cluster, meaning they have multiple rollups with a common compute layer , shared infrastructure, and management, which allows them to make assumptions that facilitate interoperability . This doesn't mean you can't communicate with the outside world, but it does mean that if I'm developing an app and have a neighbor that I need to interact with frequently, I can take down the walls a little bit and make transactions easier. And then, if I need to address some more complex or other specialized use case , I can just use the regular internet . Yes, it's "outside the cluster" and "

I think the biggest challenge here is literally getting the Layer 2 layers to talk to each other. It doesn't even require developing anything for this capability or creating specifications. Just talk to them all, find out what they want, and write it down somewhere. That would already be a huge improvement. And finally, I will consider possible environments. This is quite interesting, as the Ethereum Foundation recently launched the Manhattan Project to formally verify the RISC-V virtual machine. So I think this is something that can be easily done on top of the OP Stack or any other stack—start experimenting with different types of virtual machines.

Additionally, we could privacy-enhanced computations, such as FHEVM or ZKVM. Some are experimenting, but there are no open standards . All of them are either partially closed or have such a confusing code base that you have to be an engineer on that team to understand anything. Cool. So that's opportunity number four: virtual machines based on open source and licensing. Don't be fooled by the fact that open source is the only requirement. Some are open, but not all of them have an open license. Um , and two popular options here are, for example, Reth and Rollup Geth. Hmm, cool. So, these are four areas for

improvement that we can implement today: inclusion and execution guarantees, creating a multi-prover interface, coordinating interoperability standards, and creating openly licensed codebases for different virtual machines. Hmm, cool. So I'll move on to the last section about Rollup Boost. This is a product we are developing at Flashbots. It has open source code and an open license. Hmm , let's start with the basics. Ethereum has a so-called engine API. This is the way the consensus level and the execution level interact. To be as compatible as possible with Ethereum, it is ideal to use this engine API in your

Layer 2 (L2 ) architecture as well. So the ideal scenario is that we use this in CL and EL as well, and some stacks already do this. We at Flashbots designed this software to sit between CL and EL. It uses an additional API through which these two clients communicate, and we can pass these requests between them. We can proxy them to other components of the ecosystem. The example we created today is a block builder, so you can add customizations to your chain, like rollback protection or faster pre-

confirmations. But in the future, we also see this component as critical to outsourcing proof creation to proofer markets, and even different types of such markets. So, I think the coolest thing is that you don't have to fork OP Stack or any other stacks you're working with. If they use the engine API , it works right out of the box and you can add the chain without innovation permissions. And I think if we can innovate without... if I go to the repository and I don't have to sign a contract to improve the codebase, and it's as compatible as possible

with the level 1 codebase—that's a way to recreate the innovation cycle. Um, yes, plus Rollup Boost powers the recent UniChain launch. And to top it all off, Worldcoin recently announced that they are using it to implement a new type of block construction algorithm that prioritizes people. So , there is already a lot of innovation happening in the Rollup Boost space, and I believe it will become one of the new innovation hubs for Ethereum's second layer . So if you see me later, chat with me about how we could build CR committees, multi-chain block constructors, and multi-provers on Rollup Boost today.

Thank you. OK. Thank you very much, Dano, for a very thorough presentation. We have a few minutes to answer maybe a couple of questions. Oh, yes. Um, so let's start with, has it ever happened that innovations in Rollup or at the second level were later implemented at the first level? And that I don't know of any scenarios where this would happen. So, yeah, I think that's a big problem right now. Perfectly. OK. Next: What do you think about fractional liquidity from L1 to L2? Is this the main problem? Hmm, interesting. Fractional liquidity. Yes, I think it's like the idea of fragmentation. So, if my liquidity is on one rollup, it doesn't work on another rollup. I think

if we solve the problem of seamless interoperability, you won't even notice it. OK. We still have a few minutes. We would like to answer whether Arbitrum needs boost ( acceleration)? Do I need Arbitrum boost ? I think their acceleration time is what I heard, and it's a joke . It seems they have an algorithm called Timeboost. I don't quite understand what this question means. Okay. Let's see what happens next .

Hmm, what is this? What about new innovations on L2? Um, not transferred. Yes, there are some cool innovations at the second levels. I think, as I mentioned, ZK technologies are definitely the coolest. Um, they... yeah, there are people who deploy Solana, for example, SVM in their architecture as a second layer, which I think is cool too. I think we should continue to push the boundaries for different blockchain clients and architectures at the second level. Okay, the last few seconds. What do you think about Solana?

What do I think about Solana? Solana is pretty cool. I believe that Solana is what a blockchain client looks like if you try to optimize its performance as much as possible. Hmm, but I don't think this is what a client that is optimized for innovation looks like. Interesting thought. And lastly: what is Rollup Boost? What is Rollup Boost? Yes, it is a sidecar that can be used on second-layer blockchain clients to add features without having to change the core blockchain stack.

Surprisingly. Thank you very much , Dan, and please give him a round of applause.