C (2:45)

And Beast Mode, and for mode, I feel like these are just offensive and defensive, like execution. Beast mode is Ethereum is being aggressive. We're going forward. We're. We're pushing forward Beast Mode, and then Fort Mode is kind of what Ethereum has always done, and we are just continuing to do it, which is kind of what we call World War three resistance. It's like everything in the world will go wrong, but Ethereum will still be producing blocks because it's that resilient. It's the bunker coin. So we have like offensive, defensive is. Is maybe like a way to portray this.

B (3:18)

Exactly. And with Snox, we basically have permission to dream bigger dreams on the. On the aggressive scaling and performance.

C (3:27)

And it's worth highlighting, Justin, that Ethereum has never really done Beast Mode before. We've never really gone on the offensive like Lean. Ethereum is kind of the first time that we can actually credibly say, yes, Ethereum is scaling not marginally, but aggressively. Is that correct?

B (3:50)

I mean, I would argue that the data availability that we've been working on for many years now is part of Beast Mode for unlocking the L2s for. But the L1 has remained stagnant at the L1.

C (4:02)

Beast mode at the L1.

B (4:04)

Correct. So for four years. Well, four years ago, the gas limit was 30 million gas, and today it's 45 million gas. So in four years we've only scaled the gas limit by 50%, underperforming even Moore's Law and hardware improvements.

C (4:20)

Not very beast, not very beastly.

B (4:23)

But now, again, we have the permission to be extremely ambitious now that the technology is reaching maturity.

A (4:30)

Okay. Last four years, we've gone from 30 million to 45 million on the Ethereum layer one. As I understand it, though, in the early days, maybe this is back in 2016, it was like 6 million gas limit. So we did go from something lower to 30 million. And the way we accomplished that is just like raw engineering. But to call that scaling on the L1 anyway, beast mode, not quite right. I mean, what did we do? This is like a, you know, 3 to 5x something like that. And it took, you know, 10 years of Ethereum history. But when we say gas and gas limits and that sort of thing, what we're talking about is transactions per second. Right. Or at least it's a proxy for transactions per second. We're going to be referring to, you know, block size threshold throughout this episode a lot. So can you just define what block size actually is and how that relates to transactions per second and just like overall scaling?

B (5:32)

Absolutely. So the simplest transaction possible is called a transfer, and it consumes 21,000 gas. You don't have to remember this number, but on average we're doing more complex transactions. For example, we have dex swaps and those consume 100,000 gas. So if you have 1 gigagas per second, that's 1 billion gas per second. And you divide that by your average transaction of 100,000 gas, you get the 10K TPS. And continuing with our theme of powers of 10, there's roughly 100,000 seconds in a day and there's roughly 10 billion people on Earth. And so if you were to denominate it per human, what you get is 0.1 transactions per second per human per day. Which in my opinion is a great start, but it's just not enough for all the finance. Right. As humans we make more than one financial transaction every 10 days.

A (6:28)

And there's also the robots that are coming on chain too.

B (6:31)

Absolutely. A great amplifier. And so what I'm hoping we can achieve in terms of scale in the longer run is 10 million transactions per second. That's the Teragas error. And that unlocks 100 transactions per day per human.

A (6:46)

Okay, but so the one gigagas is that the hope is to achieve that. And the plan in Lean Ethereum is to achieve that on Ethereum layer 1. Am I correct in that? And then the Terra gas is in the Ethereum layer 2 ecosystem by committing, you know, data to the Ethereum's scaled up data availability layer.

B (7:07)

Correct. So Terragas is the aggregate of all of the rollups combined. And you can think of it, roughly speaking as being 1000 copies of the L1 each doing 1 gigagas.

A (7:20)

Okay, where are we now? So if we're trying to get to Gigagas on the L1 and TER gas on the L2, you mentioned some numbers of where Ethereum is. Was it 60 million gas limit, what's the current gas limit? And how far are we away?

B (7:37)

Yeah, so the gas limit is a little confusing because we have slots of 12 seconds. You have to redenominate everything down to the second. But at L1 we're about 500x away from that goal. So between two and three orders of magnitude. And to a very large extent, the primary bottleneck that we have today is the validators. So we set ourselves as a constraint, as a goal to have maximum decentralization. And we're not allowing the validators, or at least we're not assuming that the validators have powerful hardware. They're running on laptops. The meme has been Raspberry PI. And by removing this Bottleneck, we can easily, in my opinion, get a 10x100x and with sufficient work we can get this 500x that gets us to 1 gigag per second.

A (8:28)

Okay, and so how many gigags is Ethereum right now? So you said it's just because we're translating multiple things.

B (8:35)

You said it's 2 megagas per second.

A (8:39)

It's how much?

B (8:40)

2 megagas per second.

A (8:42)

Okay, so it's 2 megagas per Second right now.

C (8:45)

And we want 1000 mega gas.

A (8:48)

Okay. That's why we're 500x off. Another way to translate that is we have around 20 transactions per second, maybe for those simple transactions on Ethereum and we want to be 10,000. So again, that's 500x off right now. That's what Beast Mode is saying, we're going to do 500x on Ethereum layer one. Correct.

B (9:08)

That is by hope. That is the vision that I'm trying to put forward. And slowly, every week with more and more developments on the ZKE VMs, people are starting to believe this vision, that it is indeed possible.

A (9:20)

Okay, that's interesting. So we're going to talk about vision and execution throughout this episode in many places. But actually before we do, since we're still setting the context for this, I think some people will be scratching their heads and saying, well, why are you, Justin, talking about. And why is Ethereum in general talking about scaling the L1 at all? I thought the plan was the rollup centric roadmap where Ethereum layer 1 stays pretty slow. Yeah, maybe it scales up a little bit as Moore's Law improves and as engineering improves a little bit. But it's not going to be Mode because the Beast Mode plan, I thought that was already defined as the roll up centric roadmap. And all of the scale in ethereum happens on L2s. Well, you're saying, no, we're going to continue scaling the L2, but we're also scaling the L1. And some people will be scratching their heads and asking, why is this a change? Is this a pivot? Why are we trying to scale the L1 in the first place?

B (10:25)

I'd say yes, it is a change. It is a pivot because we have now technology that allows us to scale while preserving decentralization. So what came first was the requirement for decentralization and then we tried to do the best with that requirement and that's the status quo that we have. But now that we have a new technology, we can start rethinking the kind of scale that that we can have at L1. So the first answer is just because we can. The second answer is that if we want Ethereum L1 to be a hub, meaning the place where assets are minted, where bridging happens, where forced withdrawals happens, where a lot of the high value liquidity happens, then we need L1 to have a minimum amount of scale and 0.1 transactions per human is. You should think of it as being the highest density economic transactions that can make it. Everyone else will largely be potentially priced out. So you can think of it as being settlement transactions, as being minting transactions, as being transactions where you enact an escape hatch, you have $100,000 stuck on an L2, the sequencer has gone offline or something. Well, you can just force withdraw and you'll be willing to pay the $0.10 or whatever on L1 in order to free your funds.

A (11:51)

So those are the two reasons. Going back to the first, then, because we can, this implies we couldn't before. And we'll have a whole conversation about snarks and this magic cryptography that has emerged, let's say, and hardened over the last decade or so. But the idea that we're scaling the L1 now because we can means that previously we couldn't. It almost means that scaling the L1 would have been the first option if we could like, is scaling the L1 better than scaling the L2? And if we could back in, say 2018, Snarks was unleashed, then that would have been the default path rather than L2s.

B (12:39)

I think so. I think had we been able to scale, let's say five years ago with ZK vms, that's probably what we would have done, but it would not have been sufficient. We still would have had to go down the path of data availability to unlock the millions of transactions per second that we need to welcome all of finance. And so in some sense there's like a different ordering that will have happened. But I think we still would have gone down the difficult path of working with snarks for execution and working with data that will be sampling for bandwidth. And you can kind of think of these two tools, snarks and data availability, as being two sides of the scaling coin. It's basically bandwidth and compute, which are the two primitive resources that a blockchain will consume.

A (13:31)

Some people will still be confused by that answer, Justin, because they will say, wait, wait a second, why couldn't you scale Ethereum in 2018? And they'll point to other layer one chains today that are indeed Scaling, I mean you've got some L1s that are saying they can scale to 10,000 transactions per second and beyond. Some are in the million time range. I think Solana is doing, you know, thousands of transactions per second at peak at least and they promise far more. So was this a skill issue? Like why couldn't Ethereum scale?

B (14:09)

Yeah, it's a good question. So a lot of the high performance L1s have relatively poor decentralization. So on the order of 100 validators. So you know, Monad for example, roughly speaking, ballpark, they have a hundred validators, say 100 validators, you know, BNB chain even less. And not only do they have a small number of validators, but also the barrier to entry to becoming a validator is to have a server in the data center because you need to store a lot of state, you need to have very reliable and high throughput Internet connection, you need to have lots of RAM, you need to have fast CPUs and that's the kind of thing that's more difficult to get at home. And it's also the strategy that Solana has taken. So Solana on average does about 1,000 user transactions per second and they have less than 1,000 validators. And if you look at the map of where these validators are, it's almost entirely in data centers and the vast majority of them are more than 50% of them are I believe in two data centers that are like just a few dozens of kilometers apart from each other in Europe. So it's highly, highly concentrated and that's not something that we have tolerated on Ethereum.

A (15:40)

Can you name the constraint then? So it seems like Ethereum is not tolerating something, not tolerating validators running inside of data centers. So there is some self imposed constraint on the design here. Name that. What is that constraint versus like why can't we just capitulate and start running things in data centers like some of the other chains have started to do?

B (16:05)

We care about home Internet connections and commodity hardware like a laptop. And part of the reason has to do with liveness. So you know, recently we had an AWS outage, various chains went offline, that's not what we want with Ethereum, but we're kind of very paranoid to the point where we want to have a security model where even if all data center operators in the world decide to attack Ethereum simultaneously, it still has uptime and there's roughly call it 100 data center operators in the world. So this is not totally far fetched. And I guess another difference is that, you know, we're trying to have best in class uptime, right? We've, we've had 100% uptime since Genesis and part of that is not cutting corners. And I think what some of these other chains have done is they've been willing to cut corners in order to get to get higher performance.

D (17:09)

Introducing FRAX USD the genius aligned digital dollar from frax. It's secure, stable and fully backed by institutional grade real world assets, Custody by BlackRock, Superstate and Fidelity. It's always redeemable one to one, transparently audited and built for payments, defi and banking. The best of all worlds. At the core is fraxnet, an on chain fintech platform built to align with emerging US regulatory frameworks where you can mint, redeem and use FRAX USD with just a few clicks, deposit usdc, send a bank wire or tokenized Treasuries and receive programmable digital dollars straight to your wallet. Fraxnet users benefits from the underlying return of U.S. u.S. Treasuries and earn just by using the system. Whether you're bridging, minting or holding your FRAX USD works for you. FRAX isn't just a protocol, it's a digital nation powered by the FRAX token and governed by its global communities. Join that community and Help shape Frax Nation's future by going to frax.comr Bankless Frax designed for the future of compliant digital finance. Imagine a world where traditional finance meets the power of blockchain seamlessly. That's what Mantle is pioneering with Blockchain for Banking, a revolutionary new category at the intersection of TradFi and Web3. At the heart is UI are the world's first money app built fully on chain, it gives you a Swiss IBAN account blending fiat currencies like the Euro, the Swiss Franc, the United States Dollar or the Renminbi with crypto all in one place. Enjoy real world usability and blockchain's trust and programmability transactions. Post directly to the blockchain compatible with Tradfi Rails and packed with integrated DEFI futures. You are transforms Mantle Network into the ultimate platform for on chain financial services unifying payments, trading and assets like the MI4, the Meath Protocol and functions and FBTC backed by developer grants, ecosystem incentives and top distribution through the UR app, reward stations and Bybit launch pool for MNT holders. Every economic activity in UR drives value back to you, embodying the entire stack and future growth of this super app ecosystem. Follow Mantle on Xantle Underscore Official for the latest updates on Blockchain for banking, that's X.com mantle underscore official. Ethereum's layer 2 universe is exploding with choices. But if you're looking for the best place to park and move your tokens, make your Next stop Unichain first. Liquidity Unichain hosts the most liquid Uniswap V4 deployment on any layer 2, giving you deeper pools for flagship pairs like ETH USDC. More liquidity means better prices, less slippage and smoother swaps. Exactly what traders crave. The numbers back it up. Uni chain leads all layer twos in total value locked for Uniswap V4. And it's not just deep, it's fast and fully transparent, purpose built to be the home base for defi and cross chain liquidity when it comes to costs and Unichain is a no brainer. Transaction fees come in about 95% cheaper than Ethereum Mainnet, slashing the price of creating or accessing liquidity. Want to stay in the loop on unichain? Visit unichain.org or follow unichain on X for all the updates.

C (19:53)

When we talk about going from doing a 500x in terms of gas throughput from where we are now at 2 mega gas a second to a thousand mega gas a second, a 500x is not just something that you can engineer. The reason why we are doing this today is because Ethereum is going through something closer to an evolution rather than like an engineering upgrade. And some of the chains that we just talked about have always been like engineering first and that's where some of the performance benefits has come from. Like Solana has been very engineering heavy and they have just produced well engineered nodes and execution clients. And then where are those, where is that software best expressed to be its best form? Well, in a data center. Put the heavily engineered things in a data center and that's where a lot of the modern scaling chains of 2020 through 2025 have gotten some of their throughput. Now Ethereum has been patient, but in order to get that 500x, it's not really an engineering thing, it's more of like an evolution. A new path has opened up with some, with some of the stuff that you've talked about Justin, with the whole ZK era, where it's not necessarily just engineering but it's actually cryptography that is opening up a path to do something like a 500X. And so that's kind of, and that's always kind of been in the back pocket of Ethereum from day one. That's always been like the theoretical scaling strategy. And in recent years, I think you and people in the Ethereum foundation would be like, okay, this path is now clear to us and now we are ready to take it. Is that, that's kind of my diagnosis of the last few years, Is that right?

B (21:32)

Yeah, that's right. Really the key unlock here is just cryptography. And in terms of the requirements that we have for the cryptography, those are also extremely high. So one of the things that we care about, for example, is diversity. This is complicated cryptography and we want to have the same kind of diversity that we enjoy today at the consensus layer and execution layer with the consensus teams and the execution team. So I'm hoping that we can have five different ZKEVMs with uncorrelated failures. Another strong requirement for the cryptography is called real time proving. There's this idea that when a block is produced, the proof for that corresponding block needs to arrive before the next block. So the latency needs to be under one Ethereum slot, which is under 12 seconds. And then another requirement that we have beyond the security and the latency is the power draw. So going back to this comment, around the data centers, we don't want the provers to themselves be in data centers because now you've introduced a new choke point. And so what we are hoping to have is on premises proving. And by on prem, we mean on premises in a home, in a garage, in an office. And the specific number that we have in mind is 10 kilowatts. So just to give you an order of magnitude, a toaster will consume 1 kilowatt. So it's the equivalent of 10 toasters. And it's also the same as a Tesla home charger that will draw roughly 10 kilowatts. And so if we can have millions of home chargers around the world, then it's reasonable to have this requirement for the provers. And one thing that is worth stressing is that unlike consensus, which requires half of the participants to behave honestly, we only need one honest prover for the whole thing to work out. So that's why there's very different hardware requirements on the consensus participants here. We want to have the lowest barrier to entry as possible. Think a Raspberry PI or a laptop, because it's a 50% honesty assumption. But for the provers it's a one of n assumption and it's okay to bump it up.

A (24:02)

Okay, so we're starting to unpack almost the beast mode layer, the execution layer with some of those components. But I personally am still not ready to get there, actually. So I still have some questions. What you just described is a stack that allows us to still do the blockchain validation or verification outside of a data center from a home Internet connection. And I still kind of want to know why or like, what use cases are important for that. You said part of this is about liveness and uptime, and indeed ethereum has had 10 years of uninterrupted uptime, and that's fantastic. But there are other properties that decentralization and uptime kind of imbues. One of those, quite famously with Bitcoin and Ethereum, as you've come and argued on Bankless, is the property of having your cryptocurrency be a store of value asset. So Bitcoin is still on the cryptography 1.0. It's not doing any snarks thing. That's not really in the roadmap. But it has maintained very low throughput, very low through tps, but also very low node requirements. So you can, you can run a Bitcoin node from your house. It is not a data center chain similar to Ethereum. But I just kind of want to know why. Because for Bitcoin, they're very clear on why. It's because Bitcoin is a store of value. It's because it's a digital gold and everybody needs to access it. Now, we've argued on bankless that at 10 transactions per second, some of that access will probably take the form of MicroStrategy and ETFs, and you won't be able to do things in defi that you can if you're actually scaling your base layer. I don't want to rehash that, but I do want to ask the question of why what use cases on the Ethereum L1 are important. Vitalik wrote a blog post talking about slow defi is that one of them is the store of value use case. I'll just add one other dimension. We've had people come on the podcast and say the Ethereum roadmap is flawed because they obsess over decentralization. They obsess over having nodes being able to run in somebody's home. If you remove this obsession, you could scale a lot faster and they don't understand the reason for the obsession. So what use cases is like Ethereum over provisioning itself? What use cases are most conducive to this decentralization? I'll call it obsession Constraint that Ethereum has self imposed. Is it defi, is it store of value? What is it?

B (26:44)

It's store of value, it's moneyness. And you can look at it empirically speaking. You have the number one money, Bitcoin, which is the exact opposite of Beast mode. Right. It's a piece of crap. Right? It's like.

A (27:02)

What'S a piece of crap?

B (27:06)

Blockchain, the chain. Sorry. So you have which.

D (27:09)

Which even bitcoiners will say that the.

C (27:11)

Bitcoin blockchain is an encumbrance upon btc, the asset that's actually aligned with Bitcoiner philosophy.

B (27:17)

And yet it's a $2 trillion asset. And then you have something in between Ethereum which is trying to get some performance and some robustness and incredible neutrality and we're a $500 billion asset. And then you have something that leans entirely on Beast mode like Solana and they're a $100 billion asset. And those of the newer chains that are leaning even more on Beast mode have lower valuations. And so I think the moneyness requires this mimetic premium. And there's just the market empirically has told us that robustness, thought mode, uptime, credible neutrality, moving slowly, having these long term guarantees are something that are things that are extremely important.

A (28:12)

It makes sense to me that store of value would be the primary use case for something like a Bitcoin or Ethereum. Because if you just think about it from a user perspective, you want to put your value in a place you can go into a cave, you know, for 10 years and come out and it's still there. That's store of value. You're actually storing value across time. Right. And Bitcoin kind of has gotten this right. But I think when you're talking about store of value, it's also bearer instruments, you know, like. So for instance, I don't know if I care about USDC on Ethereum as a store of value and put that on Ethereum and go into a cave for 10 years and come out. I don't know what could happen to usdc. It could, you know Jeremy, earlier I'm sure it's in gray hands. Whatever laws could change, you know, it could depeg something bad could happen to usdc. So the store of value use case is really like centered around the crypto native assets on Ethereum chiefly. Eth. Like Ether is the asset primarily for store of valueness on top of Ethereum. So when I think about the tangible use cases and you say kind of store of value, the Things that require max decentralization. It's probably ether the asset and then maybe a handful of kind of defi primitives. That's what I think. And it's not so much the real world assets, except as they act as a trading pair for something like Ether. That's how I see it. But this is why I'm curious to like understand how you see it, Justin, and how people within the Ethereum foundation see it. Like what are the apps that are going to be most important on the layer one?

B (29:59)

I mean different people have, have different opinions within the Ethereum foundation. But I would agree with you that Ethereum's most important application is being money. And that's from which all of the applications derive. If you want to have loans, exchanges, if you want to have prediction markets, it's all to a large extent predicated on having this strong money. And this is especially true with these power law distributions and winner take most situations. I've tried to argue that a single chain like Ethereum can handle all of finance to a large extent. The reason why we have so Much fragmentation at L1 is because Ethereum hasn't grown fast enough to absorb all of the innovation, but now we have a credible roadmap to just absorb the entirety of it. And when you look at monetary premium, it's winner take most. You need to somehow convince society that your asset is the most legitimate one. And if you look at competitors, for example, you look at sold, the asset that's just been disqualified for being money. In my opinion, the fact that it had 10 outages over a handful of years just disqualifies it immediately. And so the most important thing is just staying long enough in the game and not to get disqualified. And now we have these two basically assets that are competing, Bitcoin and ether. And I think in a few years Bitcoin will get disqualified because of its blockchain as well. Not because it failed beast mode, but because it failed fort mode. It will not be able to secure itself with the dwindling issuance.

A (31:56)

Dwindling issuance is kind of the bear case for Bitcoin.

B (31:59)

Then yes, if you look at transaction fees right now it's about half a percent of all of the revenue that miners make. So 99.5% comes from issuance. And we know that that fraction is going to zero. Right? We're halving every four years. And right now Bitcoin is secured by three Bitcoin per day of fees. Three Bitcoin per day is just not enough to secure Bitcoin so we've talked.

C (32:24)

About the dichotomy between Beast mode and Fort mode and now I do want to kind of like maybe name our biases just because me, Ryan, Justin, we all came into Crypto into Ethereum 2017 and earlier and that's truly when decentralization Fort mode was, was, was the game. And that's kind of like our generation of crypto. The newer generations of crypto truly value Beast mode far more than Fort Mode. I think like anyone that has come into crypto 2021 or later probably has a disproportionately low amount of their portfolio of Bitcoin versus people that came before 2021. And something that I want to like, even though we were talking about like yeah, the whole idea is money. The Fort mode is your entry ticket into being inside the competition of money. Nonetheless, user preferences post 2021ish has really preferred Beast mode and transaction, transaction volume, transaction fees has slowly the pendulum has shifted towards chains that go fast change that do Beast mode. And so wow, Beast mode, I would.

A (33:31)

Add David, regardless of constraints, right?

C (33:33)

No, regardless of constraints.

A (33:35)

Home validator type of constraint.

C (33:36)

Yes. And so I, I don't want us to like talk down too much about Beast mode because actually that's what Ethereum is trying to do in 2025 and beyond is like we feel like we've covered Fort mode and now, now we can unlock Beast mode and Beast mode has a lot of value. That's where you get, you know, global composable finance all on one chain. That's where you fit all of humanity, all the finance, all on one chain. That's where you get user adoption and all the, all the great things that come with a smart contract chain. And so it's while I, I'm in this camp, we're all in this camp of like kind of Fort mode is the cool thing that blockchain is really uniquely provide to the world.

D (34:18)

Nonetheless, user preferences has been shifting away.

C (34:20)

From Fort mode and into Beast mode as blockchains become mainstream adopted and now Ethereum strategy is to aggressively penetrate that market with some of the technology and the strategies that we're going to talk about in the remainder of this episode.

B (34:34)

Yes. So I do agree that Ethereum is trying to chart a new territory for itself with Beast Mode. But one thing that I want to highlight is that if you have Beast mode without Fort mode, it's very shallow activity. And one way to actually measure this is to look at the meme coins on Solana. That's where a lot of the activity happened. And. And you know, we have over 10 million meme coins on Solana and the aggregate market cap of all the meme coins on Solana is less than $10 billion, which is an absolute drop in the bucket. So yes, there was a lot of.

C (35:09)

Is $10 billion a drop in the bucket?

B (35:11)

So, you know, relative to Stablecoins, for example, like a single StableCoin on Ethereum, L1Tether is over $100 billion. So that's just one use case 10 times bigger. You could look at loans on Avid, that's like also tens of billions of dollars. But you can also look at the Ethereum market cap that's 50 times bigger. That's one asset 50 times bigger than 10 million assets combined.

A (35:37)

Maybe we'll talk more about stablecoins later in the episode because I do have this outstanding question of to what extent do stablecoins actually need the Beast mode with decentralization security guarantees of Ethereum, the L1? But let's reserve that question for later. And let's take this in the sections that you laid out. So back to what you were saying earlier in the episode when I asked the question, what is Lean Ethereum? You said it's snarks. That's the magic cryptography that we've unlocked. It's Beast mode, which is scaling ethereum on the L1 and the L2 from a transactions per second perspective. And it's fort mode, which is defending decentralization, the lowest barrier to entry possible for someone to run a node. So let's take the rest of the episode and get into each of these sections. Snarks. Okay, this is magic cryptography. Justin, we had you on an episode. I think this is maybe the first episode that you did with Bankless. This must have been about four years ago. And you had this principle that has stuck with me since, which is basically like the true way blockchains scale is with cryptography. That's the first choice. That's kind of how Bitcoin was able to do what it's doing. And then when cryptography fails, you go to economics and crypto economics. But the gold standard is if you can scale with cryptography in any kind of protocol design or mechanism design, then you do scale with cryptography. Both Bitcoin and Ethereum were based on cryptography that has been popular for a while. I don't know, I'll call it the cryptography that had Lindy in the 2010s. Right? That's what Ethereum has been based on so far. Now Enter snarks. Give us a history of the cryptography that Ethereum is based on today and this snarks based upgrade. And what is this new cryptography?

B (37:36)

Yeah, so since Bitcoin, the cryptography that we've been using is extremely primitive and it's two different pieces of cryptography. The first one is called hash functions. That's the thing from which you can build blocks and chains. It's the thing that you use to merkle the state and basically it's lots of merkle trees. And then the other piece of cryptography is called digital signatures or just signatures and that allows you to authenticate ownership and sign transactions. And nowadays looking back in 2025, this is Stone age cryptography relative to what we have today. And this new primitive snarks really unleash a whole new design space for blockchains and in particular they allow us to solve this dilemma, or some people call it a trilemma between scale and decentralization. We really can solve this age long trade off by basically having the validators verify these short proofs and these proofs behind them having as much execution as the block builders and the chain can absorb. So if you look at the two basic resources that we have to scale, the first one is execution, we have snarks for that. And the other one is data. And here we have the data ready sampling. Now in addition to wanting to have these two unlocks from a scaling perspective, we also want to make sure that the cryptography that we have is long term sustainable. And what that means in our context is post quantum secure. So today for the data availability sampling we've taken a little bit of a shortcut. We've deployed cryptography called kzg which is not post quantum secure. And so we need to have some sort of a plan to upgrade that. And this is where snarks also help beyond just scale, they also help with the post quantum security at the data layer.

A (40:04)

I think back four years ago you were talking about snarks and a term you used, in fact I think we titled the episode is Moon math. Right. There's kind of this emerging moon math and it's been out for a while just for people who are not cryptographers. Okay. I mean we don't need to get into the details of what snarks are and what can do. I think for a lot of people listening it's sufficient for them to understand, oh, this is moon math and it's been used in practice for a while and it's, it's reasonably safe. When we say snarks and zk, because you used the term ZK evms earlier, ZK and snarks. Are they one in the same or like, how come we use ZK sometimes and now you're using snarks today? Like people maybe don't understand the differences between these terms.

B (40:51)

Sure. So the technical term is snark. The S stands for succinct. You can think of it as being small. And then the narc part, non interactive argument of knowledge. That's just a fancy mumbo jumbo for proof. So snark is nothing more than a small proof. Now it turns out that this technology snarks also give us for free another property called zero knowledge, which is relevant in. In the world of privacy. But we're not using that property for scaling. We're only using.

A (41:25)

How can we call them zkevms?

B (41:27)

It's so confusing.

A (41:28)

They're not private.

C (41:29)

We don't do a very good job of naming it.

A (41:31)

Should they be called Snarky VMs? Really?

B (41:33)

They should be called Snarky VMs, yes.

A (41:35)

Okay. We won't win that fight today. We're not here to play that game.

B (41:40)

It's a lost fight.

A (41:41)

How long have snarks been out there? So all the first generation chains today, all the chains that we have in production, Bitcoin, Ethereum, that's all been using more primitive cryptography, as you said. Hash functions, digital signatures. There was this experiment called zcash, and the Z, I think, stands for zero knowledge or snarks. Right. They use some of that tech and that's been live since, I don't know, 2014, something like that. Zcashers. Correct me on the dates here, I guess. How robust is this technology? How lindy is it? How in use is it? Are we sure we're ready for snarks for primetime now? On a chain that secures almost a trillion dollars in value.

B (42:20)

Right. So Zcash was launched, I believe, in 2016, nine years ago. And when you look back, they were absolute pioneers. But they were also degens, like cryptographic degens. They deployed the cryptography, which was like building rockets. It could explode in their face. And actually there was a moment in time where it did explode. Right. I don't know if you remember, but like a few years ago, zcash had this critical bug where anyone could mint an arbitrary large amount of Z.

A (42:53)

Right. And because it's private, we don't actually know if that happened or not, if the bug was exploited or not. Right. We don't know for sure, exactly.

B (43:02)

And so, and one of the big things that we have to do is solve this security issue and this broadly. Two solutions that are satisfactory for Ethereum. The first one is to have diversity of snarks. So you have five different snark providers and you accept a block to be valid. For example, if three of these snarks return valid and you can move on in a very similar way that we have execution and consensus layer diversity. The other way forward is what we call formal verification, where we just pick a single proof system and we audit it to the point where we have high guarantees that there's literally zero bugs. So it's a little bit like writing a mathematical proof of correctness of your entire snark implementation. Now, unfortunately we're a little too early for that end to end for more verification, but we've started the work. So last year we announced a $20 million formal verification program which is led by Alex Hicks. And a lot of progress is being made. And my expectation is that this decade, you know, maybe in 2029, 2030, we will have an end to end formally verified snark, which has zero bugs. Now the other thing that I want to mention is that zcash had an extremely simple use case which is just transfers. And what they did is that they wrote so called custom circuits. So they were getting their hands very, very dirty with the, with these snox. But the modern approach is what are called ZK VMs, which is basically a way to make use of the power of snarks without being a snark expert. So a typical developer, like a Rust developer, for example, can run right typical programs and compile them to the ZK vm. And this is actually one of the requirements in order for the SNOX technology to be mature enough for the L1. And the reason is that we want to take the existing EVM implementations and compile them to the the zkvm. So for example, revm, which is the EVM implementation within Ref, which is one of the execution layer clients, we take that, we compile it to the ZKVMs. We can take EVM1, which is another implementation, compile this EFREX, there's Zksync OS and there's also implementations that are written in Go. For example, GEF has an enemy implementation, never mind has an implementation in C. And we want to take as many of these implementations as possible and compile them to the kvm. And that is a very recent trend. It's something that has only really existed for One or two years.

A (46:03)

But we feel fine, I guess, relying on snarks as a theory, like as a core technology for ethereum at the L1 layer. I mean, they're not as mature as hash. Hash functions, which have been around since, what, I don't know, the decades, right? 1970s, 1980s, something like this. Digital signatures as well. I mean, these are very hardened cryptographic primitives. Snarks are, what, 15 years old?

B (46:34)

So theoretically speaking, something like 30 years old. But in practice, Zcash was one of the first projects to bring them in production, and that's about 10 years old.

A (46:44)

Okay. But we feel fine about snarks as a tech stack now. And in general, as this are snarks kind of commonly accepted in, you know, deep cryptography circles as like, yep, this works. The math checks out, can't be broken.

B (46:58)

Yes, but there's like, snarks and there's snarks. So we have all of the requirements. We have real time proving as a requirement. We have diversity, we have the ZKVM aspect, and we also have the real time proving requirement, and we have the requirement of 10 kilowatts for liveness.

C (47:19)

There's a Elon Musk quote that I think is relevant here that I like, which he says, the most common error of a smart engineer is to optimize a thing that should instead be eliminated. I want you to take that metaphor as to, like, why are we doing this? So we're talking about the snarks and the math behind them and how they work. Let's actually zoom out and talk about, like, the why. Because this is actually doing the thing that would make Elon Musk happy. It's eliminating a whole entire component which other chains have chosen to optimize. Can you talk about that a little bit?

B (47:50)

Absolutely. So today, when you run a validator, you're running two separate clients. You're running a consensus layer client. So at home, I'm running one called Lighthouse, and you're also running an execution layer client. And what I'm running at home is called gef. And really what we want to try and be doing is removing the bottleneck to scalability. And in this case it's gef. Like gef, literally on my computer, can't process a gigahertz per second, partly because, you know, the hardware is not adequate, but also the software is also not adequate. And what I'm hoping to do at DevConnect in about 25 days is shut down my Geth node and completely remove that bottleneck. And instead of relying on Geth to tell me that blocks are valid. I will be downloading ZKEVM proofs and it doesn't matter how big the blocks are, from my perspective, the proof is always the same size. That's the S. It's not. It's succinct. And yeah, that resonates very much with Elon's quote, which is that we shouldn't be optimizing Geth, we should just be removing it completely.

A (49:02)

So that brings us to, I think, this whole lean execution kind of trade and talk about that in more detail. So we have this new snarks, magic cryptography that allows us to scale Ethereum in general. In particular, we'll talk about Maybe scaling the L1 here and allows us to do that in the constrained way that Ethereum has always operated. And so something that you're talking about, Justin, is replacing Geth, which is your execution client. So this is the whole beast mode thing with a ZKEVM client. So rather than use the old way of doing a validator, the new way, I think, shifts the role of a validator from executing every single block, right? Like every single transaction and every single block, to, instead of executing, verifying that a block has been, I guess, executed correctly. Can you describe that in more detail? Because this is the part where we're talking about beast mode. We're talking about scaling the L1 here, we're talking about lean execution for Ethereum. And a core technology here is ZKEVMs that change what validators are doing, and they're moving from executing everything to just verifying things. I don't know that. I have an intuition for how that works, why that's possible, and how we can do this while preserving decentralization. Can you give it to me?

B (50:39)

Absolutely. So the process of verifying a block is extremely intensive. The first thing that you have to do is download the block. And that already is a bottleneck. Right. If the blocks are too big, you just literally can't download them if you're on a home Internet connection. But once you have the block, what you need to do is you need to load the most recent version of the Ethereum state, and that is on the order of 100 gigabytes. But of course, if we were to dramatically increase the gas limit, it could be terabytes, tens of terabytes. So that's a problem. And then once you've loaded the state, you need to go execute the transactions. And for that you need two resources. You need a CPU with lots of cores and you need a lot of ram. And in addition to all of this, you need to maintain a mempool and lots of peer to peer connections. And you also need to store the history, which also can be hundreds of gigabytes. So all of this like crazy machinery, we just completely remove it and we just verify it's not proof. It's stateless. You don't need to keep a copy of the state, it's historyless, you don't need to keep a copy of the firm history. It's ramless in the sense that you don't need gigabytes of ram, you might need 100 kilobytes of ram, you don't need many cores, you just need one core. And it could be a very weak device. And actually the new meme that I'm hoping to introduce is that of a Raspberry PI Pico. So the pico suffix refers to this $8 piece of hardware relative to the normal Raspberry PI, which is about a hundred dollars. And I believe that at least, you know, as a fun experiment, we could have Validator run on a Raspberry PI Pico.

A (52:38)

And if that's the case, of course, you know, more people will be more familiar with say smartphone. It could run on your smartphone, it could run on your smartwatch, for instance. Right. A Raspberry PI Pico is even like much more constrained than those environments. So of course it could run on those things. No longer a laptop.

B (52:55)

Exactly. And this brings me to another aspect of Thought Mode, which is from the perspective of the users today, as a user, whenever I'm consuming Ethereum State, I have to do it through an intermediary that is running a full node on my behalf. And so that might be Infura, that could be MetaMask, it could be Rabbi Wallet, whatever. It could be Etherscan. And I'm basically trusting these entities to tell me what the state of Ethereum is. What if instead I could just directly verify the correctness of deframe state within my browser tab, like on my phone, like within the app, and it costs nothing. It's instant. Well, now I'm not subject to all of the failures of these intermediaries. If, for example, Infura goes down, well, I can still make transactions. If Infura or Metamask wants to censor certain types of applications, maybe ofac transactions, well now they're no longer in a position to do the censorship because they're not intermediating me as much. Maybe Etherscan gets hacked and now someone puts forward a malicious front End and tries to drain a bunch of people. Like this is the kind of thing that should be harder to do once users have more sovereignty over what is the valid state of the chain.

A (54:19)

Okay, so this is why Snarks, which is the ZK in ZK EVMs as we established, achieves both Beast mode because it unlocks a bottleneck which has been execution and gets us to the potential of something like an Ethereum layer 1 with 10,000 transactions per second. Simultaneously it achieves Fort mode, which is what is Fort mode? That's defense. This is more people can run nodes from anywhere on the most basic of consumer hardware. So the reason Snarks is so powerful is because it's a double edged sword and allows us to achieve scale while also achieving not just the maintaining the current decentralization of running an Ethereum node, but like making it even better, making it such that you can run an Ethereum node on a smartphone or a watch. Okay, but what we have done in this ZKEVM kind of setup and sort of the new execution client that you're talking about, and some of these aren't under development, they will talk about what that means today, but what we have done is something important. So we have moved these validators from executing every transaction to verifying them. But somebody's doing the execution, right? Who's doing the execution now in this world? And why is it okay to just have validators just verify rather than execute and verify as they have been doing. Are the executors now a centralization vector in the whole Ethereum blockchain supply chain?

B (55:51)

Yeah, great question. So we do have a new actor which is called the prover, and the prover is responsible for generating the proofs. And there's two regimes that we are going to be deploying in production. The first one is the optional proofs regime where we're relying on altruism. We're relying on various actors to just generate the proofs for free for the network and then we're relying on individual validators to opt in to verify those proofs. Now this is a great proof of concept, but eventually what we want is mandatory proofs. What does that mean? It means that as a block producer, meaning as the entity that builds the block and proposes it, I'm responsible for generating all of the corresponding proofs. And if the proofs are missing, then that block is invalid. It's just not going to be included in the canonical chain. And now we need to look back at the incentives. We're no longer relying on altruism we're actually leaning on rationality. And the reason is that the block producer is receiving fees, Mev. And if they were to miss a block, they would also get a penalty for missing that block.

A (57:10)

And just when you say block producer, block producer and prover are synonymous in this world.

B (57:16)

So they are not, but not necessarily I should say, okay, they could be bundled as one entity and vertically integrated. But what I expect will happen is that we're going to see a separation of concerns. So even today, there's a separation of concern between the proposer and the builder. And what I expect would happen is that the builder would outsource the proving to dedicated provers.

A (57:43)

Little rusty on this. Okay, Prover builder. Sorry, Proposer builder, prover validator. Okay, run us through the whole supply chain again of how a block goes into the chain in Ethereum today, and then what this future state is going to look like.

B (58:02)

So today you have at every slot a randomly sampled validator that is called the proposer. And they will get to decide what block goes on chain.

A (58:14)

That's the thing. If you run a validator, you're running at home.

B (58:17)

Yes, but there's an important caveat, which is that the proposers are assumed to be not sophisticated enough to build the most economically valuable blocks possible. And so instead they will delegate to more sophisticated builders that will do that on their behalf. And that is called PBS proposer builder separation. And we have something called mevboost that helps us with this separation. What I expect will happen going forward is that we would tack on yet another role called the prover, and the builders would go outsource the proving jobs to these sophisticated provers. Now, it turns out that the builder landscape is fairly centralized, and so it's reasonable potentially to expect that actually these two roles in practice will be bundled for at least a large subset of the blocks.

A (59:17)

Why is that okay? Why is it okay that builders and potentially provers in the future are centralized? But we're taking all of this pain to make sure that validators can run on a smartwatch.

B (59:30)

So there's a few answers here. The first one has to do with the honesty assumption, right? So in order for consensus to run smoothly, you need 50% of the consensus participants to behave honestly. And this is an extremely high bar, is very, very difficult to achieve. So Today we have 10,000 consensus participants, 10,000 validator operators. And having 5,000 of them behave honestly is a tall order, but we have.

A (60:05)

Achieved it, by the way, 10,000 validator operators. These are independent validator operators because Some people see numbers, like into the millions of validators, but you're saying 10,000, and they don't understand why you're saying 10,000 when they see numbers like a million validators on Ethereum.

B (60:23)

Yeah, let me explain that. So for many years there was this constraint that an individual logical validator was 32 ETH, and we have indeed a million of these 32 ETH entities. But what often happens is that there's a single operator that controls multiple of those validators. Now, recently we had this upgrade called Maxeb, where we increase the maximum effective balance to 2000 ETH. And so what we're starting to see is actually consolidation of the validators. If a single operator controls multiple validators, they can now squish them together into bigger and fatter validators. And actually, if you are an operator and you're listening to this podcast, I do encourage you to consolidate because it's good for you and it's also good for the network. But if you look at the individual operators that aren't a million, there's something closer to 10,000.

A (61:19)

I've seen estimates like 10,000, some say as high as 15,000. This is in the same realm as the next most decentralized network in crypto, which is Bitcoin. I've seen estimates for Bitcoin around 15 to 25,000 nodes, something like that. And that's the thing we're keeping decentralized. Anyway, I just wanted to clarify that number, but continue with the flow, if you will, where you were where. I guess the question was why is it okay that block builders and provers in the future are very few? Are these centralized entities?

B (61:52)

One reason has to do with the fact that it's an honest minority on the proving side of things. You only need one single prover to be available for the builders in order for the chain to keep on going. And we've taken this one of n extremely seriously. So n is at least 100, because there's at least 100 data center operators that you can go pick from. But even that we're not satisfied with. We want N to be, you know, orders of magnitude larger. And this is why we're going with the on prem proving where, you know, crazy people like me could run a prover from home. And this is something that I intend to do.

A (62:31)

So that means all we need is Justin or some crazy person like Justin and everything's fine. Nothing is corrupt on the chain. No invalid block gets through to the other side.

B (62:44)

It's a fallback for liveness. So what would happen in the worst case if we were to rely on data centers is that we'd be running at 1 gigas per second. And then from one day to another, the governments are saying, hey, data centers, please stop the proving process. And we would fall back to something much lower, let's say 100 megagas. And the reason we would fall back to 100 megagas is because that's the most that could be done outside of the cloud. And that would be very bad in terms of providing guarantees to the world, because we want to have this guaranteed throughput. We want to be up only, we don't want to be degrading the liveness of the chain. And so we only want to be in a position where what we deploy in production is something that we can guarantee even in a World War 3 type situation, which is a very tall order. But it's something that the technology is able to deliver thanks to recent innovations.

A (63:47)

Which of course that liveness guarantee is very important for the store of value use case. Right. Even if transaction throughput drops in these extreme edge case scenarios, store of value is still alive because you can go access your value on chain and do something with it. Let's talk about provers a little bit more. So you said you might have the ability to run provers at home. That's good. But you also expect the prover functionality to be more centralized in I guess the majority of cases as I understand it, like provers, that's like a much larger hardware profile. Right. And it's some specialized hardware because they're crunching some numbers or they're doing some moon math. Anyway, you're saying yes, but no. Yeah, where am I wrong there? What does this actually look like to be a prover?

B (64:38)

Yeah. So it is unusual hardware in the sense that most people won't have it, but it is made out of commodity hardware, specifically gaming GPUs. So 16 gaming GPUs, for example, the 5090 that came out recently, that is enough to prove all of Ethereum in real time. And I intend to basically build a little GPU rig at home. And a bunch of AI enthusiasts are doing that because it's the same hardware that you need for AI. Now, in addition to liveness, which is one of the questions that I asked a lot around decentralization of proofers, the other very important consideration is censorship resistance. Especially when we will be increasing the gas limit. Because the way that we enforce censorship resistance today, assuming that all of the builders and the whole MEV pipeline is censoring is by relying on a small altruistic minority of validators that are willing to force include transactions from the mempool without going through the builders. And we have this proposal called Fossil, which basically increases by roughly 100x the total throughput of this forced inclusion. Today we have about 10% of the validators that are doing this altruistically. But with Fossil we will have 16 validators at every single slot. So it's all the slots as opposed to just 10% of the slots. And within a slot there would be 16 includers as opposed to just one. So in some sense it's 160 times more opportunities for forced inclusion. And that is something that is important to do as a prerequisite before growing to very high gas limits.

A (66:34)

That means that the builders, the provers, none of these more centralized components, we'll call it centralized in air quotes like entities can actually censor anything on chain. So you preserve the and you actually strengthen post Fossil the censorship resistance guarantees of Ethereum. I believe Fossil is maybe slated for next year at some point in time. I know this is all squishy, but Fossil is probably going to happen earlier than some of the other things that we'll be talking about today. Okay, so ZK EVMs, you take something like the execution client, something like Geth, and there are many different execution clients. You said you're running Geth today and you get a ZK EVM version of an Ethereum execution client. Maybe the best way to kind of fit these pieces together where the execution client turns into a verifier from executing every single block is to talk about your at home setup and what you're planning for DevConnect. Okay, so as I understand it, there are many different ZKEVM clients that are in development. I presume you're going to maybe select one of those and then it sounds like you're also going to the additional step of maybe running your own provers at home. So tell us, what's the Justin Drake experiment that's going to happen by DevConnect and then maybe we'll fit this into the broader roadmap. But what are you doing?

B (68:03)

Right, so the prover is going to have to wait for Christmas. I'm thinking of a Christmas present which is a cluster of 16 G's GPUs, but in the shorter term in November for DevConnect. I'm hoping to run my validator by, as you said, downloading ZKEVM proofs. But it wouldn't be just A single one, it would actually be as many as I can get my hands on. And the number that I have in mind is 5.

A (68:30)

So zkevm clients.

B (68:33)

Proofs. Yes. So this proofs, there's these five different proof systems and you know, at every slot there would be five corresponding proofs for each, well, one proof per, per client. So there would be a total of, of, of five of them. And these are proofs that are very short and very fast to verify. They take for example, 10 milliseconds to verify. So if you have five of them, it just takes 50 milliseconds. It's it, it, it's not a big deal. So I would download all of these and if three of them agree, then that's my source of truth. And the reason why I'm downloading more than one is because some of them might be buggy in the sense that it's possible to craft a proof for an invalid block. So that's why we want multiple of them to agree. And some of them might have what are called completeness bugs or crash faults. So there are some circumstances where the proof system just can't generate a proof because there's some sort of a bug in the system. And so that's why I wouldn't require all five proofs to agree. It's okay if two of them just never appear. I would still be able to move on. And so it's a new way of thinking about client diversity, because today the way that client diversity works is that it's across validators. So you look at the whole population of validators and say, okay, 20% are running client A, 20% overhang client B, et cetera. Whereas here the diversity is internal to a single validator. And that's possible to do precisely because we have snarks, because it's so cheap to be running multiple ZKE VMs. And that's one of the reasons why I actually believe that ZKE VMs are going to give us a step up in security relative to what we have today. So reason number one is that we have internal client diversity as opposed to external across the validators. Two, the barrier to entry to be a validator is going to be lower, so we're going to have more decentralization, more security. Another point is that we're going to be deleting tens of thousands of lines of code. So today I'm running this execution layer client, and all that I really need is the core of the client, which is the EVM implementation, that is the logic, all of the stuff around it, managing the mempool, the history and the state, and the peer to peer networking, a lot of that code can just be deleted from my perspective as a validator operator. And there's also something called the Engine API, which is a bit of a technical thing, but it's basically the communication bus between the consensus layer and the execution layer. Historically, there's been a bunch of bugs in that interface and that's completely going away because again, I wouldn't be running an execution layer client. So we're getting to this point of minimalism and actually that feeds a little bit into the lean Ethereum meme where we're trying to be as minimal and cut all of the fat so that we stay lean.

A (71:44)

Okay, just so I understand what you're actually running here and how this fits with some other things I've seen within Ethereum. So you said you're planning to run three different proving systems, ZKEVM proving systems. So right now I understand the execution layer. Again, the thing that we want to get to Beast mode as being a client like Geth, let's say that's what you're running today. And then the ZKEVM version of this is this like Reth, which is another ethereum client, plus one of these three proving systems, EkeVM proving systems that I'm showing on screen. And for those not looking at this, this is a website called ethproofs.org and on ethproofs.org you can see the progress of different ZK VM proving systems. Fit this together. To me, are, are you running Reth plus one of like. Like three of these, let's say proving systems, or do these proving systems kind of replace Reth? Like, what exactly are we talking about here?

B (72:47)

Yeah, great question. So what we want to do is preserve the diversity of EVM implementations, also known as execution layer clients. So we want to have Ref, but we want to have various other EVM implementations. And in terms of the clients that are, you know, the most ready, we have one called efrex, which is a newer Rust client by Lambda Class. We have one called EVM EVM1, and we have one called Zksync OS which has been implemented by Mata Labs. And each one of these four can be combined with a proof system. So what I might do, for example, is run Zisk with EVM1, I might run Pico with reference, I might run OpenVM with EFREX. And what I want to try and do is basically have as much diversity as possible, both the execution layer VM implementations and the ZK VMs.

A (73:51)

I got it. Okay, so just a side question. So the reason we have all of these different execution clients, and some of those I hadn't even heard of before geth, is maybe one that many people have heard of. Reth is like a Rust implementation of that from, from Paradigm. So they've, you know, hardened, they've, they've engineered that the heck out of it. Is the reason we have all of these different client implementations because Ethereum has like a hardened spec, you know, like most other networks don't have like more than one client implementation. I'm wondering how Ethereum has.

C (74:23)

Ethereum is the only chain that has a spec. An only chain that's like meaningful level of adoption, that also has a specific.

B (74:30)

Yeah, so what most chains will do is that they'll have a reference implementation without spelling out the spec. And so if you want to recreate a second client, you have to look at the implementation and try and copy it, bug for bug, if you will. And it's an extremely difficult process. And you know, it's part of the reason why Fire Dancer in the Solana ecosystem hasn't yet shipped despite it being three, four years that they've been working on it. They just, Solana just doesn't have spec. And it's a similar situation with Bitcoin. But having a spec is nice, but it's not sufficient. We also need to have a culture that encourages diversity and ultimately recognizes the value that comes with it. And the value to a very large extent is uptime. Historically speaking, we've had many individual clients fail and they're, you know, they're replaced within a few hours, within a few days. And while they're being replaced, the other clients effectively act as fallback. And then another reason why diversity is important is because it provides diversity at the governance layer. So the Oracle devs plays an important role in Ethereum upgrades. And the fact that no single client team has, you know, undue weight is, is, is a very healthy thing to have. And then the final reason why diversity, in my opinion is extremely important is because it allows us to have many different devs, hundreds of devs, all simultaneously. Understand the guts of Ethereum. I think Bankless is very famous for its quote, that the most bullish thing for Ethereum is to be understood. And I think when you say that is from the perspective of the user, of the investor, of the, the application developer, but I think it's still very, also very much true from the perspective of the client devs.

A (76:25)

Yeah. And it does propel Ethereum on this course of anyone can build a client in the world because they can read the spec, they could build the client if they have the dev chops. And so all of these clients are sort of competing with one another too in terms of innovation, adding new features, and that's a beautiful thing. Okay, so we have these, maybe these upgraded ZKEVM ready clients, the execution clients, the Geths of the world and such, even though Geth is maybe not ready for that, you name some others. And then we have this. What is going on on ETH proofs? Because this is something separate, I think, right? Or is it separate? We have a whole like competition here to get real time Proving down below 12 seconds, I believe. So what's happening on ETH proofs? Why is this important? And how does this fit in your home setup?

B (77:14)

Yeah, so on ethproofs, most of the focus is on the ZKVMs and we allow them to pick their favorite EVM implementation. And the vast majority of these ZK VMs actually use ref Revm because that is the one that's most appropriate, with one exception, which is Airbender from zksync, which is using zksync os, which is their own implementation of the evm. Now for the demo, I'm actually going to be downloading proofs from ethproofs and I'm not going to be too picky on the EVM implementation. There's mostly a proof of concept on the ZKVM side of things, but eventually, when we have the mandatory proofs, we're going to need the Ethereum community to come to consensus on a canonical list of ZKVMs and corresponding pairings with the EVM implementations. And one of the things that you said, Ryan, is that when we have diversity, we have an opportunity for competition. And I think this is a very healthy aspect here, which is that we would more likely than not be picking the 5 fastest EVM implementations that are most snark friendly so that we can still have this property called real time proving. And Geth historically has been the leader. They were literally a monopoly at Genesis. That was the only option available. And they've had this reign for the last 10 years. And I think the fact that there's this competition is a breath of fresh air and should lead to lots of innovations.

A (78:48)

This competition specifically, perhaps our listeners have seen headlines. If you're in deep crypto in Ethereum, you probably have of some of these teams achieving some Sort of milestone. And I think they, they call it like proving the EVM under 12 seconds. And this seems to keep getting faster and faster. I think Succinct was a major team to do this at first. And they're like, we got under 12 seconds and now there are other teams. I saw a team a couple of weeks ago called Brevis and now they've reached new milestones here. What, what is this race to prove the EVM at a certain speed and why is this important? And like, are we there yet?

B (79:31)

Yeah, so the reason why it's important is because it unlocks the hope for the Gigagas frontier. So like it's literally providing more likely than not like trillions of dollars of value creation for the world because we're going to unlock the, the gas limit. And from the perspective of the ZKEVM teams, it's a way to prove that technology and also have a shot at being part of this canonical list of, for example, five ZK VMs that would be baked in to every single validator and a tester on Ethereum. And actually every fully verifying node would have these five ZK VMs baked in. And so right now I maintain this tracker and list of ZKBMs. There's about 35 of them that try and cater for various use cases. But out of the 35, there's a big competition and now we've narrowed it down to about 10 that are candidates for being selected as canonical for the L1.

A (80:41)

And why is it important? The speed under 12 seconds and how is that improving so rapidly?

B (80:46)

So the way that Ethereum works is that you have a block that's produced and then within the rest of the slot, the attesters that are voting for the tip of the chain need to know that the block is valid. And so in order to keep this property that the validators are voting on the top of the chain, they need to receive the proof of validity before the next block arrives and the next block arrives within one slot, which is 10 seconds. In practice, they actually need to provide the proof faster than 12 seconds. It's 12 seconds minus a small delta because there's all of the propagation time to propagate the proof. And so the number that we have in mind is actually 10 seconds. So that is the goal. And we want basically all economically relevant blocks to be provable within 10 seconds. So there is this notion of a prover killer, which is an artificially built block that takes a long time to prove more than 10 seconds. But what will happen with the mandatory proofs is that it wouldn't be rational for the block builders to generate these prover killers because they would be hit shooting themselves in the foot. They would be dosing themselves because they wouldn't be able to generate the proof. That would lead to a missed lot. They would lose the fees and the MEV and they would also get penalized.

C (82:12)

I see this was a defensive mechanism. Can we talk about how we get from point A to point B here? Point A being where we are currently in Ethereum with none, no blocks being verified to where we want to be in Ethereum, where this is like the dominant equilibrium, where like all, almost all of the blocks are being verified. And we have successfully initialized Ethereum with this ZK proving technology. Historically as Ethereum has made hard forks, that's when we've done the big upgrades to Ethereum. We hard forked into proof of stake. We hard forked into 4844. All of the big upgrades to Ethereum have come in this very step function like we just, we hard fork the upgrade in. That is, as I understand it, not how this is going to happen. This is going to be different. Maybe you can talk about how we get from point A to point B, which is like the integration of all of the ZK metric that we've talked about into the chain. How does it actually happen?

B (83:07)

Absolutely. So the rough roadmap that I have is a four step roadmap. So phase zero involves a very small subset of the validators, think 1% opting in to verifying proofs that are altruistically generated, for example generated in the context of ETH proofs, which is to a large extent just marketing budget from a lot of these ZKVM proofs. The downside of one of the downsides of phase zero is that me as a validator opting in will be losing the timeliness rewards. So there's a special reward in Ethereum called the timeliness reward which is given to those who attest immediately to a block. And I will be losing that because I'll be attesting a few seconds late. And so this brings us to phase one where we have delayed proving or delayed attesting, or it's also called delayed execution where basically instead of having to attest immediately when the block arrives, you have more time think of a whole slot basically to attest. So even if it takes a few seconds for you to attest, it's all good. You'll be getting this timeliness reward. And at that Point, I expect the number of validators to opt in to go from roughly 1% to something closer to 10%. Why?

C (84:27)

Because that's, that's because it's when it starts to become incentivized, it's incentive compatible.

B (84:33)

Exactly. Yes. And it's, it's actually, you know, you have incentive to do it because now you don't need to run a new, buy a new hard drive, you know, when the state grows too big and you don't need to upgrade your computer if it dies. Or, you know, I could just sell my, my MacBook that I'm using to validate and just buy a Raspberry PI instead, for example. In any case, what I expect will happen is that the weakest validators, those running from home, would opt in to this mechanism. And the, the, the much more sophisticated validators think the coinbase, the binances, the lidos, they would keep running the, the.

A (85:12)

Usual way and they'd opt in because it's a lower hardware footprint.

B (85:16)

Yeah, exactly. And from that point onwards we can start increasing the gas limit, right? Because now we have two types of nodes. We have those that are verifying the proofs, we can increase the gas limit for them, no problem. And then we have the sophisticated operators that are running on more powerful hardware than just a laptop. And for them there's just a bunch of buffer to increase the gas emitt. So already in phase one, there's an opportunity to be more aggressive with the, with the gas limit. And then phase two is where, you know, a lot of the magic really happens, which is the mandatory proofs, where we require the block producer to generate the proofs and everyone is expected to be running on, on, on, on zkevms.

A (86:01)

Is that a hard fork?

B (86:03)

Yes, but it's a hard fork that only changes the fork choice rule. So it's a very minimal hard fork. It's just one that says that when you attest, you should only attest after verifying that the proofs exist and are valid. So it's not a difficult hard fork, it's actually a fairly simple one. And then there's phase three, which is the final one. But here you need to project yourself maybe five years into the future, which is what we call and enshrined proofs, where instead of having a diversity of 5ZK VMs, we just pick one and we formally verify it end to end. So we have high conviction that there's literally zero bugs in that enshrined verifier and that unlocks all sorts of it Simplifies the design first of all, but it unlocks things like native validiums, which is I guess maybe a topic for, for a different day.

C (87:00)

Okay, so five years, and that's after five years of just like battle testing of the technology. Because I think we kind of more or less expect bugs along the way during these phases and we just have to play whack a mole for a while five years before we feel that it's sufficiently battle tested to actually make it a formal part of the Ethereum layer one to truly unlock all of the magic that the snarks give us.

B (87:27)

Exactly. We assuming that every single individual ZKVM is broken, but in aggregate as a group, it's secure. And this phase two where we have mandatory proofs, you can think of it as being semi enshrined, where we have in some sense an enshrined list of multiple ZKBMs, but there isn't the one that we're putting all our X in the basket.

C (87:50)

So the theorized way that this works is that the weakest nodes, the slowest nodes, the individuals, you know, verifying Ethereum via Starlink in their camper van in some park, national park somewhere off grid, these people, the slowest nodes of the whole entire group are the ones that upgrade to the system first and they go from the slowest to the fastest. They kind of like leapfrog everyone. And as the technology gets more robust, more ready, more hardened, more efficient, the it starts to march upwards up the chain of the next slowest node, the next lowest node, until we're in a kind of like the median node. And then what starts to be left of the old legacy execution clients. Ethereum nodes are the data center nodes, the coinbase nodes, the Kraken nodes, the binance nodes, the people with heavy, heavy infrastructure with a very large footprints that are just like of the no distribution of Ethereum are the ones that just happen to be in the data center and they're like kind of the last to go because they have the most buffer, most bandwidth. And then at some point in time they'll flip too because we actually just fork it into the Ethereum protocol. That's kind of the plan.

B (89:03)

Exactly right.

A (89:05)

Can we talk about this and how this meshes with the idea? There's a blog post not too long ago from Donkrad who talked about the idea of a 3x increase for Ethereum in terms of gas limit every single year. And I want to show maybe a slide. I don't know where this came from. Actually this Looks like some Justin Drake handiwork. So I bet it's from one of your presentations which kind of goes through this. And so right now, after, I believe we do two gas limit increases for Ethereum this year, or was it just one?

B (89:41)

We've done two. We went from 36, 36 and then 36 to 45.

A (89:45)

That's right. Okay, 36 to 45. Okay. And the idea behind Dankrad's post I believe was some sort of kind of social commitment roadmap, stacking hands for the Ethereum community to attempt to Scale Ethereum 3x in terms of transactions per second and gas limit every single year. Okay. And so if we were on track for 20, 25, by the end of this year we would be at 100 mega gas. It looks like we're going to be maybe you said 45 or maybe we get to 60 or something like that.

B (90:23)

Yeah. So with Fusaka, which is coming in December, we'll be able to increase the gas limit. I'm told that, you know, 60 is safe and maybe we can get a little bit more 80, maybe 100. I don't know. But yeah. When I did those slides, which was a few months ago, Thomash was trying to set within the firm foundation the goal of getting to one mega gas gas limit by the end of this year and trying to keep this 3x pace that Dencrat originally suggested in his EIP7938. Now 3x per year I think is kind of a sweet spot between, you know, doable and ambitious. So it's quite significantly faster than Moore's Law, but it's not completely impossible. And Dankrat's proposal was to have this 3x per year over a period of four years. And importantly, it's something that would happen automatically. So today the way that we do gas limit increases is extremely laborious. What we need is the individual operators and the consensus layer clients to set new defaults or for the operators to change the default configuration in order for the gas limit to go up. So it's just at the social layer, extremely expensive and requires a lot of coordination. What Dankradt suggested instead is that at every single block the gas limit increases a tiny, tiny bit, just one or two gas, so that once we've gone through the social coordination of doing it once, it just happens automatically. And my specific suggestion is to increase the four years to six years because after six years of compounding 3x per year, you get the 500x that we need to get to 1 gigagas per second.

A (92:23)

Okay, and so let's talk about that a little bit more and mesh that with kind of the, the lean Ethereum idea. So the reason we've been reticent to hit the accelerator on gas limit and throughput has been it will start to increase the requirements for validators and kick our home validators off the network and drive Ethereum more into data centers. And that's not where we want to be. Now the, I guess the rescue or the landing pad of a lean Ethereum is as we increase gas limit, you know, maybe 3x every year, the home validating nodes, the non data center, you know, nodes in Ethereum, they can then migrate to a ZKEVM and run that on a Raspberry PI or smartphone or very cheap hardware. So prior to having a ZKEVM solution, those validators would just be gone forever, basically, and we'd become more centralized, fewer validators, more data center Y. But because they have a zkevm, as that tide rises, they can be among the first to hop to the frontier of a ZK evm. So this has opened up the playing field to allow Ethereum to consider increasing the gas limit on a more regular basis and maybe up to 3x every year. Is that roughly the story?

B (93:52)

Yeah, that's it.

A (93:54)

Okay, and then one other question I have in the weeds here. There's gas limit and then there's throughput in these two sides. The thing that we're increasing is gas limit. Is that correct? And our gas limit right now is different than the megagas that we're actually doing. You said we're at 2 megagas per second, I think earlier in the episode. But then we have a gas limit of what, 45?

B (94:16)

Yeah. So let me explain the math. There's like two complications. The first one is that we have 12 second slots. So it's 45 million divided by 12. And then there's another complication, which is with EAP1459, we have a target and a limit where the target is twice as low. So you have to divide by another 2x. So if you take 45, you divide it by 12 and then you divide by 2. That's how you get your 2 megagas per second. It's a little bit unfortunate because in some sense the gas limit is artificial because it depends on the slot duration. And we do intend to reduce the slot duration, for example, for 12 seconds to 6 seconds. So my preferred mental model is to think in terms of gas per second, which is quite close to the TPS. Concept as well.

A (95:11)

Those phases, 01, 2, final phase 3. You said getting to 3 might take 5 years. Do you have a timeline idea? I guess zero technically kicks off with you maybe among the first running this hardware in about a month or so next month. What about the timeline for the rest of this?

B (95:33)

Yeah, so 2025 for phase zero and then one year for every other phase. So phase one, 2026, phase two, 2027, phase three, 2028, for example. I think that that's a reasonable timeline.

A (95:45)

Okay. ZKEVMs allow us to increase block size, allow us to scale throughput. Real time proving is something we've talked about. We're under 12 seconds. Block times on Ethereum are 12 seconds. Right now is part of the beast mode. To get that down to 6 and below 6 and how far can we push that and how does that fit into kind of zkevms? Do we basically have to wait until ZKEVM provers are fast enough to get us safely under six seconds and then we can drop the real time like the block space production to something like six? What are the puts and takes of the constraints there?

B (96:26)

Yeah, so it turns out that the proposal to reduce the start duration is somewhat in competition with the ZKE VMs because it's going, we're going to have overall less latency to do the proving and it's going to make things harder. But I still think even if we were to reduce the slot duration to six seconds, we'll be able to get there no problem. It would just delay things by a number of months, maybe six months. And so it's a decision that the committee has to do, like do we want to reduce the slot duration at the expense of delaying ZKBMs by 6 months? I guess it's above my pay grade to make that particular decision. But if you're willing to project yourself multiple years in the future, for example, 2029, I'm hoping that we can go beyond the six seconds in the beam chain talk. Less than a year ago I was trying to advertise 4 seconds and recently we had this workshop in Cambridge with a bunch of researchers and we actually came up with a new idea that could unlock even faster slots, potentially two second slots. So I don't want to over promise this, but I do think we'll be able to go under six seconds in the context of lean consensus, which is a rebranding of the beam chain.

A (97:54)

Okay. So I guess in both cases, whether we're increasing gas limits and making the block blocks bigger, having them house more transactions or whether we're decreasing slot times. That's all toward the same goal of getting towards Gigagas, right? Both of those kind of numbers increase our gig. Is that wrong?

B (98:12)

No, no, no. So reducing the slot duration doesn't change the throughput. So if we were to reduce the throughput, if we were to, for example, go from 12 seconds to 6 second slots, we would correspondingly reduce the gas limit by 2x. So the total fruit is right.

A (98:27)

Okay. It's the reverse. Yes, of course. Okay.

B (98:30)

Yeah.

A (98:31)

That's why these two things are at odds.

B (98:34)

I mean, on paper, reducing the slot duration is actually neutral because at the time of the fork, the slot duration reduces by a factor of two, the gas limit reduces by a factor of two and these cancel out. But in terms of the engineering to get real time proving, yes, they are a little bit at odds because every second of prover time that we have is actually very valuable. And, and it just means that the ZK VM teams will just have to work that much harder to squeeze things down.

D (99:04)

Crypto is risky.

C (99:05)

Your sleep shouldn't be eight Sleep's mission is simple.

D (99:08)

Better sleep through cutting edge technology. Their new Pod 5 is a smart mattress cover that fits on the top of your bed. It automatically adjusts the temperature on each side so you and your partner can both sleep the way that you like. It's clinically proven to give you up to one extra hour of quality sleep per night. Eight Sleep's Pod 5 uses AI to learn your sleep patterns, regulate temperature, reduce snoring and track key health metrics like HRV and breathing. With a new full body temperature regulating blanket and built in speaker, it is the most complete sleep upgrade yet. Upgrade your sleep and recovery with asleep Use code bankless@sleep.com bankless to get up to $700 off the Pod 5 Ultra Extra during their holiday sale. That's 8sleep.com bankless. You also get 30 days to try it risk free. Link in the show notes for more information. Bit digital ticker BTBT is a publicly traded ETH treasury company that combines the two biggest metas of our time, Ethereum and AI compute. BitDigital believes that ETH will power finance and AI compute will power everything. Bit Digital gives you direct exposure to both. Bit Digital holds more than 150,000 ETH with institutional grade staking and validator operations. On top of that, the company owns roughly 73% of White Fiber, an AI infrastructure business that runs high performance GPU data centers. That adds a meaningful exposure to the growth of AI compute with over 27 million shares. This is an ETH treasury backed by real operations designed to capture staking yield today while positioning for the future of intelligent computing tomorrow. The ticker is btbt. This ad is not financial advice. Do your own research, learn more about Bit Digital and try their M nav calculator@bit-digital.com that's bit-digital.com Bankless is being compensated by Bit Digital for this ad. You can find out more information by clicking the link in the show Notes.

C (100:47)

In the fullness of time when this technology is just completely mature, having we just eliminated the time constraint anyways.

B (100:54)

Yes.

C (100:55)

So like say five plus five plus years, like right now we're really talking about, like, how can we get this integrated as soon as possible. And that's when like one second really matters in terms of block time. But in the future, one second won't matter at all.

A (101:08)

Right.

C (101:08)

Can you talk about that?

B (101:09)

Yes. And in the end game, what I'm envisioning is that we have snox CPUs that generate the proof as they're doing the computation. So you have a typical CPU that's running, let's say, at 3 GHz. Not only would it be doing the computation at 3 GHz, it would be producing a proof at the same time as it does the computation. And you can think of a CPU core, for example, RISC V core, as being 1 square millimeter of silicon on the die. So it doesn't consume much space. And nowadays we're able of building chips easily with, let's say, 100 square millimeters of die area. So you can imagine the future being that you buy your CPU. It's a pretty big chip, 100 square millimeters. One percent of it is used to do the raw computation and 99% of it is used to do the proving in real time. But here we don't mean in real time. With Ethereum time, which is one slot, we're meaning in terms of like in parallel CPU time, which is like nanoseconds, right?

C (102:16)

Yeah. Interesting. Okay, cool.

A (102:17)

The one piece of your home setup I just want to understand. So you're going to be. At first, you're running kind of a ZKEVM type setup, as we discussed, running provers at home. Okay, so that's your Christmas present. You get these GPUs. You know, Santa's been good to you. You've been a good boy. I guess, whatever this is. But it does require some power, some energy to run at home. Provers, and as I understand it, some of the teams are working to make that more efficient. So can you talk about if you wanted to go to the length of running your own prover at home as well, what is like the energy output required? This is basically electricity of your home required today. And then what does it need to be moving forward to make sure that we have at least some. Some level of decentralization to this prover network?

B (103:10)

Yeah, absolutely. So, 10 kilowatts, I mentioned it's about 10 toasters. It's also an electric car charger. It's also like a very powerful electric oven or a powerful water heater for your shower. So this is something that has been installed and you don't need to kind of buy a new house, I guess, in order to draw 10 kilowatts. Now, the GPUs that we're talking about, these gaming GPUs, and they draw about hundreds of watts each. Like, the maximum rated power draw is something like 500 watts, which is a half a kilowatt. And so what I have in mind in terms of the size of the cluster is 16 GPUs. So 16 times 500 watts, that's 8 kilowatts. And then you need to have a buffer for the host machines and the cooling, because you're going to need fans or whatever to circulate air, and that's also going to consume electricity. So what I'm intending to do for Christmas is buy a cluster of 16 GPUs, connect them to my home and my home Internet connection, and basically be producing a block, a proof for every single Ethereum block in real time. Now, if you had asked me two months ago, when would I be able to do this demo, I would have told you maybe six months in the future. But the pace of Snox is just so incredible that today 16 GPUs is enough. So we've already achieved the requirement that we set ourselves of 10 kilowatts. And we have multiple teams that have achieved that. You mentioned Pico and just yesterday, another team, the Zisk team, basically achieved that. I mean, technically they used 24 GPUs, but it's getting very close to the 16. And we have various other teams. For example, the Airbender team, I expect the succinct team to also get to 16 GPUs. And so come November 22nd for DevConnect, we will see how many teams have achieved this 16 GPU milestone. And I'm expecting it to be at least two, hopefully three and maybe four of them. And if you want to participate in this demo in real time, you can sign up to Ethproofs Day. So that's Ethproofs Day. Unfortunately, the venue that we have is limited to a few hundred people and our waiting list is close to 300 people at this point. But do sign up nonetheless, because we will be releasing more tickets.

A (105:49)

Is that 10 kilowatts going to be basically, is that going to go down? So once you get your Christmas present right, you're going to be running these proofreaders. Your electricity utility bills are going to spike. So it's like running a Tesla Charger 24. Seven, basically. So you're going to be paying a little bit extra. Is that just going to be the cost of running a prover or can we get it down from 10 toasters to like one toaster?

B (106:13)

Yeah, that's a great question. So there's two aspects here. The first one is that as the ZK VMs improve and you need fewer and fewer GPUs, that's going to be an opportunity to increase the gas limit. And so really what we want to be doing is keep increasing the gas limit so that we're always at the 10 kilowatts. So that's staying at 10 kilowatts. And this is how we get to one giga gas per second. The other thing that I want to mention is that, you know, this, this crazy altruistic phase is it's not really representative of what will happen eventually, which is that we don't really need the fallbacks to be proving every single block all the time. We only need them to activate whenever there's a problem. So if all of the cloud providers suddenly go offline, well, now the block builders can use me as a prover, but I'll only turn on in the 1 in 10,000 blocks where that's necessary. Most of the time I'll be consuming zero electricity other than, you know, sufficient electricity to be connected to the Internet. And so you can think of it as like some sort of like reserve army that's only activated when necessary.

A (107:29)

I like that analogy. I like that a lot. Before you fire up your own provers, who's going to be doing the proving? And by the way, in this whole setup, are provers incentivized? Do they get a share of block rewards as a portion of this or, like, what's in it for them?

B (107:46)

Yeah, so ultimately the provers are incentivized by fees and mev, and they're going to be paid by the block builders. Now one thing that I think is worth coming in with eyes wide open is that the fees are ultimately going to come from the users. And so the users are actually going to have to pay more for their transactions and specifically going to have to pay a transaction fee which is going to to cover the cost of proving. But the good news is that the cost of proving for a typical transaction is a hundredth of a cent. So for most applications you won't even realize that there is an extra proving fee which is being added on. What I expect will happen is that the MEV will be much larger and also the data availability fee will be larger than, than that. And of course, as the ZK VMs improve, we're going to go from a hundredth of a cent per transaction to a thousandth of a cent. And so, yeah, that's ultimately how the incentives work out.

A (108:51)

Just transaction fees in mev, no consensus rewards, no issuance rewards.

B (108:56)

So one thing that we can do as mechanism designers is instead of leaning on rewards, which I think are totally unnecessary because we have the fees and we have the mev, we can lean on penalties. So we can have a setup where if for whatever reason you don't generate the proofs and you're acting maliciously, then you get penalized. And the number that I have in mind is one eth. So you miss an Ethereum slot, boom, you get penalized one eth. Because that should never happen. Especially in the context where we have this upgrade called aps, a tester Proposer separation, where we remove the proposer from the equation and we only have sophisticated entities, the builders and the provers, and those should basically have extremely high uptime. And there is a negative externality to Ethereum missing blocks. It means that in some sense Ethereum skips a heartbeat and that's not good. And so putting a price on missing a slot I think is healthy and it's something that we can do once we have this APS upgrade. Because today we make this assumption that a bunch of validators are, you know, running on home Internet connections. And you know, every once in a while my, my ISP just messes up and I don't have Internet and we don't want to be having this, this one eth penalty just because you're you, you're offline and you got unlucky. But you know, for builders and proofers, yeah, we can slap them with one eth, no problem.

A (110:24)

Wow. Okay, so that is beast mode for scaling Ethereum. The layer One. I gotta confess, Justin, I've not understood it until this conversation that we've just had. Now I understand it a lot more. So many other things we didn't touch. And we're already at almost two hours, so we can't, we can't cover everything here. But very quickly, when you introduced Beast Mode, you also also said it's not just in five years, right? This could happen in five years, for instance, and it will scale up. It's not just big bang after five years that suddenly we're at 10,000 transactions per second. But this plan potentially gets us to 1 gigagas 10,000 transactions per second on Ethereum layer 1 by 2030. Okay. We're also simultaneously scaling data availability through kind of the dank sharding setup we have right now so that L2s can get to Teragas per second. So does that have anything to do with CKEVMs and everything we've been talking about, or is that just happening in parallel? And you know, every, you know, every chance we get, we're just expanding the, the fast lane and this data availability and blob space effectively for L2s, it's happening in parallel.

B (111:34)

But I do want to highlight one thing that bridges these two worlds, which is called native rollups. So a native rollup is one that has the same execution as L1, but in L2. And one of the massive advantages of native rollups is that you don't have to worry about bugs in your snark prover or your fault proof game. You don't have to worry about maintaining equivalent with the L1, which itself is an evolving thing with every hard fork and every eip. And maybe the most important thing is that you don't have to have a security council to deal with these bugs and with this maintenance. And the amazing thing about the technology, which is ZKE VMS, is that for the L2s, we can effectively remove the gas limit entirely. The bottleneck is only data availability. And the reason is that the L2s, they can be generating proofs for their transactions off chain using, you know, very powerful provers. They don't have the 10 kilowatt requirement like they can be. They can have much bigger provers if they, if they want to. And then the only thing that they bring on chain is this tiny proof that the validators can verify and that is the next generation of rollups. And you know, we're very, very fortunate to have Luca Dono from L2 Beat who is a big believer in this idea and is Championing, you know, the EAP process and all of the technical legwork in order to deploy this on Mainnet.

A (113:18)

When does that happen? In this whole timeline where we talked about the, you know, the zero through three phases of getting ZK EVMs out there.

B (113:25)

So one reality of Ethereum is that we have this governance process called ACD and we have a very limited number of opportunities to do hard forks. Like historically we've had one hard fork per year, we're trying to double this to one hard fork every six months. But even within a hard fork there's only so much that you can do. And it turns out that many different developers want many different things. And so there's 10, 20, maybe 30 different competing proposals. And in any given hard fork you can only clear the queue like, you know, three, four, maybe five, five at a time. And so that leads to all sorts of externalities, one of them being that it's just very hard to predict what will go through the Oracle dev process. And another externality is that it just leads to a lot of frustration. Like you can think of ACD as kind of being this meat grinder or this soul grinder where you have starry eyed, enthusiastic developers that come in and they kind of come out kind of frustrated and jaded because you know, their EIP hasn't been selected for a very long time. I mean, one example here could be, you know, fossil. Fossil is something that, you know, we have the eap, all the research being done, all of the, a lot of the legwork has been done and yet it's still not being included. It's been discussed for inclusion Fusaka. It's been discuss for inclusion in Glamsterdam and now it's being pushed and pushed and pushed. And so it's difficult to be able to predict some of these things. And this is actually part of the reason why I'm so excited about lean consensus. Because lean consensus is a governance batching optimization where for an extended period of time we're just doing pure R and D. And so we can have this really exciting, fast paced R and D. And then what we propose to ACD is something that is significantly better than what we currently have, let's say 10 times better. And it will take a long time for it to go through acd, but when it goes through we will be batching together, let's say 100 EAPs that would previously be unbundled. And so instead of having the long term future, the end game of Ethereum, if you will, being spread out over decades of small incremental upgrades, we have an opportunity to batch something bigger. Upgrades on a timeframe of four years or so.

A (116:05)

Mostly we've been talking about kind of the lean execution layer, because that was the big part I didn't understand. And that's the big part. Going to beast mode and scaling layer one. We talked a little bit about Lean consensus, I think, and kind of the FORT mode, from the perspective of all of this, can be run from like a smartphone or a smartwatch. But are there any other pieces in Lean Consensus? Because this is another layer of the Ethereum stack that you want to make sure people understand today. Because when you say Lean Ethereum, you're talking about lean execution layer and scaling that beast mode and you're also talking about Lean consensus. The lean consensus piece, I think, is maybe less sexy, but maybe in some ways it's more important. And you just alluded to one of the ways that most of us users don't see why it's important. What else is in the Lean Consensus piece that we have not covered and why is it important?

B (117:03)

So Lean ethereum is actually three different initiatives within L1. You have three layers, the consensus layer, the data layer and the execution layer. And it's easy to remember because it's C, D, E. Now the, the. We haven't even touched on the data layer other than saying that it needs to be post quantum secure. But yeah, there is indeed a lot happening in the consensus layer. The headliners are one replacing BLS aggregate signatures with a post quantum equivalent, two, having much faster finality. So instead of it taking two epochs, which is 64 slots, it might take only, sorry, two slots or three slots. Another big improvement is significantly reducing the slot duration. And then the final improvement is just like zkevms, we can snarkify the entirety of the consensus layer so that the really weak devices, the browser tabs, the phones, can fully verify not just the execution part of Ethereum but also the consensus layer. And so when we're building bridges, for example, between L1s, that's the same kind of technology that would be used as well. And then what you alluded to is this opportunity to do things differently in terms of governance. So we've been doing these small incremental upgrades, we've been accumulating 10 years of technical debt. It's an opportunity to refresh. And part of the reason why I'm excited about Ethereum is not because we've had 10 years of uptime, but because we're going to have another hundred years of uptime. And in the next hundred years we're going to grow our total value secured to hundreds of trillions relative to what we have today, which is just $1 trillion of, of total value secured. And I think the Oracle dev process as it is structured today is a little bit the tail wagging the dog, right? The 10 years history, that's the tail. We've accumulated a lot of technical debt and the dog is the next hundred years. And I think what Lean Consensus is all about is just rebalancing it a little bit so that the next hundred years where all of finance will be built on top of Ethereum, the vision has a chance to materialize. And that's going to require some big changes at L1. And so in some sense, Lean Ethereum is an invitation to be bold, to be ambitious, and to think about the next hundred years more so than the last 10 years.

A (119:44)

Justin, as we wrap this up, maybe this is a good opportunity to ask another question. And as I think about the context for this whole discussion where I see Ethereum going, it's really about, about upgrading the Ethereum network to snarks. So Ethereum, like Bitcoin, is originally based on cryptography, like 1.0 blockchain cryptography 1.0. Snarks is cryptography 2.0. And so now we're applying snarks and making. I think you've used the terms which I didn't fully understand at the time, snarkifying the entire stack. That's what this is. That's what Lean Ethereum actually is. It's upgrading the entire stack to Cryptography 2.0. The snarks generation of cryptography. And some networks might follow in those footsteps, others might not. Tough to say what Bitcoin will do, but probably they'll ossify and stick with cryptography 1.0 for a long time. I guess the context of this though is will we be able to do this fast enough? You were talking earlier about the ACD meat grinder and how Ethereum is so large, so many moving pieces, it can feel hard or even frustrating for developers because they're like, why can't this happen faster? And so are we able to scale fast enough to beat centralized competitors, particularly competitors with some deep engineering teams? And I think part of maybe what this question is reacting to is we had one of the original scale Ethereum EIP proposal authors Dankrad recently depart the EF for. You could call them a competitor to Ethereum. Maybe that's simplifying things. They're certainly going to contribute back to the Ethereum ecosystem as well, the form of the EVM and other things. But this is a new company, recently raised 5 billion in funding, so they have deep pockets, it's called Tempo. They are working with Stripe and invested in by stripe. So they got clearly access to tradfile, Tradfi and stablecoins and all of these things. And it seems to be the case that they're going to be implementing some of this roadmap using Reth. I mean it's a paradigm team, right? They're going to be speed running some of this roadmap and maybe that helps Ethereum in some ways, but also maybe in some ways it competes against Ethereum. And from a talent perspective, certainly D has done so much for Ethereum obviously. But is there a brain dream happening with some of these more centralized corporate chains? And are you worried about that? You're talking in terms of hundreds of years, but will we have the talent to sustain? Are we going fast enough to beat some of these competitors and implement this vision?

B (122:23)

Yes, I think that just zooming out there has been a brain drain. It's real, it's significant, but it's actually not in the direction that you expect. There has been a massive brain drain toward Ethereum. And yes, we have lost one Dankrat, but I think we've gained 10 dankrats. So since I gave my beamchain talk less than a year ago, there's been dozens of people that have come on board the Affirmative foundation or have been working externally through all sorts of lean consensus teams. And the amount of talent that has come in in the last few months is absolutely mind boggling. If you look at what Dankrat was doing, he was doing hardcore applied cryptography in the context of Dankshielding. And there's several applied cryptographers that I'm working with on a daily and weekly basis now, including, you know, Thomas and, and Emile, you know, Giacomo and Angus. And like all of these people are of extremely high caliber. Like at least as, as, as, as, as good as Dankrad. Like they don't have the reputation because they haven't been at it for, for, for, you know, seven years. But in terms of raw talent, I think we, we, we have it. And these are people again that were not on my radar even a few months ago. And then on the coordination side of things we've brought on Will who just keeps on impressing me every single day. We have Ladislaus, we have Sophia, and there's also people who are not doing either the hardcore cryptography or the coordination. So there's for example Felipe doing the specs, there's Raul helping with the peer to peer networking, there's Kevin doing ZKBMs and like Pharaoh working on ethproofs. And when you zoom out, a lot of these people, you know, came to Ethereum. So for example, Will and Farah came from Bitcoin. Kev and Sophia. Sorry, not Kev. Camille, who's one of the coordinators of one of the consensus team and Sophia, they came from Polkadot. We have Kev who came from Aztec, we have Raul who came from filecoin, Thomas who came from Kakarot and the starknet ecosystem and Angus who came from Polygon. You get the idea. There's much more incoming brain drain than there is outgoing. Now in terms of the reason for this brain drainage, I think it has to do with things that competitors like Tempo just don't have. Vitalik has this famous quote that a billion dollars is not going to buy you a soul as a blockchain. And we have Community, we have Vision, ideology, we also have this amazing technology. And you mentioned that you think Tempo might, might leapfrog and use ZK vms. I'm not holding my breath on this. My base assumption is that they're going to have a very small number of validators running in data centers. And actually I asked Ancrat, how many validators do you think Tempo will have at launch? And I'm hoping I remember this properly, but I think his answer was four. Like four validators. And Community is, is very different as well. One thing that was very stark to me was when Dankrad left, there was a massive outpour of gratefulness for all of the work that Dankradt had done and his massive contribution to Dank Xiaodang. And then you look at the Stripe side of things and it's really sad that, you know, Patrick, the founder of Stripe, kind of made this tweet to his half a million followers saying hey, welcome Dankrat. And his tweet got like three retweets. Like there's like, there's no community in Tempo, there's very little soul. And you know, I'm sure Dankrad has, you know, all sorts of reasons for leaving the Ethereum ecosystem, but the fact of the matter is that there's a massive brain drain to, to towards Ethereum. And I guess another thing worth mentioning is that I think there's a reasonably high chance, call it like double digit percentage, that Tempo is actually in some way part of the Ethereum ecosystem even if today they're they're not ready to acknowledge it explicitly. In my opinion, the incentives will be such that all of the L1s will want to become L2 so that they can tap into the the network effects that Ethereum has to offer. Just yesterday actually, or before Yesterday, Ethereum crossed $100 billion of Tether on L1 and if you want to do payments you need to have access to stablecoins and there's a lot of network effects around stable coins on Ethereum. So it wouldn't surprise me if in a couple years time, Tempo announces that they're pivoting to becoming an L2 and Dankrade comes back to the Ethereum ecosystem.

A (127:58)

Do you have a take on why there haven't been more L2s in these corporate chains? Why are they going with L1s instead of L2s? It's not just Tempo. If it was just Tempo maybe you would say that, but circle going that direction. Also plasma kind of the tether founding. There's been a lot of new L1s and the Ethereum take has always been what you said, which is like why be an L1 when you can be an L2? It's cheaper, better network effects. Why hasn't that worn out yet?

B (128:24)

Yeah, I mean we have seen this L1 premium and I think part of the reason is that there's this new design space which has been unexplored and so people are maybe valuing the unknown. Very large potential. I don't know. This is just a speculation but I think Tempo, as you mentioned, they've raised $500 million at a $5 billion valuation. I think they've done an excellent job at farming the L1 premium and now that they've secured their $500 million I think they could safely pivot to doing the correct incentive aligned thing which is to tap into the maximum amount of network effects. I certainly do recommend that they keep part of that treasury and let's say at least 1% to make an emergency pivot to an L2 if they don't become successful as an L1.

A (129:22)

Justin Drake this has been fantastic. Lean Ethereum. The next steps for this are what? Devconnect and you're going to give a presentation devconnect of the Geth node.

B (129:34)

Nice.

A (129:35)

Yeah. Talk about the next steps and what people can do to kind of stay abreast and get involved.

B (129:40)

Yeah. So I'm hoping that DevConnect is an eye opening moment where as a community we can all agree that we want to go down this ZKEVM path. There's a few, I guess, stranglers who are not yet fully convinced. But I think what's happening now is that we're disagreeing on timelines as opposed to fundamentals. So I think the most skeptical people will tell you that ZKEVMs are something for 2029 or 2030. But I think what's happening is that over time, more and more people are getting bullish on the timelines. And one, I guess, fun story here is that Kev, who leads the ZKEVM team historically at least a year ago, was, I guess, skeptic about ckabms. You know, there was a lot of open questions in his mind and it's been really beautiful to see his thinking evolve week by week as he's been able to tick off every single unknown and risk that he had in his mind. And I think Kev is still not fully convinced on the exact timelines. But if the technology keeps on progressing the way it has been progressing in the last 12 months, then I think the timelines can only shrink from here onwards. Now, one thing that I want to stress is that there will be a tipping point where the ZKVM technology has reached parity with L1 throughput and quality. And from that point onwards, what I expect will happen is that the ZK VMs no longer become the bottleneck, meaning that the ZKEVM technology will improve faster than the 3x per year, which is, I think, the fastest that we can hope to upgrade the L1. And so the burden will go back to the traditional non moon math engineers that have to optimize databases and networking and things other than cryptography.

A (131:50)

We will end it there. Justin Drake, thank you so much for joining us.

B (131:54)

Absolutely. Thanks for having me.

A (131:56)

Bankless nation. Got to let you know, of course crypto is risky. You could lose what you put in. But we are headed west. This is the frontier. It's not for everyone. But we're glad you're with us on the bankless journey. Thanks a lot.

B (132:20)

Sam.