Episode 373 - Ethproofs, zkVM Benchmarks & the Unstoppable Rise of ZK with Justin Drake

Transcript

[Music] Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. [Music] This week, Nico and I catch up with Justin Drake from the EF. We dive into ETH proofs, which he defines as a meme, a platform, a benchmarking effort, and an emerging community. Specifically, we discuss the goals that motivated its

creation, the types of collaboration being forged through this effort, the ZKVM benchmarking targets, and how these were chosen, as well as some of the future benchmarks that could extend this effort. We also cover why the EF chose to develop ETH proofs and what the ETH proofs project actually brings to the Ethereum network. For me, this was a bit of a dive back into the heart of the Ethereum L1. We got to explore how the road map, especially the road map involving ZK has evolved, was changed at the Ethereum Foundation and more. The conversation touches on one of the most dynamic and well-funded parts of the ZK space made up of the ZKVM prover and general ZK infra projects. There have been many teams moving in that direction and the mind share being focused on this

effort at the moment is immense. So it was really great to have a look at what's going on in this part of the ecosystem. Now before we kick off I just want to point you towards the ZK jobs board. There you can find job postings from top teams working in ZK. And if you're a team looking to hire, you can also post your job there today. We've heard great things from teams who have found their perfect hire through this platform and we hope it can help you as well. Find out more at jobsport.zeronowledge.fm. FM. You can find a link to this from our website and in the show notes. Now, here is our interview about ETH proofs with Justin Drake.

So, today Nico and I are here with Justin Drake from the EF. Welcome back to the show, Justin. >> Thanks for having me, Anna. Nico. >> Hey, Nico. How you doing? >> Very good, thanks. Nice to be here. >> Cool. So, Justin, this is not the first time you're on the show. I'm going to do a quick throwback to some of the episodes that we've already recorded over the years and it goes back I think to 2019. Um, we've covered very different topics pretty much every time you come on the show which is really cool. So all the way back the first episode I think we did together was about randomness and random beacons. This is during the ETH2 era where a lot of research that you were working on was focused on that. We then recorded an episode on the research

efforts at the EF. We recorded this like just before COVID hit in person in right around SBC 2020. And last time you were on, we talked about something called ultrasound money and VDFs. And actually at ZK Summit, you also spoke about ZK and hardware. Yeah. I just feel like whenever I have you on, we end up covering something very new. Today we're going to be talking about ETH proofs, which I do feel like is kind of a departure from some of the previous stuff, but maybe you'll be able to help us link these things together. Before we jump into ETH proofs, let's throw back to that last episode on ultrasound money. You talked about this meme and the question here is, did it come true?

>> Yeah, great question. So, the meme did play out for a couple years. Okay, >> basically what happened is that the supply was decreasing because there was more burn than there was issuance. And I guess a couple things happened. The first one is that the amount of stakers grew quite radically and therefore the amount of issuance also grew. And also we enabled blobs at L1 which is basically a a scaling increase which has reduced the total amount of transaction fees. Now the reason why the transaction fees um have uh gone down is because right now there's more supply than there

is demand. And so we need to wait a little bit more basically for demand to catch up so that we can have price discovery. So in some sense you could say we're in growth mode where we're favoring growth over value capture. Um the other thing that I'll say is that there are ideas to change the issuance curve to be much more sustainable for the long-term future. >> Uh so right now the way that the issuance curve is structured is that it incentivizes every rational ETH holder to become a staker and there are negative externalities to having the vast majority of all ETH being staked.

And so the proposal or at least one of the proposal is to cap the amount of staked ETH to 50%. And the way we would do so is taper the issuance down to zero as we approach this 50% cap. >> Okay? >> And when these two things happen, we dramatically reduce issuance. We dramatically increase the burn because demand has caught up with supply. And I believe that we will re-enter this ultrasound mode. >> Okay. So we're not in it right now. We're not in the ultrasound money mode at the moment.

>> Well, it depends what your definition of ultrasound is. If you take >> We haven't actually defined it. So, anyone listening who doesn't didn't hear that previous episode may be quite confused. >> So, the strict definition is basically one where the total supply of tokens is going down over time. But really the ultrasound meme came as this tongue andcheek joke almost comparing it to Bitcoin. Um >> and as of today still the total growth of the Eve supply is slower than that of the Bitcoin supply. Oh wow.

>> So it's still kind of ultra sounder or sounder than that of of the >> ultra sounder. Nice. Cool. Okay. So going back like try I'm trying to map from that episode and the work you were doing at the time what led you to work on something like ETH proofs and the work you're doing today. So maybe share with us a bit of the journey in your research since we last spoke. >> Sure. So I don't know if you remember but uh Vitalik used to post these big road maps with you know the merge the search the pledge. he stopped updating those. But one of the items in those road maps was Snockify everything.

>> Um really snarkification is this really powerful tool that can use to enhance every single layer of Ethereum starting from the consensus layer, the CL through the DL, the data layer, and finally the EL the execution layer. Now for a very long time this knockify everything was a little bit of a pie in the sky because specifically what we needed was this concept of real time proving where the latency of proofs was shorter than that of an Ethereum slot and you know I've been very optimistic on the advent of uh real-time proving but you know for a long time no one kind of uh believed me um but about a year ago go or so, we

started seeing signs that real-time proving was indeed possible. And so we went ahead and uh decided to build this website EP proofs that would document the journey towards real-time proving and hopefully accelerate it in in the process. Eve proofs is the the L2 beat of ZKVMs, if you That's I was going to ask if it was similar to that because you know L2 beats I mean this was done as an independent effort but it was taking this idea that like the ZK EVMS the rollups they didn't all have the same like they were sort of trying to benchmark each other on various things but there was no standardization all of

a sudden it gave a road map and a structure for these zk rollups to sort of work within ethroofs I feel like has a very similar thing but its focus seems to be for zk K VMs if I'm correct and I am curious like how close are we to real time proving today like you said you started this about a year ago you felt like it was coming I'm guessing this is happening in the ZKVM realm yeah how how close are we >> so it depends on your definition of real-time proving there's a lot of little caveats here and there but broadly speaking what we want is to be able to prove the vast majority of mainet Ethereum blocks so these EVM blocks within 12 seconds. And the by

vast majority what we mean now we codified it is 99% of blocks. Um and we want to do so within a little bit less than the slot. So actually 10 seconds instead of the whole 12 seconds. Um and we also have a requirement on the prover hardware and that's for decentralization reasons. So if you were to throw a massive cluster of GPUs for example you know 150 GPUs you can pull it off and actually that's something that the succinct team has shown with SP1 hyper cube but um we want to have this requirement of less than 10 kow total power envelope and the reason this 10

kowatt number uh comes up is that it's the amount of power that a Tesla home charger will draw. >> Um, >> and so there's millions of people that have these home chargers that draw 10 kow. And so it's plausible that there's going to be, you know, potentially hundreds of enthusiasts all around the world in their garage, in their offices who will be running these clusters of GPUs. And the number that we have in mind roughly is 16 GPUs. These are high-end uh gaming GPUs. Think a 5090 consumes roughly 500 W. And so if you have 16 of them, that's 8 kilowatt roughly. And then you also have some overhead for the cooling and and and

things like that. >> And the requirement is 10 kilowatts. >> Yes, exactly. >> Interesting. In that case, um you are focused on the GPU side of things. There have been teams that did a lot of their benchmarking on CPUs. Are ETH proofs more focused on this sort of GPU approach? >> No. So, we're totally agnostic to technology, but one of the things that we're starting to see is patterns. So, I've started this ZKVM tracker, which now has 32 different ZKVMs, is this spreadsheet. Um, >> crazy.

>> And one by one, you know, these ZKVMs are integrating with Eve proofs. >> Yeah. >> And what we're seeing by looking at the data is that there's these big massive trends at play. So one of them for example is that hashbased proving is winning over all of the other approaches. Another trend is that GPU proving is also winning and that was maybe not clear you know two three years ago. One could have said maybe a very large cluster of CPUs especially if they're multi-core um could win out. It also could have been possible that FPJs went out >> but we've seen you know through the data including teams pivoting away from alternatives and joining joining the fold and then you know there's all sorts

of other patterns that come up. So for example, Risk 5 is winning out as an ISA for the ZKVMs. >> But it's like it's not competing against the ZK EVM projects, is it? Like ZKevms to me are like L2s. They have a purpose. They are there because you can like port, you know, existing solidity contracts there. But yeah, when you're talking about sort of some of these trends and like Rust and Risk 5, would you say that this is sort of a new space entirely, do you actually see that eventually eating the ZKevm space?

>> So technically, what we want for EF proofs is ZKVMs. But traditionally, if you rewind the clock 5, six years ago, the way that people would build these ZKVMs is monolithically, right? They would literally try and build a circuit for every EVM up code and that was a huge amount of effort and maybe here the the best example is is linear. So they started 6 years ago and only just a few weeks ago or months ago they they completed you know every single up code and now they can prove all Ethereum blocks. Um but Linear is the only team that is still alive that's doing that.

All the other teams took a different approach which is >> to build a ZKVM for a much lower level ISA something which is much much much simpler than the EVM and then basically take highlevel EVM implementations and compile them >> compile it okay >> to the lower level ISO. >> Yeah interesting. So, but your goal this and this gets to a question. I mean, I think we should define ETH proofs what it is and all of that, but you're saying that ETH proof's goal still is actually the ZK EVVM side of things. It's not like ushering in an era of the EVM being like discarded. You still want the EVM

at its center. >> Absolutely. We need to be backwards compatible. Every time we make an upgrade, the EVM is going to stay part of Ethereum for the rest of eternity. Um, and really what we're trying to do by stockifying the EVM is to scale the L1. So, traditionally the way that you would scale the L1 is by increasing the gas limit. But then all of the validators, the testers need to keep up with all of that throughput. And unfortunately, the amount of work that they have to do to replay the transactions to re-execute them is linear in the amount of throughput. And so, the best that we could hope for is maybe a 10x increase. let's say in in the gas limit by really pushing the

optimizations in those execution layer clients. But the alternative approach is that we have this new set of entities called provers that will prove in real time the ethereum chain so that the validators only have to verify those proofs. They don't even have to download the blocks and that uh they can still attest to the validity of those blocks. Hm. >> So is there already a plan of how to integrate snarks into consensus or at this point are we just saying let's try to prove blocks and we'll see where we use it later?

>> Yes. So there is a plan uh in in multiple phases. The very first phase is just allow anyone to just prove blocks and this is something that can be done permissionlessly and in some sense this is what if proofs is all about just having people opt in to proving Ethereum blocks. This phase after that is what I call mandatory proofs and delayed execution. So right now in order to keep up with the chain is kind of hard because you have to generate the proof for the attesters within a few seconds of the generation of the block. You don't have a full slot. And the idea of delayed proving or delayed execution is to give a full slot or almost a full

slot for the prover. So think of the block being committed to at the beginning of the slot and whoever produced the the block having the ability to provide the proof towards the end of the slot. >> Now once we have this delayed proving, we can also make the proofs mandatory, meaning that the block is only valid if whoever produced it also produced the proof. So that's phase one. And then the the endgame which I guess you could call phase two is enshrining the ZKVM.

So in the first few two phases um basically we would have a plurality of ZKVMs um that would snarkify the the EVM. And here it's very similar to the situation with with client diversity. So with consensus layer clients and execution layer clients, we have five or six different clients and if there's a bug in, you know, one, two, or even three of them, Ethereum survives. >> And the assumption that we have is that every single client is buggy. And this is the same thing with the ZKVMs. We assume that each individual one is buggy, but as a group, they're actually quite secure. In order to reach the endgame of enshrining a single ZKVM, we need to have end to end formal

verification and very high confidence in the one that we pick. >> Wow. I didn't realize that that was there was sort of a competition towards this this endgame. Or do you think is the EF kind of looking at developing their own ZKVM like a bespoke one for this particular case based on what you're seeing? or do you think you will you will choose one of the open- source kind of client quote unquote ZKVM projects? >> So on the competition point of things, uh I actually like to to zoom out and look at the the big picture. In the very very early days, it was all about feasibility and viability of snarking, right? We had theoretical breakthroughs and practical breakthroughs. And I remember maybe it was like 3 years ago

or so where PSC for the very first time managed to prove an entire Ethereum block and it took two days to prove this one Ethereum block. >> And then there's kind of this second phase where people were optimizing for throughput and cost >> and then now we're kind of entering this phase where we we're optimizing for latency. And what I think will happen in the future is that people will be optimizing for simplicity and and security. >> Um, and so yeah, we're still quite far away and really there there is no like competition at this point. We're all working together to get the the diversity of ZKPMs that that we need.

But to answer your question, the most likely candidate I would say right now for enshrinement would be something along the lines of Jolt. So Jolt stands for just one lookup table and the whole point is that it's extremely simple. It's just this one lookup table in some sense and it's fairly easy to audit. The code base is fairly minimal. Now unfortunately Jolt isn't perfect. You know it's not postquantum secure for example and there's all sorts of things that that we can improve. But directionally this is the the way that we're thinking. And one kind of side note is that Dra Foundation is indeed developing its own ZKVM >> but not to snogify the EVM. It's to aggregate postquantum signatures for the

consensus layer. >> Interesting. So right now we have BLS signatures where the B stands for Dan Bonet and basically you know we have a million signatures that are generated every single epoch and those need to be aggregated and we need the equivalent that is postquantum and the approach that we've taken is to do all of this with just hashes. So we have hashbased uh one-time signatures. We make those multi-time signatures with something called XMSS. The details don't really matter. And then these signatures are aggregated using a a a postquantum snark, specifically one that is also hashbased. H

I want us to take a step out of what we're talking about here and just define the ETH proofs project because I hear it being used sort of in different ways. For me, it came to me as like almost a community, a website, a benchmarking tool, a place where you could start to compare these different ZKVMs on specific metrics in a much more kind of like even-handed way than it had been before where it was often coming from individual teams benchmarking on their own hardware in their own kind of perfect setups. But it sounds like it's bigger than that. So, can you just tell us what exactly ETH proofs is? Is it an initiative? Is it a website? Is it a group?

What is it? Is it the the actual word ETH proofs? Like proofs of ETH? Like is it the actual ZKPs? Yeah. What is it? >> Yeah. So you could say that Eve proofs is a meme. Um >> okay. >> And um you know it comes from Ethereum proof. So it's a port monto. Uh and actually before we named it Eve proofs, the the website that we were considering was proofs.thereum.org. So it was like literally proofs of Ethereum Ethereum blocks. Um now what we're trying to do here is to accelerate the bottleneck that we have towards dramatically scaling the L1. And here there's another meme which is gigas L1.

What does that mean? It means one gigas per second of throughput on the L1. And the only way that we can get there is by having this diversity of realtime ZKVMs. >> What is gigas? What is that? >> So the unit of computation in Ethereum is denominated in gas. Uh a transfer for example is 21,000 gas. >> Today uh we're processing about 2 mega gas per second. >> And the goal is to basically increase that by roughly a factor of 500 to get to one gigas per second.

>> That's the speed that you want to get to. So you've already improved it from what it was in the past. I mean, I I did live through the era of the insane gas prices um and slow speeds, but yeah, what would that even look like? And I I guess I'm having trouble understanding how ZK and ZKVMs and proofs in general help with the gig gas or with the gas prices. >> Yeah. So, let's move away from gas because that's a bit of a of an abstract concept and go let's go back to TPS transactions per second.

>> Okay. So, um, the goal is to have 10,000 TPS. So, an average transaction will be roughly 100,000 gas. And so, 1 gigas per second divided by 100,000 gas is 10,000 TPS. Okay? >> And 10,000 TPS is a lot of transactions. It's more than basically any existing L1 today by by uh several times. >> And you're right that when Ethereum started, it was doing less than 10 transactions per second. And now, you know, we've we've grown over time and, you know, a lot of the throughput is is is through the L2s. And the ultimate vision that I'm hoping we can enable with ZK is 10,000 TPS on L1 and 10 million TPS for for all of the L2s

combined. And the meme there is one teragas. It's a thousand gig gas per second. >> Crazy. Okay. This would allow for I'm guessing just like more complicated programs, more happening speed. Like what else does this enable if you have such a setup with with the 10,000 TPS? Like what does it actually change? Cuz things already feel like for what we're using this for, at least what I'm using for, it feels a lot faster than it used to be. So like what do you want to do with it that you would need so much more? Ethereum is an extremely ambitious project and what we're aiming for here is to be the internet of value and there's going to be some really high

value transactions that people will want to do. And if we can achieve 10,000 TPS, that would be roughly 0.1 highv value transaction per day per human. So it's not a lot, but it's kind of enough to get you started. And some of these high value transactions will include minting assets, you know, settling other L2s or, you know, doing high value trades or whatever it is. Um, now in my opinion, the L1 is not sufficient, right? 0.1 transactions per day per human is not enough. We need something closer to a,000x that uh which is 100 transactions per day per human. And we can get that

through the L2s. And the good news is that we have a whole scaling road map for the blobs that will give us sufficient data availability to secure the 10 million transactions uh per second. Um and because the L2s scale horizontally you know you can imagine for example a thousand L2s each with one gig gas so that the union of them uh will be a teragas because of this horizontal uh scaling there is no sequential computation bottleneck it's very very scalable >> this 100 transactions per person per day is that based on the current financial system is that sort of what you've found

is what is required to be able to at least match what exists today but in the sort of trady world like credit cards and all of that I guess yeah >> if you look at systems like Visa and Mastercard and PayPal they'll do tens of thousands of transactions uh per second >> um if you look at exchanges you know things like like NASDAQ or or or NY and all sorts of other exchanges they might do hundreds of thousands of of transactions per second and actually they're designed for for more for millions of of of transactions per second. But what I expect will happen is that once we provide the capacity, there's going to be this notion called induced demand. People are just going to find use cases for for these things.

>> And one of my particular thesis, which you know is a little abstract, is that we're going to have AI agents help us make all of these transactions on our on our behalf. >> Makes sense. >> And you know, ultimately, you know, we visit way more than a 100 websites per day potentially. we we we perform a lot of actions and so why not also do so in in in the financial world. >> I was going to actually ask about agents because it sounds like that acceleration of like more and more and more it's coming alongside potential future requirements that these agents bring.

>> I mean one of my thesis is that the richest entities in the world are going to be AIS >> and AIs are going to store their value in cryptocurrencies like ETH. >> Very likely actually. It's a good thesis. Um, okay. Going back to ETH proofs. So, what is it? Okay. So, the meme is kind of this this abstraction, but like concretely we're trying to accelerate this this main bottleneck. And as you said, we have all sorts of different arms to Eve proofs. One of them is the website which has benchmarks for the average case, meaning the actual load that hits the Ethereum blockchain. But it's also looking at what we call prover killers, which are these artificially crafted adversarial

blocks that will try and make it as hard as possible for the provers to prove those blocks. >> Wow. >> And that is going to help us guide some of the hard forks that we need to do to L1. In particular, some up code repricing. So there's some up codes out out there like uh mod x modular exponentiation uh where the gas price is much much much lower than the cost of doing the proving. >> Now we also have uh some bounties. Uh, so we've announced three $100,000 bounties for whoever can prove every single Ethereum block in real time for a period of time and and publishes uh the

proofs on EF proofs. We also have EF proof calls. So we've had three so far. The first one was introducing you know the 30 ZKVM teams. The second one was all about real time proving and and and all the innovations that got us there. And the third one was titled Gigas L1. And the fourth one uh which is going to be on August 22nd. Uh anyone is welcome to join by the way. Um is going to be dedicated to risk 5. It's going to ask the question should we enshrine risk 5 as the native ISA within Ethereum. And one advantage that we would have here is that we would allow developers to use

Rust to write their um smart contracts. And they would also benefit from much better performance. Um because the the gas cost the gas schedule would basically be set roughly one gas for one risk five cycle. Um and so you kind of have access to bare metal performance if you will. And then the other final advantage is that Ethereum as a project would be dramatically simpler. >> Why? Because risk 5 as an ISA is just a few dozens of lines of Python to describe whereas the EVM is more of a monster kind of thousands of lines of code to describe.

>> Actually, this takes me back to the patterns you were mentioning that are arising looking at all these ZKVMs. Do you think risk 5 is there just because it's kind of one of the first ones for which we had a ZKVM or is it really that it has like uh an advantage over all other ISAS? >> Come to E Proof's call number four and we'll we'll figure it out. >> Good advertising. >> I have to say I highly recommend the calls. I've been to I think two of the three and they are incredibly eye opening especially in terms of like what teams are doing. Uh and it's incredible to see all these teams collaborate and work together and share their ideas which is something that we did not see three four months ago.

>> Absolutely. Like previously a lot of the teams were not very impressed by the their colleagues and the reason is that everyone was claiming that they were the fastest ZKVM and the reason was that everyone was using a different benchmark and that led to lots of frustration and lots of wasted time because >> every ZKVM team had to dig into the benchmarks of their competitors to highlight what was going wrong and where they were cheating. But now that we have this fair playing ground, uh we can actually have much more objective and and healthy collaboration.

>> I want to go back though to what you had said about ZK EVMS and the EVM being central because what you just said with like the risk 5 ISA potentially being enshrined. Doesn't that kind of contradict that? Like doesn't that actually suggest that the EVM may be replaced? the EVM wouldn't be replaced but there would be a new ISA that would be available under the EVM and the EVM would now be defined as risk 5 byte code. So right now the EVM is defined abstractly as an ISA. So in the yellow paper or in this thing called eels which is um a specification of the EVM in in in Python we kind of abstractly say okay

there's an add up code it does addition there's a multiplication up code is multiplication and then um you know there's all sorts of clients that go implement this this specification what we would do instead is that we would take one implementation we would compile it down to risk 5 and that would be the definition of the EVM >> like this a string of risk 5 byte code and then now kind of the abstractly defined ISA would be risk 5 that would live under the EVM. So as a contract developer you always have the option to hit the EVM >> but if you're sophisticated you can go directly to risk 5 and benefit from >> more performance.

>> Right now the EVM lives on what ISA on itself. >> Yes, >> it is the ISA. So you would be putting a layer underneath it >> and it would compile down to. >> So the new ISA, the enshrined ISA would be risk 5 and the EVM would be essentially a smart contract that lives on top of RIS 5. >> Whoa. Does that open it up to all sorts of other languages then like at the base layer? I mean so far we've heard about ZKVMs. Just a little backstory. ZKVMs have actually been around for a while and it wasn't always risk 5, right? Like ZKVMs were privacy focused. I mean, Miden I think was was earlier and they

were billing themselves as a ZKVM. So, yeah, like now risk 5 is the thing. I'm curious if risk 5 becomes that underlying ISSa, but I don't know if I'm supposed to say ISA or issa, but I'll I'll go with you. you're starting to build the EVM on top of that. Then could you put like I mean this is probably false but like some Python on top of that. Could you have Python like VM EVM like in the on the main chain somehow? >> Yeah, that's a fantastic question. >> Sorry. Is it fantastic or is it just a very nonCS gra like I didn't study computer science so maybe Python's a dumb qu dumb example but you kind of know what I'm saying right? There's probably better language

examples than that, but >> no, that that's a great question. So, it turns out that there's this uh piece of infrastructure called LLVM, and it's a compiler tool chain that allows you to take high-level programming languages and compile them to a whole suite of of backends. And one of the supported backends is Risk 5. >> And so, if you support Risk 5, you support all of the highle languages that LLVM All of them allows for interest. >> Exactly. And those include uh Rust, C, C++, I believe things like >> Haskell.

>> Oh boy. I don't know about school. >> Sorry. >> I think Go is in there. >> Okay. >> Yeah. Um I mean I actually think that Go is a separate thing like they have their own compiler uh which does support Risk 5 but it doesn't go through LLVM. That's my understanding. But I'm not an expert in this kind of tooling. The the point is that there's a lot of tooling around compilers and compilers are extremely difficult to build and so you're right Anna you said that there were alternative ISAs that were developed so there's the maiden ISA there's the valida ISA there's the Cairo ISA and various other ISAs and for all of these ISAs potentially with the exception of valida that we don't have the equivalent

LLVM integration >> and so most of the developers are just cut off. >> Um, and you know, maybe one example here is is Cairo. Cairo is quite an old ISA, but it doesn't have this LLVM integration. And one of the teams, Kakarot, spent a whole three years trying to build the EVM directly in this low-level programming language and they gave up after three years. It was just too difficult. >> Um, and so there's a lot of value to having this compiler tooling. >> Interesting.

I still like ETH proofs. Is it an organization coming out? I I'm going to keep coming back to this, I think, because I think it's it's an interesting project. Is it a company? Is it like a part of EF? Is there a group dedicated only to ETH proofs? >> And so, let me give you the origin story and some of the the history. So, a bit more than a year ago, the risk zero folks were chatting to us and they had this idea. what if we had an archive somewhere of proofs of every single historical Ethereum block? And I said, "Yes, this is a fantastic idea. Let's let's do it." And originally, as I said, the URL was going to be proofs.org.

But back in the day, the Ethereum Foundation was, you know, very supportive of this substraction mindset where we try and delegate as much as possible to the community. And so we decided to have a separate GitHub organization for ETH if proofs and have as a plan the idea of spinning it out of the Ethereum uh foundation. But what happened in the last few months is that the FM foundation was uh reorged internally and now it's kind of much more acceptable if you will uh for e proofs to be part of the effirm foundation and now we have a dedicated team called the zkvm team um that is you know helping with the development uh of

the website and is using the website to try and fulfill and accelerate its goals. >> Wow. comparing it to the L2 beat which you mentioned was an inspiration that as far as I understand had always been independent. It was just like a place where they could benchmark the different L2s based on the framework that Vitalik had actually outlined with these like five stages and all of that. In this case, it sounds a bit like you're the metrics and the the judgments that's also that's still evolving, right? It's not like one am I correct there or do you feel like it's already been set and now you're just kind of rolling it out?

>> Yeah, so directionally there's a huge emphasis on on latency. So the website does show both the proving cost and the proving latency, but the most important metric is latency because we're trying to unlock real-time proving similarly to L2B, we have this notion of pizzas. So basically uh we have eight pizza slices and they can each have one of three colors. uh green, yellow or red and they'll capture different things about ZKVMs including things like the security. Um so for example, how many bits of security are you targeting? Are you audited? Are you formally verified?

Uh things like that. Um so these criteria have been set at least you know they exist today. Uh but it is very much possible that they will evolve a little bit in the future. Now, if you're willing to think potentially 2026 or 2027, it's possible that Eve proofs will grow quite a bit its remit beyond just scaling the L1. It's possible that it will also include uh a whole section on privacy. >> Ah, >> and and client side client side proving >> interesting.

Oh, that's so funny, Justin. I was going to bring that up later, but I don't know if you heard we had Mu on the show a couple weeks ago and we talked a lot about ETH proofs in that episode. >> Um, but you weren't there. So, I'm really glad we're getting a chance to actually speak to someone from the group. But Muchu did bring up this idea of currently there's no metric for how well it functions on client side, how how much privacy can ease even have. And so the focus has been on this latency and scaling and like the very kind of scalability succinctness kind of side of things.

>> But yeah, we this actually had come up. So that's really cool to hear that you're also you're also thinking about it, >> right? And this is something that has been teased publicly uh which is that the PSC group is also going to be reorged within the FM foundation and it's going to focus exclusively on privacy. PSC stands for privacy and scaling exploration. >> True. And the acronym is going to be changed a little bit so they only focus on privacy. >> It's just give it a different meaning. >> Nice. Yeah. Give E a new a new meaning. Give S a new meaning, I guess.

>> Yes, exactly. >> Yeah. >> Actually, I'm interested in some of the the pizzas and sort of the targets there. I I see that verification time also comes up. Proof size also come up. Where are these being applied? Why do we care about verification time and proof size? In this case, >> in the context of scaling DL1, we would have the validators download these proofs and they would download more likely than not something like three proofs. And so we want to make sure that within the 12 seconds, it's reasonable to be able to download three proofs. And the latest uh target that we have is about 300 kilobytes. And the reason is that three times 300 kilobytes is under one megabyte. and that's something reasonable to download within uh 12 seconds. And it's a similar thing with

verification time. We're going to be verifying three proofs and we want to make sure that the total CPU time is uh is negligible. That makes a lot of sense. And then security, I see that some teams are operating around 80 bits of security, others 100. The gold standard used to be 128. How do we pick a security level and why do we pick it? Most of the teams nowadays will pick 100 bits of security. Uh the two exceptions that I know are ZISK on the good side of things. They're picking 128 bits.

>> Um and Airbender I believe are only using something like 79 bits or roughly 80 bits. >> Now what the Ethereum Foundation is trying to push towards is this 128 bits uh of of security. But the downside is that the proof sizes tend to be larger. >> Um especially if you're using the the hashbased uh snarks that we're recommending because usually the way that these DKVMs are built is that there's an internal hashbased snark and then there's an optional wrapper for example a graph 16 wrapper so that the onchain verification is cheap. Uh but we don't have any onchain verification. We only have off-chain verification of

proof. So we don't need the wrapper. and the wrapper actually adds a bunch of latency which we don't want and so we're encouraging the teams to not have this wrapper. Uh but now the um the total proof size does come into consideration. Now another subtlety is do you use a proximity gaps conjecture or not? >> So for hashbased knocks you have two options. You can either have provable security in the random oracle model or you can make use of a conjecture. And actually, one of the things that I'd like to tease uh for the very first time on this episode is that the Ethereum Foundation is going to put a $1 million bounty to prove the conjecture that the

community is currently using. So, it's the up to capacity uh proximity gaps conjecture for read summon codes. And in practice, almost all of the teams are using the conjecture. And what the conjectctor gives us more or less is that it allows us to reduce the proof sizes by a factor of two. Um, and if we can prove the conjecture, fantastic. If the conjecture is found to not be true, then it's possible that all of the teams would basically have to adjust their proof sizes. Exactly. Yeah. Mhm.

>> Just to clarify, is this the conjecture sort of the the vanilla correlated agreement conjecture or is this the strengthened version that we see in were and maybe basefold? >> So just to give a little bit of context for the the listener, um traditionally we've had uh fry be like the the number one tool that we use in these these hashbased snarks. And here we only need what's called correlated agreement. And recently there's been kind of these Fry 2.0 if you will like next generation Fry which have better properties one of which is called were and here it uses a strengthened version of the conjecture called mutual correlated agreement. So there's this additional word mutual. Now

I think most experts will tell you that if something has correlated agreement then almost certainly it also has mutual correlated agreement. So uh what we'll be encouraging is the uh the stronger version the the mutual correlated agreement and this has um upsides for you know the the aggregation of postquantum signatures where you know we're really leaning into where because it has very small proof sizes and is very friendly to recursion. So if we want to aggregate signatures and do so there's multiple aggregators that can themselves be kind of meta aggregated then we're going to make heavy use of recursion and this is where shines >> back to sort of metrics and performance

is there also like a pizza for how much energy I'm using or what kind of rig how much CPUs I'm using or maybe just how expensive it is to prove >> on the website right now um we have two modes of proving we have a single GPU a single 49 90 and then we have the the cluster of of GPUs and almost all of the teams that have integrated now there's eight of them are using the the single GPU and one of the things that we track is indeed the cost in in dollars and the way that we calculate this cost is that we look at how expensive it is to rent the machine that the prover is using per hour for example on AWS and then we uh use the total proving time to calculate

the effective cost. And one of the really shocking things to me is that these uh proofs are extremely cheap on the order of 1 cent per Ethereum block. And if you think of a block as having let's say roughly a 100 transactions, each individual transaction will only cost a uh hundth of a cent uh to prove. Now, one question that's often brought up is what are the incentives for the provers to do the the proving? And it turns out that the answer is just the same that we have today. So, we are going to require the users to pay for the proving cost at least 100th of a cent per transaction. And if they're

willing to pay that through the tip, then the prover will have the incentive to include that transaction in the block because the proving cost is less than what they receive as a tip. And ultimately, that transaction will make it in in the chain. And what I'm hoping will happen is that over the next, you know, year or so, the proving cost is going to decrease by another factor of 10, and it will just be so so small that the users won't even realize that it's part of the tip. I want to just clarify something here because we talk about ZKVMs, VMs, virtual machines, but then we also talk about this actor called the prover.

And we've talked about this on in past episodes, but I've always understood the ZKVMs or users of the ZKVM as the customer and provers as the suppliers of proofs specifically in the proving marketplace context, which a lot of ZKVMs are also providing. So I'm just wondering when we're doing this benchmarking and you talk about prover cost are you talk like this is where I'm kind of confused like are you talking about the prover marketplace talking about the provers acting in that marketplace connected to a specific ZKVM or you talk about the cost of the request coming from the ZKVM.

>> So the entity that would be doing the proving is the block producer also known as the block builder. So when they build a block, they're also responsible for the proof. Now they have the option to generate the proof in whatever way they wish. So option one might be that they themselves have a cluster of GPUs and they do it themselves. Um they could deal with a centralized trusted provider that they interact with or they could, you know, interact with a permissionless and decentralized uh marketplace. But whatever approach they take, uh ultimately we're talking about paying for the energy cost and the depreciation cost of the the hardware and that's on the order of 1 cent per block.

>> But is that because there's these marketplaces that have emerged and there's more provers or is it because that's that's how much it costs for that like Yeah, I'm I'm I actually don't even know what the actor is on the ZKVM side, but what is it? It's the ZKVM itself. It's the sequencer. It's the I mean you called it the block producer. Yeah. What what is it actually when you talk about these like this connection point? >> So the the ZKVM is just pure software >> and then there's two entities on both sides of the ZKVM. On the one hand you have the prover that is going to >> operate hardware and kind of crunch rule of numbers to generate a proof and then the on the other hand you have the verifier who will consume the proof and

that's going to be the tester. So on left side it's the block builder that the prover on the right side a tester verifier. >> But what is the ZKVM? Like you're talking about a cost and I'm trying to figure out who defines the cost. Is it the verifier then? >> No, it's the prover. So the prover will have to rent hardware for example AWS and it will cost them 1 cent worth of AWS resources to generate this this one proof for the one block. >> On the verified side of things there's almost no cost, right? they have to download the proof which is less than 300 kilobytes and it takes let's say 10 milliseconds to verify and it's essentially free.

>> But then if you're talking about like these cost comparisons like are you comparing then different provers and if you're comparing provers are you comparing like systems of proving or are you actually comparing ZKVM cost? >> This is where I'm confused. >> Yeah, great question. So um usually a a ZKVM will come with a reference prover which is kind of this reference piece of software with with proving algorithms >> and you're right uh that the proving algorithm can be swapped out and some teams do do that and the uh hardware itself can be swapped out. So you could use AWS but you could use vast.ai AI or you could use all sorts of of other

combinations. And what's starting to happen is that people are trying to use the best combination in order to get the most efficient proofs. And you're right that a marketplace is a natural economic mechanism to kind of bubble up these most efficient provers who will >> end up winning most of the jobs. >> Yeah. By the way, this is something we also see on the ETH proofs website, right? You have ZKVMs that are listed, but you also have prover infrastructure that's listed. And you have >> some provers running different VMs and maybe using VMs from like a competitor. Yeah, it's interesting. Exactly. And you can see on proofs which CPU they're using, how many cores it has, how much RAM they have. We're trying to put as much information as possible. And we even want to be in a position where

anyone can reproduce the the numbers themselves. So ideally we'd have a Docker image kind of oneclick redeploy on AWS for example and you can reproduce. >> Yeah I was going to ask is everything sort of self-reported like time and cost or >> so time is not self-reported and the reason is that we can just um you know measure the time between when the block was produced and when we received the proof. The machine used right now is self-reported, but what anyone can do permissionlessly is kind of get the exact same uh hardware and then rerun the the the prover assuming that it's either the binaries are available or the the source code is available. By the way, availability of binary source code.

This is another thing where I found ETH proofs was incredible is it has really pushed teams to open source their code and open source their binaries because you just had this spreadsheet that lists everyone named and then you had two columns in the middle. Big red box if you were not open source and big green box if you were. And I find that amazing. >> Absolutely. And for Liveness, one of the requirements is that the prover be open source. Um because ultimately if um you know most of the proving is done by a few entities if those entities go offline we want anyone to have the option to reboot a prover anywhere in the world. Um and uh I think teams are starting to understand that open

sourcing the provers is important and at the beginning of the year we had basically zero or maybe one prover that was open source and now we're at a point where we're starting to get close to the majority. I want to throw back once more to that episode I did with Mu and I don't know if either of you heard this. It was actually Germa was the co-host on it but in that you know they Lee Harrow they're focused a lot more on this like client side. I mean he was talking about doing proofs on a phone and that you don't even need GPUs. So what do you how do you kind of compare teams like that like in today's model with the pizza pie that you have? It's it sounds like you don't have I mean you don't have a privacy one but and you don't yet have this client

side but yeah would you would you be changing the requirements at some point to something like can you do it on a phone or would you add this as like another category? >> Yeah. So right now we're focused on the the server side proving and it's very much geared towards latency and and and cost. we would need to find a new benchmark for the client side proving. >> And one of the interesting things that could potentially involve client side proving uh at L1 and privacy is this thing called wormhole uh which is a fantastic idea.

>> Um >> not the bridge I guess >> not the bridge no much better much better wormhole. So the idea is that you can take any firm address and send funds to another Ethereum address and prove that this other firm address is unspendable. >> So basically onchain it just looks like a normal transaction. There's no way to discriminate against it. And then once you can prove that this address is unspendable, you can go mint another address with the exact same balance.

>> And for that we would need to do a a hard fork which enables this this wormhole. Um and you know one of the very important things here is the the security and simplicity of of of the of the proof. And the reason is that you know just like Zcash if there's a soundness bug in the proof you can just mint an unlimited number of tokens. >> So um you know just like we have this minimal ZKVM for signature aggregation we could imagine the same potentially the same ZKVM which has been endtoend verified also be used for privacy and wormholes.

>> Interesting. I I was reading a quote of from Tun today and I don't know if I'm gonna butcher it, but he was talking a little bit about how, you know, in this DeFi context. The crazy thing about adding the ZK all over the place is you can start to do something similar to what you just described with the wormholes, it wasn't about unspendable, but I think it was about like proof of liquidity somewhere or using things as collateral from one part of a chain to an L2 to somewhere else. Because the minute you have these proofs, you don't have to do these like lock and hold and bridge all those concepts where we had to move kind of like not you're not really moving but like you're theoretically moving tokens to a new place where they could be used as collateral. Here you just need the proof

and then you have collateral in different places. And it yeah it sounds a little bit like an echo of what you just described. >> Absolutely. And the way that I think about it is that snarks are like the third very powerful tool in the con in the context of blockchain. So we have hashes and signatures. And then there's there's snarks. And you can do all sorts of things. So we already mentioned >> what was the third one? Hashes. >> Hashes, signatures, and snarks is the third one. >> Okay. Okay. Sorry. Got it. Cool. >> And as you know, Michael Sailor would say, there's no fourth best. That's pretty much all all that you need. Um and um you know we've already talked about snarks unlocking scalability and privacy but they can unlock all sorts of other things. So one

of them is composability and there's two aspects of composability here. One is uh synchronous composability across rollups. Once you have real-time proving that becomes possible um and also there's this notion called cross rollup bundle safety. So, and this is maybe what Tarun was talking about and is basically what a layer is is is working on which is that if you have some sort of an intent for a super transaction that touches multiple rollups and you want to make sure that it doesn't get unbundled in its constituent transactions, you can basically gate the settlement of the super transaction with a proof that the intent is indeed satisfied. It's all a little bit, you

know, abstract, but um that's one of the things that you can do. And then the other thing that snogs give us kind of surprisingly is safety of rollups. So today rollups have two kind of attack surfaces. The first one is uh that there could be bugs in the implementations whether it's the fraud proof game or the snark circuit and then the other uh attack surface is governance. So if you take a a a typical EVM equivalent rollup they fundamentally need governance in order to stay in sync with the EVM which itself is a living beast.

>> And so with with Snox what we can do is we can expose this pre-ompile on Ethereum called the execute pre-ompile to have native rollup. So a native rollup is one which reuses the L1 execution the L1 EVM. It's an exact copy, if you will, of the EVM. And by definition, it's bug-free and by construction, it doesn't require governance either. >> Did you have this from a few years ago, though? Wasn't this like the based rollup or something? Wasn't there I don't know if I'm remembering this correctly, but I like I remember hearing you on a show. I don't think you'd spoke on this show about it, but yeah. Where you were talking about something like this.

>> Yes. So, there are like these two different concepts. One is base rollups and the other one is native roll-ups. They touch different layers of the rollup stack. So the base rollups touch the sequencing. >> Yes. >> And the idea is that you're sharing the same sequencer as the L1. So you have the validators basically order the transactions of your rollup. The native rollups are those where you're using the execution layer of the L1, namely a copy of the VM. And it turns out when you combine these two, when you're both based and native, you become an ultrasound rollup. Um and and you benefit >> back again the meme.

>> Exactly. And you benefit from much much simpler synchronous composibility than than otherwise. >> So looking into the future of like ETH proofs and ZKVMs, do we expect to see sort of a disruption to the patterns that have emerged? Do we expect to see things like latisbased proof make their way in? Especially if we're looking for maybe smaller proofs, maybe that's something we can get from latises. And are we expecting to see maybe risk five get swept away? Although I did sort of ask something in that direction earlier. >> Yeah. So it's always tempting to say, hey, you know, there's been so much research done like surely we must be done by now. Uh but >> I'm always surprised at how much innovation we can still >> there's always a cool new thing.

>> There's always a cool new thing. >> Um and like right now I think we're witnessing like two mini revolutions within the hashbased NOx which are kind of maybe worth highlighting. One is this migration from univaried polomials to multilinear polomials and you know the the emergence of of sum as this you know very efficient primitive uh to to build uh uh snarks and then the the other like mini revolution which is related actually is the move away from fry 1.0 to fry 2.0 you know with and and and constructions related to that because more and more we're going to rely on recursion and you know were has just this this this extremely good uh recursion

>> by were just for anyone who's maybe used to it is spelled it's whir it's the were stir work that we we've done actually an episode on that too I'll I'll add a link anyway sorry Justin keep going >> exactly and you can think of stir as being fry 1.5 so it was an improvement but were kind of um is even better than than than stir. >> Cool. >> I guess one revolution mini revolution is the formal verification of of circuits. So traditionally when you want to formally verify something you need to do two things. You need to prove that your uh circuits are sound and uh that they're that they're complete. And it turns out that the vast majority are soundness bugs with under constrained

circuits. And there's this new tool uh called Pyus from Veradise which only tackles the under constraint part but in practice it just finds all of the bugs. >> Oh >> almost all of the bugs. >> Oh because most of them are under constraints. Yeah. >> Exactly. Yeah. So there was actually this this piece of research done where some academics looked at um you know a hundred snark bugs that they could find and something like 98% or something was uh was under constrained. Is that the ZK security work? >> It's on the website. Yes.

>> Okay. I don't know if they did it all, but we actually I think we featured it in our recent state of ZK report as well. Interesting. >> And so, you know, we've had risk zero, for example, use them. SP1 is starting to use them. It's it's it's a surprisingly powerful uh tool. >> Cool. >> Yeah. Now, going back to you know, your question of of of bigger revolutions. Um it it is possible that that lettucees will a big move and um you know I I don't want to share like too much alpha but I was told like very recently by a researcher that I really really trust um that there was a a massive breakthrough for latisbased stocks potentially a 100x improvement over the the state-of-the-art. And not only is it a performance improvement but it's also

potentially a a simplification and complexity improvement. And so if if that's the case, we could see, you know, a revival of these >> knocks. >> Another thing that you asked about was the the ISAS. So right now it's clear that risk 5 is winning but is it just because you know all of the tooling is there and uh really it it might be kind of an unstable equilibrium over the very long-term thing like 10 20 years whereby if we were to really invest in a a from scratch design and also have the tooling then we could squeeze more from from risk 5.

One of the kind of surprising outcomes of um the last few you know months and years is that the constraints of hardware kind of mirror themselves to a surprising extent in the design of of snarks. So you have kind of similar notions of locality and you know similar uh the physical constraints almost kind of match with the the cryptography. At least that's one of the thesis that Justin Faylor has been talking about a lot in the context of Jolt. And if if that's the case um then we're we're in for a treat because you know risk 5 was designed for hardware and if it's one to

one then we can expect hardware to be a long-term >> micro deliver. >> What is the state of things with hardware? Because I you talked about this earlier on. You said like >> we had explored FPGAAS. You talked about this act around the time of ZK11. You gave a presentation on like ZK6. This was like something that was being considered. There was the Z prize which was focused very much on hardware as well. That effort generated all this innovation. Yeah. What what is the state of hardware? Because now it sounds like we're just kind of going to go with GPUs and even you know there's some teams talking about moving it all the way to the phone. So then you're you're not dealing with specialized hardware at all.

>> Yeah. So in in my opinion like the the main bottleneck that we have now is is is reducing power. Um you know we have basically low latency with these these big clusters. We want to reduce power and you know AS6 really do promise you potentially an order of magnitude maybe more on on on power. Now you're right that previously there was some some attempts looking at at FPGAAS and one famous example here is irreducible and you know they recently pivoted away from FPGAAS and hardware. They're no longer doing any of that. um they've become a clientside uh proving shop and I think that's a testament to the fact that you know in the short term really GPUs have have crushed everything and potentially it's you know has been helped by the

advent of AI right where there's just so so many billions of dollars that are poured into these GPUs that they're just so so so efficient >> they're getting so powerful >> but um you know fundamentally if you were to design your circuits to be friendly to to prime fields and extension field and you know FFTs and all of the basic operations and your hashes then you you should be able to squeeze to squeeze an order of magnitude. But the real question is, can a rag tag, you know, AS6 startup with $20 million compete with uh Nvidia, which is a $2 trillion company. Um, >> and you know, we'll see very soon. And the reason is that there's this company

called Fabric, uh, that received a few tens of millions of of dollars, and they actually taped out. They've received the chips. Um, they've also received what's called the the package, which is kind of the the envelope around the die. Uh, but the the factory that puts the two together somehow uh is is is at capacity and and and can't do it for them. So, I'm hoping that in a few weeks, potentially a few months, we will have numbers from from Fabric. And they basically designed this this ZPU, if you will, like this this GPU designed for ZK.

>> Cool. Um and uh they claim you know 10x potentially uh performance improvement that we'll see. >> I think the challenge we talked about this a couple times and I've mentioned it on the show. One of the big challenges here is also this ever evolving proving systems and if we're moving away like if we start doing lattises do they does that require different hardware? I don't I mean I don't know but I'm just like I think if you're seeing this innovation on the cryptography side moving at the speed it is it's been from what I understand really hard to just like make a snapshot freeze things and decide like yeah we're going to build this FPGA or rather we're going to build this ASIC which is like such an investment for this particular system it will make it super fast but like watch all these other systems kind

of like run circles around it in the future. >> Yeah. So that's one of the selling points of a system like like fabric is that it it's programmable. So they have these >> okay >> basic building blocks where you can change the prime field for example. >> Okay. >> Um and they even have uh CPUs on on the die. So they have risk five actually CPUs that can do all sorts of glue logic around these you know specialized blocks that will do things like FFTs and MSMs. >> Cool. I want to ask you this is a little bit more just your opinion or what you think is coming. I don't know if ETH proofs has any impact on it or if it's really paying attention to this, but the business model of ZKVMs has been

something that we've thought about. I think we've talked about a couple times on the show. Something I've been thinking about like 2023, we saw all these co-processors come out >> and we had a few prover networks. Then we had like the ZKVM definition. I mean, Risk Zero was I think the first to really kind of like pioneer this the way we understand it today. ZKVM start to become prover marketplaces. So there's sort of like merging these two business models and it what it feels like and then you also have people who have done the verification layer. So they're like looking to decentralize the verification. You have these different teams that are sort of moving from different quadrants of the proving stack. And a lot of the time what it looks like is they're trying to find the

business model that will work because a ZKVM on its own like doesn't really have a place for a token. Do you know what I mean? Like it's an it's a virtual machine. It's not a network or marketplace. It doesn't need a utility token alone. So that's I think where the prover marketplaces come in. But yeah, I'm just curious what you make of these kind of moving business models. if you think it's sustainable enough to have this many teams too running individual prover marketplaces because I think a lot of them are kind of pivoting in that direction and you just said there's 32 of them but like can they all do that yeah >> I guess naively you could assume that ZKVMs are public goods right there like

these pieces are open source hardware software anyone can can can copy them but um you know nowadays I I changed my opinion I'd say that's a little myopic And I actually have a little bit of a of a story here. So um maybe three four years ago, we approached one of the ZKVM teams, DM Foundation, and we actually tried to acquire them. >> Oh wow. >> And you know like the the the ballpark figure, you know, for acquisition acquires is you know on the order of a million dollar per head. So you know one strategy could be to build a company with like 30 excellent engineers and then get acquired by uh by by some other entity. And I I really do think that that ZKVMs are going to eat the world.

Like very large parts of computation are going to become snified even if they fall outside of the remit of blockchains. you know anything that's kind of high integrity high value like whether it's banking you know medical or you know aeronautics and rockets or all of that I think to will will be snarkified and I think companies like Google will just have you know hundreds of engineers working on these things uh potentially and and Nvidia you know will be manufacturing these ZPUs um that that that will unlock this this this noification.

Now what happened a few years ago like 2 three years ago is that the VCs came in. So the the foundation was offering like a few tens of millions of dollars for one team. the VCs came in with hund hundreds of millions of dollars literally across you know dozens of teams and they they make this this big VC bet and the it looks like it's paying off and the reason is that just a few days ago succinct launched its its uh proven network and and marketplace with the proof token and the proof token has a fully diluted valuation of something like $1.5 billion >> and so >> today we never know how these things No right right we will see but at least there is a possibility that there will

be this this cash injection and from my perspective it's fantastic because it is >> you know directly funding these these these public goods in the context of a firm layer one where the business model is is is not that big I mean if you look at all of the L2s and you look at all of the throughput you know this terra gas 10 million transactions per second even if you're talking of fractions of a cent of proven cost per transaction, it does add up across the the whole network. And so there might be business models for example like um you building the the hardware or having like really really fast algorithms and you know we we've seen all sorts of companies like like Super National like in in Gonama like ZAN have like you know milliondoll kind

of contracts to try and accelerate systems. >> I hear you on that. I just I to me I don't feel like it's proven yet. I I agree with you that there was this like VC boom, this attempt to just inject so much capital, maybe too much capital, maybe too much capital to like a very unpolished product market fit, you know, like as an industry almost like that's and I think that's why we've seen so many teams shift around. Like I to me it's like we'll know if it's successful once a lot of these things have launched and then existed in in the wild for a couple years. Um yeah, that's my take.

Yeah, I mean I wouldn't be surprised if a company like RZero or Succinct gets acquired for over a billion dollars by Microsoft or Google or something like that >> by like a fang or something like that. >> Yeah, >> I don't know if people still use that acronym but >> because you know we're limited by talent. There's very very little talent in our space. Yeah, >> you know, the hundreds of engineers will will make up most of the talent and you know, a company like Reszero and SP1, they have, you know, dozens of these these top engineers. >> Cool. You've been talking a lot about the EF and the structure of the EF and PSSE and we kind of had meant to talk about this a bit earlier in the episode, even your own title, like when I was asking you before the show, how do I

introduce you? Are you researcher at EF? You're like, actually, I'm sort of in a different domain now. So, yeah. Can you share a little bit about what those changes have been like from your perspective from where you're sitting? >> Yeah, so a little bit of a story. I've been at DA for 8 years and when I came in um you know I was expecting a very professional team of researchers securing this like decabillion network but it was kind of a ragtag team of five people and you know it was an extremely flat organization a little chaotic and and and and disorganized but it also kind of really empowered those who were like very proactive and autonomous and you know now I think we've grown to a size the film foundation about 250 people where we need a little bit more structure

uh and indeed now we have this notion of a cluster of teams. So we have uh at least two clusters. We have the protocol cluster and the echoev cluster. The protocol one is the the technical one and we also have PSC which I guess will be this this this third cluster. And then within the protocol cluster I'm part of the architecture team. >> Okay. >> Um so there's something like 20 teams within the the protocol cluster. Each team has a team lead. Uh there's also projects and project leads. So there's kind of lots of hierarchy now. And you know, it's been working very very well, at least for the last few months. You know, just to give you a little bit of um a sense for pace, this $1 million bounty that I teased earlier in the

episode. That's an idea that I had on Saturday. So that was August 9th. We're recording August 11th. Yeah, >> you know, I spent the weekend talking to a few people trying to get permission to announce it on the podcast and uh and we're moving extremely fast. >> And is that a lot faster than it was before all of this reorg? >> Yeah, I think so because now, you know, we have very clarity as to who are the decision makers and you can just go to them and get uh a green light from them and and and and you'll be good.

>> Cool. I want to close with uh sort of a throwback to the start of the episode. We talked about the meme, the ultrasound money meme, >> and kind of like you putting it out in the universe and then it's sort of re it's been redefined in a lot of ways. We have a lot of ZK memes. We've heard ZK's endgame, ZK for everyone, ZK's future. What is the other like what's the one that everyone like there's this one going around now which is just like ZK everything or ZK I don't know like and often these are coming from individual teams. Um, yeah. I'm just wondering the thing is the goals that you've outlined on ETH proofs like and a lot of what we've just talked about over

the last hour and a half, it's been very much focused on this infrastructure on the ground for developer like you like if you if you're deep in it, you can see these benefits, but then you have these slogans which are extremely high level. They don't really say anything. Yeah. And there's and I'm just wondering about that sort of I don't want to say disconnect because maybe you do need both, but I'm I'm curious what you make of all that as a meme lord yourself, you know. >> Yeah. >> I guess maker, I should say. >> My favorite version of the the meme is that real time ZK is the endgame.

>> Okay. >> Um the real time is is is is important. I mean when you zoom out and you so one of the the roles of memes is to recruit right like we need more talent and it just so happens that empirically speaking a lot of people come when there is a little bit of rough >> uh so I personally came in late 2013 you know Bitcoin was bubbling all of the way >> to to $1,000 and you know we have this expression come for the money stay for the tech and I think that does apply for for a lot of people.

>> I'm guilty of it, too. I'm a 2017 joiner. Also, an era of bubble for sure. >> Yeah. And we're going to have a 2025 bubble and we're going to have, you know, hopefully tens of thousands if not, you know, hundreds of thousands of developers or or, you know, candidate developers come in and we we need to have some sort of an inspirational story to to tell them. And so, yes, like whenever there's this disconnect, there's the opportunity to have promises not be fulfilled. >> Um, but you need a little bit of that spark in order to get people in. And, um, you know, it's think of it as a form of advertisement. that frothiness you talk about like so far a lot of it's

been blockchain related like block you know crypto froth price action but ZK is this other it's like this this side quest where yes there is you know there are teams that have tied themselves to blockchains but ZK is not inherently a monetary thing right it's are and we are seeing it being used by web 2 companies out in the real world I'm so excited to see that to sort of see it almost break out of blockchain, but can it retain the froth quote unquote frothiness without that sort of monetary side of it? Does it always have to be linked to a blockchain for that to work?

>> No, you're absolutely right. And um you know, one of the things that Vitalik said a few years ago is that even if all blockchains go to zero, it would still have been worth it. And the reason is that >> created ZK. >> Exactly. Yes. that >> to have accelerated ZK actually not even create it's it existed before but it was really accelerated through this. >> Yeah. And I remember a few years ago I was I was looking through all of the speakers at crypto you know crypto is this top cryptography conference and also I was looking at the e-print papers published and I was shocked at the percentages that were basically motivated by by by blockchains. um >> you know in in in crypto specifically

like close to half of the abstract kind of mention Bitcoin or Ethereum or blockchain and you know we've we've provided literally hundreds of millions of dollars uh at this point of of funding. So for example, you know, the the FM foundation gave a a very large grant to the the Stanford blockchain group and and that funds SBC every year and also that has led to so much research out of Dan Bonet's group and um we have just this this fantastic symbiosis between uh cryptography and and and and blockchains and um you know you mentioned the froth.

I think the good news is that ZK is just has such strong technical fundamentals that the froth can't get too out of control, right? There's there's really this this this tether as opposed to a notion like monetary premium uh which is much much more untethered. >> Ah interesting. I feel like this is like this is a conversation I want to keep having with folks, but I because I I mean or I have been having with folks actually behind the scenes this like Terrun will often ask this like well ZK is important but is it fundable? Is it going to make anyone money? Um >> and yeah, I don't know.

>> Well, Nvidia is going to be producing ZKVM accelerators. >> You know this like this is a fact. >> Okay. I'm willing to bet anyone, you know, a large amount of money that within 10 years, Nvidia will be not only generating producing GPUs, but also, you know, ZPUs. I guess >> that's so cool as an idea. Wow. I mean, I've never heard anyone make that bet, but I but I like it. >> I mean, you know, a very large percentage of the energy consumption in the world will go towards AIS. And so, you know, we need to have like the most energy efficient AIs that we can. Hence why we have all of this effort around GPUs. And if indeed you have a a thesis that most of or big chunks of the the

computation will be verifiable then because the overheads are so high energetically we need to have these hardware accelerations like um the order of magnitude overhead today is 10,000x. Uh so let me just kind of walk you through this. If you take a a a typical CPU, let's say running at 5 watt, um it will have a clock speed of let's say 1.5 GHz. Um the way that a prover would have to keep up with this is with 100 GPUs each running at uh 15 MHz and each GPU consumes 500 W, which is 100 times more.

So there's 100 times more power consumption per GPU and you have a 100 GPUs, hence the the 10,000x overhead. We need to get that that overhead down if we're going to have significant portions of of computation be be verifiable. >> It's funny like even talking about it in this context, it makes me think of early internet like song security and how kind of wild west and dangerous it was. That's sort of like what AI is now, which is just like completely unwieldy, unprovable, unverifiable. Like it's completely kind of could be could be scam, you have no idea. So much of a mess. And a lot of it's working because it's novelty. Like all the sort of bad actors haven't like fully activated yet. So it's like the happy time of the internet. We're like kind of

in a bit of a happy time of the AI kind of. I mean there's a lot of people who are scared of it too, but >> yeah. But that verifiability, I mean, I always think of it as a little bit of a check on on AI and just kind of giving it a bit more of that like structure, security, making sure you can actually trust what you're dealing with. And there ZK comes in. >> Even if we somehow reduce the overhead from 10,000x to just 100x, you know, training an AI, for example, will will cost 100 um megawatt hours or something. And so if you have a 100x overhead over that, uh, that will be like 10 gawatt hours. That is an obscene amount of energy. And so the more we can optimize

the better. >> It's funny though. I think you're talking more on the scaling front. You're like we can make it like more efficient. And I'm I'm actually talking on the like the verify like the trying to verify things about AI that more like using it to prove. >> Yeah. Basically, you want to prove for example that training was done properly. So you have >> a public set of data. You want to make sure that the training was done properly. The overhead to training is going to be 100x, you know, in the best case likely. And so, you know, energy becomes the bottleneck. I mean, energy is already the bottleneck for AI without verifiability. It's going to be 100 times worse with verifiability.

>> Crazy. Cool. Justin, thank you so much for coming on the show. I feel like especially the last little bit, I feel like there's little sparks of convers. We could probably continue talking about a bunch of these things, but we have run out of time. So yeah, thanks so much for coming back and for talking to us about ETH proofs, the future of Ethereum and like kind of the future of the digital internet world. >> Yeah, thank you both Justin. This is super exciting and looking forward to see the conjecture up to capacity bound being proven and having >> proven security of small proofs now >> and the lattice stuff you're talking about >> and the stuff absolutely yeah thanks guys.

>> All right, thanks again. Um, I want to say thank you to the podcast team, Rachel, Henrik, Tanya, and Kai, and to our listeners. Thanks for listening. [Music]