Passkeys : the good, the bad, the ugly

Hello, hello. Awesome. Wow. Cool to see so many people turn out to discuss the rollup-centric roadmap. 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 for anyone watching the live stream. Cool, well let's get into it. I'm Dan, also DMARS online, and I'll be talking about how we can turbocharge the Rollup-centric roadmap with Rollup Boost. I'll be using a lot of triple R alliteration. If you see any of those, talk to me afterwards and I'll give you a special prize.

Cool. So this will be structured in three parts. I'll go over a little reflection on the Rollup-centric roadmap. I'll then talk about what a Layer 2 technology tree looks like, and then I'll discuss how we can use Rollup Boost to accelerate innovation on the Layer 2 technology tree looks like, and then I'll discuss how we can use rollup boost to 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 rollup-centric roadmap. If you're unfamiliar with what that is, the rollup-centric roadmap was Ethereum's strategic shift towards scaling the network by embracing rollups as a primary solution. You know, if you're unfamiliar with rollups 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. In this vision, Ethereum becomes a more robust and secure settlement layer while most activity happens on these layer two rollups and we've already seen that a lot of activity has shifted to a lot of layer two rollups.

Yeah, and there's a lot of benefits of this, and 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 tons and tons of research and formal analysis before we ever actually start to create a proof of concept or ship something. Because a lot of the times when you are trying to build innovative features, you typically don't discover... There's a lot of unknowns, unknowns you don't discover until you start building. And we've seen many such cases of that with MEV on Ethereum. Yeah, cool.

So let's go into it. So we're four years in. How are we doing? 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 2 ecosystem. So let's go through each of those. First, how are we doing on TPS? Well, if you look at L2Beat, we have scaled Ethereum 26x 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. On the way to scaling transactions per second, we also discovered maybe that's not the best metric as there's a lot of activity on chains which aren't just which can't just be basically categorized via a transaction. A lot of chains simply just have a transfer, and that's 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, 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 this is a bit small, but if you can see on conduits, rollup.wtf, we have increased the gas per second by almost 55x compared to the Ethereum layer one.

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

Most of the top rollups are less than, you know, a cent sometimes to transact on. Cool. And so the last one, which is much more complicated and will be the segue into the rest of this talk is how are we doing on outsourcing of innovation to the Layer 2 ecosystem? And I think this is really important because with the roll-up-centric roadmap, we essentially said, hey, you know, everyone focusing on Layer 1, you know, you keep doing that, but we are going to push the boundaries and the next version of Ethereum will be built on Layer 2s. And so it's really important that that actually succeeds.

And we as a community lended all of our credibility to these layer twos. And so we should be checking in on how they're doing. So it's a little bit complicated to look at how innovation is transferring between these layers, but there's roughly three 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's been ported from layer one to layer two? Well, basically everything. Most of the popular blockchain clients, layer two blockchain clients, with the exception of some, actually use a minimized version of the Ethereum one blockchain clients that has like a very 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 chains like Optimism where after EIP 1559 went live, they had it very soon after and all other upgrades.

But this is not true for all chains. Yeah, layer two to layer one. 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 really haven't been any EIPs driven through the layer two process that have gone into the layer one. There is one large notable exception that ZK proving and ZK technology has massively been accelerated by the fact that layer twos have poured tons of research and usually through the support of a token. But again, none of that has actually gone live on the layer one yet.

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 slash roll-up improvement proposal like yesterday, which is pretty cool, but it was only two roll-ups. So we still have a lot of room to go. Yeah.

And I think that just brings me to the sort of the main point of this is we have a lot of flourishing gardens on layer two ecosystems, but because of coordination failure and the lack of incentives for these layer twos to collaborate with each other, we've essentially had coordination failure where we haven't been transferring innovation between each other. Yeah, and this is my chat GPT rendition of the scenario. We have a lot of, you know, awesome spaces to do cool things, but none of them are really helping each other out. Yeah, so that's like a pretty serious concern because this is the future of the ecosystem and how can this be the future of the ecosystem if none of these participants are talking to each other? Well, 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 block scout or ether scan is suddenly much harder. All of the tooling like the SDKs that front end developers use to integrate with these chains also become much harder. And on top of that, you know, it's one thing for a layer 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 the SDK, and so the incentives also aren't great there. And what I think is potentially another reason for this is what I call an innovation death loop because of tokens and tribalisms.

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 roll-up teams fighting against each other about very small details and then going separate ways and not creating standards to address these differences. That then leads to all of our tooling being for a specific L2. Yeah, and I think because of this tribal rivalry, innovations are gatekept. And 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 basically the 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 twos. Yeah, so I think for the rest of this talk, I'll identify four key areas to help improve Ethereum's innovation on layer twos. And I hope that next year someone, or in two years, someone will give a talk addressing one of these areas as I think they're critical. Cool.

So let's go into it. A layer two tech tree. If you're unfamiliar with what a tech tree is, 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. 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.

And there's another so there's there's an institute called the foresight institute which solely is focused on basically creating these tech trees and then allocating funding to areas of the tech tree that are underdeveloped. 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 two to try and help us get to the golden age of layer twos. So this is the tech tree, I'm going to go through every single leaf. No, just kidding. There's there's way too much. If you want to follow along.

There is a URL and a QR code you can scan to reach it. If this is very interesting to people, we may end up turning this into a website that you could easily modify and add to. Cool. So let's get into it. So this is the high-level tech tree.

There's four subtrees in here. Funds are safe. This deals with the safety properties of the rollup in that 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. There's Web2 scalability. And so the idea here is that we want to approximate the holy grail of everything on one computer, but obviously we can't put everything on one computer.

Don't let anyone let you think that. It should be as easy as you going to a cloud provider and 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 as long as there's someone funding this software, then it should be able to grow and have abundant compute space. 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 assets are on one chain, but you want to do compute on another. And then another one is also like plentiful 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. And then I'm going to focus on the censorship resistance portion of liveness. 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. And censorship resistance is really about getting either inclusion guarantees or execution guarantees. And so 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 L2 from the L1. The only problem with that is it's actually at a greater than the L2 or even L1 block time granularity. So you only get the guarantee that your transaction will be included in the, like, you know, like in the epoch of L2 blocks, which could be, you know, tens, hundreds of blocks. Yeah. And so there's a lot of areas here.

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

Cool, the next part of the tree, research proposals, as well as encrypted mempools. Cool. The next part of the tree, the right side of this funds is safe, is under validity. And this one is also very exciting. Yeah, cool.

So under validity, we developed multi-prover. We developed this term, multi-prover. It's been a known term, but the idea is no roll-up will likely ever trust a single proving system. And so the idea here is roll-ups want a proving system so that they can have faster finality. Right now, most roll-ups are optimistic roll-ups, meaning they get pushed to the L1, and it takes some amount of time, which is very annoying to users, for someone to say, like, ah, there's no fraud here.

This state transition was good. You didn't have your phone stolen. 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. 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 good luck auditing that. 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, there's been a lot of teams developing TE proofs. One specifically is we've been collaborating with Automata to develop TE validity proofs, and the performance is looking pretty good, actually.

We've been able to prove in TDX in 0.2 milliseconds specific blocks. And so we think this should be an additional layer of proving. But yeah, 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. Cool. We'll get into the next part of this tech tree which is web 2 scalability. As I said, the idea 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 a.m. and, like, oh, we need more capacity, and I need to go, like, manually deploy script to launch another chain, and, you know, all of the configurations associated with that. But in order to get there in this world where we could have multiple chains for a single application, we need seamless interoperability, and this is just a massive mess. There are so many things here.

This tree is broken up into out-of-cluster and in-cluster. The idea here is that stacks like Optimism are creating a cluster, meaning they have multiple roll-ups that 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, 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 some other specialized use case, then I can just go through the regular internet. Yeah, so that's out of cluster and in cluster.

I think, honestly, the biggest thing here 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 and then lastly I'll go through plentiful compute environments and so this one's pretty fun, I think, because recently the Ethereum Foundation has launched a Manhattan project to formally verify a RISC-V VM. And so I think that's something you could easily do on top of the OP stack or any other stack is start experimenting with different VM types. On top of that, we could be experimenting with other privacy-en privacy enhanced computation as well, such as like FHE VMs, ZK VMs. There are some experimenting, but there's no open standards. They're all either partially closed source or in a very obfuscated code base that you need to be 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 roll-up 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, 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 Flashbot developed the 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 even multiple different types of prover markets. So yeah, I think 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, yeah, if we're able to innovate without these like, you know, if I go to the repo and I don't need to sign a contract to 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 loop.

Yeah, also on top of this, Rollup Boost is powering the latest Unichain launch, and then on top of that, WorldCoin also recently announced that they're using it to enable 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 2. So if you see me later, chat with me how we could build CR committees, multi-chain block builders, and multi-provers 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. So let's start with, has it ever happened that innovation at Rollup or Layer 2 was later on adopted on Layer 1?

I don't know of any scenarios this has happened. So yeah, I think that's the big problem right now. Great. Alright. 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 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 rollup.

I think if we solve the seamless interoperability subtree, then you won't even notice this. Alright, we do have still a few more minutes. We'd like to answer, does Arbitrum need a boost? Does Arbitrum need a boost? I think they're boosting time, is what I've heard, which is a joke.

I think they have an algorithm called Time Boost. I don't totally know what this question means. Okay, let's see, what is next? Is it this, what about new innovations on L2s? Yeah.

Not transferred. Yeah, there are some new innovations on L2s? Not transferred. Yeah, there are some cool innovations on Layer 2s. I think, as I mentioned, like, ZK, ZK Tech is, like, by far the coolest.

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

Solana's pretty cool. 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 a blockchain client for performance to the max. But I don't think it's what a blockchain client that optimizes for innovation looks like. Interesting take.

And one last is what is Rollup Boost? Okay, what is Rollup Boost? Yes, it is a sidecar you can use on layer two blockchain clients to enable features without having to fork the underlying