A (3:00)

I personally share your excitement on this topic. I really think that it's one of those changes that are really Ethereum at its best. It's one of those really ambitious technical projects that I think Ethereum is in a unique position to deliver. It will have a huge impact, primarily through scaling, but in many ways I'm sure we'll talk about all of this and I really think it's something we can look forward for, we can be proud of. And yeah, I'm excited to talk about the details. I will tell you, by the way, you said hard fork. And the interesting thing here is similar to if you think back at the merge, right, we had first the launch of the Beacon chain, which was one moment in time, and then we later on had the mergers, like two separate moments in time. And I think similarly, maybe even to a larger degree with zkevm, as we'll discuss it, actually it has this nature of it's an ongoing transition that is basically about to start. Then we will have the main hard fork and then it'll continue after. So it's much more like a ongoing transition. But yeah, let's dive in.

B (4:03)

So it is the introduction of an era of Ethereum rather than an acute hard fork. And I think the ZKEVM era will be. Has the potential to be Ethereum's best era because of what the ZKEVM does for Ethereum. So let's, let's stop hyping it up and start to get into the technical details. What do we need to know about what a ZKEV is? What is it? And then we can talk about like, why what it is that's so significant to Ethereum.

A (4:28)

Yeah, So I think in order to understand this, like really kind of, you have to start from the problem statement. Right. So. So ZKVM really arose in the, in the context of scaling of. And basically the fundamental point is that a blockchain, if you blockchain, you have these three primary constraints you have the data, right? You have to first, like any new block you create, it has to get to the user, then you have the IO, you have to then go to disk, you have to get all the data you need to actually then verify the block and then you have the actual verification, the execution, the compute, right? So those are like the three main constraints, the bandwidth, the I O and the compute. That's any blockchain, no matter the design, those are the main constraints. And so if you want to scale this, you can just do the thing where you take that and you just scale it up and we'll talk about this in a bit. That's actually to some degree what we're doing in the short term. And that's what many other chains have been doing. That's a very natural thing. But you do run into limits, you do run into tight limits. And so ZKVM is this fundamental, it comes from the cryptography side, these snarks, zero knowledge proofs. And it is this fundamental insight that what you can do is you can basically allow nodes to verify that a block followed all the rules without having to re execute the block. And again, that's something, it's a very non intuitive thing, right? Normally a blockchain by its nature is a very symmetrical thing. Every node basically does the same thing. Of course, you have block producers, but then every node kind of has to download, re. Execute. You're duplicating the effort across the network. And now you're jumping to this, like through this very fancy cryptography, you're jumping to this world where you still have the same effort to build a block. But then verification in a way is effortless. It has this magical compression element to it. And then specifically, what's so important in the L1 context is the real time element to it. So a ZKEVM just allows for this compression. And for example, many listeners, I think, will already be familiar with the concept of ZK rollups, right? So those have been around for a while. And that actually was a huge first jump in this technology, which just allowed for this compressed ZK verification in the first place. But so far this is done in an asynchronous way. So, meaning you have your L2 blockchain that, you know, it's its own chain basically, and it keeps progressing. And then afterwards, with some, you know, up to several hours of delay, you come and you basically you compute over a long time these proofs and then you bring them to the chain. And what now is the second huge jump here is to go from this very asynchronous delayed process to a verification loop from block creation proving verification that all happens at the same speed of the blockchain synchronously. So like within a single Ethereum slot right now, that's 12 seconds, we'll bring that even further down. You have this entire loop, closed loop within that short amount of time. And so basically that's many orders of magnitude of performance improvement. And that really is what unlocks all of these huge gains for the L1.

B (7:32)

Galaxy operates where digital assets and next generation infrastructure come together, serving institutions end to end. On the market side, Galaxy is a leading institutional platform providing access to spot derivatives, structured products, defi lending, investment banking and financing. With more than 1600 trading counterparties, Galaxy helps institutions navigate every phase of the market cycle. The platform also supports long term allocators through actively managed strategies and institutional grade staking and blockchain infrastructure. That scale is real. Galaxy has over $12 billion in assets on the platform and averaged a $1.8 billion loan book in late 2025, reflecting deep trust across the ecosystem. Beyond digital assets, Galaxy is also building infrastructure for an AI powered future. Its Helios Data center campus is purpose built for AI and high performance computing with more than 1.6 gigawatts of approved power capacity, making it one of the largest sites of its kind. From global markets to AI ready data centers, Galaxy is serving the digital asset ecosystem and end Explore galaxy@galaxy.com bankless or click the link in the show notes Euphoria brings one Tap trading to the palm of your hand. Built on Mega Eth, Euphoria takes real time price charts and projects it over a grid of squares. You tap the squares that you think the price will enter in just 5 to 30 seconds in the future. If the price goes into that quadrant, you can pocket anywhere between 2 and 100x your trade. No other application helps you trade faster and with more leverage on market driving events like FOMC meetings, presidential speeches or global macro events. Thanks to Mega ETH's real time blockchain chain, Euphoria is the way to get real time price interactions with the market. On Euphoria, you'll be able to compete with friends using Euphoria's real time social trading experience, allowing you to go head to head with your friends. A great party trick. If you project the app on a tv, it'll be like the Mario party of derivatives to trade. On Euphoria, people can deposit stablecoins from any chain or do direct fiat transfers and everything Gets converted into mega eats native Stablecoin USDM in the background. Check it out at Euphoria Finance and download the app or find it in Telegram as a mini app. In 2024, emerging markets generated over $115 billion in annual yield for investors. With yields ranging between 10 to 40%, these are some of the highest, most persistent yields on earth. The problem? Defi can't access them. BRICS changes this built on mega eth bricks takes emerging market money markets and sovereign carry and turns them into composable primitives you can access straight from your wallet. While defi investors earned 3 to 6% on stablecoins and T bills, institutions have been harvesting 10 to 50% yields backed by sovere monetary policy. BRICS connects these worlds with institutional grade tokenization, local banking rails compliance across jurisdictions and real time Stablecoin settlement bricks does the heavy lifting so Defi can finally access real collateral and structured products. On top of real world yield, even the best carry trades can be within reach. Bricks brings Defi's promise to the emerging world and brings emerging market yield to your wallet. Let the yield flow with bricks maybe going back to just like what makes a blockchain a blockchain. Bitcoin had this fundamental insight of the way that we get rid of a leader in a blockchain is that everyone checks the legitimacy, the authenticity, the correctness of everyone else. And so when some bitcoin miner mines a block but it finds the correct hash and it proposes that that block, everyone else in a network doesn't trust that leader, they re execute all of the same work to verify it for themselves. And that's, that's the way that bitcoin discovered the way to have a decentralized network is everyone's checking everyone else. And that re execute word has just been the status quo for, for all blockchains. Everyone redoes all of the work. And the way that that impacts blockchains, all blockchains to this day, is that it kind of is hamstrung by the slowest node in the network. Or at least there is some requirement for computation that every blockchain has that. You know, if you aren't at least this fast, you can't keep up with the network because you can't keep up with executing all the everyone else's work. And now, you know, some blockchains have different opinions as to like how much requirement you have. Bitcoins is very low. Ethereum has also been a very low requirement because we want to be decentralized. You know, as you Said like, you know, some chains like Solana or other very fast chains have had a higher opinion as to the computational requirements it takes to do the RE execution. But nonetheless, all blockchains to this day are re executing all of the same work. And it's redundant. It seems unnecessary. It seems like, is there a way where we can not do all of that extra work and still have a blockchain and a parallel to that? As you said, with like the Ethereum layer twos, what we understand is that there is a way to not do this, and that is with ZK proofs. And so in addition to the technological progress of blockchains as a whole, we can make them more efficient. We can, you know, we can juice some of the throughput, but on a parallel path. There are, there are cryptographic algorithms that instead of allowing or forcing everyone to do the RE execution, you can simply verify a cryptographic hash, a cryptographic proof, and that part is trivial, that's easy to verify. It's hard to produce. In the same way a block in a blockchain is hard to produce, but it's trivial to verify the correctness of a cryptographic proof. And that's kind of the, the trick. That's, that's where we remove the RE execution. A great Elon Musk quote here is the best part, is no part at all. And what a cryptographic proof does is it removes the whole part of RE execution. So the blocks in a blockchain get re. Get executed once and then no one has to actually re execute it. They can just trivially verify it, which allows for a lot of redundant work to get removed from the system and that allows for just work being constrained down to one block producer and then everyone else is just like, thumbs up. That is correct. And we really like take off the brakes off of a, of a blockchain system. Now, the reason why Bitcoin wasn't built like this in the first place, the reason why Ethereum wasn't built, or any other blockchain wasn't built like this in the first place was, you know, technological progress along cryptographic hashes also needed to mature. Maybe you could like take everything that I just said and run with it, but also, also talk about just like the technological parallel path of cryptographic proofs as they've been progressing alongside blockchains.

A (14:03)

Yeah, absolutely. So actually, just to start with where you started with, with the Bitcoin example, because some listeners might have, might have heard this and might have been like, hey, actually, isn't there this asymmetry as well, where a miner does all this very expensive work but then not every other node has to redo the same mining, right? Indeed. In the mining process there's the same efficiency like asymmetry. And that's actually, it's a very common trick in cryptography where basically you try with mining, you try all these different hashes, you find one hash that has enough of leading zeros. That's how difficulty in Bitcoin work. And then you can just show people and it's very cheap to, to verify. So Bitcoin on the consensus mechanism side already uses a similar trick, right, but on the actual content of the block. Right. So like what is in a block? In a bitcoin block it's all the transactions. Each transaction comes with a signature. So you have to actually verify the signatures. You have to say okay, balance was moved from this account to that account. All of the actual operations of the blockchain, that's the re execution part, right? So Bitcoin does get, has this like again because this is a very typical trick in cryptography that you have this like asymmetry of generation versus execution. It uses that for mining because that's easy to do with proof of work. It's very, very hard to do this for the actual operations within a block. And so now this is what basically the main unlock here is that basically now we are bringing the same efficiencies that people are used to from this like one, one miner everyone can verify easily. We're bringing that same efficiency to the entire block. And of course on Bitcoin the actual Bitcoin block is very small. It's, it's a very simple operations on Ethereum because you can run smart, smart contracts and you, we are massively scaling the throughput. It's, it's much more complex. Like the vast majority of the overhead in processing and following the chain is not the consensus part, not the proof of stake part, but it is this the actual contents of a block. So what, what has changed on cryptography? Actually my, my, my friends from, from the Zero X Park team, they are like one of those cryptography research labs they always talk about, I think they, they call it maybe I maybe getting the slightly wrong but they, they call it the first generation of cryptography and the second generation of cryptography. What was the first generation of cryptography? It was basically handcrafted algorithms for very specific use cases. So a signature algorithm or a hash function or anything that basically it fulfills a very specific purpose and you can use it for a very in a very specific context. And, and those are amazing, right? And like that's been like the story of cryptography for the last 50 years, right? It's basically like more sophisticated special purpose mechanisms. And those were already very mature when say Bitcoin started, right? This is why they were able to just take the concept of hash functions off the shelf. And you can do amazing things, signature mechanisms, all that kind of stuff. What is very new, it basically started I don't know, a decade ago or something like this, probably academically a little bit earlier. I'm not actually a cryptography expert myself, so I don't know the exact kind of early story there, but, but that's basically like Cryptography 2.0 in a sense. It's general purpose cryptography. It is basically now the ability to make cryptographic statements about arbitrary computation. Instead of having to like handcraft it for a specific use case. You're now, you're going to this general purpose world. And this is like a huge leap because it means that instead of like just say signing a message, you can, you can prove whatever you want, anything Turing complete, anything that you, any execution whatsoever, you can now compress, you can make it, you can make a cryptographic statement over and, and that, that was a giant leap. It was, I think only really it was pulled from academic theory to feasibility, I think through a lot of funding that came from the blockchain space, of course. And it's, it's really incredible progress. And that progress, I think I would think of it as several stages. So one was just. Not just one was what we saw with ZK rollups. And then of course already prior to that special purpose chains like zcash, right Was just the ability at all. You have a protocol and you can make a proof of it. You can prove that a block of a blockchain is valid. What we've seen since is this progression of the tech stack. So for example, all of these earlier stages, like again zcash, early ZK rollups, what they all did is they basically they handcrafted the rules of the chain that they were trying to verify into very low level, it's called circuits. You basically express it in very low level constraints that you then make your knowledge proofs about. And where we've been going from there is now we have this and you can really. It parallels the early progression of computers as a whole. Right? We went from. You have to manually specify every individual system you want to prove. Yes, as like the set of constraints of circuits. It basically went from there to Introducing. And it's such an elegant idea, but it's crazy that it works. It's just introducing this intermediate instruction set. So it's called an ISA instruction set architecture. And you can think of it like how a processor in a computer has instruction set, so x86, for example, right? Like intel or ARM or basically like it's what instructions does your processor understand. And the way these modern ZK systems are now built is you pick one of those instruction sets. Like the one that is actually becoming the standard in Ethereum right now is RISC V. RISC V is similarly, in principle, it's just like a list of operations that your processor could do, right? It's often run in a virtualized way. So it's not actually run on real RISC V hardware, it's mostly run on in a virtualized kind of way. But basically it's just like a list of instructions. And then you then write zero knowledge provers that can just prove arbitrary RISC V code. So you're just saying like, look, give me any RISC V code. And I just have this machinery that can make statements, cryptographic statements about it. And what that now unlocks is instead of having to handcraft like the early ZK EVMs, they were literally handcrafted EVMs inside of ZK systems. Now you can just literally compile, you can just take basically, basically you can take an Ethereum client instead of compiling it to whatever your local machine has as an instruction set, instead of compiling it to x86 or something, you are now just compiling it to RISC V and then you just get the ZK proving for free because. And RISC V, like that's just like a typical kind of endpoint for compilers, right? So basically you're modularizing the tooling and toolchain. And of course that's only possible now with all the efficiency gains, because of course you're losing some benefits of handling crafting all the optimizations. But it's a phase change from how feasible it is to do this for just like big complex projects. And so really the way Ethereum does the ZKVM is again, of course, the real world is a bit more complex, but in principle you can really think of it. We take the existing Ethereum clients and we just compile them to RISC V and then we just have provers that specialize in making proofs over RISC V. And it's really amazing how far the industry there has gone to make that feasible. And then the last jump, the last big kind of Conceptual jump from there to this is becoming feasible for us is the real time element. So we arrived at that world and you could do that within an hour. And sometimes if the block is actually convenient to prove, maybe you can get it down to a few minutes, whatever. That's the world that we used to be in. And then we have had this massive industry collaboration effort that started like a year and a half ago with Justin Drake really like pushing super hard on this and these teams, this is really mostly driven by teams outside of the Ethereum Foundation. These teams have done an absolutely amazing job. And I would say the last year was really the year of performance, of real time performance. Throughout the last year, teams just kept pushing this down orders of magnitude. And now we're at the point where you can, you can, we are starting to achieve the target zone. So like we are actually able to prove, consistently, reliably prove a full Ethereum block within five seconds, something like that. And that's basically the promised land because now we have all the technological building blocks and now we can talk about the rollout and all these things, but we have all the, from the cryptography side, we now finally, for the very first time ever, we have all the elements we need to run a general purpose blockchain at real time proving speeds. And that's something that has never been possible before.

B (22:20)

I really like the idea of. There has been this, you know, three parallel paths of computing. First starting with computers where they were first narrow and then we were able to make them generalized and then we were able to make them generalized and fast, which is where, you know, modern computers are now to this day. And then we created blockchains, you know, virtualized ledger based computers in the, you know, in the sky decentralized systems. They started narrow with Bitcoin and then we learned to generalize them with Ethereum and then we learn to generalize them and make them fast with many other other smart contract chains. And now we are doing the same thing with cryptography. Started narrow with cryptography, learned to make it generalized, and now we are making them generalized and fast. And that generalized and fast unlock on the computing tech tree of cryptography is now being able to be taken and bestowed into Ethereum, which is what we're going to talk about for the rest of this episode. So now that we have the ZKEVM and it's, and it's in the Ethereum blockchain and you know, it's up and running, what does that actually change with Ethereum when we get to this point? How does Ethereum actually change?

A (23:29)

Right, so of course we're not there yet, but that's kind of, that's where we're going. And so why is this useful? So coming back to scaling, right, I said that there's basically three main elements of scaling. There's the, the bandwidth, the I O and then the actual computer. Now the amazing thing about real time ZK VM is that it actually is the core of a broad. Like the way I would say it is. Like it helps us scale all three of these, but not just on its own, but it's the unlocking piece that allows, that basically enables a broader transition that addresses all of these elements of scaling. And so that's why when we talk about zkvm, to me it's more like the most exciting element of this broader change. And that's why when you said at the top of the podcast, this might be the biggest change ever, I would agree. Not just the ZKVM itself. We'll talk in a second about statelessness, about data availability, sampling. All these things come together to unlock this. And so let's take it step by step. So the one of those three constraints, the one immediate impact you get is on the compute side, right? So because that's the nature of ZK proofs, right, you basically you're able, with very little compute effort on the verification side, to verify arbitrary length execution. So no matter how much you fill the block, now of course we can talk about constraints, there's still block building. Some node somewhere needs to do that. So it doesn't give you literally infinite throughput, but basically you can have whatever length of computation you have, you can compress it down into a constant size proof and then you can verify that with just very little compute. So compute scaling, that's in a way the easiest one. That's the one that you get very easily. Now you look at the other two and you're saying, okay, how does it impact IO, right? So historically, traditionally when you execute an Ethereum block, what you do is you start executing, you do some compute, at some point, you want to load some state. Actually, already at the beginning of a transaction, you need to load your account. You need to load the account that you're calling into that you're sending eth to. So you basically, you immediately need to go to disks, right? So you have this entire mixing of sometimes you go to disk, you load values, sometimes you do some computer, then you go to disk again. It's like this, there's intermixing one actual Change to Ethereum that we're already doing before zkevm. It's called Block Level Access list. So it allows us to. It basically it adds some annotations to a block of like this is the data you'll need. So actually what happens now is that you actually go to disk at the very beginning. You bring all the data and then you can do the execution. But you still have this element of having to go to disk both before the block and then again after the block to go and be okay. But what's, you know, like we have to update all the values and then we have to also like compute what is the new state route. So how does it look with zkvm? Well, there's a few things that are fundamentally like improved by zkvm. So the important part is that ZKBM basically already takes in as part of the claim. It's like, hey, assuming the blockchain was in this state and I apply these transactions, now the next state is this. So basically you no longer need to go and load the data from the values from disk. So basically you're saving this IO on the load side naturally. And then the thing that you'd normally still have to do is you have to go and still write the updates, right? So you still have the state of Ethereum. So after you verify the block you still have to go and say okay, these values change, right? So you have to go and apply that change, one that's no longer in the critical path. So you can do that after you've already finished verification. So if you have validator you can already vote, you can say ah, this block was valid. And then afterwards I go and actually apply the updates. So in terms of like what is the current price of this uniswap pool or what's the balance of this account, right? Like I might only go update this on disk after I already know that the block is valid. So, so, so that's, that's a natural benefit you get. But if you want to push it further, we have to. And this is what I was saying, like this is one of those changes that is enabled by zkvm, but it's its own change, it's state stateless Ethereum or partially stateful Ethereum. So what does that mean? Well, instead of like today, any node in Ethereum network basically has to have the full state and that's with free execution that is unavoidable, right? Because if you want to verify a block, you have to go and again load all the data you have to have it all locally. Once you have zkevm, that becomes optional because you don't actually need the data local to double check the validity of the block, right? So, so what you can do is you can, in principle, what you could do is you could throw away the entire data, right? So you can basically just, you can only keep like this, this root commitment and you can just always update the root commitment and that's it. In practice, what you'd want is, because Ethereum nodes have multiple functions, they also operate the Ethereum mempool, they have to understand validity of transactions in flight, all these kind of things. What you'd want to do is you don't want to run fully stateless, you want to run in what we're calling partial statelessness. So for example, there's this proposal called VOPS Validity Only partial statelessness. So it means you specifically have a subset of the state. And that can be defined by several different rules. It can be, say, the balances of all the accounts, or it can be, I don't know if you are specifically interested in some state that belongs to you as the user or something. You can define what state you're interested in, but basically now you can keep a subset of the Ethereum state, and that's totally safe because of zkvm, right? And you only have to apply the diff, you only have to go to disk, you only have to have the IO overhead of updating that subset. So that's the second, basically like you have ZKEVM for compute. Now you have partial statusness for more optimized IO and also by the way, for keeping your disk size contained. We'll talk about state growth maybe towards the end, but basically, so you don't have to have a huge disk and then it leaves the third one, which is bandwidth, right? And how do you actually keep scaling the chain now with the CK system while actually keeping bandwidth requirements the same or even reducing them? Well, that's yet another separate trick that's also again enabled by zkevm, but it's separate and that is you no longer actually need to download the full block. And that makes sense, right? Because you get the ZK proof, you have to download the proof, and the proof tells you, hey, assuming there is a block with this hash or something, once I apply the block, this is the result and that's proven. So the only thing you need to know about the block is that it exists. And that's a bit of a nuanced thing, like why do you Even need. I mean someone clearly must have created it otherwise they could not have created the ZK proof. So why do you have to verify that it exists? Well that's for the nuance reason that you can otherwise withhold the data. Like that's also the same for. That's why for example we even have blobs in the first place. Actually for L2s is the same story you have to publish. You have to basically prove that the block was published. So anyone can access it and anyone can get access to, to the transactions that were applied basically. But what you can do is, I mean that's again where like the synergy with the L2s, it's just a beautiful story. We have already built out specialized functionality for verifying the existence of data very efficiently without downloading it all. It's called data availability. It's called blobs. Right. So what we will do is we'll take the Ethereum blocks and we just basically become our own roll up. In a sense we're putting the data into the blobs. It's called block and blobs bip. And with that, now all an Ethereum node has to do is just sample, sample the data. And we are in the progress of making that more and more efficient because we want to provide more and more data for our L2 partners. And that now naturally also benefits ourselves because now you can have more and more like bigger and bigger blocks while keeping the footprint in terms of bandwidth also very constrained. So now you're right coming back. We have ZKVM and we have partial statusness and we have block and blobs data availability sampling together they scale bandwidth, they scale IO and they scale compute. And that is how you basically use all of these elements to scale the blockchain. And then there's some nuances. You don't get everything for free. You have state growth, we can talk about state growth that we have to separately address. And you have things like being able to efficiently sync an Ethereum client. There are things like being able to efficiently run an RPC node, like what Infura is doing these kind of things. So there's more to scaling than this. But, but the core story is that you have these three constraints and ZKEVM directly and indirectly addresses all three.

B (31:31)

You zoomed in on each one of those three and as you just said, you put those three together. That's how a blockchain becomes a blockchain and we improve all three of those things. I want to zoom out and really focus at that level of advantage, when we reconstruct how a blockchain becomes a blockchain on, on like all three comprehensively, the you, you said, you really kind of said it when you said Ethereum uses its own data availability to be a ZK roll up. As I understand it, the zkevm when it is up and running and operational and you know, fully fleshed out and forked into, into Ethereum, the Ethereum layer one has the performance of a blockchain that is a ZK that would like be a ZK rollup. In fact, it maybe even is a ZK roll up. It just also is the layer one itself. And so we get all the performance benefits of rollups. We get, we get to ZK everything which unlocks the brakes, undoes, takes off the brakes on the Ethereum layer one. And we already have the infrastructure needed with the data availability sampling for this to get done. And so from a performance perspective, The Ethereum layer 1, which is known to be a slow, antiquated, you know, expensive blockchain do computation on upgrades itself to have the performance properties of a ZK rollup. Is that a true statement that I just said?

A (32:56)

Yeah, I think that's right And I think, I think like, just, I think it's important to understand like why even does Ethereum. Like why, why, why is Ethereum so slow, right? Like if we, if we ask that provocative question, the one really important element is that core to Ethereum's design philosophy is this, this, this guarantee that Ethereum never wants to compromise on which is verify, like easy verifiability and auditability. So the world that Ethereum always wants to be in is that any, anyone that want, any user of Ethereum can easily, if they want to verify or audit that the protocol is following the rules and why this is so important. Like people are always like, well, but in practice many users don't do it. And like other chains. Yes. Like for example, if you, if you're trying to join one of those high performance chains, it's actually, it's really, really hard to run a full node for one of those chains that scale just by increasing hardware requirements rapidly. Because not only is it do you need a heavy machine, but often you're not even allowed to join the peer to peer network because it's so performance sensitive that they have to have whitelists for who even is allowed, which nodes are even allowed into the network because otherwise they are just too brittle and they just immediately collapse. So basically, and why does it matter? Because I think people Think about proof of stake always in this like well there's validators and they vote on what's the current state of the chain. In Ethereum, validators get basically get handed the current rules of the chain by the community, right? And any hard fork is basically a social decision of hey, it's a social governance act. The Ethereum community decides that now there are new rules to the chain and the validators only vote on like okay, given those rules, which blocks did I see which blocks follow the. There's no individual decision that in a tester in Ethereum that makes right, they just, they just watch the chain and they just attest to what they see in other proof of stake chains. While in principle that should be the same thing, what in practice happens is that because any non validator user of the chain is just a light client because you can't just participate in the chain, basically any user in those chains distrusts the majority of validators. So in practice those validators determine what the rules of the chain are, right? Like in a chain that does not center about verifiability, you validate a de facto control what the rules of the chain are like. If the majority of validators want to run a different set of rules, they can do that. In Ethereum that's not the case. Validators can't accept or reject a fork, they can just make a fork of their own. They just get handed the rules by the community. And the ultimate power always lies with the community, right? So that's why verifiability, auditability is so core to Ethereum and that's why we have been historically slow to embrace scaling because that would endanger that property. And now with ZKVM we have this magical way of, of getting the best of both worlds, getting the full verifiability and the full performance. Although I will say all of this is a bit too black and white actually what's been happening. So for example, I'm not actually like, I'm personally while I'm involved with our ZKBM work, we have experts, we have Justin who has been on the podcast before many times, we have Kev who's doing absolutely amazing work there. We have many people there that full time work on this and I'm actually focused much more on short term scaling. And so while it is true that with traditional scaling there's like a limit that you can reach and otherwise basically you have this fundamental trade off you can't escape. Ethereum historically has been very much in this mode of. Well, we are working towards this eventual end state. And we know we want to eventually do zk, so we'll focus on that. And as of say a year, year and a half, two years ago, I think the mindset on Ethereum has shifted a lot towards saying look, we are now in this moment in time, real world adoption is here, right? Like it's no longer this future thing that we're building towards. So we have to like now and it's actually a very non trivial thing. We have to find the right balance between still working on these Manhattan projectile type jumps like real time zkvm. I really, I think, I agree like you said, I think it's the biggest thing Ethereum probably will ever have done. But we can't just wait for another three years for this to arrive. We have to do things now. And so this is why I think we actually scaling is this perfect example. We have this really good hybrid approach. The next like we started last summer, we're saying ZKVM is three years out and we will in a second I think talk about more the sequencing of the exact rollout but we don't want to wait three more years. This is what the old Ethereum would have done. What we're actually doing is we came up with this scaling plan and it's a, it's a very continuous smooth function. So our goal is basically we have this rule of thumb, we're saying Our goal is 3x scaling every single year. So we are increasing the throughput of the Ethereum blockchain by roughly 3x every year. This is more of like a goal, an ambitious statement. It's not clear that every single year we'll be able to hit that, but we think we see a path at least it's a possible outcome. And in practice the first three years of that scaling with traditional means and then from that point on basically we have the smooth handover into the ZKEVM paradigm. So it's not all just black and white and Ethereum is only doing zkvm. We're actually now, I think we have the best of both worlds now we have like the next two, three years. We are doing this ZKEVM in parallel, but we're still doing the traditional scaling. And then we jump into the ZKEVM paradigm. And so that means if you're a builder and you're considering building on Ethereum L1 you have this like instead of having to like exactly think okay one is this hard fork and what is the exact. No, you can just say 3x every year you look at the throughput today you can and you can just like very simply calculate like, you know, what throughput needs do I have? Is the other one a good fit or not? It's a very simple story, but under the hood it has this like these like two synergistic elements to it. So those long answer.

B (38:46)

Yeah, yeah. Well, the idea is that we're pressing the gas on stealing, scaling on multiple fronts, not waiting for the Manhattan Project of the zkevm, which, you know, the ZKEVM has been in the Ethereum roadmap since Genesis. I think like we've understood theoretically of the possibility of turning the EVM into a ZK algorithm. And you know, we understood that theoretically back in 2015. Now we're in 2026 and like, oh no, this is now, you know, just an engineering challenge. And we're like in the last mile of this and like it's basically almost here. And in the meantime we are scaling on the more traditional front as well. I want to get into the qualitative nature of the scale of the zkevm. So with block times and block sizes, those are the two ways that you have throughput. You have how big is your block and how frequently do those come, you know, you know, height times height times length. So can we talk about what that the nature of scaling with a zkevm does, does it help lower block times? Does it just increase block size? I want onsgar both fast and big blocks. I like my blocks big and fast. It would be great if we could increase the size of blocks. But there is also very important element of just like block times is critically important for trading and finance. So how does the ZKEVM impact both of these variables?

A (40:10)

Right, so to answer that question directly, zkevm indeed, it's not a panacea. It specifically addresses the throughput level. So it gives us much, much, much bigger blocks in the same kind of time constraints. It's even to be fully transparent, it is a small extra strain on the timing. Just because you have one extra step, right? You have to have this proving step that's in between block creation and block verification. You have to have proving, but that's a minor constraint, but it in itself does not give us lower latency. And this is why when you said at the top it's the biggest ever change, I was actually tempted to say, well, to me that's true on the execution side of the blockchain. Right? Like, same as with Bitcoin, how we Said there's the consensus mechanism, proof of work in that case, in our case, proof of stake, and then there's the actual processing of the blocks, Bitcoin transaction, Ethereum transactions, that kind of thing for the actual execution for the transaction bits. The ZKEVM and the related changes really are the major story for the next five years in parallel to now putting together this really, really exciting roadmap on the consensus layer side. And like the latency, that's, that's, that's all a consensus layer story, right? Because that's where basically the heartbeat of the, of the blockchain is determined. And so we have this, this, this, this separate process and you should probably, you know, this is maybe setting us up for a separate podcast episode. You should have bring someone on that's, that's specifically focusing on that type of work at the air for and, or the, the broad ecosystem. Because I think we have, we have this really exciting roadmap there that's getting us to a much faster finality. So right now finality in Ethereum takes two epochs. That's 64 slots on average. Two and a half epochs actually. Even so it's like long amount of time we're bringing this down all the way to basically single slot finality, two slot finality. It's going to come down like orders of magnitude. So that's super exciting. And then even within a single slot, instead of 12 seconds, we have a story there that's going to gradually get us down from 12 seconds to I don't know, 8, 6, 4. Much, much, much faster. And then there's separate work streams around. Can you get even faster? Inclusion guarantees, right? So that's the heartbeat at which the chain actually progresses. And you get guarantees about that's the result of your transaction. But can you maybe get in principle, like speed of light, just round trip time confirmation that your transaction will be included. Right. Like ideally I want to click a button and before I can even like, you know, within the hundred milliseconds it even takes me to realize something happened, boom, I have the confirmation like my, my trade will be included and then within like say four seconds, I know at which price. Right. Like I think that's the world we ideally want to be in. And we have a really, really exciting roadmap there as well. But it is a separate roadmap from zkevm.

B (42:50)

Okay, understood, understood. So the ZKEVM massively increases block sizes. I don't know if you can put numbers around that. And then it adds a Marginal increase in block times. Can that block speed come down in the future? Or what does it take for block times to get faster? And is that something that we are aspiring to in the roadmap?

A (43:08)

Yeah, that's what I was just talking about. Like we are aspiring to that. That's not just aspiring. That seems so indeterminate optimism. We actually have a plan that will come down. It will come down as early as towards the end of this year. That's not quite certain yet, but basically we're starting to make this a priority as well and it will rapidly then become a major priority.

B (43:28)

So maybe, maybe the part that I was wasn't sure of is like maybe the block speeds don't necessarily come down, but transaction assurances come down very, very fast. And you're kind of saying, well, that's what people want anyways. Is that correct?

A (43:40)

Well, it's, it's basically you have three things. You have the, the time to inclusion confirmation, you have the actual time to the next block and you have the time to finality. All three of these will come down. The, the heartbeat of the chain. The time to next block will actually be the one that's only going to come down maybe by a factor of three, something like that, from 12 seconds maybe to four seconds. Eventually maybe we can go lower, but I don't wouldn't necessarily want to promise this. I think the other two are actually the more exciting ones. Finality will come down massively and time to inclusion, that's a bit more of an exploratory process still, but that also will come down massively. So I think basically like, yeah, but block times as well will come down, but none of this will be through zkvm, although of course it will be part of an integrated system.

B (44:18)

Right, okay, understood. Okay, so you're saying there's a variety of ways in which Ethereum speeds up broadly and then there's like zooming into what speeding up means, you know, has nuances which you just went into. And as at least when it comes from a user experience perspective, we have ways of providing essentially instant speeds from the perspective of a user. Right, okay, let's talk about the, the rollout plan for the zkevm. We are in phase of Ethereum where there is no zkevm. In the future we will be a phase of Ethereum where it is all zkevm, but it is not an acute moment as I understand it. How do we go from A to B? What does that, what does that roadmap

A (44:59)

look like of Course, because this is like a multi year process. It's, it's as typical, there's like very concrete steps as say for the next 12 months. And then as you go further, further into the future, I can more point out that's the current plan. These are maybe the open question, these are the directions. Right? So that's how these things always work. The interesting thing, as I said, top of a podcast, is that it's not just a one time hard fork, there will be a one time hard fork and that is about the eventual switch from what will come first, which is optional zkevms for those nodes in the Ethereum network that want to consume proofs instead of re executing. Then at some point there will be this moment in time where we say, okay, now Ethereum just runs on proofs. Of course you can still run a node optionally in re execution mode if you want to, but by default the network now guarantees that there will always be proofs, basically. And then from this point where the switch to mandatory proofs is, is when you really get the scaling gains because before then you are basically not yet mandating that. Anyone? Right? So like you're still allowed to run a full re execution node and you're

B (46:03)

allowed to flow and the network will hear you.

A (46:06)

Exactly. And after that it's like okay, if you want to be a re execution node, that's a special purpose role. Now that requires special purpose hardware of that's internally it is a big project. How do we make sure that if we run at much faster speeds that you can still run an RPC node in a performant way? So this is a separate work stream that we're working on. But in terms of the typical, both typical validator even and the typical full node out there, that's not even a validator. Those people basically by default will all at that point then switch over to zk. Now again, as I was saying before then is this phase of optional proofs. So that has not started yet. Right now we're in the proof of concept phase. So I think Justin presented in Buenos Air is there's this proof of concept of hey see my validator can in principle already run on zk, but that's not yet like if you're a validator, you can't use this yet today. Right, but the idea is that very soon, so meaning within say the next 12 months or so we are starting to put this out there in a early production ready state where the idea is that we will of course we will give very clear guidance of like this is the specific nuanced level of confidence we have yet in the, the security of the system, all these kind of things, right? And for example, at that point we could not yet have the majority of the network run on this yet, right? Because if there's some bucket with it or something, you very much still want to have the backbone of all the major validators run on this. But if you are just a full node just for hobby purposes, or maybe you're a validator on a very weak machine, you might be tempted to just at that point transition over. So that will be the first step. And then one thing we haven't really touched on yet is that up I guess a little bit is that there's actually quite a few technical requirements that we need to hit before we can move the bulk of our validators over. And I can briefly go over those. So one we already touched on, for example is the block in blobs, which will come at some point where we basically say, look, we now put the block into the data. So there's also the sampling aspect to it. If you are a re execution node, you still download all of it. But if you now are a ZK node you can start only sampling it, right? But this will come after the initial optional proofs rollout. So before then a validator basically has to download the proof, but also has to download the full block still. So it means they don't yet gain any bandwidth benefits, they only get the IO and the compute benefits. So basically like we have the block and blobs that will have to come. We have to have in general networking improvements that are in the works. We have repricings, meaning we have to actually make sure that the parts of the Ethereum chain that are especially hard to ZK verify we make a bit more expensive. We basically rebalance the cost and then the most important technical dependence dependency for the mandatory proofs, the full transition basically is actually it's related to the statusness element. And that's specifically that we need to transition the Ethereum state tree over to a new format. Like long term listeners might be familiar with this like elusive worker tree idea, right? And so merkle trees were this early Ethereum idea of like, hey, we currently have a Merkle tree. So like any account in Ethereum is part of this huge tree structure and every block the entire tree is updated and at the roots you have your balance and you have all these individual elements about your account. The original idea was let's transition this over to a more efficient form that's called Verkle trees. And that was the unfortunate trait that verkle trees had, is that they were just never really necessary. They were always like one of those nice to have features back then, back when we were not quite sure how aggressive do we want to scale the chain? How quickly will state growth become a problem? There were some worlds in which it would have been a more urgent topic, but because we never went down those routes, it was always right beyond the edge of urgent enough to ever do so. We never ended up shipping verbatrees. But the nice thing is we now already have a lot of prior work and now we can actually go directly to the next generation of cryptographic structures here. And so instead of a virtual tree, we're going to something that's basically called a unified binary tree. It's somewhat similar. The main difference is that it has a very different kind of like, instead of like a vertical tree is a very wide tree, a binary tree is a very narrow tree, and the main, I guess, simple set. The main difference is that the binary tree uses a post quantum secure hash function that is also very efficient to prove. So it's already basically fitting into this future world that Ethereum is going to. Whereas the Verkle trees were basically the standalone piece that doesn't quite fit. But the nice thing is we have a lot of prior expertise. We have Guillaume, who has been the champion of verkle trees and he's kind of frustrated to no end that we never ended up shipping it. And now his time has come. So like he's been very excited. He's now working towards this binary tree upgrade behind the scenes already and he's doing an amazing job there with his team. And so actually over the next two years, I would say the biggest kind of individual story that we'll have in Ethereum will be this upgrade to binary trees. So that will probably over the coming months start to become a bigger and bigger topic. People will start hearing about it and that will then enable very efficient stateless operations or partially stateless operations for nodes. So to recap, basically starting a year or so from now, we will roll out optional proofs. Those optional proofs will initially only be immediately effective for compressing computation and helping somewhat with I O load, but you still have to run in stateful mode. And then we will bit by bit start bringing these pieces into the protocol that unlock the full potential of zkevm and in parallel keep hardening the ZKEVM security properties so that by the time we are running out of conventional scaling means, which is, that's why all of this is so beautiful. We basically have exactly like three years of scaling, two and a half more years of scaling ahead of us of traditional scaling. And at that point we will be ready to just seamlessly move over to zkbm. So one year from now, optional proofs, two and a half years from now, ish plus minus this full transition to mandatory proofs. And then we'll have all the pieces ready to then immediately keep scaling based on ZKBMs after that. So that's the full out

B (52:18)

as I understand it. The way that it happens is that in a year we will introduce optional proofs. The Ethereum enthusiasts of the world who just, you know, love Ethereum, tinker with Ethereum, run nodes or Ethereum out of just pure passion will start to do these optional ZK proofs. They will be the pioneers of the transition of Ethereum to be a, you know, a classical blockchain transitioning into a ZK blockchain. And that will give, you know, Ethereum researchers like you, the, the EF a lot of data of what it looks like to be in production because of these enthusiasts that are running this optionally because they just, you know, love Ethereum so much. That will give you guys the information you need to do the prerequisite upgrades that are needed to actually get a full mandatory ZKEVM fork. And as you alluded to it will also give us just insight into, you know, in production use of the zkevm. Maybe there are bugs. If there are bugs, we need to find them before we make them mandatory. And so, you know, all the different clients will have their own version of the ZKEVM and we'll be stress testing all of those by using them into production. Basically there's a whole era of demo Ethereum zkevm and that will take, I think you said, you know, somewhere two to three years. As we run out of classical scaling that will have, we will have the hardened data and the information, we will do the prerequisite work to unlock mandatory the zkevm. Around two and a half, three years from now, the mandatory ZKEVM hard fork will happen and then Ethereum will make the transition to this is now a ZKEVM blockchain. The story doesn't end there though. What happens after the mandatory ZKEVM fork? How does the story continue beyond that point?

A (54:00)

And just by the way, to clarify a little bit for people that maybe think, oh, now gung ho starting to Release optional proofs for anyone who wants to be like an experimental guinea pig here. I think when we are ready to start releasing this there will be very explicit guidance around what is this for? What kind of production grade readiness does this have for which use cases? I think it's more you can imagine more it's about how many nines after the comma ethereum mainnet must never go down. We have 100% uptime. We are not willing to risk this. So we are basically willing to take extra precaution there. But importantly if you're for example at some point running a ZK validator and you actually there is a bug or something, right. The worst it happens no one will get slashed, right? What happens is just you're briefly kicked off the chain and then you're automatically flipping over back to normal re execution mode and then worst case if we're already in this partial status world you might have to first resync some of the state, right? So worst case you're offline for a couple of hours and then you're back to back online back on the chain. So. So none of this, we'll do it very responsibly just because you know, just to clarify this. But yeah so and basically I think the way that these again absolutely amazing ecosystem ZK teams are talking about this. I think last year was all about, I would say it was the year of performance getting to real real time ZK VM this year is the year of security getting to like absolutely hardened. There's also like this bits of security measure, right? Like getting getting to a level where we are very confident in the security level. Then next year I think will be the year of productionizing the ZK VMs and then the year after will be the year of like transition to mandatory. So like that's basically the performance security production and then like full transition. That's how I would think about it is like one year at a time in terms of what comes after the transition. Well it's just I think and that's why I was saying earlier like with the further you go out the more unknown unknowns there are. It's just about saying at that point we will have all of the ingredients like you know we have the state partial statusness, we have the block and blobs and we have the ZKVM to take advantage for scaling but we don't expect that once we get closer that it's like a one time switch and now we can run it a thousand times faster. Instead we basically like right now, conservatively, quote unquote, are projecting this three times per year because we expect that there will be individual remaining challenges we have to address. Right. Maybe we have to restructure the way nodes sync, or maybe you have to restructure the way RPC nodes again, operate. Operate. So you're confident that the chain is still usable at higher rates. Right. So this is just expressing that while we have the main architectural ingredients, there will still be a lot of detail work. And so we expect instead of making use of it all at once, it's going to be this continuous process. And again, the nice thing about this rough 3x number is if you just say look, every two years you get a rough 10x 9x 10x. So basically we're thinking we have a path for maybe five or six years of this. So six years at 10x every two years means 1000x. So basically the first three years of that we get traditionally, then the next three years. So the ZK EVM. So in six years, roughly 1000x of where we started last year. That's, I think the. Again, is this guaranteed yet? No, we don't yet have. We think we see a path. We think we see a path. That's our goal. And then of course beyond that you could, if you want to be like more inside fiber world, like now you can think about native roll up. So maybe the way we then keep scaling beyond that is not through just the single chain. You know, maybe then we are back to this kind of sharding type setup of multiple chains synchronously composed. Yeah, we have to see. But that's, that's the, the plan.

B (57:37)

What if you could trade gold, Forex and global markets with the same tools and speed that you use for crypto? That's exactly what Bitget Tradfi unlocks. After strong beta demand, including over $100 million in single day gold trading volume, Tradfi is now live for all users. Inside of your existing Bitget account, you can trade 79 instruments across forex, precious metals, indices and commodities, all settled directly in usdt. No platform switching and no fiat conversions. This is Bitget's universal exchange vision in action. Crypto and traditional finance side by side. You get deep liquidity, low slippage and leverage up to 500x letting you apply crypto strategies to macro markets. New to Tradfi. Start with gold. The Gold USD pair is liquid macro driven and a familiar natural bridge between crypto and traditional markets. Try trading gold on bitget now@bitget.com click the link in the Show Notes for more information. This is not financial advice. Few people in crypto put real skin in the game when they make public top or bottom calls. The Defi Report is one of them. The week before the October 10th flash crash, Michael from the Defi Report emailed his entire newsletter saying he's going aggressively risk off and sold the majority of his book from crypto into cash. This is when eth was about $4,000 and Bitcoin was 110. Michael runs the Defi Report, an industry leading research platform built on data cycle awareness, risk management, transparency and most importantly, skin in the game. We like Michael at Bankless. We like his analysis and that's why you hear him on the Bankless podcast about once a month. And the Defi Report is giving Bankless listeners one free month of access to the Defi Report. So if you're looking for some sharp, sharp data driven analysis to make better informed decisions around your portfolio, you can learn why and how Michael called the top and what he's doing next all in the Defi Report Pro. Check it out, there is a link in the Show Notes onsgar. As I understand it, client diversity is a big topic here. Why? Why is client diversity relevant to the zkevm and how does the ZKEVM impact it?

A (59:29)

So I mean of course I think people will be familiar why client diversity is so core to Ethereum and to Ethereum's kind of hundred percent uptime, right? Like there's the redundancy factor you get, you get from client diversity. And so the reason why this is relevant is just that like the nature of clients, the nature of client diversity changes in this world. And that is because again if we think back to how I explained how there's like this basically most likely risk 5 kind of intermediate target for ZK and then you basically you just run a of course heavily modified but basically like a traditional execution layer client that gets compiled to RISC V and then you take one of those new ZK proving systems that then take the risk 5 code and prove execution over it, right? So what that means is now basically the Ethereum execution layout nodes live inside of the ZK proofs, right? Which is of course conceptually like very different from what that used to be before. And so what it means is that now the actual node architecture is actually quite interesting. You basically you run and that is a little bit still tbd. Like it might be that you're still running this explicit split of two clients like the consensus layer client and the execution Client. But the execution client's role is very different. Now it basically just verifies the proofs. The one that you run locally, right? It just verifies the proofs and does some, maybe like mempool networking, that kind of stuff, state management. But inside of the proof lives the CK program that was also derived from an execution layer client. So if you think about the roles of clients now basically it means that the main question is what about the diversity within those proofs, right? Because the outer system we are familiar with, but what about the diversity within those proofs? And so the nice thing is that in principle you kind of, you get a very comparable, very parallel type of mapping where you can just, you know, you don't just take a single execution client and compile it into RISC V, you take multiple. So you know, you basically you take kind of, you know, the existing ones, you know, or like also there's the few ones that will be specially written for that use case. You compile all of those and then to make sure that the redundancy is full stack, not just the first half of the stack, you also have multiple of these proving systems that take RISC V because of course there could also be bug in that part of the stack, right? Like that take the RISC V and prove over it. So you say you have like as an example, five of each, right? You have five execution layers that can be compiled into this RISC V and then you have five different proving systems. And what you can do is you can basically build pairs of those. So you can say, and Justin has this really nice idea where you can in principle even say performance, match them. So maybe the fastest execution client is paired with the slowest proving system. So the pairs kind of balance each other out. But that's just an idea. But basically the point is you then have these combinations of like, okay, this execution client with this proving system. And then in the end, again, in this example of five, you be in the world again where you have like five different types of proofs that could all. And they're all kind of redundant. They all have different, they're full stack different from each other. The generally novel thing here is that today you run one execution client, right? Like there's multiple, of course, and there's multiple consensus layer client, but you choose one of each. In this new world, what you can do is you can just verify multiple proofs. So for example, there's this idea, and again, just to use example numbers, but they seem roughly ballpark right, you could have a system where you say I only accept a block if I saw at least three different valid proofs for it. So I know that there are these five different ones and I have to have to have seen at least three of them, otherwise I don't accept the proof, accept the block. And so that actually gives you better redundancy because it's kind of almost as if every Ethereum node today would run three different client setups and would basically only accept blocks if they all agree. Which of course gives you much better properties than right now. We only have the redundancy across nodes, not within a node. So it's a better story, but it's also one where you actually have to be intentional so that you don't accidentally collapse any layer of the stack. And as just a side note, there is this experimental idea and of course in the age of AI, all the timelines collapse, so who knows, maybe that's actually even short term viable. But this experimental idea of a fully formally verified client and you could imagine an EVM implementation in RISC V that is fully formally verified to be correct in that world that could basically then you would no longer need redundancy at that layer of the stack. But again, this is as I said, like the further out items have some more uncertainty. This is like one of those theoretical out there approaches. But that of course would be also really nice to have. And I think formal verification in the age of AI will become a much bigger deal anyway. So this might be a really nice synergy.

B (64:02)

Yeah, as I understand it, the clients are where all of the risk is with the ZKEVM and why, where we have to be have like an extreme level of caution with the transition from a classical blockchain to a ZK blockchain. And like if, if something is going to go wrong, it's going to go wrong at the client level. I mean, I suppose that's always where it would go wrong. But when we, you know, we have, you know, Ethereum has over a decade of uptime because of client diversity, because of how hardened these clients are and we are kind of resetting that to kind of go back to you know, zero lindy with the zkevm, you know, we have some properties that will be carried over, but nonetheless there will, it's, it's risky in the sense that like we have all this great hardened infrastructure and we're kind of rebuilding it to be zk and so we have to have this like extra levels of redundancy as you said, like three proofs, three correct proofs to make sure that you know, not just two proofs, because two proofs might have the same bug, so we might prove the same bug twice. So three things like this. And so you know what, what's your level of fear about this part of the transition for Ethereum from the classical blockchain, which is so hard and 100% uptime to go where we go here. How scary is this?

A (65:22)

Oh, it's a really good question, right, Because I think the promise here is so huge that we're all very, very excited about this. But it is also generally like a huge, a very, very big challenge. And this is why I think it's not at all natural that we are even doing this two step rollout with the optional proofs and then the mandatory proofs. In principle, we could switch over at the end of this year, right? And we already plan with this extra 18 months period specifically because of that level of certainty that we want and that we project. That will take some more time. Again, it also gives us the extra time to roll out these other dependencies to really make use of CK proof. So it's actually quite synergistic, but still. Right, like this extra 18 month delay is specifically for that reason and to be clear, we would always be responsible with this. So if it turns out 18 months are not enough, of course we would delay this full transition to mandatory proofs. Maybe we even find some more gains we can get on the classical scaling side until then, right? So maybe it wouldn't even matter, but basically we would always wait until we are really, really confident. And it's not in principle harder, but it's just as you said, right. It's a bit of a reset. So a lot of say our internal expertise, both inside of the EF and across the client teams around security work, testing work, a lot of this is currently actively being restructured for this very new domain, for this very new type of operations with ZK understanding what even are the weak points here. Also say on the cryptography side, we have absolutely world class cryptographers inside of the Ethereum foundation and in the ecosystem and they are very thoroughly, really turning around every single stone here in this overall stack and really making us understand what are the critical points here. And, and again, how far are we from being willing to actually trust this? So for example, just to take a related example, I'm not sure if you already had maybe an episode on Post Quantum, but that's also a big topic on Ethereum. We will see, yes, mostly unrelated, but of course there's synergies here. And it has a similar nature where I talked about the binary trees. And part of the binary trees is this choice of hash function that you need in the tree. And there, for example, we also can't not block. But the longest piece of the timeline there is us talking with our cryptographers. We have a candidate like a set of a family of candidate hash functions. But getting to this point where we're saying, look, they are actually robust enough, they have been around long enough that we actually trust that they are secure. Especially something like hash functions that's so fiddly you can't really prove security. It's basically like a lindiness to it. How long has it been around? How many people have tried to find vulnerabilities? Has there been anything found? Right. This kind of thing. And so some of these things you just can't accelerate. Right. Like how many years of academics having looked into this has there been? Right. That's just like a hard constraint. And so both in this post quantum but also then binary trees we're also using for making use of ZKEVMs. It's not directly ZKEVMs but making use of them. There's just some elements of the timeline there that are dictated by the security needs that we have. And we just can't cut corners. So it's a big concern. But I think we are very responsible about it.

B (68:23)

Yeah, yeah, yeah. Which is why it's taking, you know, not a short amount of time. So just to maybe conclude this podcast the timeline it is now at the start of 2026 by the time we hit 2030 is a good guess for when we think we will have the full power, the full properties of the zkevm. You're nodding your head. Does that sound right?

A (68:46)

That sounds right. And I think we will be still probably in the process full use of it for scaling. So we will be hopefully 2030 will be another 3x year, maybe more than 3x because we have AI and the hard fork timelines are compressing. But basically another 3x year and 2031 will look like another 3x here. So we will be on this continuous scaling path but already squarely in the ZKEVM backed side of that scaling path.

B (69:09)

Right, right. I guess one point you made earlier and I guess it's worth reemphasizing here is we are the aspiration of Ethereum is to do a 3x scaling increase every single year, not just for the next three years, next three years for classical scaling and then the Next three years after that for ZKEVM scaling. So you know, while I am excited about the ZKEVM and I think it's incredible and why I want to like rally the Ethereum community around it acutely, there won't be a ZKEVM moment as felt by the transactors users of Ethereum because we are doing a 3x scaling per year for the next six years, first with Classical, then with ZK. And so you know, while the merge, you know, acutely transitioned us from proof of work to proof of stake, EIP 1559 acutely transitioned US from, you know, to have the burn and better transaction UX and like same thing with 4844 as an acute transition. This won't be that because we are scaling anyways.

A (70:08)

Right.

B (70:08)

But nonetheless, I think it is important to know that like only Ethereum will actually be able to access, you know, the, the final, you know, years three through six of scaling in that capacity. Because this, this is Ethereum's Manhattan Project. Like we said, only Ethereum has been working on this. It's been working on this since Genesis. And while Ethereum makes this transition from a classical blockchain to a ZK blockchain, it will be leaving every other blockchain behind in the, in the previous classical era. And so maybe that's why I'm so excited about it is like Ethereum is making the, the generational leap to the next gen blockchain and no other blockchain will have these properties that we've been discussing about on this podcast.

A (70:53)

Well, and I think this is, this is what I said earlier. Like it's not, it's not just that, like it's not an accident that you won't notice this, this transition. Like it's, it's actually by design. Like we're trying, we are like I think in this, in this, in this moment in time, we are really trying to balance this, continue the strength of Ethereum of being able to make these leaps, these paradigm jumps that I think other projects really struggle to be able to follow. I think again that's why we'll also just naturally have the post quantum properties. I think many chains will actually struggle quite a bit with actually getting there and at the same time realize that now we're no longer in this sandbox mode. We can't just say just wait, just wait for three more years. Don't be so impatient. No, no, no. I mean people are coming on chain agents, AIs are coming unchained, like today, right? So I think it's important that we basically just like we are a continuously scaling blockchain and it's our responsibility to under the hood, make that happen and use whatever both traditional and magical future ZK means necessary to make that happen. I will say, because you said like no one else will be able to do that. I think, I actually think it's one of those areas where there's again natural synergy between ethereum and the EVM L2 ecosystem. I think one thing that for example, we didn't talk about at all, but that I'm very excited about is that again similar to how the initial jump to non real time ZKVM came, mostly driven by the L2s, I think now that we are driving from the L1 side this move to real time ZKVMs, the L2s will also be huge beneficiaries of this because they will also just become the gain the ability of real time settlement. So that means also say all the bridging pain across the L2 ecosystem, right? Like, oh, in principle it takes either I use a mint and burn bridge or it takes like seven days for my asset to move across chains. All of this will disappear, right? It's going to be a few seconds for any asset to move from any L2 to any other, any real time zkevm proven L2 to any other real time zkevm proven L 2s through the Ethereum L1 or of course into or out of the Ethereum L1. So I think it's yet one of these cases where the fact that if you're part of the Ethereum family, we're like, this is kind of, this is the ecosystem that really has this principled approach to things. You get all of these benefits for free. Basically you are on the principled architectural path. And I think that has always been our competitive advantage. And I think while doubling down on the competitive advantage, I think we really are already trying very hard and I think we have to keep trying even harder to close where maybe we've had the competitive disadvantage, which is, I think that Ethereum in the past has sometimes been a bit too much in this pure research mode. And like maybe discounting the type of activity that already existed and saying, ah, that's just sandbox whatever, like the real world adoption will come later and then we'll start focusing on it. Real world adoption is clearly here. And so finding the right balance, I think is the ongoing challenge. It's what, for example, Tomasz and Xiaowei, in their time at the Ethereum foundation have like really put a lot of focus on and I think that's how I would like narrate the future of Ethereum, both the Manhattan Project and the short term focus and ownership of the protocol as a useful thing today.

B (73:59)

One theme that I've picked up on a handful of your answers throughout this conversation on SCAR is that there seems to be a significant number of second order positive effects of the ZKEVM that are not related directly to the main questline of the ZKEVM which is just straight, you know, layer one scaling but solves a bunch of second order problems, you know, you know, layer two scalability and composability being the one that you just said, how, how big is that second order effect? Like am I correctly identifying that it's actually like somewhat large in the positive second order effect number?

A (74:33)

Yeah, I mean I think there's the immediate second order like the, as you said, like the things that like just the benefits to the broader EVM ecosystem, especially EVML2 ecosystem. Because again, I guess maybe I didn't mention this so much. Like I think, I think it's much easier to adopt or to benefit from this technology for L2s, for EVM L2s, whereas like other EVM L1s, I think while I think that's actually it's also very exciting for them, I do think basically you'd have to re architect your entire chain, right? Similar to how I was saying like the Ethereum L1, it's the ZKM is the core piece, but there's like many elements to it. Right? Whereas because the L2s already have this architecture where they are just naturally settling on the L1, they just have to compress the timeline like the settling time for them, it's almost like a trivial upgrade to follow us to this world. So I really think there's the unique synergy for the Ethereum L1 and then the Ethereum EVM L2s. I think longer term, if I'm talking beyond blockchains here for a second, I think we've already seen how in the world outside of crypto we are starting to see this like second generation of cryptography really impact and become very impactful. It took a while, it took a couple of years for people to start taking it seriously. And so I think you can start to see it with all kinds of things like Microsoft is doing things like a lot of governments are doing, like Zkid type of systems. You're starting to really see use cases that go beyond Just blockchains. Blockchains are like the most valuable. So that's why we always, we always see the technology there. But you can imagine a world and especially once you have this real time element unlocked, you can imagine a world where like I know just to, you know, to be futuristic here like AI agents might use real time ZK proofs to make provable statements for trustless interactions with each other. Right. Like some of that might be on chain for like you know, for direct asset backed interactions but some other things might just be literally just ah, I'm just proving that I have access to this data and this data has this structure and that I or you know, all these kind of statements you can just down trivially real time proof that you just couldn't before. So I think that's a five year down the road maybe kind of thing. But five to ten years, but that will come and that I think will be really exciting. And then for example, I don't know if you've seen this like more and more countries starting to introduce, I don't know, social media bans for like miners and that kind of stuff. And like usually that's implemented in a super dumb way. You have to like just, they use a service, you have to upload your ID to the service. Right. And if we can replace that with like a ZK ID system where you really don't leak anything other than I own an ID and my birth date is above this level the threshold, obviously that's a much preferable world. So I think we are currently, I think blockchains and especially the Ethereum ecosystem is currently funding this massive leap of the cryptography toolkit that we have. And with some delay, five to 10 years delay, it will also hit the non blockchain space and I think it will be super impactful.

B (77:23)

Yeah, one idea I've had is that Ethereum and all the research that we have invested in over the years hopefully is one big contributing factor to like kind of restoring the brand of crypto by helping the world overcome some like generational challenges as you've, as you correctly identify, you know, you know crypto doesn't really have the best brand at this present moment. Hopeful, hopefully with some of these, you know, sci fi tech advance advancements, this Manhattan project that Ethereum has been working on, we don't just you know, improve the nature of our own blockchains, but we improve the nature of the world around us. And the second order effects upon Ethereum as a brand, as an ecosystem, eth price is benefited downstream of all of that, Ansgar, this has been a super educational episode. I really appreciate you coming on here and giving me and the bankless nation the time about the zkevm. I think, you know, broadly the crypto industry is looking for reasons to get bullish about something. I think this is a very valid thing to be excited about and to be bullish on. And so I'm trying to rally the troops around the ZKEVM fork just in Mindshare in education. And I think you've done the job I've hoped we could do here on the episode today. So I thank you for that, sir.

A (78:37)

Sounds good. And one last caveat, just to repeat this, right Like I'm not personally a ZK expert. I mean obviously I'm in the loop on a lot of these things, but I'm more like our broader scaling expert. So this is part of my job. But really we have absolutely amazing people, so I'm sure I got some of the minute details a little bit wrong and the people will scream at their monitors but, but I hope I got the broader picture roughly right. And I agree it's very exciting. I think both the execution layer side, the ZKVM scaling story and then on the consensus layer like these next generation upgrades we're planning there, very, very exciting. I do think we should understand though in this moment in time also I think we should try to become more and more the boring infrastructure layer and I think we should really ready the stage for the applications. And so I'm personally incredibly excited for the the actual real world application side of crypto. We are really starting to see this come online. Agentic payments, real world assets, stablecoin payments, all this is incredibly exciting. I think it's a great moment to be in crypto and yeah, and of course one last shout out there maybe. Actually if anyone listening to this was actually interested, excited by these technical details of everything we talked about though and actually wants to help on the infrastructure side, do reach out to me. I don't know either on Twitter, DM or unscared ethereum.org we also always in principle are hiring if any smart kid out there like really would want to join us here on the infrastructure side. It's not the only exciting thing in crypto, but it is still very, very exciting and please come join us.

B (80:08)

We'll make sure your Twitter is in the show notes on YouTube or Twitter or wherever people are listening to this podcast. Ankar, thank you so much.

A (80:14)

Thank you very much banquet.

B (80:16)

You guys know the deal. Crypto is risky. You can lose what you put in. But nonetheless, we are headed into the future. We're going to ZK the future too. With the help of the zkevm. That's not for everyone. But we are glad you're with us on the bankless journey.

A (80:28)

Thanks a lot.