How Native Rollups Scale Ethereum | Uma Roy & Justin Drake

Native Rollups are the next big step toward scaling Ethereum securely. In this episode, Uma Roy (CEO of Succinct) and Justin Drake (Ethereum Foundation researcher) break down what Native Rollups are, how they leverage Ethereum’s core infrastructure for execution and validation, and why they're crucial for stronger security, better composability, and sustainable Ethereum growth. Tune in to understand the evolution of Ethereum’s rollup-centric roadmap and how Native Rollups could become a foundational upgrade for Ethereum's future. ------ 📣SPOTIFY PREMIUM RSS FEED | USE CODE: SPOTIFY24 https://bankless.cc/spotify-premium ------ BANKLESS SPONSOR TOOLS: 🪙FRAX | SELF SUFFICIENT DeFi https://bankless.cc/Frax 🦄UNISWAP | SWAP ON UNICHAIN https://bankless.cc/unichain ⚖️ARBITRUM | SCALING ETHEREUM ⁠https://bankless.cc/Arbitrum 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle 🌐CELO | BUILD TOGETHER AND PROSPER https://bankless.cc/Celo 🏦INFINEX | THE CRYPTO-EVERYTHING APP https://bankless.cc/Infinex ----- ✨ Mint the episode on Zora ✨ https://zora.co/coin/base:0x9ad876e913102d5097df82db0617816a17b07414?referrer=0x077Fe9e96Aa9b20Bd36F1C6290f54F8717C5674E ------ TIMESTAMPS 0:00 Intro 6:41 Why Native Rollups? 16:32 Security & Composability Benefits 38:13 ZKProofs 42:52 Making L2s Native 50:48 Network Effects 52:35 Customizability Trade-Offs 58:59 Timelines 1:02:39 ETH Economic Impacts 1:05:46 Other Advantages 1:08:17 Succinct 1:08:59 ETHProofs.org 1:11:32 Real-Time Proving 1:12:33 Ethereum’s Bottleneck 1:15:43 Closing & Disclaimers ------ RESOURCES Uma Roy https://x.com/pumatheuma Justin Drake https://x.com/drakefjustin Native Rollups https://ethresear.ch/t/native-rollups-superpowers-from-l1-execution/21517 Succinct https://www.succinct.xyz/ L2Beat https://l2beat.com/scaling/summary ETHProofs https://ethproofs.org/ ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures⁠

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  I think the simple like one liner is become native, get more TVO, get more users and everyone wants that and that's good for the roll up. That's good for users. That's also good for Ethereum.

• 0:17David Hoffman?

  Welcome to Bankless, where we explore the frontier of internet money and internet finance. And today on the show, we're exploring the frontier of native rollups on Ethereum. The big problem in the Ethereum rollup landscape is the problem of non homogeneity. When Ethereum decided it was going to scale with rollups, it exported its scaling strategy to independent layer two teams, which all rolled their own code for rollup design. Now Ethereum has scaled with many different rollups, but all of those rollups are themselves not very close to Ethereum. They all have different code. They all have different security assumptions and they're all creating their own competing standard. This heterogeneity in Ethereum rollups have given rise to the meme that Ethereum layer twos are not Ethereum.

• 1:02David Hoffman?

  Ethereum layer twos are in fact distinct from Ethereum and a lot of the problems in Ethereum are downstream of this reality. Enter native rollups, which is a design construction of an Ethereum rollup that tackles the issue of non homogeneous rollups head on. It does this by baking in the security of Ethereum rollups directly into the layer one itself. Instead of optimism, Arbitrum, Base, all having fraud proofs and a security council, the idea of native rollups is that this is actually a service that the Ethereum layer one can and maybe should provide by baking in an EVM precompile directly into the code of the Ethereum layer one.

• 1:41David Hoffman?

  The Ethereum layer one in this world would verify the validity of its native rollups and rollups like Arbitrum, Optimism, Base, they can all just throw away their fraud proof code. They can throw away their security councils and simply use the layer one precompile to access Ethereum level security. Today on the show, I have Justin Drake and Uma Roy to help me understand this conversation. It's a very technical episode and I am a non-technical guy. So that means I help you break down the technical topics as best as I can. So I think you'll Be able to keep up with Uma and Justin just fine. It was challenging, but I think I did an okay job. Let me know if I didn't. Some topics we discussed. What's a native rollup? How do they work? What do they fix? Why EVM chains like base Arbitrum, ZK sync?

• 2:23David Hoffman?

  All benefit much more from native rollups and non-EVM chains all get left behind. What does it take for an existing rollup to become native? How are based rollups relevant? How does this impact the economics of ETH? What's the whole timeline on this whole thing anyways? And why, like all of Ethereum's problems? Does this ultimately collapse back down to human coordination at the end of the day? So let's go ahead and get right into it. But first, a message from some of these fantastic sponsors that make this show possible. Bankless Nation, super excited to reintroduce you to Uma Roy. She is the CEO of Succinct. Succinct is a developer platform to help make ZK proofs easy to work with. No giga brain needed. Just enables more of the internet to become ZK proven more easily. Uma, welcome back to Bankless.

• 3:05Speaker 00

  Thanks for having me.

• 3:07David Hoffman?

  And once again, we also have Justin Drake. He is a researcher at the Ethereum Foundation and he has been researching and advocating, advocating for newer constructions of rollups that I'll say are all kind of closer to the core of Ethereum. Maybe first with base rollups that repurpose the layer one validators to replace sequencing for rollups. And now with native rollups, which repurposes the layer one EVM for execution. I'm still a little foggy on what that means, which is why we are doing this episode. Justin, welcome back to Bankless.

• 3:34Speaker 02

  Hey, David. Thanks for having me.

• 3:36David Hoffman?

  Okay, so I want to start with actually showing this tweet on screen because this tweet is exactly why we are doing this episode. This is a tweet from Uma. Uma, you tweeted out, "I finally understand Justin Drake's native rollup vision and I'm so fucking bullish Ethereum. Native rollups solve ETH value accrual and extend Ethereum layer one security into the entire rollup centric roadmap." And then you follow up saying more details below with a pretty long tweet, which is basically turning into the agenda for, for this podcast. So maybe we can just like start there. You got native rollup pilled. Maybe you can kind of set the landscape for us. What's the current problems in the current rollup landscape that we have with the optimistic rollups?

• 4:19David Hoffman?

  Like Arbitrum optimism base with a single sequencer and a governance token. Maybe we can kind of like set the context for what the problem is or and what you're really excited about with, with native rollups.

• 4:30Speaker 00

  Yeah, I mean, I think the rollup-centric roadmap is definitely terminally correct. So let me start off there. I think the Solana kind of architecture of we're going to fit everything on one computer is very dumb and is not very practical. If you look at any system that's ever scaled before in the history of the Internet, you have to have many different servers and you have to be horizontally scalable, which is the rollup-centric roadmap. So I think it's good that we all align that rollup-centric roadmap good, but at the same time acknowledge that today the rollup-centric roadmap has, you know, a bunch of problems. Certainly, one of the biggest problems is interoperability between different rollups.

• 5:10Speaker 00

  So for example, you have like optimism arbitrum-based top three rollups by TBL, I believe, and all of them have these seven-day withdrawal windows due to their fault-proof systems, which is the optimistic fault-proof game that they have to play to prove their validity to L1. And what that means is basically like if I'm a user and I have assets on one chain, it's really hard to get assets on another chain. And we've all talked about that problem a million times. That's one problem, and I think ZK will help solve that by basically instead of having to wait seven days for this optimistic fault-proof game, you can just have a ZK proof of validity and then settle the rollup in one hour, if not, you know, like five minutes. So ZK helps solve interoperability.

• 5:52Speaker 00

  But then there are still some other problems, which I think Justin's excited to solve with his based and native rollup proposal. So to dive into two of these other problems. One of the problems is that today's sequencers for rollups are centralized. So like, for example, they're just running a single sequencer, and that actually contributes to some of the interoperability problems. It's kind of a centralization vector and has other challenges that I'm sure Justin's excited to talk about. And based rollups basically are a way of leveraging the L1 for sequencing, which can help solve some of these like single sequencer problems. The other problem is that right now, every single rollup has to kind of roll their own

• 6:33Speaker 00

  state transition function and proof system to prove its validity back to the L1. And that can be problematic for many reasons from a security perspective. And then also it can mean that you have all these different standards. There's no like shared standard for all these roll up teams to talk to each other and interoperate. And then also, the most problematic part is that today, all these rollups have security councils to basically govern the upgrade of all their proof systems. And that's not ideal because basically you have this single point of failure. And the security councils are multi sig, so it's not just one person. But you have this single point of failure where the security council has a lot of responsibility over what is a valid rollup?

• 7:18Speaker 00

  When does the rollup upgrade, etc. And native rollups solve a lot of those problems by extending Ethereum's social consensus and Ethereum-level governance and security over that very important part of a rollup stack. It's kind of like, I guess, there's a lot more we can talk about here, which is, I guess, why we have this podcast episode. But yeah, maybe that's like to try to summarize in a few sentences.

• 7:41David Hoffman?

  Yeah, I do want to hang on and really try and set the context for really understanding the landscape here. I think people are not, everyone's familiar with Ethereum's interoperability problems. But unpacking that even deeper than that can take some time. And I really want to set the context here. And so Justin, I want to give you your turn to kind of maybe also do the same. But I want to also bring up something that you said one of the times we had you on previously, where Ethereum, this is something that you said, is Ethereum did this genius maneuver where it outsourced scalability to the rollups. And what that means is like, we outsourced research and development of scale to VC-backed teams.

• 8:22David Hoffman?

  And so Ethereum as an ecosystem is leveraging VC involvement, VC investment into things like Arbitrum, into optimism, in the example of Base with Coinbase. And now we understand how to scale and we got that knowledge by just incentivizing VCs to kind of scale Ethereum, which is cool. It's like some free work, some free research by the Layer 2 teams, VC-backed. But one problem that had with that UMA highlight- Was that well, each different org made their own solution. And now there's like 17 different solutions and there's not really one standard. And since, uh, you know, every single roll up wants to become the best version of themselves. Everyone, uh, if you're the base, you want everything to settle on base. If you're Arbitrum, you want everything to settle on Arbitrum.

• 9:06David Hoffman?

  But we lose the credible neutrality of the Ethereum layer one. And so now we have like 17 competing standards and we're, we're losing some of the, the properties that the Ethereum layer one had, even though we have the research and the knowledge, we lost some of the things that make Ethereum so, so magical by outsourcing this to, you know, privately backed entities. Uh, and, and so that's, that's part, part of the, the problem here. That's maybe some, something to add to the context of where the problem of Ethereum's roll up centric roadmap has, has run into. So that's maybe that's my contribution to this, to this section. Maybe you can also add like your commentary as to like really helping define the, the context of the, the, the topic here.

• 9:47Speaker 02

  Yeah, absolutely. Um, so a few points, one, going back to the initial tweet, I do want to clarify something around value accrual. I think it's easy for people to think of me as ultrasound money man. And therefore like all of the research downstream of this as being to increase the ETH burn. For native roll up specifically, um, the proposal is to provide this new pre-compile called the execute pre-compile essentially for free. And the reason is that yes, there would be a burn similar to EAP 1559, but the bottleneck, I expect it to be the data availability, not the, the execution. And so the, the, most of the value accrual comes from the, the, the blobs.

• 10:32Speaker 02

  Now in terms of the problems that the roll ups are trying, the native roll ups are trying to solve is, uh, are around, uh, number one bugs. So right as, uh, Uma said, um, the, the roll ups today have to emulate the EVM and this process of emulation introduces bugs. And we don't even expect today L1 clients to not have bugs. But we assume by default that GAF, REF, BESU, nevermind, and all of the other execution clients have bugs. And our strategy to mitigate the bugs is to lean on client diversity. But you can't really do that within the L2s.

• 11:15Speaker 02

  And so instead of emulation, what the executive compile provides is introspection. So it allows the L2 to peek under the hood into the L1 and have access effectively to this client diversity that the L1 is providing. And then there's a second problem, which is even more fundamental than the bugs, which is this idea of being forward compatible with EVM upgrades. So right now, roughly speaking, once a year, we do a hard fork and we change the EVM state transition function. And in order to remain compliant, compatible with the EVM, you need to have some form of governance. And really what we're trying to build here is trustless rollups, where you don't have

• 11:59Speaker 02

  to trust the security council, you don't have to trust a governance mechanism or governance token. And native rollups is all about providing a pathway to solve this. Now, David, going back to your comment around outsourcing. In 2020, we went with the rollup-centric roadmap almost because we were forced to. We didn't really have the technology and the maturity to do everything at L1. And as you said, we've greatly benefited from all of the investments that came from VCs.

• 12:38Speaker 02

  But ultimately, I think the end game, as Uma said, for the native rollup is directionally pointing towards the native rollups. And I think now it's a good time to introduce this idea and start working towards this new direction. And as you said, ultimately, the goal is for rollups to become one with the L1, to kind of unify with Ethereum. And they can do so at the sequencing layer with base sequencing, but they can also do it at the execution layer with native execution. And if you're both base and native, then arguably you're kind of a shard of Ethereum.

• 13:23Speaker 02

  And one way to think of native rollups is as programmable shards, as opposed to the very rigid and non-programmable execution sharding that was suggested in 2020.

• 13:36David Hoffman?

  Maybe with the, maybe I'll characterize the early stages of the rollup-centric roadmap. The Arbitrum optimism base phase of the rollup-centric roadmap is that the rollup-centric roadmap allows for teams to build a layer two that has a high degree of tolerance from the Ethereum layer one. There's not really too much rigidity that the Ethereum layer one extends to the layer two. They're very flexible. They are very customizable. They're very free from being rigidly integrated into the Ethereum layer one. And I think that has allowed, has incentivized teams to be able to go attract VC funding because of, well, Ethereum can't scale, Ethereum needs to scale.

• 14:19David Hoffman?

  We are going to build a layer two on Ethereum and we are going to help scale Ethereum. That's been some of the incentive for VC investment into the layer two space. And I think we also see why, when we look at the sequencer fees or the chain fees that Arbitrum is getting, that base is getting, that optimism is getting. It's a pretty profitable business model and it comes from a large degree of tolerance that layer twos and flexibility that layer twos are allowed to have versus the Ethereum layer one. And I think as we are learning about the benefits and costs of that model, we are learning that there's not a lot of fee value capture back to the Ethereum layer one that comes from this very flexible and free rollup model. And I think that's when we started to learn about base rollups.

• 15:03David Hoffman?

  It's like, hey, if we have base rollups, we can get rid of the centralized sequencer and we can get some layer twos to consume more layer one resources, including mainly sequencing from Ethereum layer one validators. And using more layer one resources. Is a little bit less flexible for the rollups and it consumes more layer one resources. So it's good for ETH layer one value accrual. And then now we also have native rollups. It's like, okay, now we can also repurpose execution. And so my arc of understanding for the Ethereum rollup centric roadmap is we started with this very flexible, free, high tolerance constructions of rollups that allow to do whatever they want and also keep a lot of the value that they that they capture, that they create. And now we're learning, okay, there's, there's an incentive alignment issue with that would

• 15:47David Hoffman?

  between Ethereum layer ones and what could be, excuse me, Ethereum layer twos versus new newer constructions of layer twos, base and native layer twos. And the, the theme that I've seen out of you, Justin, lately, over your last two years is like, okay, there are newer types of layer two constructions that are closer to the heart of Ethereum, that are closer to the economics of Ethereum and are more like technically aligned with Ethereum. Do you agree with that, that long arc of construction of Ethereum layer twos? And what would you add to that?

• 16:16Speaker 02

  So maybe to your surprise, I actually disagree with this take.

• 16:20David Hoffman?

  Oh, interesting. Okay.

• 16:21Speaker 02

  So I, I think what native rollups and base rollups are all about is increasing network effects for Ethereum. And if Ethereum is not, is going to be extractive in the process, then it's going to be very, very difficult for the L twos to opt in to base sequencing and native sequencing. Now, if we can take each independently, for base sequencing, what you stand to lose is MEV. But you know, I have this thesis that MEV more and more is going to be extracted upstream by applications, wallets and users.

• 17:03Speaker 02

  And so it won't be a permanent source of revenue for, for L twos. And so it's not much of a loss for them to become based, but it's a great gain because they gain the network effects of composability. Now, if we look at the, the native rollups, what they gain is the network effects of security, also known as shared security. And that means that you can build money legos that are trustless and that other people want to compose with. And so it's kind of ties in with the network effect of composability. And going back to one of my previous comments, I expect the ultimate bottleneck to be data

• 17:45Speaker 02

  availability, not execution. And so the fees that rollups will have to pay to access this native execution will be minuscule compared to the fees that they will have to pay to consume plain data availability. Now, you could argue that it is indeed very, very bullish for Ethereum, because, you know, we're gonna, we're gonna have a working system with high network effects. And indirectly, this is going to be very, very bullish for Ether, the asset, partly because it's going to need to more demand for the fee burn, but it's also going to create more demand for, for Ether as money and as a pristine collateral asset across the whole ecosystem.

• 18:22David Hoffman?

  Uma, you were nodding your head yes to basically everything that I heard Justin say. Anything you want to add to Justin's commentary?

• 18:30Speaker 00

  Yeah, I think I really agree with Justin's point of view that before we talk about Ethereum value accrual or extraction, first we need to think about Ethereum value creation, right? Like, the rollups are customers of Ethereum, the protocol. They are creating businesses that benefit by using Ethereum. So, for example, I, I talk about this a lot with, you know, looking at staking rewards. If you're trying to just build a chain and you want verifiability and security, one way you can do that is you can build an alt L1. And if you look at Solana, they have billions of dollars of admissions given out. Or you can have a chain that leverages

• 19:11Speaker 00

  Ethereum for DA and then uses ZK for verifiability. And then you also have verifiability and security in this decentralized block space. And it's actually more cost effective for you to build your chain in that way than having to pay a bunch of validators, a bunch of staking rewards. So I think especially as crypto enters its like product era and like more pragmatic era, I think builders are going to start thinking in this more kind of like product mindset of just evaluating like, what is Ethereum giving to me? What's the value it's giving it to me? And is it reasonable to pay Ethereum for the services it's providing? So I think it's really important that like we as the Ethereum ecosystem think of things in that way. And really view Ethereum more as a product.

• 19:54Speaker 00

  And I view native rollups as basically giving Ethereum the product, another very important feature that gives its customers more value and therefore like customers are more willing to pay Ethereum and like, and eventually all of that obviously flows back to Ethereum, the asset in some form. And Ethereum, the ecosystem is very good, but it's actually a very simple value prop. So to make it more concrete, like today, I think John Tarbitt had this really interesting statistic that only 2% of all Ethereum is bridged to L2s, which is actually super low if you think about it. And I think the reason for that is like, if you put your money on L1 and then disappeared for 10 years,

• 20:37Speaker 00

  probably you actually feel pretty good about the money still being there, Ethereum still being alive, it being maintained, et cetera. Whereas if you put your money into an L2 and you disappear for 10 years, right now, there's a lot of kind of assumptions that you'd have to be comfortable with to feel good about that decision. Like you have to trust the Governance Council, you have to trust the Security Council, you have to trust there's no bugs. You have to have a lot of trust in all these actors. And I think the goal of native rollups is kind of to provide this new feature, the execute precompile, that if rollup teams are able to use, then they're able to build systems where their end users feel much more comfortable

• 21:19Speaker 00

  sticking money in a rollup for 10 years and having the kind of same security properties as Ethereum in the rollup form factor, which is what I think is really needed to get more and more money bridged over to these rollups and people transacting on these rollups. So yeah, that's like how I would kind of summarize how I view native rollups. Is this just a new product feature that Ethereum's adding that gives rollup superpowers and awesome security and makes their users feel more comfortable, which you know, makes them enabled to have a better product. And therefore they should be willing to pay Ethereum a little more money in return, which is, it's just a very positive sum relationship, which is awesome.

• 21:56David Hoffman?

  Uma, would you say that when we have the current rollup landscape on one side of things like Arbitrum, Optimism base, and then we have native rollups on the other, is this a trade-off space? Or do you think that this is a strict improvement into like rollup designs? Are we losing something by becoming native? Or do you think that this is just fundamentally a better type of rollup construction and eventually all rollups will look native?

• 22:22Speaker 00

  I think if you're building a type 1 EVM-compatible rollup, like your goal is basically to build a rollup where block space is fully Ethereum-compatible and then also follows Ethereum's like hard forks and upgrades, which is a position that Arbitrum and Optimism have taken today, then becoming a native rollup, I think, is just strictly better. You get better security properties. You don't have to roll your own fault-proof system. And you can really have a credible claim to having L1 security, which is really awesome. But I think the beauty of the rollups under a roadmap is that it allows for infinite customization. So for example, like say you're building an SVM rollup on Ethereum,

• 23:05Speaker 00

  or you're building something like Mega ETH where it's not EVM-compatible. I think their database and state root computation is a bit different. Then those people can't be building a native rollup because like it's just not compatible with the Ethereum spec. But that's really fine. Like those people can exist and like they're just providing a different point on the trade-off space. So I think all options, going forward, all options will exist. Like there will be native rollups, there'll be like EVM-compatible, non-native rollups, there's going to be like SVM rollups, there's going to be really fast rollups. There will be all types of rollups.

• 23:39David Hoffman?

  Okay, I want to try and understand native rollups because I think that's the purpose of this episode. And I think, if my understanding is correct, that really the crux of this conversation starts at the fraud proofs mechanism in a layer 2, or the proof mechanism of a layer 2. And Uma, in your intro, you said all these layer 2 teams have had to like roll their own proofs. We need to make one, each team, Arbitrum, Optimism, they all going to make Make their own proofs. Base, because it's part of the superchain, will re, will use the same proof as optimism, but it's going to use that same proof and it's on a different chain. And I think what you're proposing for native rollups, for how native rollups work, is that actually, we do this thing called an EVM precompile,

• 24:24David Hoffman?

  and that is basically internalizing that role for all rollups on top of Ethereum that want to use that precompile. I don't, I don't think I'd be able to teach anyone what a precompile is, so maybe we can start with that, and then we can extend that to how, how that changes the construction of layer two rollups. Maybe, Justin, I'll throw this one to you. Can you define a precompile? What does it mean to have an EVM precompile? And how does it work? How does that change the game for generating proofs for rollups?

• 24:53Speaker 02

  Absolutely. So just zooming out to the problem that we're trying to solve here. As you said, we have L2s and rollups that have so-called state transition functions, STF. And what it, what that is, is basically taking some sort of input, which is characterized by a prestate root, and advancing the state to get a so-called poststate root. And really, where the proof's coming is to prove that the state transition from the prestate root to the poststate root is correct. Now, traditionally, as, as Uma and you said, you have to roll your own proof system. You have to do emulation that introduces bugs and all sorts of complexities. What if instead, we have the L1 validators

• 25:36Speaker 02

  just do the checking of the state transition on behalf of the L2s and the, and the rollups? Now, what is a precompile? It's basically an instruction for the EVM. So in any instruction set or in any CPU, you have instructions like add these two numbers, multiply these two numbers, push something to memory, read from memory, whatever it is. We usually call those opcodes. But then there's some opcodes that are a little special, that are kind of more complicated, and we give them a different name. Pre-compile. And it basically is just a complicated instruction. And this complicated instruction is kind of a special one because it provides introspection.

• 26:21Speaker 02

  Introspection is kind of this computer science term whereby a system has visibility over itself. Intro means inside inspection, it means like seeing, so you can see inside yourself. And basically what we're doing is we're allowing the EVM to see within itself. And actually, in 2017, Vitalik had essentially this proposal of an execute pre-compile, and it was called the EVM inside EVM pre-compile.

• 26:51David Hoffman?

  And so the EVM, okay, so that was like an early concept of what now we are now talking to be native rollups.

• 26:57Speaker 02

  Exactly right. And just to give you a little bit of a history lesson, the context back then in 2017 was plasma. And so this pre-compile was meant to simplify the designs of plasmas. And then kind of it got ignored and then eventually the proposal was was closed. But but then, yeah, we had the rollup-centric roadmap in 2020. So it predates the rollup-centric roadmap. But now, with the benefit of hindsight, it makes sense to revisit this research topic and apply it not to plasmas but to rollups.

• 27:31David Hoffman?

  I want to bring up Layer 2 B here because Layer 2 B has, you know, it's classic five-slice risk parameters. The five slices that go into risks around a layer two. And I'm just looking at Arbitrum 1 here. And I think the slice that we're talking about here is state validation. And when we say Layer 2s have had to roll their own code, they've had to roll their own proofs, we are looking at that state validation part of the Layer 2 B, like orange slice. And Arbitrum, they have a green slice because they have fraud proofs. And they work in the fraud proof system that they have built is up to a certain standard that Layer 2 B calls it, okay, this is green, this is good, we like it, it does its job, it works, it functions.

• 28:16David Hoffman?

  There's not too much risk here if we're getting a green slice. I think what I'm hearing from you You guys that with native rollups, we just eliminate the slice entirely. In fact, we allow Ethereum, the Ethereum layer one to have like this state sponsored infrastructure that allows layer twos to just use the EVM precompile to do the state validation. And now layer twos don't need to roll their own code. And so this risk vector for layer twos, this whole entire slice just eliminates. And for any native rollup, the state validation, like layer two beat slice is just not relevant because the Ethereum layer one provides that service. Is that correct?

• 28:50Speaker 02

  Yep, that's correct. And you can think of native rollups effectively as unlocking a new level of security for this slice, kind of a bright green fluorescent color. And you can potentially imagine at some point, L2B is introducing a new rollup stage, maybe stage three, where you know, you have this premium level of of security.

• 29:13David Hoffman?

  Since we're on the subject, there's also a sequencer, there's a sequencer, layer two beat slice, and there's like sequencer failure, and what happens if a sequencer goes down with the layer two. And if we're talking about base rollups, base rollups also eliminate the sequencer failure risk to a layer two. And so if we in theory have a native and base rollup, does that mean that state validation and sequencer failure, those two of the five slices in the layer two beat risk orange slice, those are just not relevant. Those are just provided by the Ethereum layer one.

• 29:46Speaker 02

  Yes, that's exactly right. And actually, today, with the L2B criteria, you can have a green slice even with a centralized sequencer.

• 29:55David Hoffman?

  Right.

• 29:55Speaker 02

  And so it's looking at different things. And so I think there really is an opportunity to have these two pizza slices be bright, bright green and to have a state three. And going back to the the state validation, yes, there is some software and some code involved, but there's also ancillary infrastructure. There's proven networks, there's watchtowers in the case of foreproof games, there's security councils, all of that ancillary infrastructure just collapses to one line of code where you're just calling the precompile. And so not only is it a massive security improvement, it's a massive simplicity improvement as well.

• 30:33David Hoffman?

  Can we talk about what happens when rollups become native? I think we touched on it a little bit, but I want to go over and trace that conversation. When all of these rollups are all using this enshrined EVM precompile, they're all using the same fraud-proof system. They're all on like, like kind of on the same circuit. This is when we unlock some composability benefits. Maybe Uma, you can take us back to that part of the conversation and let's like dive into that one. Talk about why all these native rollups being on the same EVM precompile, how and why does that unlock composability across layer twos?

• 31:08Speaker 00

  I think the composability is actually unlocked more by the based sequencing aspect than the native rollup aspect. If all rollups use this native precompile, you just get better security properties. It's kind of this stage three thing that Justin's talking about. And then they're, because they're all using the same proof system, they definitionally have to have the same state transition function. So it's very like homogeneous, uniform block space. But then I think Justin's a better person to talk about this. Once those native rollups start also using based sequencing, that's when they can all do interoperability. And also, these two things are orthogonal. Like you can be native and based, you can be native and non-based,

• 31:51Speaker 00

  you can be any combination of like in the quadrant. Yeah.

• 31:57Speaker 02

  Another benefit of native rollups around composability is the idea of making real-time proving so much easier. And the reason is that the L1 has the ability to cheat a little bit with a proposal called delayed execution, where the state roots can be delayed by one full slot. So this is a proposed future upgrade. And what that means in the context of native rollups is that the validators, that do all the checking of these state transition functions, they have a whole slot to receive the proofs. And that means that those that are generating the proofs have a whole slot to produce them.

• 32:42Speaker 02

  As it turns out, the technology for snark proving can be relatively easily brought down to reduce the latency to under one slot, 12 seconds. But it's much, much, much harder to do the more aggressive thing, which is to produce the proofs in the exact same slot, where the latency will have to be on the order of, say, 100 milliseconds. And so this is where there's a little bit of a synergy between the based and native rollups, where we can get this synchronous composability, which requires real-time proving. But behind the scenes, we're cheating a little bit. It's next slot, real-time proving, not same slot, real-time proving.

• 33:23David Hoffman?

  I think I need a little bit more help understanding that. Because as a user, I'm guessing I'm just on a based native rollup and things are happening very instantaneously. I'm not waiting for another slot on the Ethereum Layer 1, which comes in 12 seconds. I'm not waiting 12 seconds. Something is happening where it's still instantaneous to me as a user, but there's some tricks going on in the background. I could use a little bit more help kind of understanding the mechanisms here.

• 33:51Speaker 02

  Yeah, absolutely. So today, if you put a transaction on-chain, it has to be valid to go in because the validation happens in real time in the same slot. With the delayed execution, we actually relax the rules a little bit. So we say, block proposer, you can propose whatever block you want, and it could be complete garbage. And what will happen is that only in the next lot will the block be validated and processed. And the invalid transactions will be pruned away and will count as no ops. So they don't change the state. From a user's perspective, what you care about is that your valid transactions have made it on-chain. They basically have been included.

• 34:37Speaker 02

  In the DA layer of Ethereum. But from the perspective of everyone else knowing exactly how this transaction executed, you have to wait one slot, especially if you are a like client. Because the way that like clients work is that they basically ask the Ethereum network, the L1 validators, what is the canonical state root? And so like clients have to wait an extra 12 seconds. But if you are a user on the wallet, nothing really changes because the wallet knows that it's a valid transaction that went on chain. And so it definitely knows how the transaction will execute.

• 35:16David Hoffman?

  Can we talk about how ZK proofs are involved here? I know they are because Uma is here and she's excited about it. I just don't exactly know where ZK is actually incorporated into a native rollup, a part of the tech stack. Maybe Uma, you can take this part of the conversation.

• 35:32Speaker 00

  Yeah, definitely. So with the native rollup, you're adding this execute precompile on L1. But so why can't we do this today? You could do this today, but the problem is Ethereum has this block gas limit, right? Of I think it's 50 million target, 30 million limit. And if you add this execute precompile, you can't actually use arbitrarily more gas. Because there are reasons for the Ethereum block gas limit, which is to limit state growth, which is to make sure that at-home validators with a certain hardware can actually process everything, et cetera, et cetera. So without ZK, you can add this precompile, but basically the amount it can be used for is very minimal.

• 36:17Speaker 00

  And so it's not actually scaling Ethereum. With ZK, though, and the delayed state root stuff that Justin is saying, maybe to keep it not go super into the weeds, what you can do is you can have this execute precompile. And then instead of having the validator, all Ethereum validators needing to re-execute all the transactions that go in that precompile, they can instead just verify a ZK proof of the correct execution of that precompile. Then you can have calls to this execute precompile that use basically arbitrarily much gas. And you just have the validators verifying a ZK proof. And so now you're actually really scaling the L1 in a meaningful way.

• 36:58David Hoffman?

  Let me see if I understood that really quick. So we have this EVM execute precompile. And if we just use it in like a vanilla fashion, we're actually not scaling Ethereum. We're just doing this. We're doing, we're doing the same layer one execution, but with this extra step of being inside of the precompile. And we're not actually scaling anything. So I think what you're saying is that in order to actually leverage the benefits of this EVM precompile and actually scale Ethereum, we have to use ZK tech, ZK proofs to scale and then use the precompile to get the benefit and scalability of ZK and then insert it into the layer one EVM via the EVM precompile. Is that how that works?

• 37:38Speaker 00

  Yeah, exactly.

• 37:40David Hoffman?

  Justin, why would you add to this?

• 37:41Speaker 02

  Yeah, one thing I want to stress is that it's possible to have two different flavors of the execute precompile. The simple naive way of doing it, as Uma said, is just to use naive re-execution. And then the advanced way of doing it is with snarks. And one of the big benefits of snarks is that you can dramatically increase the gas limit, 10x, 100x, maybe even 1,000x. Now, the reason why I want to mention, highlight the fact that we can have the simple version is that this may allow us to do a hard fork in the relatively near future. Put possibly, you know, if there's a lot of demand from the community, you know, end of 2026. And the reason is that it wouldn't require any fancy technology.

• 38:23David Hoffman?

  2026, is that in the relatively near future?

• 38:26Speaker 02

  In if time, yes.

• 38:30Speaker 02

  And part of the reason is that we already know what we want to do in the next fork, which will happen in a few weeks. We also know what we want to do in the fork after that. We definitely want to do PiraDAS. And then there's all sorts of things competing for the fork after that. And so, yes, Ethereum does move slow. One of the benefits of shipping the naive execute precompile sooner is that it can actually benefit the optimistic rollups immediately. And the reason is that optimistic rollups only have to call the execute precompile in the fraud proof game, which by default never happens. And so even if the execute precompile

• 39:14Speaker 02

  has a very small gas limit, say a 1 million gas limit or a 10 million gas limit, you can still have optimistic rollups with unbounded gas limits.

• 39:24Speaker 02

  The alternative to optimistic rollups are pessimistic rollups. The reason why I introduce this new term pessimistic rollups is that, you know, ultimately, the enforcement can either happen through snark proofs or through re-execution, both of which are types of pessimism where you want to know upfront that this is valid. The pessimistic rollups will have to wait until we dramatically increase the L1 gas limit, and that will only happen when behind the scenes we're using snarks.

• 39:55David Hoffman?

  Justin, you brought up the idea of Layer 2s leveraging this precompile. Is that all it takes for them to become native? Maybe we can talk about the topic of existing Layer 2s, base arbitrom optimism, the big ones. How do we want them to become native? Uma says it's just a strict improvement. How do we actually do that? What are the incentives to become native? Like, what's the carrot? And then, what's the difficulty as well? Is this like a technical challenge or is this relatively trivial? Maybe, Justin, I'll start this one with you.

• 40:31Speaker 02

  Yeah, so my definition of native rollups is one that uses the precompile to execute user transactions. Now, in order to do such a thing, you basically have to decouple the execution of user transactions, which is known as the EVM state transition function, from all the rest that it takes to launch an L2, which includes parsing the blobs, handling the sequencer, handling the governance, all sorts of system transactions that are peripheral to the user transaction processing. Now, unfortunately, today, the way that rollups have been designed is that they've intertwined

• 41:13Speaker 02

  both the user state transition function from the system-level code. And so what needs to happen is basically for these L2s to refactor that code so that they have a very clean decoupling between the layers.

• 41:29David Hoffman?

  So there is a decent technical hurdle to overcome for the current existing rollups. That's what I'm hearing.

• 41:36Speaker 02

  Exactly right. And I also do want to stress that for some rollups, it's just plain impossible for them to become natives. So if you have a completely different virtual machine,

• 41:47David Hoffman?

  Right.

• 41:47Speaker 02

  Whether that's,

• 41:48David Hoffman?

  Like Eclipse, for example, who uses the Solana virtual machine.

• 41:52Speaker 02

  Exactly. Move, Cairo, Wasm, you name it. It's just impossible. And so the way that I see it is that if it is possible for you to become based, sorry, native, meaning that you are trying to be equivalent, then it's kind of a no brainer. But if you're not, then it's just impossible. And so what I see happening is kind of this bimodal distribution kind of happening where we see a very, very clean separation between the EVM equivalent rollups in one bucket and then the completely different rollups in another bucket. It won't really make sense to be kind of halfway in between where you're EVM equivalent, but you have a few bells and whistles that prevent you from becoming native.

• 42:36David Hoffman?

  Okay, so if you are an EVM layer two, the incentives and maybe it's still like, there's a decent hurdle like we just said, but the incentives to become a native rollup are very large. And it's also possible for you to do so. And then if you're a move-based, any other language, anything that's not the EVM, you just don't get the benefits of being interoperable, part of the shared compositability, the shared network effects that the EVM native rollups do.

• 43:05Speaker 02

  That's exactly right. You don't get the shared security. But maybe that's okay because there's some virtual machines out there, for example, Cairo or Wasm that are either extremely simple and they can be amenable to formal verification or are standards that are completely frozen. The core of Wasm or the core of RIS5 doesn't change. On the other hand, the EVM is a living thing that every six months or 12 months gets updated.

• 43:31David Hoffman?

  What about the, maybe we could just define the incentives as to why a rollup would enjoy becoming native? Especially if you're in an existing ecosystem like Base and you already have huge network effects. What's the motivation for why would they would become a native rollup?

• 43:47Speaker 02

  I mean, as Uma said, it's a dramatic improvement to security and that has downstream effects in terms of TVL. So today, we have less than 10% of all assets that are on these rollups. Really, we should have 90%, close to 100% of assets on these rollups. And I think it's correct to blame, to a very large extent, the possibility for bugs, as well as the security councils that can just, from one day to another, just completely wipe out and drain a rollup. By the way, I have experience with security councils and they use very, very similar processes and mechanisms to the recent hack that we've seen.

• 44:31David Hoffman?

  The Bybit hack?

• 44:32Speaker 02

  The Bybit hack, yes, that used the safe infrastructure. And so I'm actually a little bit surprised that North Korea didn't target a rollup, which has $10 billion of TVL, versus just Bybit, which only has $1.5 billion.

• 44:46David Hoffman?

  That makes it very real for me. I see it as a defense mechanism and I think part of some of our just early ideas of bankless is that like strong property rights is so much of what underpins what is successful in crypto. Bitcoin and the current price of Bitcoin, the value of Bitcoin, I think, comes from its commitments to the 21 million in strong property rights. And I think that we can extend that to like, why is there only 2% of all ETH on layer twos? It's because people, I think, don't believe in the strong property right assurances that layer twos can offer. So the claim here is that the carrot for something like Base or Optimus or any layer two to become native is that you have stronger property right assurances, equivalent property

• 45:31David Hoffman?

  right assurances that the Ethereum one offers and you can take that to the Ethereum layer two. You guys are both nodding your heads, yes. Anyone else want to add any color to that? Uma, what do you want to add to that?

• 45:41Speaker 00

  Yeah, I think the simple like one liner is become native, get more TVO, get more users. And everyone wants that. And that's good for the roll up. That's good for users. That's also good for Ethereum, right?

• 45:56David Hoffman?

  Is there a network effects conversation here? I remember when we were having a conversation, Justin, about base rollups. Is that when there is just one base rollup? That's there's not, there's not that much incentive for one chain, one layer two to become a base rollup. But as soon as there is already a chain that is based, the incentive to become a, you know, join in the base rollup ecosystem becomes larger and it becomes stronger and stronger and stronger, the more base rollups that they are, because there's a composability network effect around base rollups. The benefits of being a base rollup increase as a function of base rollup market share. Is there a similar property like that for, for native rollups? Or is it mostly just about the security benefits that we just talked about?

• 46:40Speaker 02

  I'd say at first order approximation, it's mostly about the security, but there is a second order benefit, which is that as applications become more and more complicated and they use more and more money Legos, they're going to prefer money Legos that are native as opposed to non-native. Now, one good concrete example of a money Lego is ENS. And what we're seeing is the emergence of app chains like NameChain. And, you know, from my discussions with NameChain, they want to become, you know, maximally secure, maximally neutral, so that they're the best money Lego possible. And, you know, they have this roadmap to become based. And they've signaled, you know, recently, just a few weeks ago,

• 47:23Speaker 02

  on sequencing call number 17, along with many other rollup founders, that they're very, very much interested in, in, in, in native sequencing. And for them, it's kind of a no brainer. And, you know, my thesis is that we're going to see more and more app chains. And I think it will make sense for them to become based and non-native.

• 47:42David Hoffman?

  One of the conversations that I want to bring up, so I'll bring it up now, is the idea, the trade-off space of customizability when it comes to Layer 2s and native rollups. So if a native rollup just uses the EVM precompile and it's just repurposing the Ethereum Layer 1, the EVM, that's great, but that also kind of ties them to the mast of the EVM. And upgrading the EVM is possible, and it happens, like you said, Justin, it's an alive beast, but it also doesn't upgrade as fast or introduce the same level of features that I think current Layer 2s are really hungry for. I think the big example here is account abstraction and the war to get account abstraction

• 48:24David Hoffman?

  features into the Ethereum Layer 1, which I think started in like 2017, 2018, and then was just put on the shelf for whatever reason. And then we got it back off the shelf, we dusted it off, tried to put some account abstraction features into the Layer 1 in 2023, or maybe even this year, we finally did it. But meanwhile, over that like six-year-long gap, Layer 2s have been like, "Well, I'm just not going to wait for Ethereum, I'm going to just do my own native Paymaster, I'm going to roll my own code, I'm going to introduce my own account abstraction features into my Layer 2, because of the Ethereum Layer 1, EVM is just not upgrading fast enough. So I'm going to fork away from the EVM standard to build out my own features, because I can do it faster." Now, we're asking, "Okay, but there's benefits to becoming and all using the same EVM standard, so we should do that."

• 49:10David Hoffman?

  But there's a trade-off here, because now Layer 2s can't really access the freedom and flexibility of creating their own, you know, alternative flavors of the EVM to add the features that they want to add. Maybe we can talk about this trade-off space. How can Layer 2s still access customizability and, you know, get the benefits of security that we talked about with native rollups, but not necessarily like tie themselves to the mast and be beholden to the very long Layer 1 EVM upgrade cycles?

• 49:42Speaker 02

  Sure, happy to take this. So, some of the vectors for composability that L2s want is around tokenomics, governance, for example, treasury management, sequencing, if they're doing something special like Unichain, but they don't necessarily want to change the EVM. And if you zoom out and you look at the top L2s, the vast majority of them are at least trying to be EVM equivalent. And every divergence is more of a technical limitation that they haven't yet been able to overcome, rather than something that they fundamentally want.

• 50:23Speaker 02

  I mean, we've seen historically that chains like Optimism kind of rewrote the whole code base to be maximally EVM equivalent. And we're seeing the same thing now with ZK Sync. They used to be merely solidity equivalents, meaning that if you wrote a program in solidity, you could run it on ZK Sync, but they quickly realized that that was not enough, they needed to be bytecode equivalent. And now we're seeing teams like Scroll that are EVM equivalent, but they've changed the state tree to be snark friendly, and now they're moving back to the actual, real EVM

• 51:03Speaker 02

  Ethereum state tree so as to maximize compatibility and minimize the devex friction that departing from the EVM introduces.

• 51:13David Hoffman?

  I think what your answer is, is that the EVM as a standard is actually not where Layer 2s are expressing their interest to have composability or customizability. They're doing it in other venues, other vectors that are outside of the EVM. And what you're saying is like, there's evidence to show that anytime anyone has deviated away from the EVM, they've corrected course and went back to just trying to use the EVM for one for one as possible. And the areas of customizability are like on their token, on things that are outside the EVM. I think that's how I'm summarizing your answer.

• 51:48Speaker 02

  Yep, that's exactly right. And if you do want to fundamentally innovate at the virtual machine layer, because you want to have much more throughput or parallelization, just completely change the virtual machine, move to something like SVM or move or whatever it is. But then you lose the benefit of becoming native. Correct.

• 52:05Speaker 00

  I think there's a lot of customizations that are outside of the EVM that are interesting that maybe are worth touching on. So for example, like what Base did with flash blocks recently, and what UniChain did with flash blocks is an example of a sequencer customization with more sophisticated pre-comps and 200 millisecond block times, but that it doesn't deviate from the EVM spec. So you can have flash blocks, but still be a native rollup. And that's still a better UX. And so there's a lot of aspects that I think you can still improve UX meaningfully while leveraging being native.

• 52:42David Hoffman?

  So on that conversation, you're saying, okay, we can have UniChain, and UniChain could be native and still leverage their flash blocks innovation that allows them to have super fast blocks, but that invalidates their ability to become based, right? Because they're doing their own sequencing, and so they can't be base because they want to kind of like roll their own code as it comes to sequencing. This is my understanding. Is that right?

• 53:05Speaker 02

  Yes and no. So it turns out that it is possible to have some sort of hybrid and convergence towards the two. And in some sense, preconfirmations are prerequisite to becoming based, because base sequencing has these very long slot times. And so things like flash blocks are precisely the technology that are going to unlock base sequencing. Now for UniChain specifically, not only do they want to have these fast preconfirmations, but they also want to be really opinionated on the ordering of the transactions, where they want to order descending by priority fee. This is something that you can do if

• 53:46Speaker 02

  you want, but that's going to damage the composability benefits that you get from being based, because it limits the opportunity for super transactions across L2s that are fully determined by the sequencer as opposed to being constrained by this priority fee rule.

• 54:06David Hoffman?

  I'd like to talk about timelines for all of this. I know that this isn't, there's not one single native rollup project. Maybe the EVM precompile actually is the project. But maybe we can talk about just like the rollout plan for this. So like, what's the timeline conversation? What's the roadmap conversation like? What's the necessary tech required? Does this require social coordination? Whose job is this to get this done in the Ethereum ecosystem? And I know not really a lot of these questions really make sense. And I know if I ask an Ethereum developer, what's the timeline? They're going to give me a very loose, nebulous, it's a rough consensus problem answer. But can we just map this forward as to like where we are now, which is we're talking about on a podcast versus where we want it to be, which is a reality baked into the Ethereum layer one

• 54:50David Hoffman?

  with with adoption. What does the path between AMB look like? Justin, I'll throw this one to you.

• 54:56Speaker 02

  So I think the major bottleneck that we have right now is that we're lacking a coordinator, a champion to take responsibility for this, work full time, just like Tim Baker did to ship EIP 1559. Because there's a lot of coordination to do with the L2s, with the execution layer clients, with the researchers and all sorts of other entities. And so if you're listening to this podcast and you'd like to make a massive contribution to Ethereum layer one, well, there is a big opportunity here to make an impact. Now, assuming that

• 55:35Speaker 02

  we do find a coordinator to champion this, what we're going to need is this hard fork. And, you know, as was mentioned, any hard fork is going to take time because we need to write an EIP, we have to go through the Oracle devs, we have to go through dev nets and test nets. And so it's at the very, very least, you know, a 12 to 18 month process. One of the things that FML1 is trying to do is accelerate the cadence of forks. So historically, we've done forks once a year. We're trying to shift gears and do two forks a year, which is very ambitious. But if we can do so, then we can project ourselves four forks in the future by end of 2026 and envision potentially, if there is demand

• 56:19Speaker 02

  for it at least, an execute precompile, which is backed by re-execution, not by anything fancy like Snocks. And then if you want to project yourselves, you know, three, three years into the future, then we can envision this precompile basically increase dramatically increasing its gas limit and being backed by, by, by stocks. And the reason is that in, by, in three years' time, we should have all of the necessary ingredients to, to do that. We should have the delayed stake roots, which, which was mentioned previously. We should have a very

• 57:00Speaker 02

  strong diversity of mature and real-time ZKVMs. And we should also hopefully have something called attester proposer separation, which allows us to put the burden of proof on sophisticated entities called execution proposers. There are a lot of dependencies to get to the end game, but I think it's important to start planting seeds with this initial version of the, the precompile backed by re-execution, which, as I mentioned previously, if you're an optimistic rollup as opposed to a pessimistic rollup, doesn't have any impact on your business because you can have an unbounded L2 gas limit, even

• 57:42Speaker 02

  though the execute precompile gas limit would be very small.

• 57:46David Hoffman?

  I want to now finally turn to what I actually think is the most fun part of this conversation. Going back to Uma's tweet that really started this all, Uma, you said native rollups solve ETH value accrual. How do native rollups impact the economics of Ether? Uma, I'll throw this one to you.

• 58:04Speaker 00

  Well, we're adding a new feature to Ethereum, the product, which makes it more valuable. And so, okay, solve is a very dramatic statement, but I think significantly help, I think is, is something for sure. On a more practical level, today, I think you see there's kind of these alternative DA solutions popping up like Idin DA or Celestia or Avail.

• 58:30Speaker 00

  And right now, if you're a rollup, you can, you roll your own proof system, you can use all DA, and it's all kind of the same to you and to your users. It's like a first glance basis. With the native rollups, you have to use Ethereum DA to use this execute pre-compiled. And so there's just much stronger kind of lock-in to using Ethereum as DA. And as Justin has been saying, he thinks DA is going to be the biggest source of value accrual in the future for Ethereum. And so having this stronger lock-in, because you're providing this, you know, new feature, I think significantly helps ETH value accrual in this world because rollups are much more likely to use ETH DA.

• 59:13Speaker 02

  Yeah, I would agree with Uma that L2s are more likely to use Ethereum DA and therefore become rollups. But I do want to stress that it is possible to be what's called an optimium, which is to post data in an alternative DA, with an alternative DA provider, and at the same time have this optimistic fraud-proof game. The one thing that is not possible is to be a validium, where you do not consume Ethereum DA and at the same time, you have this pessimistic validation of the state. Now, the other thing that I want to highlight is that

• 59:57Speaker 02

  if you want to be a pessimistic rollup, which I think most rollups will want to be in the future, they don't want to have this, you know, seven-day optimistic game. There is a little bit of an overhead to DA consumption. And the reason is that not only do you have to specify the L2 transactions and blocks, but you also have to specify the state accesses. So every time you read state, you have to put that data on-chain and it's kind of information that currently doesn't go on-chain. And my ballpark estimate, even though I want to do a little bit more of an empirical study, is that this is going to yield, roughly speaking, a 20% increase in demand for Ethereum DA.

• 1:00:42Speaker 02

  At first approximation, it doesn't really change the fee accrual and the economics. But, you know, here and there, at the margin, there is maybe a 20% delta.

• 1:00:53David Hoffman?

  Guys, I think we've covered, I think, everything I understand or know to cover about native rollups. But before we actually close this episode, I kind of want to just open this up. Is there any stone that I've left unturned, any topic that is worth elevating? Or do you think actually we did a pretty good job here?

• 1:01:09Speaker 02

  I do want to highlight two advantages of native rollups that we haven't mentioned yet. The first one, kind of maybe surprisingly, is quantum security. So today, the most of the ZK rollups are not post-quantum secure. And the reason is that they take proofs and then they shrink them to elliptic curve-based proofs, so that they don't pay as much L1 gas when they verify the proofs. With native rollups, there are no proofs that go on-chain. And so there's no risk that they are quantum insecure.

• 1:01:49Speaker 02

  And so what would happen is that automatically, when the L1 validators upgrade their setup to be post-quantum secure, the rollups automatically also become post-quantum secure. And so, in some sense, the L2s don't have to worry about post-quantum security at all. The other benefit that I wanted to highlight is this idea of proof aggregation. In theory, we have this amazing technology, which means that Ethereum only has to verify a single proof for all of the rollups. But we have a human coordination problem, right? We have multiple L2s with different teams that just can't, for some reason or another,

• 1:02:34Speaker 02

  come to consensus on the exact proof system to all use because of competitive dynamics and all sorts of other dynamics. With the native rollups, what we can have, basically, is aggregation of all of the proofs across all of the native rollups happen behind the scenes by the L1 validators. And so ultimately, this is an optimization which could lead to much less gas being spent by the L2s to settle. Because today, if you want to verify a proof on-chain... It's going to cost you, let's say, 200,000 gas.

• 1:03:13Speaker 02

  And if there's, you know, 100 rollups, that's a lot of gas just to verify the proofs with the native rollups, that that that cost is going to dramatically shrink.

• 1:03:24David Hoffman?

  Uma, a question to you. Is succinct relevant here at all? Or are you just native rollup pilled and you thought it was really cool?

• 1:03:32Speaker 00

  Well, I think succinct and ZK and the ZK VM we're building will be used to actually make the native rollup pre-compile scale and have unlimited gas. So that's kind of like the tie into succinct. But beyond that, I just thought it was a very cool design. I think it makes a lot of sense. And I think basically, like, the more activity and transactions that get put on rollups, the better it is for us because like every transaction is going to be ZK proven. And like, I see Ethereum and rollups winning as like succinct winning. So that's why I have a vested interest in making sure that happens.

• 1:04:06Speaker 02

  Oh, actually, I do have one thing I wanted to mention, which is we have this this awesome website, ethproofs.org, which is basically the equivalent of L2B for for ZK VMs. And what we're trying to do is encourage the the ZK VMs to reach real time proving and to lower the cost of of generating the proofs. So what this website shows is the the cost in cents to generate the proof and the latency in in seconds. And where we're at right now is extremely promising because the cost to generate a proof is on the order of cents already.

• 1:04:49Speaker 02

  It's something like five or six cents to prove that a mainnet L1 EVM block is is valid. And the latencies, as you can see here, the proving times are on the order of, call it, two minutes. And two minutes is 10 slots. And so we're roughly an order of magnitude away from a latency standpoint towards the one slot real time proving. And the amazing news here is that this website right now only supports single machine proving. So these proving numbers are on a single GPU. And so you can imagine, once you, once we have support for multi-machine proving

• 1:05:32Speaker 02

  with a cluster of GPUs, we're going to be able to, to, to bring the, the proving time much, much lower. And several founders of ZKVM projects have publicly stated that they believe they can get next slot real time proving this year. And maybe Uma would, can, can talk about this more.

• 1:05:54Speaker 00

  Yeah, we're, I think, the top ZKVM on ETH proofs in terms of latency. And as Justin was saying, right now, the latency for proving an Ethereum block on a single GPU is like a few minutes and the costs are super cheap. And already, if we want with SP1 and what we've built, if we distribute the proving across many GPUs, the latency can be as fast as like 20 to 30 seconds. So we're actually already very close to this 12 second real time, next slot real time proving benchmark that Justin is saying. And we definitely think we'll be able to hit that this year with algorithmic improvements, engineering improvements, and a bunch of other stuff. And so, yeah, that's something to be excited about and be on the lookout for.

• 1:06:39David Hoffman?

  Can we talk about what is unlocked with real time proving? When we hit the event horizon, when we hit that threshold, what does that unlock for us? What doors are opened?

• 1:06:48Speaker 00

  With real time proving actually working and having basically proofs of Ethereum blocks within the next slot, you can add this native rollup precompile and just jack up the gas limit of that, you know, very, very high. So you can basically have like the L1 gas, effective L1 gas of the L1 plus all the native rollups, you know, 10x or 100x, the throughput of Ethereum today, which is super awesome. And yeah, and I know Justin's timeline for native rollups being added to the L1 is late 2026. And I think honestly, the ZK stuff will be ready a lot sooner than that. Cause we're not bottlenecked by all port devs and all the Ethereum shenanigans.

• 1:07:31Speaker 00

  So yeah, I, I, I think we could just ship it. The native role of precomp Paul and ZK, you know, hopefully by 2026 for sure.

• 1:07:40David Hoffman?

  Justin, this is a whole different arena for a question that I'm going to ask you, but I just want to get your perspective on it. It seems to be that all of Ethereum's problems all collapse back down to there's some social coordination issues with the all-core dev calls and shipping upgrades. And I think maybe that's the motivation behind the faster cadences for hard forks, which I think can encourage some faster coordination and allow room for faster coordination. But nonetheless, it's a human, like, why is Ethereum in the place that it is? Well, the answer is, is like, well, Ethereum is a decentralized ecosystem. We've done the research, that's in the rearview mirror. We've done, we can do the engineering, that's not the hard part. It's actually social coordination, and that's always seemingly the bottleneck for Ethereum making progress.

• 1:08:25David Hoffman?

  Maybe you can just like, kind of comment on that analysis. And where do you think Ethereum goes with tackling that problem?

• 1:08:31Speaker 02

  Absolutely, I 100% agree with you that coordination and champions are the number one problem. And actually, recently, a different foundation research team just hired two new coordinators, Lattice Laos and Will. And already, they've only joined for a few weeks, but already we're starting to see a different kind of pace, once we have that kind of support. Now, it's all well and good, you know, to propose these, these big ideas like, you know, base sequencing, native execution and the beam chain. But in order to actually deliver these things to mainnet, we're bottlenecked on coordination. And, you know, I can only do so much. And so what I've chosen to focus on is the beam chain.

• 1:09:15Speaker 02

  And I'm really hoping to delegate both the base sequencing and the native execution to other champions. Now, going back to your questions around governance, what we're trying to do is a couple of things. The first one, as I mentioned, is to try and accelerate the pace of the forks. So that, you know, if there's, if there's small things that we, that we want to, that we want to push, they can be pushed with, with, with lower latency. But at the same time, there's this other effort, the beam chain, which is also about tackling the governance problem, but it has a completely different strategy.

• 1:09:57Speaker 02

  What we're trying to do with the beam chain is basically only focus on research and development and technology for a period of years. And then only at the very end, kind of enter the game of the very expensive social layer where you have to go through the oracle devs, the dev nets and the test nets. And so you can think of it as being a batching optimization at the governance layer. And not only that, it allows us to make bold and ambitious upgrades as opposed to targeting the small and medium upgrades that are currently being shipped with oracle devs. And so if you zoom out, we're kind of shifting gears and having these two parallel strategies.

• 1:10:41Speaker 02

  And so if you're willing to zoom out and look at the bigger multi-year picture, I think it's very easy to have high conviction on Ethereum.

• 1:10:51David Hoffman?

  Justin Uma, thank you so much for joining me today on the show and helping me go through native rollups and everything that they can do for the Ethereum ecosystem. Really appreciate it, guys.

• 1:10:58Speaker 00

  Yeah, thanks for helping us.

• 1:11:00Speaker 02

  Thank you.

• 1:11:01David Hoffman?

  Bankless Nation, you guys know the deal. Crypto is risky. You can lose what you put in. But nonetheless, we are headed into the frontier. It's not for everyone, but we are glad you are with us on the bankless journey. Thanks a lot.