Are Layer 2s Failing Ethereum? A New Proposal Advocates for Native L2s - Ep. 736
38:47 Share

Native rollups means that Ethereum just deploys a bunch of rollups themselves. They would have the full trust and the full brand, essentially, of Ethereum behind them, and they would be developed in a way that's highly interoperable with L1. ♪

Hi everyone, welcome to Unchained, your no-hype resource for all things crypto. I'm your host, Laura Shin, author of The Cryptopians. I started covering crypto nine years ago, and as a senior editor at Forbes, was the first mainstream media reporter to cover cryptocurrency full-time. This is the November 19th, 2024 episode of Unchained.

Polkadot is the original and leading layer-zero blockchain with over 2000+ developers. And the Polkadot 2.0 upgrade will be a massive accelerator for the ecosystem, making it faster, more secure and adaptable. Perfect for GameFi and DeFi to build, grow and scale. Join the community at polkadot.network/ecosystem/community.

Robinhood Wallet, Robinhood's DeFi mobile app, takes no fees on same-chain and cross-chain swaps. Use Arbitrum's Layer 2 to swap with low network fees in just a few taps. Other fees may apply. Download on iOS or Android today.

Yeah, thanks for having me. Hello.

You gave a talk at DEF CON about how you believe that Ethereum should deploy 128 native zero-knowledge layer 2s. And this, you know, created quite a stir. But before we get into your proposal, why don't we start with what problems you were trying to solve? Yeah, so, I mean, I think the current Ethereum scaling roadmap is only accomplishing about

parts of its goals. So the history was, there was initially the idea to have sharding. So kind of say, okay, we have Ethereum, but then we basically just have many versions of it and they communicate nicely together. That never, well, couldn't really figure out how to build that. So the approach now since a couple of years is so-called roll-up centric approach where you have Ethereum

But then you have roll-ups, so roll-ups or layer twos built on top. And that has been a success in the sense that there are now many roll-ups and they are being used, but I would argue they are only...

loosely connected to Ethereum. So essentially they are just separate chains that have some connection to Ethereum. And what I'm proposing is something that is much stronger connected to Ethereum and where for a developer, it feels much more like one chain. And kind of an obvious example is liquidity fragmentation. So

If you today start a new rollup, then, for example, all the tokens, they don't have liquidity. So you cannot trade them there. So you have to build up your own liquidity. You have to have kind of copies of, I mean, first you need to deploy Uniswap contracts or other DEXs. Then you probably also want money markets or something like Aave. And kind of in a way, you have to replicate everything that Ethereum has and then build up your own liquidity there.

And in an alternative approach, you could ideally just tap into or kind of natively communicate with Ethereum, but still have scaling benefits. And that's what this proposal tries to address. All right. So tell us what your solution is. Yeah. So rollups today, again, are somewhat separate chains that have different

some form of how you can communicate with Ethereum and most importantly, bridge assets there. But other than that, they operate fairly independent. So yes, there are some mechanisms that the roll-up eventually finalizes or it stayed on Ethereum. And there are ways that you can force include a transaction from Ethereum

to the roll-up but in general kind of they can progress differently so there's a roll-up that they usually have very fast block times and then there's ethereum and and the two are just independent chains in that world and that's kind of the first thing it's called or that is already a concept that's yeah out there it's called based roll-ups so in that world um

the rollup progresses in sync with Ethereum. So the rollup always only does a new block when Ethereum also does a new block. And actually, Ethereum, in a way, builds the block for the rollup itself. So Ethereum has layer one transactions, but then they have the so-called blob data that

that includes the transactions of the rollups. But in the kind of traditional rollups, they usually kind of just build the transactions and then sometimes later they put those transactions minutes later, 10 minutes later, all in those blobs. In those based rollups, the transactions that are

in the Ethereum block are essentially immediately executed. So there's no time delay, but on the other hand also means you cannot go faster than Ethereum.

So that's kind of the first important piece of that construction that I'm proposing. And there are some attempts of this already. There are one or two based roll-ups. Then I'm...

Essentially saying we need or Ethereum should go one step further. And that is really the question of who is developing it and to what extent can you trust that or can you trust them? So the idea here is trust.

Okay, we could have based roll-ups and again, the idea or the ideal world would be that then it almost wouldn't matter if you have the asset on the L1 or the L2, they can super quickly move and they are essentially equal. In reality, if such a roll-up is developed by

some unknown or random team, then for a developer, it's still a significant decision to say, can they trust that code? Can they trust that team? Because building those roll-ups is a complex thing. And so

you essentially have another form of fragmentation. And that is kind of this risk fragmentation that you have now, let's say four or five different roll-ups. They might all be

theoretically similar, but practically, let's say they're just developed by different teams, different standards of how many security audits have been done. So those are important things. And that can still mean that an asset on one chain is essentially different than an asset on another chain, because with one, there's simply a higher risk that there is some form of problem or some form of bug. So what I

what i'm proposing in a way on top of this idea of based um roll-ups is very simple to say ethereum as a community and as as as developers as open source developers that currently kind of create ethereum clients that there should be a set of roll-ups that's actually developed and deployed and maintained by that very same developer process and developer community

And that would, yeah, dramatically...

Yeah, essentially improves the trust or the, I mean, it's not only the trust, it's basically saying if Ethereum would do it, then it would be done properly. So Ethereum would not deploy an L2 with some form of multisig. How it's basically currently all L2s have some form of upgrade mechanism and that's also kind of needed, right?

because Ethereum itself is changing and will be changing. And therefore, it might be necessary that you need to upgrade a roll-up on top of Ethereum. Someone needs to have the right to upgrade that. And as long as... And the way Ethereum updates on itself or Ethereum updates itself is through those kind of hard forks that are done roughly once a year now.

And here, that would be another advantage of those native rollups or what I call native rollups. So rollups developed by Ethereum itself, that upgrade process could also be done in the same way as Ethereum update is upgraded. So the core message is here is those rollups wouldn't have any...

yeah, smaller owner set like a like a multi-sig that has the right to upgrade them, but instead they would upgrade by a regular Ethereum process. Yeah, it's interesting because people always say that the layer twos are secured by Ethereum, but basically what you're proposing, these particular layer twos would, they would have

Much greater security just by virtue of going through the same process to even be deployed. One other piece of this is you're proposing that there be 128 native layer twos. Why that particular number as opposed to, for instance, a smaller number?

I mean, the goal is simply to say, to make Ethereum block space that is in high demand and of course, with the consequence that transaction costs are really high.

create as much as possible of that block space. The number 128 comes from the limitation that Ethereum still would have even in that design. So in general, the goal would be to get that number as high as possible. So in early sharding, in

In early charting proposals a couple of years ago, there was even talk about 1024 equivalent kind of Ethereum L1s. So I would like to go even to that number. But the bottleneck that is still there is data availability or blobs. And the 128 would already...

only make sense with an increase of blob space. So as long as we have a very limited number of blobs, currently essentially just three per block, even the 128 couldn't really be supported. But increase of blob space is already in discussion. And with that increase, the 128 would be feasible, that number.

And why are you proposing that these be ZK roll-ups or zero-knowledge roll-ups as opposed to optimistic roll-ups? Right. So the big advantage of ZK is that you can much faster prove the correctness of that roll-up. So in an optimistic roll-up, essentially you say, okay, here's my state. And then you need to give everyone time, knowledge,

to challenge that state. And there is a debate of how long that time should or needs to be. In the optimistic roll-ups we see today,

say, optimism, arbitrum base, they even use a time window of seven days. You could certainly reduce that time, but you need a sufficient or you need some somewhat large time. I mean, at the very least an hour, probably even a day or something like that to give everyone time to challenge that. And that essentially means that

that if you want to do a transaction from the roll-up back to Ethereum, you basically need to do the transaction, then you have this state, and then you need to give that time for everyone to challenge that state, and only after that time has passed, the transaction can hit Ethereum L1.

In a ZK or in a rollup where you prove correctness, the time it takes you to go back from the L2 to the L1 is just the time that it takes you to generate that proof. And here we are already in a range of minutes. So it's possible to say...

You do this transaction, you create this block, and minutes later you have this proof, and then immediately that allows you to execute the transaction on the L1. We are even on a path to be able to reduce that proof time to seconds.

There is technology to create specific hardware that is just optimized to ASICs, kind of like you have ASICs for Bitcoin mining. You can have ASICs specifically for those proof generation.

And if we get to that point, it would even be possible to generate the proof within a block, within the currently 12-second block time. And that would be really the ideal case because in that world, you could send a message from or do a transaction from the L2 or on the L2.

immediately proves the correctness of this L2 state transition. And then essentially in the same block, one block later, execute that transaction on the L1. And that really kind of goes back to what my starting point was. My starting point was to say, okay, instead of having different L2s that are essentially just

kind of loosely connected to Ethereum, but essentially are their own independent chains. It would, for developers and for Ethereum, be much better to have essentially one chain where assets and tokens and users can move extremely fast around and you can, to a much larger degree, even abstract away the idea of

whether you are on this, kind of in those 128 rollups. Yeah, the goal would be that, yeah, you could completely abstract it away that you are on a particular two of those many. Okay, and would any of those rollups be privacy preserving or no? Yeah, so no. So I think this is...

So the idea here is to really just say, well, we have Ethereum L1 block space and it's in high demand and we just want to create more of it. So it would really just have the same features of Ethereum. And I think that it also connects to one of the questions I got for the talk. What about all the other rollups that are currently being developed?

And here my answer would be, yeah, it would probably mean that those roll-ups would need to do some things on top of just providing regular EVM block space. And here one possible direction could absolutely be, yeah, be privacy preserving. So for example, there's AdStack and there are a bunch of other roll-ups that go in this direction. And that would still be, yeah, kind of valuable information

work that could or should be done beyond this proposal. Okay. And then one other thing is, and you may have just briefly touched on this, but generally when people talk about chain abstraction, that's like designing the product in a way where the user doesn't know what chain they're using. And people typically say that that creates a better user experience, but you don't seem to think that that's a good idea. So can you explain a little bit more about why that is?

Yeah, I mean, so the issue in the current roll-up landscape is that because, yeah, roll-ups are...

have widely different security standards. So kind of on L2 beat, I think you find over 100 different roll-ups listed. And the term roll-up really kind of means almost nothing. So the security, some are just literally controlled by a single key. And others, of course, take security very seriously.

have various processes, have audits and so on. But if you basically now say we should abstract it away from the user, whether they are on this

quite secure, extremely secure chain or on a chain that's very insecure, then, yeah, then kind of chain abstraction turns into wrist abstraction. And that's certainly not a good thing. And of course, it leads to the situation where then

If a user is eventually affected by those risks because one roll-up kind of blows up in some form, of course, then you can no longer abstract that away. And then you have to tell the user, well, sorry, you were just on a chain that was very unsecure. So yeah, long story short,

Chain abstraction is, of course, a good... I mean, it would be ideal that the user doesn't have to care about that. But as long as there is no standard for security, I think it's dangerous to then abstract those risks away. And I think, again, the only way to really have or to really allow...

So, yeah, this chain abstraction is to say, OK, we have this set of rollups, let's say 128 that we know follow the same rigorous process that Ethereum is following because it is developed by the same community, by the same process. And yes, then you could actually abstract it away.

All right, so in a moment, we're going to talk about the follow-on effects if this is adopted. But first, a quick word from the sponsors who make this show possible. Polkadot is the original and largest layer zero blockchain with over 2,000 plus developers. And the anticipated Polkadot 2.0 upgrade will be a massive accelerator for the ecosystem. Upgrading the infrastructure with eight times higher transaction throughput and twice as fast block times, perfectly tailored core time for the needs of every protocol, and

Trustless bridges internally and into Ethereum, Cosmos, Near, Binance Smart Chain, and revised tokenomics and the implementation of a token burn to reduce inflation. Perfect for GameFi and DeFi to build, grow, and scale with one of the most active crypto communities in the space. Polkadot recently announced a partnership with Mythical Games, bringing top games like NFT Rivals with over 650,000 players and 43 million transactions to pave the way for GameFi and the Polkadot ecosystem.

Get your Web3 ideas to market fast with economics that work for you. Think big, build bigger with Polkadot. Join the community at polkadot.network.com.

Big news for DeFi traders. Robinhood Wallet, Robinhood's non-custodial wallet mobile app, has partnered with Arbitrum to make access to L2 swaps easier than ever. Enjoy gasless swaps and cross-chain swaps on Arbitrum and other networks. The best part? Robinhood Wallet takes no fees on same-chain or cross-chain swaps.

Other fees may still apply. With Gasless Swaps, you can pay network fees with the same token you're swapping instead of ETH. Cross-chain swaps make it incredibly simple to swap crypto without any manual bridging. Download the Robinhood Wallet mobile app today on iOS or Android and join people in over 140 countries exploring Web3 with Arbitrum.

Overwhelmed trying to manage your crypto investments? Introducing iYield, a free financial planning tool for crypto natives.

Unlike portfolio trackers, which just get the value of your assets, iYield reveals your full financial picture by also supporting debts, incomes, and expenses in both crypto and fiat. The dashboard compares returns from your DeFi positions side by side. This removes uncertainty and provides clarity to help you make better decisions.

iYield supports a growing list of over 16,000 tokens across 16 blockchains and 40 of the top DeFi and staking protocols, as well as all fiat currencies. Ditch the spreadsheets and take control of your financial future. Get started today at iYield.com. Back to my conversation with Martin.

So one of the benefits of your proposal is that it would likely have better composability. Can you explain how composability would be improved in the system you're proposing?

Yeah, so it would allow developers to create applications where a user can do a transaction that is affecting both state on the L1 and the L2. And so, yeah, just to give an example, it would allow you to do a trade that... Or it would, for example, allow you to bridge assets to the L2 and in the very same trade already use those assets to then...

do a trade on the L2. And that's quite different from today's world and where you have to bridge. And then usually it takes at least a couple of minutes, sometimes much longer. Then you have to kind of continue the process. But it would go even further. So on the L2, the idea is that there the state of

of the state of the L1 of Ethereum is available. So for example, if you want to deploy some protocol on the L2 that needs to read

oracle prices, then you wouldn't need to separately kind of somehow get those in that L2. You could synchronously or you could just read from the contracts that are on the L2. You could natively just read into the L1 space. Another kind of very practical consequence of all of that is

Just an easy way to understand that currently this high level of composability is not given is to just look at a protocol like Aave, where you have currently separate instances of Aave on Ethereum, but also all the big rollups.

And you will find that the very same assets, let's say UCC, have quite different interest rates. So on whatever, on Ethereum it's currently 7%, on Base it's 12%, on Arbitro it's 9%. And that shouldn't really happen if it was kind of one ecosystem. If it was one ecosystem, then all those rates would immediately kind of even, or you basically would have

one rate and that one rate would have the deepest liquidity. So kind of just the, the, the, yeah, the, the fact that those different rates exist show already that there's all kinds of friction to move assets across those chains. Okay. Yeah. I saw in that discussion that because you had tweeted about that, that you were saying that there could be one unified liquidity pool on the L1 that any L2 could tap into. So basically it would sort of be like, yeah,

like Uniswap that was deployed on the L1 could be accessed by any of these L2s that you're proposing? Right, so...

With something like Uniswap, I think it's maybe a bit harder, but even there, you could say the main liquidity is on the L1. The L2 might have thin kind of buffer liquidity, I would say, where if it's a really small trade, then it doesn't need to touch L1 at all. It can basically just take the price from the L1 and kind of

and use some form of buffers to execute this trade immediately on the L2. But if the trade is large enough that it kind of needs the L1 liquidity, then it would need to, or then you could say all the trades that are, all the, yeah, all the buys and the sells are

that kind of match each other, that you can kind of directly settle on the L2. But the remainder, if there's more buying or more selling, then the remainder you would settle in one transaction into the L1. So on the L2.

Okay. Yeah, it definitely would be a big benefit, I think, to a lot of users. So you also said that your proposal could be implemented without a single change to Ethereum. And if that's the case, then it sort of seems the community just would need to get behind this. So I was wondering what the reaction has been to your proposal.

Yeah, so maybe just to first comment on that it's possible without change. So yes, it is possible without change to create base rollups. And of course, it is possible for the Ethereum developer community to deploy those. Of course, if...

If Ethereum would develop them itself, then there are, of course, there are changes to Ethereum itself that could be done that would make this proposal even much stronger. So there are just one idea or one concept is that the idea would be that on those L2s, you would...

make sure that they have distinct addresses. So currently you can have the same address on different L2s and that can create some form of problems and confusion. So there is already a proposal to have chain specific addresses and

If we are going this route, then of course it would be nice if it's actually possible to use your L2 address to make a call into L1. And there are some details where small improvements or small changes to Ethereum could make this proposal even stronger.

Now, to your question on the reception. Yeah, I think it's mixed. So I think it was certainly a proposal. It's certainly not the mainstream Ethereum roadmap yet. So...

Currently, the idea is still, okay, we will just have all those external layer twos and maybe even some will decide to be base. So kind of to use Ethereum as a sequencer instead of having their own sequencer. And yes, I'm now going a step beyond and I'm saying that's not enough.

that will not solve this fragmentation that, in my view, Ethereum is suffering from. Yeah, I got a bunch of people saying that's exactly right, that's exactly what we need. But overall, I remain somewhat... Well, it currently doesn't look like that this proposal will get kind of

enough support for it to be implemented, but I will certainly, at least for a while, try to push it. And what is the opposition? Hardly have seen really arguments against it other than, yeah, existing L2s might not be happy about it or...

I have not really seen argument against it, but kind of just not enough support. So, I mean, just in general for Ethereum, there are hundreds of open proposals of how to improve or how to change Ethereum. And quite often the default thing is not necessarily that a proposal faces specific opposition, that someone says that's for those and that reason bad, kind of the default thing.

The reason why a proposal gets not implemented is simply because it doesn't get enough support or attention. So I think that's really the key question. Can you get enough momentum behind it? And then there's a chance that it will be implemented. Otherwise, it will end up in the long list of not implemented ideas.

Well, you know, as you mentioned, there are like the only opposition that you've seen is from existing L2s, or I don't know if it's from them, but it's about the fact that these other ones exist. And that's the only kind of natural constituency that I can think of that would be against this proposal. So let's say that it were to be implemented. What effect do you think it would have on these existing L2s?

Yeah, I mean, I think as I said previously, they would certainly need to do some form of innovation beyond offering regular Ethereum EVM block space. Because if you just do that, then people will probably kind of just say, okay, well,

Here's Ethereum block space directly coming from Ethereum, super nicely connected to Ethereum layer one. Sure, I will go there. Why should I, in a way, use a smaller ecosystem or kind of have some form of additional platform risk unless I get a specific upside beyond just having, yeah, EVM block space?

Okay. All right. Well, I guess we'll just have to see how it happens. Do you have any plans for trying to drum up more support or was it just the presentation? Yeah, I think I will see. I mean, there is certainly, I think there is a larger kind of debate in Ethereum, whether or not Ethereum is on the right track.

Certainly, people have noticed that Ether has kind of somewhat underperformed, at least in relationship to other, let's say to Bitcoin and a few other blockchains. I think from my perspective, a big challenge for Ethereum is that it's not...

obvious or it's in my view it's not clear what ethereum wants to be and there is there is one um one side that tries to a little bit go the bitcoin route and essentially say ether is money and

If that's your idea of why Ethereum should be valuable, because it's used as money and kind of programmable money, all those ideas, then it almost doesn't matter that much how much capacity the blockchain offers and everything.

what kind of let's say the total transaction fees are because then you can always say okay well bitcoin has even way less capacity and they are super successful with kind of just being money in a way or just claiming to be store of value and something like that so

If that's your goal, then maybe not really that interesting of a proposal. But I'm more in the camp of saying Ethereum's main goal should be to be a platform for developers.

where developers know, okay, this is a credible, neutral platform. I can build applications here that last or can last for a long time, for decades. And I don't have the risk that the platform will just be turned off or just kind of changes in significant ways.

And in that world, of course, the biggest problem is that Ethereum so far scales poorly or kind of has reached its capacity since a long time. And we need ways to improve the capacity. And again, ideally...

to do so without losing the network effects of what makes Ethereum already attractive. And that's really kind of the liquidity and the contracts and kind of everything that is...

is happening on L1. So in my view, if there would be consensus to say Ethereum really kind of what counts is how many transactions is Ethereum able to process, how many fees is Ethereum generating in total out of all those transactions. And that's really kind of also what gives ETH value because let's say those transaction fees are burned and in some form that

is what defines ESO, then I think it would be much clearer to say, well, that's at least the direction we need to go. And we cannot just outsource all of that additional block space creation to third parties, essentially, which are essentially current L2s. We need to do that ourselves.

And so actually, one last question. It sounds like you are in the camp of L2s being parasitic to Ethereum. Would that be correct? Well, I mean, no, not really, because I would say, I think, I would say,

Ethereum L2s created the value and therefore it's totally fair that they captured the value. So I would just say kind of if Ethereum wants to capture value from L2s, it needs to develop them and deploy them itself. And Ethereum, I mean, I would say Ethereum is not parasitic to L2s.

So it is not capturing the value they created, but that's simply how it should be. And if Ethereum wants to capture value from L2, then it needs to also do the work. Okay. Well, I would say that means that you do think that they're parasitic. But anyway, well, Martin, it's been really fun chatting with you. Where can people learn more about you and your work? Yeah, I'm pretty active on Twitter, at least.

Always, if I have something new to push, then I'm using Twitter as the main medium. And your handle is? Yeah, Koppelmann. So K-O-E-P-P-E-L-M-A-N-N. Okay, perfect. It's been a pleasure having you on Unchained.

All right. Thanks for having me. Thanks so much for joining us today. To learn more about Martin and his proposal for Ethereum native layer twos, check out the show notes for this episode. Unchained is produced by me, Laura Shin, with help from Matt Pilger, Tjuan Urbanovic, Megan Gavis, Pema Jumdar, and Mark Akuria. Thanks for listening.

Unchained is now a part of the Coindesk Podcast Network. For the latest in digital assets, check out Markets Daily five days a week with host Noelle Atchison. Follow the Coindesk Podcast Network for some of the best shows in crypto.