Right now, L2beat tracks 116 L2s. However, they represent a wide range of trust assumptions, which makes assets—or more abstractly, messages—from these L2s non-fungible and thus significantly hampers interoperability. We are advocating for Ethereum to deploy a large number of native L2s, developed and governed by Ethereum's open-source developers. These L2s would be highly interoperable with L1, fulfilling Ethereum's early promise to provide sharding using L2 technology.

Main Stage

Fair money @aboutCircles
Co-founded Gnosis. Supporting @gnosisDAO, @gnosischain, @gnosisSafe, @gnosispay, @cowswap

koeppelmann

Ethereum needs native L2

 The controversial presentation and I kind of expect to make well kind of everyone angry because I'm criticizing to some extent the existing L2s and to some extent the existing Ethereum core roadmap. But I think it needs to be done. So in this role, I'm founder of Gnosis, but in this capacity I'm just speaking as someone who has built for over 10 years now on Ethereum. So we started building on Ethereum when it was still a testnet, deployed one of the first apps a couple of weeks after Ethereum was released, and have continuously been builders in the space. So, let me make a few comments on the previous presentation. I have the absolutely highest respect for Jesse, for what BASE is doing, what Coinbase is doing in general, but I do think the claim to say we are bringing people to Ethereum Coinbase is doing in general. But I do think the claim to say we are bringing people to Ethereum, we are bringing the next billion people to Ethereum, is wrong. We are bringing the next billion people to base. And that is a significant difference. So just a few examples. So Jesse was also talking about the 30% fee that centralized platforms can charge from you, of course, referring to Apple, that is something, for example, Base can absolutely do as well. So if you are an app on Base, it's absolutely in their hands to control how much fees you're paying for a transaction. And of course, they can start charging a 30% cut. And this is typically something that doesn't happen early on. That happens much later. Once a platform is established, a lot of kind of lock-in effects happens. And it often even doesn't happen with the first generation. So ultimately, Coinbase is a regular company and yeah, they are great people. I absolutely, again, have highest respect for Jesse and Brian. But they are employees at the company and at some point they might leave. They might retire. They might do something else. And then another set of people comes. And ultimately, it's a company controlled by shareholders. There's a fiduciary duty to maximize shareholder value. So, oh, we have this asset base. Oh, we can spike up fees. We can take more fees from those applications. And in a way, it's even our duty to do it because we have to maximize value for our shareholders. So my claim is bringing people to those L2 ecosystems is quite different from being on Ethereum. The claim, of course, is always rollups inherit the security of Ethereum. And we see labels like it's secured by Ethereum, you kind of get what you get that you would get from Ethereum. But the reality is absolutely none of those that top L2s actually, yeah, kind of truly inherits the security of Ethereum. So if you look into detail, funds can be stolen here, funds can be stolen here, funds can be stolen here, funds can be stolen here, funds can be stolen. And then on top of that, now we are saying, okay, let's do chain abstraction. So let's make it invisible to the user on what chain they actually are. But in a world where the underlying security is quite, well, different and opaque, chain abstraction actually means, in that case, risk abstraction. There was a nice talk two days ago. So if you're abstracting the chain, you're abstracting the risk. And that's, well, that's dangerous. So at some point, funds might be lost. And then you can no longer abstract the chain. And you need to tell the user, oh, sorry, your funds are lost. But there are even more risks that even L2 beat does not cover. Yesterday there was a great presentation by James showing and again just referring to the presentation showing that on any chain with a centralized sequencer that's again for example BASIC, arbitrage optimism, if you have funds as a user on a with a centralized sequencer that's again, for example, based up from optimism. If you have funds as a user on a money market like Aave and Compound, the sequencer can indefinitely and at zero cost prevent you from accessing your funds, from withdrawing your funds. And you might think, yeah, but you can force include a transaction via L1. No, that won't help. So roughly the idea is you create this withdraw request, and because the sequencer ultimately can control the exact transaction ordering, they can alter the state of that money market so they can just, for a sub-second, borrow too many funds out of that money market so that your request to get funds out or your own funds out fails and then kind of directly after you repay, so they pay zero interest because it's the same time, it's in the same time stamp. So just kind of those kind of things, yeah, in my view, again, truly show if you build on one of those two systems, you're far from inheriting or getting the security that Ethereum promises. So what does Ethereum security actually mean? It means things, it's a culture, it's a process, it's much more than code. So Ethereum security means public core developer calls, public discussions, multiple client implementations, rigorous testing, highest level of promise of backwards compatibility. And kind of those things cannot be derived or exported automatically to an L2. Just because you kind of deploy some code on Ethereum, that process and that culture cannot be derived. Of course, there can be efforts to kind of promote that culture. And to some extent, Ethereum is doing that. And kind of Talik is going around and saying, yeah, if you don't do those things, then I won't call you an L2 anymore. So, yeah, that culture can try to promote this culture. And L2 is, of course, doing a great job in kind of trying to export that culture. But again, it cannot be derived with code. So looking at another data point, again, the claim assets are secured by Ethereum, but the reality is only, or it's the part that is actually of assets that is actually coming from Ethereum is getting less or the fraction is getting smaller and smaller. So most assets, again, this is for example base, but it's very similar on other chains and on smaller chains, it's even much worse. Most assets are actually not coming from Ethereum. So this is here the canonical, the, oh yeah, so back here in time, the canonical bridge was still the dominant. So that is kind of the one, the assets that are actually kind of secured by Ethereum. Now the dominant part are native assets. So those are assets issued on the L2 or on that other chain directly. And they do not inherit, there's not a concept of exiting those to Ethereum. And there are reasons for that. So if you use the canonical bridge and you want to derive that security and you currently want to say, let's say, send a message from Arbitrum to Optimism and get a message back, that transfer takes two weeks. So if you actually use the canonical bridge, it would take you two weeks to do that so a pigeon is faster in transporting a message for most parts of the world so yes, no one is using that mechanism instead we are using new kind of bridges or external bridges that don't inherit the security of Ethereum so if most assets are not natively bridged, and sequencing is also not done by Ethereum, so assets not bridged means from Ethereum not secured by Ethereum, sequencing not done by Ethereum, then the role of Ethereum kind of is reduced to being kind of this checkpointing systems. So here again rollups could choose to how they build blocks and they can either choose to use their own sequencing which means they can do super fast confirmations, they capture their own MEV. But the disadvantage is that they can only not synchronously read into Ethereum. And that is the rational choice to do if you optimize for connectiveness to other chains or for yeah for for TreadFi or you can go kind of what's called based where you let Ethereum do the block building and the sequencing and here you are really optimizing for connectiveness to Ethereum but that's only rational if it's more important for you to be as closely connected to the kind of economic zone that Ethereum is. But the reality is only 1% of value is choosing to do that. So here's my proposal for Ethereum to fix that and to address those issues. And the proposal is that Ethereum itself should develop and deploy ZK proven EVMs, rollups, and deploy 128 equal instances of that that are highly interoperable. And that are truly kind of, if you build on those, you truly build on Ethereum. So what would that mean, being built by Ethereum? It would mean that you don't even think about introducing a multistick. That would be unthinkable that Ethereum deploys something and it has some multistick as the upgrade mechanism. It would mean that we at least have, well, we want to have multi-clients, so we would have at least two independent implementations of, let's say, the proof systems. That's the most important part here. Rigorous testing, thousands of eyes that look at the stuff and actually care about all the details that are often pulled under the rug. So the idea is, yes, we can still have L2s, a wide range of designs. Within that we have based L2s, so L2s that use Ethereum for block production and for sequencing slash block production. But even a subset of those would be native L2s. So truly built by Ethereum, governed by Ethereum. And again, we can here see some things. So reads into L2 are synchronous here. But of course, also the economic perspective is important. So only in the native roll-up, essentially all value of that roll-up is captured by Ethereum itself. Now, one question could be, is that actually sharding what I'm proposing here? No, not exactly. So sharding would be a design where you would have, in a way, multiple L2 instances. And that was kind of still the promise a couple of years ago that we would have 1024 shards. So essentially instances of Ethereum L1. And they would all be kind of live on the same layer. What I'm proposing is not that. But instead, but still something that comes, tries to come as close as possible. Have the L1 and then have those 128 equivalent L2s. But still in this hierarchy. And looking more at it, yeah, some things. So on an L1, you can do synchronous reads and writes, and that's what we all love about Ethereum, this composability. The composability within this larger system would still be pretty strong. So from an L2, the idea is you can still do synchronous reads into Ethereum. So meaning you can execute some code on the L2. You can actually read a contract on L1 in that execution. So let's say in price oracle or anything that lives on Ethereum. And you can kind of even read the function, continue with that result in the L2 process and do things. So kind of the L2 can do things dependent on the state of the L1 so it has immediate transparent access. The other way around, from the L1, you cannot read immediately the state of the L2s. That is asynchronous reads. But writes are actually synchronous. So if you can very well do a transaction on L1 that in the same transaction, so atomically also creates a write into the L2 and affect the state, you will just not in the context of L1 be able to immediately get kind of the result of that state change. So again, the read will be asynchronous. Same in communication between L2s. So you can synchronously make a transaction that affects the state of two L2s, but again, you cannot read from one L2 to the other. So the general idea is stuff that everyone should be able to read, a kind of contentious state might live on the L1, and on all the L2s, they can access the state synchronously, but there can be much more non-contentious state. So all the things I have proposed so far would be possible today on Ethereum without any kind of upgrades or changes to Ethereum. It would essentially just take the Ethereum community to decide to build that. Of course, if we do that, we can actually make those L2s even more powerful. So two things I'm proposing here that can be done. If we make those L2 native, we can make them also native to the economics of Ethereum. So Ethereum, of course, let's say issues ESERV to reward validators to participate in the consensus. In the same way, it could also kind of redirect or direct this issuance towards proving the correctness of all those L2s. Another one is that I'm suggesting that those L2s should have distinct namespaces, so meaning an address should be clearly attributable to one L2 or to one kind of in a way chain, either L1 and L2. And in my view, that is a big problem that right now you have an address and the same address on various chains can mean very different things. So, for example, if you have a safe, then actually the same address can exist on multiple chains, but can have completely different things. So for example, if you have a safe, then actually the same address can exist on multiple chains, but it can have completely different owners. So what I am suggesting here is that we shouldn't have this address collusion. So each L2 kind of uses an additional salt to have its own address space. And if we have that, we could allow sending a message from the L2 with its unique address into the L1 and actually have the message sender on the transaction be that unique address that only exists on the L1. So that allows you to do things like, let's say, you hold a token on L1 by an address or a contract that only lives on an L2. But yeah, some technical details. So here's kind of the spiral I expect or I see already happening if we don't go this route. So if we don't go this route, it means the economic zone that is Ethereum and Ethereum block building becomes less relevant. And therefore it already makes it less attractive to use Ethereum as a block builder or as a sequencer. And again, we already see this today. 99% of the economic value of L2s choose not to be based and not to use Ethereum as a block builder. At the same time, more and more native assets are not coming from Ethereum and are not really secured by Ethereum. Either they are natively issued or they use external bridges. So for those, the economic security of Ethereum also matters less and less. So in total, that means that the relationship between roll-ups and Ethereum really becomes weaker and weaker. And yeah, I'm going so far and say it just becomes a meme. So now, so essentially in my view, that's the crossroad we are in front of. With native roll-ups, we can kind of continue to have Ethereum the most relevant or economic zone. I would claim that should be the goal, to be the most relevant economic zone even in the world. That's a place where prices are... There's also the other perspective. Some believe Ethereum should be a meme or is a meme. And they promote this idea of, yeah, let's say Ether is money. And their perspective might be, if we do native roll-ups, we kind of damage the meme. We damage our collective maybe religion or kind of, and because we create tension within this nice family that we all are. So we disenfranchise those roll-ups so therefore the ETH meme gets weaker and all that economic stuff doesn't really matter. It's just about saying ETH is money and spreading ETH and therefore it's better to not do native roll rollups. All right. So final slide. For whom is it to decide what route we go? Absolutely. For all of us that are here, for everyone who is Ethereum and we are all Ethereum it's not just let's say some core developers or the Ethereum foundation essentially it is yeah Ethereum and anyone can essentially affect changes to Ethereum thank you very much applause applause applause thank you very much. Thank you so much. And while we're still on that note, we have some questions from everyone here. And the first one is, there are 128 identical rollups. Which one should I deploy my DAP on? Yeah. So, I mean, the first important part would be that right now, if you wanted to deploy somewhere right now, well, you either use L1 Ethereum or you have to choose one of those many ecosystems, be it Superchain or AgLayer or something. And this would give you the opportunity to actually just say, okay, I want to be on Ethereum. Now, if you have to choose a particular one, then again, reads and writes within a particular L2 are synchronous. So if there are other applications you want to regularly interact with, then yes, it would be wise to choose that one. If you're fine to say okay, I just need to access, I want this close access to the L1, they are all equally close to the L1, then you really should just choose the rollup that is used the least because that will be the cheapest. Why not implement this on Gnosis? Yeah, I mean, maybe, but I think really, I mean, well, Ethereum is the big thing. So Ethereum has that credible chance to be this most important economic zone. As much as I would like Gnosis to become that, we are not there. I mean, Ethereum is 100 times bigger. And again, I mean, saying that again, so there are all those ecosystems, and Gnosis is one of them, that also tries to do valuable things. And again, I think that's totally valid. I'm just saying, I'm not saying if you come to Gnosis, you'll come to Ethereum. No, you come to Gnosis. And we try to do valuable things there and in the same way I would say other ecosystems again, they are great ecosystems and they bring great value but you should understand that you are building on that ecosystem and not necessarily on Ethereum. Alright, why 128? Why not start with 4 or 16? Yeah, I mean, the idea is really to make it clear that building on Ethereum or building here is long-term viable and that, of addresses costs so I do think, well I absolutely also want to share the vision to bring a billion people on chain and for that Ethereum needs to be much more ambitious and I think 100x increase in effective block space is really what should be aimed for on a timeline for let's say two years, I would say it could be realistic for that and not the 4X or something like that. Alright, the next one wasn't necessarily a question, it was more a compliment. They just agree completely and they're thanking you for stating the hard truth. But then we've got, do you consider this as rugging existing roll-ups? Yeah, I mean, well, rugging, yeah. So I think existing roll-ups, well, already have big time advantage. They are live. They are already built. So that will take at least, again, I think, let's say another two years. But then, yes, if existing roll-ups will not offer anything other than kind of just provide EVM block space, then they will have a strong competition. But I do absolutely think that all those existing roll-ups are great people, innovative people and I think they will be able to kind of evolve and create something or essentially have additional innovation on top and if they do that then yeah they can just be much more kind of basic EVM block space as we know and love it since 10 years. That's what I'm proposing here, to just create much more of that. And then there can be those L2s that are more innovative, that do additional things, that do cutting edge, maybe built-in privacy, maybe some form of other sequencing that is much faster. There are all kind of ways to innovate. So I think, yeah, again, both absolutely can live. All right. Unfortunately, we are out of time. Thank you, everyone, for your questions. And thank you once again, Martin, for your phenomenal talk.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6736e7311b0f83434d194833.vtt