What's the Best Way for Ethereum to Grow? Justin Drake and Martin Köppelmann Debate - Ep. 740
01:26:30 Share

I'm personally not too worried about Solana. I think the golden age of Solana has happened. And from now on, I think that the high performance applications can come to Ethereum. My take is that the big, big problem is interoperability. And I don't see a solution to that for the current state of rollups simply because they are very heterogeneous.

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 of Forbes was the first mainstream media reporter to cover cryptocurrency full time. This is the November 26th, 2024 episode of Unchained.

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.

Overwhelmed managing crypto investments? Meet iYield, a free financial planning tool for crypto natives with automatic DeFi yield tracking. Unlike portfolio trackers, iYield provides a complete financial view of assets, debts, income, and expenses in crypto and fiat.

Ditch the spreadsheets and take control at iYield.com. Polkadot is the original and leading layer-zero blockchain with over 2,000+ 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.

Today's topic is the Ethereum Beam Chain and Ethereum's broader roadmap. Here to discuss are Justin Drake and Martin Koppelman. Welcome, Justin. Martin. Hi, Laura. Thanks for having us. So there's a lot of discussion and controversy nowadays about the roadmap for Ethereum. And there's been this backdrop this whole year about whether L2s have been parasitic to Ethereum.

Obviously, people are watching the ETH-BTC ratio just going down, hitting new lows not seen since 2021. And meanwhile, there's also been this trend of Solana outpacing Ethereum on many metrics this particular cycle, especially price, but also just generally in terms of mindshare amongst newbies.

So against that backdrop, DEF CON took place in Bangkok a few weeks ago. And Justin, you presented your plan for what you called the Beam Chain. It sparked a little bit of controversy. Martin, you also presented an idea for native Layer 2s.

perhaps a little bit more well-perceived. Maybe I didn't read everything. I'm not sure. But before we get into all the details on your proposals, I am just curious to hear you both describe what problems you think Ethereum is facing right now that are most critical and that need to be resolved. I'm just kind of curious to see how you're thinking about this, whether similarly or differently. Justin, why don't we start with you?

Sure. So Ethereum is a very ambitious project. And in some sense, it's trying to do many different things. And one mental model that I have is that the L1 is trying to provide the foundations for the internet of value. It's trying to be maximally robust and secure. It's competing for moneyness. In some sense, it's competing with Bitcoin. And then on the other hand, you have this other lane, which is a much faster lane, which is the L2s.

which is trying to compete for growth, for user acquisition, for activity, for fee revenue. And in some sense, you could say that it's competing with Solana.

And I think what needs to happen is both of these tracks need to be accelerated. The good news is that we're making tremendous amounts of progress on both tracks. The first one, sorry, the second one, I guess, the L2s, we've had major unlocks recently with this notion of pre-confirmation. So one of the things that Solana prides itself with is this notion of fast slot times. It has 400 millisecond slot times.

And now Ethereum actually has a roadmap and it has already partially delivered on this roadmap to offer better UX than Solana. And this is done through this notion of pre-confirmation. So for example, on Arbitrum, as a user, I send my transaction to the Arbitrum sequencer and I get a pre-confirmation within 250 milliseconds. Something very similar is going to happen with Unichain.

And we even are going to have the base roll-ups that have this native 12-second slot times also have pre-confirmations. And what I expect will happen is that the latencies will go down to zero over time. What is today 250 milliseconds will go down to maybe 10 milliseconds or even less than that. Now, the other big metric that Solana prides itself with is this notion of throughput, which

How much gas can it process per second? And the good news is that Ethereum now has really strong foundations for sustainably scaling the amount of execution. If you go to this website, rollup.wtf, it will show you how much gas is being processed on the overall Ethereum ecosystem, which is the L1 plus all of the constituent L2s.

And what we're seeing there is that all of the L2s combined have roughly 100x the throughput of the L1. And what I expect to happen is that over 2025, this will grow roughly 10x to 1000x. And then in 2026, maybe another 10x. And it can just grow as much as there is demand.

And this kind of horizontal scaling is very much sustainable. Whereas on the other hand with Solana, I think they're going to hit a bit of a brick wall. And the reason is that they're trying to run everything on these servers and the servers are already kind of maxed out. And there isn't an opportunity to grow 10x, 100x, 1000x or even more because Solana

The only way that they can grow, at least using the current path that they're going down, is vertically as opposed to horizontally. Now on the first lane, which is the L1, that is trying to compete on strong foundations and security, one of the problems that I identified was that we have an extremely ambitious roadmap.

that, in some sense, is mismatched with the pace at which we make upgrades to DL1. So the way that we traditionally do upgrades to DL1 is through a hard fork every single year. So this is a whole process where we make a proposal, which is called an EIP. This gets discussed in all core devs. And then there's a whole process of dev nets and test nets and

And we can only go through this whole ceremony, if you will, once per year. And we can only be so ambitious in what we push in these forks

talks, for various reasons, partly because there's a lot of different clients and there's a lot of overhead in the governance, if you will. Basically, what I'm suggesting is to try and accelerate the timelines by batching multiple upgrades into one and basically try and complete the entirety of the Ethereum roadmap on a relatively fast schedule of four or five years.

And so what this would allow us to do is basically reach maintenance mode, if you will, for Ethereum this decade and basically enter what I call pre-ossification, which is this phase where Ethereum no longer has to do big changes and it can start having a similar mentality potentially to Bitcoin and kind of be considered done.

But the nice thing about this pre-ossification is that it would be healthy ossification in the sense that we have a design which we believe is optimal and there's no need to change it because it is optimal. And this is very much in contrast to Bitcoin, where, in my opinion, they have unhealthy ossification for reasons other than technical optimality.

Okay. So Martin, obviously we want to hear your kind of view on what the problems are with Ethereum, but also in your answer, you might even want to respond to some of what Justin just said. Yeah.

To me, the big problem that Ethereum is facing is losing its interoperability. And essentially what I'm seeing and what I'm concerned about is that all the rollups that are popping up are really essentially separate chains.

And what made Ethereum great and why people loved to be on Ethereum is that there is activity, there is liquidity, there are, I don't know, there are all kinds of protocols. And if you as an app developer kind of deploy on Ethereum, then you can already rely on having DEXs, having money markets, having NFTs, having the naming system and all of that.

But the reality is, if you deploy your application on a new roll-up, then you can by no means access all of that state and all of those contracts. So I would say, sure, we can look at the aggregated number of gas of

what all those L2s together produce. But in my view, that's a fairly meaningless metric because they don't really create currently strong network effects.

It's almost, I mean, that's a bit of an extrication, but you could say, okay, that some chains and they, let's say they timestamp onto Bitcoin. They kind of once in a while post there. Then you could say, oh yeah, all those chains really are kind of an aggregate. That's Bitcoin and that's all great. But in reality, I mean, they could timestamp into Bitcoin, but they can also not do it. And I feel like it's quite similar to the development currently with Rollup. So yes, they currently do

kind of timestamp or kind of maybe even checkpoint into Ethereum. So yes, they have some connection to Ethereum, but ultimately that connection is weak and it's not really one shared economic zone where you would have and kind of just one way to kind of make this very visually or kind of very clear is that on Ethereum you will

never see the same token have a different price for more than 30 seconds or even one block because immediately someone will do the arbitrage and one token has one price on Ethereum. One token does not have one price across

all roll-ups. And that is also kind of clear because it takes up to a week to transfer a token from a roll-up back to Ethereum. And you see the same thing with interest rates. So if it would really be one economic zone, then you would expect the interest rate

of USDC on Aave to be the same. In reality, it's widely different on Ethereum, on BASE, on Arbitrum. It's sometimes four or five percent different. And again, this just shows we have a fragmentation mess in my view. And the way to turn that around would be to say,

We need roll-ups that have strictly the same security standards because only if you have really kind of the same security, then things are... Only then you can be frictionless, interoperable. Otherwise, you always need to have additional layers of kind of dealing with that risk and you essentially don't have really fungibility.

And that's my big criticism of the Ethereum roadmap, that this level of interoperability, that there's not enough focus on that. Justin, can you address some of what he said? Yeah, absolutely. So I'm so pleased that Martin has said this because this has been my message for all of 2024. I've been communicating that I believe that a lot of the rollups today are siloed and they break down composability.

But I'm much more optimistic. I think that we're in, like, directionally speaking, on the trajectory to fix the fragmentation. What I expect will happen in the medium term is that we're going to see the formation of clusters. So we're going to see different ecosystems, maybe the super chain, the elastic chain, you know, maybe the polygon ecosystem. Yeah.

I mean, AgLayer is meant to be infrastructure that is credibly neutral, that could work Ethereum-wide. But you're right, like Polygon as an ecosystem could form as a cluster. And within those clusters, I think we're going to see the emergence of network effects through, for example, shared sequencing, shared standards, shared deposits and bridging, maybe like shared blob packing, etc.

shared proof verification, basically lots of sharing. And I think what will happen is that eventually once we do these experiments around sharing infrastructure around the clusters, we will have best practices that will emerge.

And we will have also the emergence of infrastructure that is credibly neutral enough to serve Ethereum-wide as opposed to cluster-wide, because eventually that's what we want. And one of the things that I've been advocating for most of 2024 is this notion of shared sequencing, which is Ethereum-wide. And I believe there's only one candidate, which is the L1 sequencer, also known as based sequencing.

The really cool thing about the base sequencer is that it doesn't introduce a new token, it doesn't introduce a new security assumption or a new brand. It's just plain old vanilla. As such, direct competitors, for example, the super chain and the arbitrage ecosystem can feel comfortable mutually joining this neutral territory and playing win-win games, basically positive sum games where they...

increase the size of the pie, because as Martin said, there's these network effects at play. And ultimately, this will be very, very healthy for Ethereum. I mean, my response to that is that I think Ethereum should try to create that, what I would call economic zone or that cluster directly for Ethereum right now.

But to me, it's two things. So yes, base rollups have, in principle, the advantage of being able to synchronously interact with Ethereum's state.

The problem, in my view, is that currently Ethereum is on track of becoming, yeah, in a way, less and less relevant. So for rollup, you essentially have that choice. You can essentially either be your own economic zone

And there you have, of course, you have some advantages. You can capture your own MEV. You can potentially be faster. You can, if you're faster, that makes it more interoperable with traditional finance. If you want to be more interoperable with Solana and so on, then kind of those would all be reasons to be your own zone. The reason to kind of choose to be based and to be part of the Ethereum kind of economic zone, the main reason is

the existing liquidity and activity on Ethereum L1. And currently we are in a trend where if you just look at how much liquidity is there on L1 and how much liquidity is there on other chains in other zones, then currently L1 is losing in this ratio at least.

So I would say we are currently on a trajectory where it becomes less likely for rollups to be based. So I would say to change that, and I certainly would like to change that, I think Ethereum first needs to continuously grow.

try to push the limits of L1. I mean, I think kind of there's now since three years, we are at a 30 million block gas limit. And I absolutely think even kind of increasing this to 45 million, 50 million is simply something that has urgency and needs

It's too much ignored. But then, of course, also have a push for those based roll-ups. And here is what I would also say we need to go one step further than kind of just say they are based, so just use the sequencing approach.

Here, I would say, in reality, roll-ups right now have still a wide range of trust and security assumptions. So as a debt developer, you really need to carefully decide, or it's not an easy decision to say on what roll-up to

do I go? So ideally, as a debt developer, you wouldn't even have to choose for a specific ecosystem. You could just choose Ethereum. So my proposal here is that there is a set of standardized

highly tested, highly secure roll-ups that essentially just have the security standards of whatever Ethereum is doing. Ethereum would never do something where some multisig has still the right to upgrade. Ethereum would never push a major release that's not properly tested, that doesn't have at least two clients. So that culture of security, of ultimately brand, I guess,

Having roll-ups that have essentially the Ethereum brand and that allow debt developers to say, I don't choose a specific sub-ecosystem, I can just choose the original brand, in a way, Ethereum, that's what I think is necessary to make sure that this Ethereum L1 economic zone with its extension of based or what I call a native roll-up is, again, strong enough so that then in the second step, yes, then in the second step,

Also, the super chain and the and the layer and elastic chain and whatever, whatever those are, have a strong incentive to say, oh, wow, there's so much liquidity and there's so much stuff going on here. We can certainly not afford to do that. It takes us seven days to to do a transaction to this super interesting and relevant economic zone. We want to be as close connected to it.

Yeah, actually, I do have a few questions. Frankly, like I feel like four came up in my head. I don't know if I'll remember them all. But one would be just that, you know, just in the way you talked about these different ecosystems. To my mind, yeah, it wouldn't necessarily solve the fragmentation. Like obviously it would reduce it. But if you still have these different choices, the elastic balance.

you know, chain the super chain, the ag layer, et cetera, then it does create that fragmentation. But also I think when I'm hearing, if I'm, you know, just thinking about what Martin's proposing and what you were talking about, it kind of feels like actually,

in a way they could all coexist. But I feel, and this is just, you know, I'm not even like a technical person. It's just, I'm just absorbing this. And I, it feels to me like what might make more sense is in the short term to do something like what Martin is proposing. And obviously someday when Ethereum is bigger, then like having these different ecosystems might make sense. But like in the short term, what is happening is that this economic economicization

activity is moving away from Ethereum, which is like kind of causing some of the issues in the, frankly, at least from my timeline, pretty negative sentiment around Ethereum. Yeah. So, I mean, one thing that I'll clarify is that I'm proposing all of the things. I'm proposing that we basically improve Ethereum in all the ways possible.

But for what you said about wanting to go with based rollups rather than his proposal for ZK native rollups, why are you making that choice? Okay, so I guess I need to clarify what are the definitions. So if you want to be attached to the Ethereum ecosystem, you need at minimum to basically settle on the chain. And that means that you become an L2. If you don't settle on Ethereum, then that means that you're an L1.

Now, let's assume that you are an L2. Now you have three different choices in terms of being proximate to Ethereum. Choice number one is whether or not you consume Ethereum DA. If you do consume it, you're called a roll-up. If you don't consume it, you're called a validium. The next choice is, do you want to consume the sequencing?

If you do, you're called based. If you don't, you're called non-based. And then the third choice is, do you want to consume the L1 virtual machine, the execution layer? If you do consume it, you're called native. If you don't, you're not called native. These things are totally orthogonal and not mutually exclusive. So you can be based and not native, native and not based natively.

These are up to the choice, I guess, of the developers. And what I'm proposing that we do is that we at least provide the option to everyone to be based and also be native. The good news for being based is that you don't need a hard fork. This is something that you can do today. And we already have one base roll-up, it's called Tyco. And I think in the last few months, the Ethereum ecosystem has started to appreciate the advantages of being based.

The main downside of being based is that you inherit the 12-second slot time. And so in order to improve the UX, you need to go back to what I was talking about at the beginning, which is this notion of pre-confirmations.

And the base pre-confirmations are harder to do than the pre-confirmations on Arbitrum because they rely on crypto economics. The basic idea is that the L1 validators would post collateral and when they make these pre-confirmation promises, they would get slashed if they were not to not honor those promises, which is very, very different to the way that the pre-confirmations on Arbitrum work, which are reputational pre-confirmations, where

where basically Arbitrum is pinky promising that they will include your transaction in the next block and that pinky promise arrives to you within the 250 milliseconds.

So I think the base ecosystem is on a very good trajectory. We've just had the sequencing week just before DEF CON. There were 30 different companies, 60 different individuals who came together to work on standardization of the infrastructure around base sequencing. And there's now dozens of companies that are either building base rollups or building infrastructure for the base rollups. Now, the native rollups are actually much harder to pull off. And the reason is that

To pull them off, we need to snarkify the whole EVM chain. Now, the good news is that in recent days, we've had a massive explosion of what are called ZKVMs. So these are pieces of technology that allow for any developer around the world to make use of the power of snarks without actually being an expert in snarks. And...

These ZKVMs basically allow us to take the existing execution clients, so that would be Geph and Ref and Bessu and Aragon and all the other execution clients, and basically allowing them to compile down to these ZKVMs and at the end basically get these succinct proofs that allow resource-constrained entities to verify the correctness of these EVM blocks.

Now, once we've snarkified all of the EVM chain, we can expose within the EVM a ZK EVM precompile. So it becomes a little bit abstract here, but basically what we're doing is that we're giving roll-up ecosystems the choice of

to inherit an exact copy of the L1 EVM, as opposed to having to rebuild their own copy. So if you take the top few roll-ups in production today, you know, there's Base, there's OP Mainnet, there's Arbitrum, they're all trying to be EVM equivalent. So they want to be exact copies, but being exact copies is extremely difficult. And the reason is that they have to reimplement their own fraud-proof games or their own circuits

And these are very complicated systems that will have their bugs, more likely than not. And it also requires governance because every time the L1 EVM changes, they also need to make an upgrade at L2. And that can only be done if you have token governance or some sort of multisig to update the rules of the virtual machine. So once we have this precompile, it will be a one-line code to be exactly EVM equivalent.

And you have the guarantee that you have no bugs by construction and that you will at all times stay in sync with the latest version of the EVM, even when there is a hard fork.

And my criticism is that, so essentially you're saying it becomes very easy to start a roll-up. And my criticism would be as a dev developer, I don't want to start a roll-up. I just want roll-ups because actually I can say this as someone who is also running or not running, but involved in trying to create an attractive chain. It's so much more. So kind of to understand

to make your rollup or your chain attractive, you need integrations like you need block explorers, you need developer tooling, you need, I don't know, Dune, Nansen, ESA scan, kind of all those things. Those are things that define whether a chain is attractive or useful. So as someone who just wants to build an app,

Then essentially Justin's telling me, okay, it becomes relatively easy to do a roll-up. And then you can bid, no, I don't want to do a roll-up with all kind of the requirements of doing a chain. I just want to have a chain or roll-up available and I want to deploy my app there. So now, and essentially the answer is Ethereum is kind of sourcing that problem out and says, okay, there can be many roll-ups that then now exist.

try to build attractive roll-ups. But as soon as they have to do that, then of course they also have to have their own business model. I mean, all those things cost money to attract then, let's say, this developer tooling, support, block explorers, all that. So they have to have somewhere a business model. And to some extent that again means for me as a dev developer, I

I somehow have additional platform risk. I cannot just say I choose Ethereum as a platform. I have to use this specific rollup that has also their own business model. So again, I would say Ethereum should not only think of rollups as their customers. I would say kind of the maker and the Aave and Uniswap are historically the users of Ethereum.

and those users or ENS. And currently all of those are essentially, all of the ones that I mentioned right now are in the process or have already launched their own chains. And I would say that's not necessarily what they wanted initially, but they are kind of forced to do it. And I would say Ethereum should provide just, again, what I call native rollups, slightly different. So standardized rollups,

developed and maintained by Ethereum itself, governed by Ethereum itself. So no admin multisig or something like that, but just governed through regular Ethereum hard forks. And those truly native or credible neutral rollups that don't add additional platform risk for me as a developer is essentially what Ethereum, in my view, should offer.

So in a moment, we'll have Justin respond to Martin's comments there. But first, a quick word from the sponsors who make this show possible. 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.

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.

Polkadot is the original and largest Layer 0 blockchain with over 2,000+ developers. And the anticipated Polkadot 2.0 upgrade will be a massive accelerator for the ecosystem, upgrading the infrastructure with 8 times higher transaction throughput and twice as fast block times, perfectly tailored core time for the needs of every protocol, 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, bills bigger with Polkadot. Join the community at polkadot.network/ecosystem/community. Back to my conversation with Justin and Martin.

So Justin, you know, Martin obviously just laid out kind of why he feels like it's more important to have these roll ups that are native to Ethereum. And, you know, some of what he was talking about does remind me a little bit about that psychology experiment of where when you go to the grocery store, if there's 32 jars of jelly, then you have a harder time choosing than if there's just like five or something.

So I feel like in a way that's partially what he's saying. But then I also agree that some of what he talked about in terms of the codification of Ethereum's processes around making these changes, that process is very well done. And when you have all these different ecosystems, some of them are making different choices. There's varying levels of centralization. And there's just all these different factors that...

You know, basically, I do agree with Martin that probably these other ecosystems don't necessarily come with the same sort of safety and security guarantees that something native to Ethereum would. So anyway, what's your response to what he said?

Sure. So I have a few points. The first one is that I think we need to clarify terminology because we both use the word native for different things. I've been using the word enshrined or native for several years. And the meaning that the word traditionally has is only related to the execution, the virtual machine execution.

What Martin is suggesting has been called for more than half a decade, it's been called sharding, execution sharding. And the good news is that in some sense, these two concepts are not mutually exclusive. Like one is strictly more powerful than the other. The native rollups is strictly more powerful than execution sharding. And the reason is that if you have native rollups,

then you can go ahead and deploy execution shots. 128 of them is what Martin is suggesting.

Just one second. So happy to use a different term. It would still be slightly, in my view, it's still different than charting. So in charting, the idea was that we have 128 or 1024 chains or execution environments that are on the same level. So there's no hierarchy between them. In what I am proposing, there is still a hierarchy. So there is still kind of the L1. And then there are those 100,

128 L2s. And there is a hierarchy because from the L2, you can synchronously read into the L1 or kind of all the L2s also have the state of the L1 available while the L2 does not, sorry, the L1 does not natively has all the state of the, or is not expected to have all the state of all the L2s available. So I'm just saying it's not exactly sharding, but yeah, I'm happy to try to use a different term than native L2s, but it's,

It's close to sharding, but still using the roll-up approach.

Right. So I did watch your DEF CON talk where you kind of made this subtle technical point that, you know, you can only synchronously read, but not synchronously write. I actually disagree with that kind of technical assessment in the sense that... I mean, if we can go to real-time proving, then yes, we can. Right, right. So, but right now we are not quite there yet. I also am optimistic that we can get there, but yeah. And I'm sorry, can one of you explain real-time proving? Sure.

Yeah, the core idea is that you have some roll-ups and you can only go back from the roll-up. So you can do some transactions on the roll-up, then you go back to L1 and the L1 needs to know that this message that's coming from this roll-up is actually correct. And the way you would do that is that you provide proof that all the transactions that happened there

correctly result in the state and this state also results in this message that's now executed on the L1. And now the question is, how fast can you provide this proof? And currently we are talking about maybe a couple of minutes. So we have created this new state, but now it takes us two minutes to create this proof. So essentially it would mean if you want to send a message from the rollup to the L1,

you create the state, but then it takes you two minutes to prove that it's correct. And that essentially means you can only execute the message. So let's say sending a token from the L2 to the L1 would essentially take you two minutes. If we can get the proving time down, and a magic number here is of course 12 seconds,

because we have 12 second slot times or block times for the L1. So if we can get the proving time real time, so kind of less than the slot time, then we can imagine that we do a transaction and at the same time we are doing this proof. So essentially in the next block, we can do the transaction already proof that this transaction results in this state and already kind of

Yeah, kind of then...

further process the transaction on the on the on the l1 so essentially it allows you to then say okay i am i'm moving some funds or i'm moving some tokens some nfts from the roll up to the l1 and in the very same transaction i already can use those tokens to then swap them and that's of course that of course would be a big big unlock and would really kind of yeah kind of

bring us much closer to this goal to have one shared economic zone without interruptions. And yes, we might be able to get there in two, three years.

I think it's realistic. Well, I think, wasn't that the faster finality single slot finality that Justin proposed to be incorporated in 2029? That would make it harder again. So kind of if we have, I mean, those are two separate things. So kind of the one question is kind of what's our cadence of our main blockchain? That's year one. So that's currently 12 seconds.

And of course, we also want to bring that down. But a separate question is how fast can we prove the correctness of those roll-ups? And currently, real-time proving would mean 12 seconds. If we bring down the cadence to, let's say, four seconds, it would also mean real-time proving will be, again, harder, but potentially possible.

Okay, so I'm sorry. So Justin, you were in the middle of addressing Martin's comments from earlier. Right. So I think hopefully we've clarified the terminology a little bit. And I think what Martin is suggesting, assuming that we do have real-time proving, it's basically execution sharding, synchronous execution sharding, which is the best kind of execution sharding.

Now, one of the points that Martin brought forward was this notion of deferring business models to the L1. Now, the good news is that you can have a different business model, but still have the exact same security. So for example, you could imagine a programmable native rollup where the fee token has been programmed to be something else. And the governance is only responsible for managing the treasury. So for example, it's responsible for

funding public goods for it. And the governance, importantly, has no impact whatsoever on the virtual machine. The virtual machine is immutable, it's fixed, it's an exact copy of the EVM, and it will be so for the rest of time. And so if you have a base native roll-up

with its different business model, you can have the best of both worlds. You can have the exact same security as the R1 and you can have an incentive for external participants to bring on more users onto Ethereum. And I think this could be a fantastic end game for the base chain. The base chain, I think it makes sense for it to become based and native

but then to have some sort of fee revenue, which goes to the Coinbase shareholders or it goes to fund public goods or whatever it is. And that this business model does not conflict with the security. And these are users that we might otherwise not get.

right? On Solana, Coinbase does not have an incentive to bring its users because it doesn't control the business model of the L2. So I actually think that allowing for more programmability with the native rollups as opposed to the rigidity of the strict execution shards is potentially more incentive aligned for growth.

Well, and I would say I absolutely still want to have based and optimism and kind of all those all those roll ups. I'm just saying I do think their incentive to to choose to to kind of to tightly connect to Ethereum will depend on how strong Ethereum L1 is.

plus, let's say, execution sharding is. And I would say I'm not certain that we're currently on the right track to be strong enough for them to have this incentive to choose to align closely with that. So therefore, I'm saying, in my view, having those, let's say, execution sharding roll-ups

will first rank in L1 and therefore make it more likely that this will actually happen. So one of the things that you said previously was around the ratio of funds moving away from the L1 economic zone. So I actually had a look at the latest numbers. So if you go on L2B, it will tell you how much TVL there is on all of the L2s. And it's about $47 billion. Right.

And if you go to ultrasound.money and you scroll down to total value secured, it will tell you how much value is secured by Ethereum. And that's 730 billion. So about 6.4% has migrated to these different economic zones. So it's a relatively small number.

But what I expect will happen is that part of this 6% will eventually come back to Ethereum, right? Because it's just a matter of flipping a switch in some sense, where you change your sequencer, you become base, and now suddenly you're back inside the economic zone.

Now, in order for the various rollups to turn on that switch, they need to have incentives to do so. And in particular, as you said, they need to be able to plug in and enjoy the network effects that come with sharing the sequencer.

And the network effects, technically speaking, originate from what's called synchronous composability, which is where you can have a contract in rollup A, immediately call another contract in some other rollup on the L1. And basically that unifies liquidity and gives developers superpowers.

Now, in order to achieve that, we're actually going to need the real-time proving. And so what I expect will happen is that it's going to be an emerging story over time where one by one, some of the roll-ups come in because they suddenly have a prover which is fast enough. And by the way, there's at least three different types of real-time provers. There's the snark provers, which I think is what Martin was alluding to. This is a

fundamentally engineering challenge to just improve the latency. And we have things like a massive parallelization of the proving across the GPU clusters. We have knock proving ASICs that are coming. We have all sorts of optimizations at the algorithmic level, at the proof system level. These things are improving extremely fast and I'm very, very bullish. The other type of real-time proving that is available today is using TE's trusted hardware.

And I think there's no shame in using TEs as a training wheel for the next few months, potentially a couple of years, until we wait for snark-based real-time proving to happen. And then there's another type of real-time proving, which is the trusted real-time proving, where you just have some entity that signs a message saying this is the correct state of the world. And I think this could also work as a training wheel for some of these ecosystems in the short term.

First, 100% agree with all the things and 100% agree that, yes, synchronous composability is what really creates a strong network effect. Two comments just. First, I would say even having synchronous reads is already extremely powerful. So kind of from the roll up, being able to just...

be able to create contracts that can just read or call any contract on L1 in real time only as a read call, already that kind of just consuming price oracles, consuming token balances, that's already powerful. My other comment on your first one about what's the state of the existing roll-ups is,

And what's the total value in there? I think that's extremely important to carefully look at it. And for example, on BASE, I'm looking at L2B. So according to L2B, they have, what is it, 10 billion, roughly 10 billion worth of assets in BASE.

But only a third of them is actually really coming from Ethereum and is secured, or I would say is secured by Ethereum. So a third is only kind of bridged from Ethereum. Two thirds is native to the two base. And that's, for example, USDC. And here the reality is someone can move, essentially it uses its own bridge and you can move from base to, let's say, to Solana.

faster than or kind of that transaction will already clear before the state of base is even kind of finalized on Ethereum. So I would argue that that value is not really secured by Ethereum or is essentially already in a kind of different economic zone. And I'm well, and the trend to me is that this is happening right now more and more.

I mean, as I see the trend is that, you know, L2 started as extremely, you know, centralized and isolated projects and are gradually becoming closer and closer to Ethereum. And we can see this on L2 beats with the pizza pie, right? Like,

more and more of the slices are becoming green. They go from red to yellow to green. And once the option to become base becomes viable with pre-confirmation, and once we have this pre-compile to have the native rollups, I think we're going to see more and more of the L2s becoming Ethereum. And I think, at least I'm hoping, that at some point there will be a phase shift

because the network effects will start kicking in and you'll just be left behind if you don't join in. Right now, the network effects are relatively small because even if you were to share a sequencer, you still have to pay the latency of settlement, which as you highlighted, can be seven days for these optimistic rollups. So

The good news is that this is just pure technology, pure engineering. We can replace the fraud proof games with snarks and we can replace the snow snarks with fast snarks and eventually we'll have real time proving. And this is where the phase change will happen and everyone will be incentivized to join the party. Actually, one thing, Justin, I feel like what I'm hearing, and please correct me if I'm mischaracterizing your remarks, but I

I don't know if I feel like you've necessarily directly addressed what Martin's proposing. It sort of feels like you're saying that you feel like some other aspects of the, you know, either what's happening now or what you're proposing do address what he's talking about. But are you actually opposed to what he's proposing?

I mean, what I'm proposing, which is the native roll-ups and what he's proposing, which is the execution sharding is like 95% aligned. Like one is slightly more powerful than the other. And I think if we were to have execution sharding, I would be extremely happy, but I would also say, Hey, why don't we just do the more powerful thing?

I mean, there was a couple of comments that I'll say. The first one is like maybe somewhat political in the sense that if we have execution shards, they are exclusive execution.

to the Ethereum brand. And so all of the existing L2s won't have the option to make use of this superpower and they might feel left out and that may make the proposal a little bit more controversial. The other thing that I'll highlight is that the native rollups are more flexible when it comes to incentive alignment. And the reason is that you can choose your fee token and the tokenomics around it.

On the other hand, the execution shards would force E30 assets in terms of the fee token. It would force some sort of a burn mechanism and an EIP-1559 style pricing.

And so there again, there might be like some political tension with the existing rollups. And I think it's totally fine for Ethereum to basically forego and gambit these execution fees because in return, we get a lot of BD and growth with actual users.

Yeah, I mean, to some extent, yes, there will be attention or there can be attention between, yeah, let's call them execution charts for now and existing rollups. I would say existing rollups still have plenty or can have plenty of room to innovate beyond those and do things other than, yeah, those would essentially just try to say, okay, we want to create more of Ethereum, more of what one provides right now. But there's...

there's a ton of innovation. So kind of there are some, I don't know, there's EdTech that tries to build a privacy. There is UniChain that tries

It tries to say, OK, we have some TE logic in our sequencer. So there's BASE that just creates super nice integrations into Coinbase. So I'm saying all those things can still, those are still ways to differentiate and to innovate.

I'm really looking at the perspective of a new debt developer that says, I don't want to choose one of those sub-ecosystems. I want to be able to just choose Ethereum. And today I cannot really do this other than paying the very high one fees.

So I have a couple of questions. And it's so funny, because here we made it into 15 minutes of the episode, and we actually haven't heard Justin kind of explain his meme chain proposal. So why don't we do that? Well, we'll start with that, because I do have other questions. But we've sort of been, you know, I'm sure people have kind of heard bits and bobs of it out there. But go ahead, Justin, why don't you explain what you're proposing?

Sure. So when you zoom into the L1, there's three different layers that appear. The first one is the execution layer that we've been talking about so far with the native rollups.

There's the data layer, which is also known as the blob layer or the dank sharding layer, where data gets ingested by Ethereum. And then finally, there's what we call the consensus layer, which is expressed today through what's known as the beacon chain. Now, I think we are on a very good path for the data layer and the execution layer to complete all of the things that we want to complete today.

within the next five years, call it. But on the other hand, for the consensus layer, there's a bunch of things that we want to do which are just hard. And part of the reason why they're hard is because they require a lot of coordination across many different teams and having to go through this governance process iteratively over many, many years and this being a slow process.

Basically, what I'm trying to do with the Beam Chain is to zoom out, look at the big picture. We're going to have so many upgrades happening over the next few years. But what I want to try and avoid is the last few big ticket items just lingering on and on for decades, potentially. And so what I'm suggesting that we do is that we take this clean slate approach specifically for the consensus layer. And the reason why the consensus layer is especially exciting is because it's not directly consumed by applications.

So applications will directly consume EVM opcodes, they will directly consume blobs, and because there's a need to not break applications, in other words, there's a need for forward compatibility, we can't really make big changes there other than the native rollups, which in some sense is about wrapping the whole EVM inside a snog as opposed to changing the internals of the EVM itself.

Now, because we have this freedom, why don't we just take a clean slate approach and bring all of the latest and greatest research ideas into a fresh design, which would be called the Beam Chain. And in some sense, one way to frame the Beam Chain is as a new era for Ethereum consensus. We've had the proof of work era for five years.

followed by the proof of stake error, also for five years. And I think we're going to be entering soon this ZK error, where we can basically make use of the magic of ZK to improve the consensus layer. And so in some sense, it's very, very reminiscent of

to the native rollups and the execution charts because it's the exact same technology. It's the ZKVMs that we would be using to snarkify the chain, but it's a different chain that's being snarkified. For the native rollups and the execution charts, the chain that's being snarkified is EVM chains. But on the other hand, for the Beam chain, it would be a consensus chain that is being snarkified.

But in addition to snarkifying the whole chain, there's all sorts of other improvements that are being suggested. So for example, finally shipping single-slot finality, which has been talked about for many, many years.

upgrading the chain to be post-quantum secure. In this year, 2024, there's been massive breakthroughs in quantum computing. One of the top commentators, Scott Aronson, is now claiming that within the next 10 years, he expects practical quantum computers to become a reality. And

We also could pick some of the low hanging fruit in terms of shortening the slot times. This is something that Martin alluded to. When we pick the 12 second slot time, in some sense, it was a bit of a guess and it was a conservative guess. And now we know that we have the technology to simultaneously keep the decentralization profile that we have today, which is that we want validators that

with home internet connections, potentially in remote jurisdictions like Australia, being able to participate and still be... Go ahead. Just one second. So I can say, well, we could just...

to five second slot times right now on Ethereum with the exact same technology. And I know that because we, a Gnosis chain, are running a beacon chain with home validators, with 300,000 validators, stable now for two years with a five second slot time.

Yeah, so I think you need to be a little bit careful when quoting validators. And the reason is that oftentimes you'll have a single operator who will control multiple validators. Of course, of course. And I know that we have spent a lot of effort into getting people physical dep nodes and have quite diverse. Of course, we don't have 300,000 different entities, but...

and neither has Ethereum, but we know we have a large set of homeworld daters as well. Right. I mean, even today, yeah, maybe there is an opportunity to reduce the slot times, but just the coordination challenge of changing the slot time is something that comes with a lot of overhead. And in the short term, there's other things that we're looking to prioritize. For example, inclusion lists.

We have a problem with the centralization of the builders. If the top two builders decide to censor, this will be a big problem for Ethereum. And so this is why we want to prioritize it.

One of the reasons why I'm not too worried about the 12-second slot times is precisely because of these pre-confirmations. I believe that over the next few years, the vast majority of FFM transactions, call it 90% of transactions, will be pre-confirmed and in some sense will have abstracted away the notion of the slot duration. It will be implementation detail that is hidden and abstracted away from the users. Now, in addition to trying to accelerate the timelines,

One of my kind of meta goal for the Beam Chain is to introduce a new meme that kind of gets the community excited and helps the developers in particular kind of all come together and work on a common goal. Like right now, we don't have a clear sense of a quote North Star. There's a lot of discussion around like what needs to be prioritized in the next few forks.

And I think it would be good and healthy to basically draw a line somewhere in the roadmap where we say, okay, these are items that we want to do in the next few years because they're high priority, they're low hanging. And then there's another set of items that are ambitious, more likely than not require kind of a clean slate approach. Let's just bundle all of these things together, minimize the use of governance,

and basically ship everything in one go. And so on the topic of minimizing governance, I think of it as a governance batching optimization, right? If it takes a whole year to go through the governance pipeline, EIP or call devs testing and whatnot, let's just go through it once as opposed to having to go through it 10 times. Now, another thing that I want to highlight is that

The current crop of consensus developers, there's 48 of them that are spread across five different teams. They've been doing a great job over the last decade or so.

And I'd like to use this opportunity to bring fresh blood into the ecosystem. And I'm very pleased to share that there's now seven new teams that have basically approached me saying, I also want to build a consensus client. So there's now a total of 12 different teams

And interestingly, about 50 people have, individuals have emailed beam.chain at ethereum.org. And, you know, that's roughly the amount of manpower that is currently assigned to the consensus clients. And so I'm hoping to inject a little bit of vitality in the L1 R&D.

Well, I did want to ask you, though, because, you know, if I were to kind of sum up some of the reaction on Twitter, which you referred to when you gave your talk after DEF CON at the Thankless Summit, and you said that there was what was your most hated slide ever, which had the five-year timeframe on it. And, you know, I saw comments like Zero Expo and the engineering lead at Eigenlayer said,

All the mistakes we had now is because things changed so much from five years ago when the original proposal was created. And I saw Martin had some critiques of the timeline. In general, if I were to just kind of take everything that I've been seeing on social media, it does feel like there is a little bit of a feeling of urgency, especially when it comes to competing with the likes of Solana. At this moment, they have a better UX. They were onboarding more newbies. It just sort of feels like

people are worried about Ethereum falling further behind in this five-year timeframe. And I know in your bankless talk, you did talk about like all these other changes that will happen between now and then, but it does feel like...

you know, I'm sure you guys know, five years in crypto is an eternity, you know, especially since the election we've just seen. There's just so much news happening every day. And I think what people are worried about is that Ethereum could get out-competed while it's trying to make these changes in its slow and careful way, which, you know, I don't think anybody's objecting to wanting to do it in a secure way. But, you know, one other criticism that I saw that I think maybe is tied to this is,

This beam chain fork that you're proposing would bundle together a number of large changes all at once. And I feel that there's also some concern about that. So I don't know how you would address any of those criticisms. Absolutely. So let me address them one by one. The first one, I guess, is around Solana competition. Now, as I stated initially, Solana

I think the proper way of thinking about it is that it's the L2s that are competing with Solana, not the L1. And what we want is the L2s to basically beat Solana on all the performance metrics. What are the two key performance metrics? Latency and throughput. This is literally the roadmap of Solana. Reduce latency, increase throughput.

But then, but just one question. So you, it sounds like you are firmly in the camp of the L2s are not parasitic to Ethereum, you know, because I'm sure you're aware a lot of people think that, but it sort of feels like you're just kind of bypassing that criticism.

Well, it's give and take. So basically the L2s, I think, are responsible for BD, for attracting builders, for attracting users, for essentially growing the ecosystem. And what they get in exchange is execution fees. So, you know, it is a loss of potential income source if Ethereum were to do everything, but Ethereum L1 just can't do everything.

The reason why we don't have execution charts today is just, we just don't have the technology. The technology will only be ready in a few years. And so we can't just, you know, do nothing for so many years. We need to engage some other entity that is-

Yes. So there's hundreds of millions of dollars of VC funding that has gone into Risk Zero and Sucinct, which is behind SP1. So I just checked recently, Sucinct has raised $55 million, Risk Zero has raised $40 million, and then there's five other Risk Five ZKVMs, and then there's another roughly five non-Risk Five ZKVMs. And so

Despite all of this investment that has happened, the technology today is still not ready. And the reason is that it's just fundamentally hard. Like, stocks are very, very hard. As an ecosystem, we've improved by orders of magnitude in terms of performance, but even today, we're still not there. And what I think will happen over the next one, two, three years, the technology will be

mature enough that we can incorporate it at layer one. I wish that we did have the technology. I just don't think we have it today. One of the things that was mentioned is this five-year timeline. Now, maybe I kind of messed up something in my slides, but there's only four years in my timeline on this slide. So it's basically...

2025 all the way to 2029. There is a little bit of 2024, but 2024 is kind of almost over. And there's a little bit of 2029 as well. But overall, it's a four-year timeline, not a five-year one. But again, I guess take the dates with a grain of salt. I tried to be conservative, but they could change either way. The other point that was brought up is that a lot can happen

in terms of research within those four years. And if we use today's snapshot of the best ideas, then they will be outdated four years into the future.

Well, one possible answer here is that we have definitely observed a reduction of the turn in research ideas. I've been a researcher for seven years now at the Afferent Foundation and we started doing completely blue sky ideas and now we're like

debating really minor details and minute details within individual modules that we're trying to improve upon.

And then the other thing that I'll say is that if there are ideas that I found over the next few months or even the next year or two, we still can incorporate them, right? Because the spec writing process is ahead of us. And even once we have written the spec, there will be an opportunity to incorporate feedback either from the developers or from the broader research community and academics.

So I don't think the risk of working on something ambitious means that when we do ship it, it becomes outdated. Now, the other point that you raised was around the ambition of the fork and basically the need for testing.

The two answers that I'll give here is that number one, we're reusing a lot of infrastructure. The main thing that is changing in the clients is the so-called state transition function. Like this is the core, the heart of what makes a consensus client. But around it, there's various pieces of technology. So for example, there's the networking layer, which uses LeapP2P. There's the mergulization layer, which is called SSZ or Simple Serialize.

All of these pieces of ancillary infrastructure would be reused. And it turns out that most of the complexity of writing a client is in this ancillary infrastructure.

And not only that, we would be able to reuse the existing teams that previously did not exist. So for example, now we have a dedicated security team. We have a dedicated DevOps team. We now have a whole framework for writing specs in Python and having unit tests. So all of this kind of common know-how and knowledge

will make the beamform actually much, much less ambitious in some sense than the original beacon chain, just because we have so much more infrastructure that we can leverage. And to your point around the need for testing, this is to a very large extent why the roadmap is so long. It's because I allocated two full years just for testing. I tried to be very, very conservative.

But if people feel comfortable that after one year or a year and a half or six months or whatever it is, the system is mature enough, then I think the timelines could potentially be accelerated.

So, Justin, I also have to ask you, you know, and this goes back to the question about whether L2s are parasitic. You know, you were kind of the architect of this ultrasound money meme and, you know, this notion of like the fees would get burned and all this stuff and ETH would become deflationary, right?

during peak periods of activity. And obviously with the introduction of just all this L2 activity and shoot, I'm just forgetting the name of the upgrade that enabled more blobs. Yeah, the blob. I mean, Denkun.

Yeah, sorry, Den Kuhn. After Den Kuhn, obviously, we have seen that now ETH has basically pretty relentlessly become inflationary. And that has coincided with this period of the ETH-BTC ratio dropping pretty persistently. And, you know, I was just curious, like, you were the one who kind of had this meme about the ultrasound money. And it feels like, again, you're

Now that these different upgrades that you guys are making are actually taking ETH away from that narrative. So how do you kind of square, you know, your plans with what you had previously worked on?

Right. So there's a couple of things here. So the vast majority of the burn will come from the blobs eventually. Right now, in this really kind of strange and temporary and maybe slightly awkward and confusing period where there's more blob capacity than there is demand. And the reason is that we went from zero to three blobs. It was coming from zero to one in some sense. And it took a few months for...

for the demand to catch up with the supply. But now we're at a point where the blob demand is roughly equal to the supply. And so any kind of burst of activity is going to start leading to significant burn with the blobs. And my personal thesis is that we're going to see

very large amounts of burn through the blobs. And actually, if you want to kind of push your time horizon to 10 years into the future, I actually have a whole thesis around there being billions of dollars of burn through the blobs. And I'm happy to walk you through the math if you're interested. But the other thing that I'll say is that

From the point of view of the fees that ultimately users pay to the roll-ups, there's two components. There's the data component, and then there's the execution component. The data component goes to the L1. That is not something that is minimized or sacrificed. If anything, like the...

The more composable, the more network effects that we can have, the more base rollups, the more native rollups we can have, the bigger the burn will be from a data standpoint, because there'll be more of a demand to consume one data. But then the other component, which is the execution fees, I think that has been largely sacrificed in the rollup-centric model. And I think it's fine. And the reason why I think it's fine is because ultimately it's compensated by the fact that it will bring more users onto Ethereum.

Now, the current source of burn or the major source of burn over the last few years has been the L1 EVM burn. And I think what will happen is that the ratio of burn from the L1 EVM is going to go way, way down and eventually it's going to be less than 1%. And the reason is that fundamentally...

What you want to use the L1 for is settlement of the rollups. And settlement can be done with, in theory, just one SNARK. You can have one SNARK settle all of the rollups on Ethereum. And so basically it's a constant amount of gas that you need to consume for an unlimited amount of rollups. On the other hand, data is something that doesn't scale exponentially in the same way. You're going to need...

some fixed number of bytes for every single transaction. And there's no way to compress it beyond a certain point.

Yeah, I don't share that. My view is there are kind of three layers. So one is execution. Second is transaction ordering, sequencing. And the third one is just data availability. And I would say the lower you go on the stack, the less it is worse. And in my view, what Ethereum essentially did is to say, OK, we are

We are selling right now this high value product execution. And now we say, okay, well, we give up that product and we kind of right now, we actually even sell just the lowest value product, which is just data availability product.

Whereas maybe we are selling transaction ordering. If more roll-ups would become based, that would be a step forward because then the product is more valuable. But what I'm really saying is, yeah, we should continue to produce the high-value product and produce much more of it. And I mean, essentially, that is what I'm proposing or trying to say, okay, we have one capacity. What is the realistic path to 100x the market?

L1 capacity or at least come to something that is as close as possible to that on the Beam Chain, maybe just in general. In principle, I would say all those things are reasonable. I just don't think it's the right priority. I do think the type of users I'm most concerned about is applications.

app developers, dev developers that want to deploy some smart contracts or something on Ethereum and to them to say, okay, let's say we reduce the requirement to be a validator from 32 to 1 ETH. That's completely irrelevant to them. No one says, oh, Ethereum has only 1 million validators. That's the reason I'm not choosing Ethereum.

the reason people are not choosing Ethereum today is because fees are too high for L1 and for L2 you have this big fragmentation problem. So to me the absolute number one question we will need to be able to answer is if you have an NFT on one roll up and you want to kind of transfer it to the other one or you want to

kind of do some contract call you want to read some state here and you want to interact with some state there how very practically as an application developer am i going to do this how can i

create transactions across rollups and how can we make this experience for, for, yeah, for debt developers as, as easy as possible. And currently, again, I don't see, I don't see Ethereum there on a, on a, on a good path. I mean, to some extent, there is a lot of talk about interoperability, but usually what it boils down to is,

Some solutions that say, okay, for liquid assets like Ether and USDC, yeah, there it is certainly possible to say, okay, we have liquidity bridges or we have some intent systems there.

But that's still very far from really native interoperability where, and of course, that's also one of the promises of Solana, that there you don't have to decide on what rollup or where you are. You're just on one system and whatever is available on the system is also to you as a developer available.

natively available. So whatever it is, liquidity or contracts, you can just call that contract and interact with this contract. And that to me is the absolute number one priority Ethereum needs to solve. If you are living on this one rollup and you want to interact with state on two other rollups, how do you do that? How do you do this as seamless as possible?

So you guys, we're coming up on time. So what I'm going to do is just to ask you to both make kind of like your closing argument and

And, you know, or in that, Justin, you can address what Martin just said. But essentially, you know, correct me if I'm wrong, it seems to me like these proposals are out there and like what actually happens is sort of kind of up to the community. So given that, you know, unless I'm wrong about that, it does feel like, yeah, you should kind of make your closing arguments like what you think is the best path to go and why. Yeah.

So I'm an eternal optimist and I think we should do all of the paths and we can totally do all of the paths. There's two games that are being played. There is a short term game and you could say it's a competition with Solana. We're trying to beat Solana on all of the performance metrics.

And if you want to do that, you need to have a mindset of an L2. And this is the mindset that I've had for all of this year, where I've been trying to advocate for shared sequencing, for shared standards, for base sequencing, for pre-confirmations. And in some sense, this falls outside of my remit as an L1 researcher. Most people within the EF are focused on the L1.

And I think right now the L2s are on a very good trajectory with the clusters that I said, with the pre-confirmations, and with the fact that we have a very scalable architecture where horizontally we can scale and there's a real push for interrupt. There was...

For example, the Interop forum that happened at DEF CON, many of the side events were focused on Interop. I think this is something that we have awakened to and we, at the very least, we acknowledge the problem and we have dozens, if not hundreds of companies that are working to solve these problems in all sorts of creative ways.

Now, I'm personally not too worried about Solana. I think the golden age of Solana has happened. And from now on, I think that the high performance applications can come to Ethereum. I think in parallel, we should also be playing the long-term game, right? Like ultimately, we're trying to build systems that are going to last for decades and centuries. Like we shouldn't be focused on the week-to-week or the month-to-month battles with Solana.

with the meme coin casinos. We should also be thinking about the bigger picture. We should be thinking about moneyness and credible neutrality and World War III resistance and all of these big words, I guess. And the good news is that I don't think these two paths are in conflict at all. And this is partly why the timeline is so stretched. It's precisely because it is not being prioritized in the short term.

I think I would agree with Martin if I was to come on stage and I'd say, okay, let's take all of the Ethereum resources and work to deliver the beam chain within the next year. That would kind of be a complete strategic mistake. But instead, what I'm proposing is that we take our time, we do it properly, we bring in fresh blood that is not currently allocated properly.

to the short-term games. And we have this new cohort play the long-term games because ultimately these long-term games are also important. And I think the saying that kind of crystallizes all of this, actually, this is something that I've stolen from Vitalik, is that the L1 competes with Bitcoin, the L2s compete with Solana.

Yeah, my take is that the big, big problem is interoperability. And I don't see a solution to that for the current state of roll-ups simply because they are very heterogeneous. They all are slightly different. And therefore, they all also have slightly different underlying risk profiles.

And now if you have all kind of slightly different risks and then you want to abstract that away and have a homogeneous experience on top of that, it's actually very dangerous. There was a nice talk at DEF CON that says chain abstraction is risk abstraction. So I would say the only way to really abstract chains away, rollups away, would be to say if they exactly have the same

risk profile and, of course, the absolute minimum risk profile. So I would say the technology to create those kind of ZK-proven EVM chains is not quite there, but it's ready enough to say that is really...

what we should be or Ethereum should be working on. So kind of essentially bring that level, that technology that largely exists already to a state where it has the same kind of

level of quality as Ethereum stuff should have. So of course, like let's say multiple independent implementation, proper testing, and then you have roll-ups or then you have a roll-up system where you can then of course deploy many instances of that, that are truly, truly inherits the security of Ethereum and where you can truly say assets and tokens are fungible.

While building that, we absolutely critically need to improve standards for cross-chart, cross-rollup.

The communication even starts with basic things like addresses. So, I mean, currently it's a terrible situation that we don't even have a proper standard to define. I mean, you're using the address, but then you're using the same address on money chains. So one small part of my proposal was to say,

Of course, all those different charts would have chain-specific addresses. We would use the same format, but we would add some salt or hash to it so that we would make sure there's no address collusion. So if we talk about an address, we exactly know what rollup we are talking about. And then, of course, developers should not have to look at third-party bridges or figure

figure out how to now call this contract on another chain, they should have a clear and easy solution for that. Long term, ideally, we can go for a synchronous composability, which again would

what would imply or what requires this real-time proving. But I would say the good thing is we don't have to start there. So we can start at a point where we have a synchronous read. So those rollups would be constructed in a way that they allow you to read any one state.

and still reasonably fast write into it. So kind of you can do a transaction, you can kind of trigger a trade. But yes, that will take maybe two minutes. But kind of the good thing is that time would automatically go down. So kind of as we get faster, improving times, it will reduce to one minute and eventually be even real time. So I'm saying...

Yeah, kind of outsourcing all that work to L2s would essentially mean risking fragmentation

Of course, also risking value capture for Ethereum. So my take is they are not parasitic. They are just creating value and capturing that value. And I think Ethereum would be in a good position to create that value itself. So Ethereum is currently a...

what is it, almost $400 billion asset, it should certainly be able to spend a couple of hundred million dollars to create those native roll-ups, which I think is totally doable with that budget and would make a lot of sense for Ethereum.

Yeah. So obviously I'm not a technical person, so I'm going to make that caveat. But, you know, if I'm just kind of thinking just from a very zoomed out perspective, you know, like for all of the crypto boom cycles that we've seen after, obviously, the 2013 cycle, which was just Bitcoin, you know, every single new trend in crypto started with Ethereum. And this is the first time that I've seen that it didn't start with Ethereum. And instead, base is copying things from Solana. So, you know, just like on a really, really

basic thing, that's what I'm seeing. And so even though I can see a lot of benefit to the different proposals that Justin made, even on a longer timescale, I also do see that Martin's proposal maybe could fulfill some of the sense of urgency that I think some people in the Ethereum ecosystem have. And on top of that, it does also feel like

you know, so much, so much happens. And so I'm sure you frequently hear, you know, I, I'm sure you know the saying better than I do, but like, like developers generally will try to kind of like release things quickly and iterate, you know, whereas like, I do see a little bit of risk of having a sort of longer timeline change, which I just feel like reduces some flexibility that you have to respond to like changes that are happening in the market. So,

From my understanding, though, I don't think your two proposals are necessarily mutually exclusive, but, you know, it's just a sort of like, what are the priorities? How does the community think about like what's most important to do now? So anyway, I hope that we were able to, you know, help people kind of understand what the different tradeoffs are with the different proposals. But this has been such a great discussion. Thank you both so much. Where can people learn more about each of you and your work?

I'm drakefjustin on Twitter, but you can also find me on Telegram. I'm justindrake or lowercase. And you can also email me justin at the film.org. Yeah, Twitter is a good place. Yeah, Koppelmann is my handle. K-O-E-P-P-E-L-A-N-N. Perfect. Well, it's been a pleasure having you both on Unchained. Thank you. Thank you, Laura.

Thanks so much for joining us today to learn more about Justin Martin and Ethereum's roadmap and the Beam Chain and Martin's proposal for native layer twos. Check out the show notes for this episode. Unchained is produced by me, Laura Shin, with help from Matt Pilcher, Dvon Aranovich, Megan Gavis, Pamba Jumdar, and Mark Okuraya. Thanks for listening.