gigagas L1

Transcript

Okay, let's get started. Um so I believe that we're at this inflection point for Ethereum scaling and in particular I have conviction that we will enter a gigas error for the L1 and specifically I mean uh one gigas per second which uh if you have transactions that consume 100,000 gas on average that's roughly 10,000 TPS and the key unlock for the gigas error is ZKVMs and real-time proving.

So in the first part, I'll talk about what it takes to turn the L1 into a ZKL1 and what really that means and then I'll focus on the engineering marvel that is real time proving that really unlocks this transition. So to have a ZKL1 you need ZK execution layer clients and validators. So the basic idea is that as a validator instead of having to download and execute the blocks I just verify snark proofs and I check data availability with database sampling as opposed to having to download the blocks.

And so really uh what ZKVMs do is that they solve this dilemma of scale and decentralization. We really can have both very large scale and best-in-class decentralization. So the rough um goal that uh I have in mind and various other people have in mind at the foundation is to scale the L1 3x per year. So Tomas has this number that he shared internally which is 300 million gas by the end of next year and Dankrat has this EIP uh which proposes to do 3x per year uh for period of four years and basically what I'm saying is why stop at four years right we can just

do an extra two years uh and basically push the limits of the EVM and reach this gigas per second error. So this is Dankrat's EIP 7938 and basically the idea that we're that it basic idea is that the the the validators will automatically vote for a new uh higher gas limit following this exponential schedule and this would give you know a certain sense of predictability for those who want to build on Ethereum over the next 5 to 10 years and also because it's this exponential growth it's it's also very ambitious Now um not only can we grow the L1 uh by orders of magnitude but we can also

improve the decentralization of Ethereum. So the current meme is that you can run uh you know an execution layer client like like like G or Ref on the Raspberry Pi. Well, I'm taking the this meme to the next level which is the Raspberry Pi Pico. Um, the Pico is a $7 device. It consumes one watt of of energy and it's sufficient to have a fully validating node on this on this machine. Basically, you just have to download and verify the proofs which takes only a few milliseconds.

Now, some of my personal goals for this year are one to get rid of my external NVMe drive uh and run my validator statelessly by verifying uh proofs of validity as opposed to having to download the Ethereum blocks. I also want to try the Raspberry Pi Pico. If you want to help uh coding this, uh I'll run it on my validator. And I also want to from home prove the entirety of Ethereum in real time uh using a a cluster of GPUs. Now in order to uh really unlock the the full potential of ZKVMs, we need this thing called delayed execution or delayed

proving. And the basic idea is that between two block proposals, block N and block N plus one, there's time to do the proving. So the proof for block n can basically arrive just a little bit before the proposal for block n plus one. And you can use all of this time uh as active time for for proving. And this is where you know the real time proving meme comes from that you need to be able to do proving within one Ethereum slot. And if you want to learn more there's an e research post about this.

Now, scaling the L1 is not just about scaling the validators and the wallets and the includers that come with Fossil, but there's all sorts of other actors in the ecosystem. So, there's block builders, there's block explorers and and RPCs. And traditionally, the primary bottleneck for scaling has been these weak and unsophisticated nodes. like we have such a high um degree of requirements for these these decentralized nodes that we that that has been the main bottleneck for scaling. But going forward because we have this solution of SNOX what I expect will happen is that the bottleneck will shift actually to these to these other entities. And the good news here is that these entities are much more

sophisticated. they have more resources available and the solutions um are traditional engineering solutions just traditional database stuff and networking stuff unlike the moon map that has been unlocked by uh the ZKVM teams recently. So just to give you one example of this kind of boring uh traditional engineering um you know GE is using Level DB which is a database from Google and Ref is using MDBX and you know these are like traditional things that databases that are useful in all sorts of contexts. So, you know, B trees or LSM trees, if you're familiar with those. And what we're seeing now is that there are databases that are customuilt

for Ethereum, specifically the Ethereum estate tree. Um, Coinbase uh base has a has a a database. Um, it's still private, but um maybe if you DM me, I can try and help you get access. But a few days ago um layer zero announced QMDB with and both of these databases are roughly speaking an order of magnitude 10x faster than than the state of the art. So I think we need to be migrating away from these legacy databases to to new ones. Okay. Real time proving this is the key thing that was considered to be essentially close to impossible a couple years ago and now we have four different teams that have achieved it. Um and it's a very very hot topic. uh including at EFCC we have

seven talks today about ZKVMs and real-time proving which uh which is really cool. So um Succinct made this big announcement a few weeks ago and they had this really nice animation on realtime.succinct.z. The the website unfortunately is is no longer active but I think they'll they'll turn it back on soon. Uh we have risk zero uh that is aiming for real-time proving in in in a garage. So they've uh they're building a cluster of GPUs on premises in their offices um and uh and trying to do real-time proving there. And just today, ZISK made this amazing announcement again of of of real time proving uh and I can see the ZIS team all in green there in the audience

which is very recognizable. And Airbender also had this massive announcement where they have truly excellent uh performance and um yeah, they're they're basically very very close to to real-time proving as well. And the cool thing is that three of these teams here uh RZero, Zisk, and Airbender have fully open source and permissive licensing specifically for the prover side of things including the GPU acceleration and the multi-GPU cluster uh orchestration. Now proving is a oneofend assumption meaning that we just need one entity in the world to do the proving in order for the proofs to be generated. Um but you know because we care so deeply about

decentralization we want the n to be fairly large. So in particular we don't want to depend on data centers. Why? Because there's only about let's say 100 data center operators in the world and n equals 100 is not great especially if the barrier to entry is to build a data center. So um one thing we've observed is that you know millions of people tens of millions maybe of people have electric cars and that is uh something that can be done at home. So the the guidelines that we have for real-time proving is a maximum of $100,000 of capex for the the the cluster and at most 10 kilowatt. So this Tesla home charger is rated at 11.5 kilowatt. And what we find is that the bottleneck is

actually the power not the cost. So if you uh you know purchase a GPU cluster for 100k um it will more likely than not consume much more than 10 kilo 10 kilowatts. Okay. So what I think will happen over the the next few weeks and months is that the notion of real-time proving is going to crystallize a little bit more and and formalize. And here are here's a kind of a first draft of what we need in order to really take Ethereum uh to the next level. So of of course we need the latency to be very very low um a little bit less than 12 seconds 10 seconds for 99% of mainet blocks and we need the capex and the power to be limited and we also need the code to be open source for

for the prover and on the verifier side of things we also have some requirements for example the security needs to be high enough at least 100 bits of security proof sizes need to be reasonably small etc etc now let's focus on power because that is really the the bottleneck. So um kind of a state-of-the-art art artis 5 execution runs at about a gigahertz actually a little bit more 1.5 that's what this team has achieved and like roughly speaking the order of magnitude is that uh this this exeutor will consume five watts right is like enough power to for the CPU and and the hard drive that will hold the ethereum uh state tree and then you basically need a cluster of GPUs to

keep up with the with the execution and roughly speaking state-of-the-art um GPU proving for example from airbender achieve roughly 10 megahertz per CPU so you need 100 CPUs each CPU consumes 100 times more than the exeutor so you that's a total of 100,000 sorry 10,000 x overhead uh to do the the proving from a power perspective now you may think okay 10,000x is is terrible right uh but I see it as a great opportunity to to improve. It means that there's more juice to be squeezed. And in particular, um my I guess guess talking to to to many of the teams here is that there's

at least another 10x from software improvements and there's another 10x from uh hardware improvements, specifically Snark A6 and and and things like that. And if that's not enough to get to the scale that we want, we have another trick um down our sleeve which is multi-remise um proving. So we can have collaborative proving across different clusters. So for example me from home I can collaborate with someone else and even though we um single-handedly we don't have enough power combined we have enough power to to do the to do the proving.

Now, um, one of the amazing things is that we've seen in the last few months an absolute blossoming of of ZKVMs. So, uh, here we have 10 ZKVMs that can prove Ethereum blocks. And proving an Ethereum block is, you know, quite difficult to reach that level. uh partly because you need to have a virtual machine and an ISA which is um you know flexible enough to to to prove it but also you need all of the continuation and recursion infrastructure to take these big blocks chunk them into much smaller statements and then glue everything back together with recussion.

So massive congrats to these uh test 10 teams that have achieved proving of L1 blocks and there's another nine that are aiming to achieve um the proving of L1 blocks uh uh this year and within these 19 teams all of which by the way are open source. Uh we have 13 um that are aiming for uh real time proving or have either achieved real-time proving or aiming for real time uh proving this year. And so by the end of this year, what I'm expecting will happen is that we'll have at least uh 10 ZKVMs. And that is amazing diversity. And by the way, this diversity is important for security reasons because just like uh we assume that every single execution layer

client and consensus layer client is buggy, which is why we emphasize so much on client diversity, we have the exact same strategy for ZKVM. So more likely than not, every ZKVM has critical bugs. But if we have a diversity of ZKVMs, then that gives us uh some some amount of robustness. Now, this is my last slide. If you're not familiar with this uh website, it's basically trying to provide legibility into ZKVMs and their performance, the cost uh in dollars and the the the latency in in in seconds. And right now we're basically encouraging the various ZKVMs to uh submit proofs for one in

every 100 blocks. And uh we have this kind of mini block explorer. And uh there's also these uh pizza slices which might be reminiscent of L2B. And actually the in some sense the mission of Eve proofs is to be the L2B of of ZKVMs. So that's it. Um, I've negotiated with the the crew for an extra five minutes of questions because I'm the last speaker. So, feel free to shoot ahead and yeah, looking forward to to your questions. [Applause] Any questions?

Do we have a second mic? I will bring it back. Yeah. Oh. Um, how how does this relate to the beam chain? Okay, great question. So, the beam chain is dedicated to the consensus layer. Um, there is snogification there. So, we do want to snify in real time the entire consensus layer. um but it in some sense it's it's a separate layer and therefore um not not not related. There are some some definite synergies. So one of the synergies is that the same tooling the same ZKVMs can be used for for for both layers. Um and

um I guess one of one differentiation between the beam chain and the execution layer is the amount of resources necessary to do the proving. So for the EVM, we're capping ourselves to uh you know a 10 kilowatt cluster which is quite a lot of power. Um for the beam chain what we're aiming for is a single laptop CPU to be able to prove the entire consensus layer in real time. Um and the reason why we can achieve uh such low proving uh resources for the beam chain is that we can make it extremely uh snark friendly from from from day one. So we would use snark friendly hash functions like poseidon and snark friendly signatures uh that

are that are hashbased as an as an alternative to BLS. BLS is extremely extremely uh snark unfriendly. So by swapping BLS for something postquantum secure we also gain at the same time uh snark friendliness. Yes. Um just a question if you can comment a bit on uh red how reducing slot times affect this because you're shown a delta like two seconds uh when you formalize what real time proving is. So yeah. Yeah. So um fantastic question. um when you do the the proving a a lot of the components uh are either like massively paralyzable or um are take linear time

with the amount of work. So if you do the the initial execution which is sequential work that is linear in the in in the gas used. So if we reduce by two the slot duration and also reduce by two the the gas limit then the execution doesn't change. um all of the paralyzable stuff that also you know doesn't really matter. Um but one of the things that we we have is kind of this logarithmic overhead to the proving and there's two components. One is that when you take your block and you split it into chunks, you have to basically recursively um take the proofs in order to have a meta proof. And and here you have a basically a binary tree and the

depth is is login. Um and and here basically when you when you decrease the total amount of of leaves you only reducing by one layer and so you're not you still have this this overhead which is kind of um annoying. The good news is that the ZISK team today made this you know in their presentation they showed that the recursion is just extremely extremely fast. uh the latest numbers is like 150 milliseconds uh for for a 2 to1 proof folding and I believe they can also like do multiple recursions on a single GPU maybe the number is something like like 16. So this part here is actually not too worrisome for me. Um and then the other component is the

gossiping of the proof and that is also logarithmic because when you have a a a gossip ch gossip uh pitspin network you basically have you connect to some peers and the other peers also connect to other peers and you have this this exponential anyway um there's like overhead to gossiping and um you know that's maybe on the order of of of one second or or half a second or something. So if we if we start reducing the slot durations too low then that's suddenly like the the gossiping time start to dominate and the recursion time also dominates. But right now with 12 seconds there's a lot of room to go down to six which is the proposal. Yeah.

Yeah. Um so on Twitter I've seen for example Nezarmind and uh some other clients reaching one gigas and I was wondering uh do you think uh with the current hardware it will be possible if we run those uh clients? Yeah, great question. So um one of the things that um the the CL execution layer client devs have have been doing is launching perfets. That stands for performance test nets. And actually this is I believe a screenshot of never mind.

And not only have they reached one gigas, but they've actually reached six gigas on their screenshot. And the the EVM is being pushed to extremes. Uh we saw the layer zero. they they they're they're claiming a million transactions per second which is kind of completely uh in insane. Um and so I think you know how I said that there's these two different buckets of engineering. There's the moon math with the snarks which traditionally was thought to be impossible but that actually is no longer the bottleneck. Uh what I expect will happen when we grow 3x per year like the ZKVMs improve 10x per year.

Like 3x per year is like child's play. Um but for the traditional engineers like improving databases at 3x period that's that's that's much much harder. Um oh okay uh with this diversity of ZKVMs like how we're going to basically choose which ZKVMs kind of qualify for being accepted to produce proofs in Ethereum. I suppose there will be some kind of qualities maybe I don't know the size of the proof like how long it takes to uh generate this proof maybe postquantum security maybe what kind of aspects of ZKVMs you kind of look for to kind of be accept to for ZVM to kind of be accepted to be as a real prover for Ethereum yeah

that that's a great question I basically try to kind of list out the the requirements here these are are soft requirements in the sense that every validator ultimately every operator can do do whatever they want. Um, but the I think the thing that makes sense from my perspective is to have client diversity internal to an operator. So, traditionally the way we do client diversity is that it's across the operators like I run g like you run ref and some other guy runs run something else. But here with proofs, it's actually very cheap and easy to be a to run multiple clients uh on on on one device just because you're each proof takes a few milliseconds to verify. So

you can verify five of them. So you can imagine um a setup similar to vouch. I don't know if you're familiar with vouch, but vouch is basically this institutional tool where you can run multiple clients, for example, three of them, and if two out of the three agree, then that is your canonical view of of the chain. Um now I think what would be nice is that there's some sort of like soft rough consensus around what is this list of clients of ZKVM sorry uh that are that are used to verify the the proofs and once we have this this convergence then it it means that um you know it's things simplify so for example the the gossiping simplifies and the the proving simplifies and and so in my

mental model right now is that we would want to kind of soft agree on five of them and have a four out of five rule for example and um yeah it's going to be interesting to see you know which five could be selected um but um what I what I expect so one thing that I didn't mention is that not only do we want diversity at the ZKVM level but we want to retain the diversity of the execution layer client so one way to do it is to pair one ZKVM with one execution layer client. So for example, you could pair like ZISK with with GE and you can pair risk zero with with with Ref or something. And the way that

I would do the pairing is that um I would have the fastest ZKVM with the slowest execution layer client so that when combined you kind of have an average uh kind of real real time prover. Um, and so what I would do basically is pick pick the fastest the five fastest ZKVMs and pair them with the with the five existing execution layer clients and hope that this average it out to to to under one second of latency. Um, doesn't it become a arms race that you're scaling the execution layer that you also now need to scale the proving?

And the proving is already at a 10,000x overhead. And even with 100 10x on uh hardware, 10x on software, that's 100x. Um, and you also have to basically include another overhead for scaling the execution layer in this case, right? Um so because the proving the proving time will essentially increase if the execution layer um performance also increases right okay so there's a lot a lot to unpack here let me address your very last question which is when you increase the gas limit does the latency increase and the answer is no and I have

to go to my extra slides to answer this technical question uh which is this uh so there's a fantastic EIP called EAP7825 which caps the amount of gas used per transaction and this is landing in Fusaka this year and the cap is 30 million gas and the amazing thing with this EIP is uh what I call subblocks or mini blocks. So you can take a big Ethereum block and you can chunk it into subblocks at transaction boundaries and then you can do the execution which is the sequential part of all of these sublocks in in parallel. And so you can have enormous enormous blocks, but because you can chunk at transaction

boundaries very easily, it's not going to affect the the latency. And actually SP1 when they announced ISP on hyper cube that does the real-time proving, they use this trick in order to to to get the under the 12 seconds. Now your other question was related to the fact that yes, where we where we are versus where we want to be is roughly 600x. So we're at about 1 point well we're at exactly uh 1.5 meggas per second right now and we want to get to one gigas per second. So that's roughly a 600x. Where do we find the 600x now? I think there's at least 10x from software at least 10x from hardware. So let's

let's but the hope is that it's more than 10x. Maybe it's 20x on hardware and like 30x on software. But even if we take the worst case scenario where it's only 10x and only 6x, it's only 10x on both software and hardware, we would be off by a factor of six, right? Because you got 10 10. We need to get to 600. So we off by six. Well, we just need to do collaborative proving across six different premises in order to to reach that. Hi Justin, I see a lot of talk about um risk five. Does that mean we're like

switching from EVM to risk five? So at this point in time where the only thing that we're doing is increasing the gas limit. You can use whatever um ISA that you want and actually you can see uh that some people are using standardized ISAs like MIP and was um some teams are actually like hardcore rewriting the EVM using circuits and and kind of low-level programming languages. So that's what linear and kakarot have done. And then uh there's a few teams out there that have like exotic ISAs which mean that it the tooling is not there to have compilers from high level implementations like ref all the way down to this to this new ISA. Um but you

know having a diversity of ISAs is actually a great thing in the short term. Why? Because a lot of this um a lot of this tooling is dependent on LLVM. So LLVM is basically this this this compiler framework that allows you to take high level languages and compile them to things like Ris 5. What if there's a bug in LLVM? Then now like all of all of these ZKVMs are are affected at the same time. There's correlated failures. So having a diversity with things like linear and ref and and maiden and whatnot that's actually really helpful. Now if you're willing to think on a longer time frame um let's say three to five six years um then one of Vitalik's idea uh which I you know

really like is that we could enshrine a new ISA that is ZK friendly under the EVM and the the current proposal I guess is to use that to to use risk 5 even though we're you know looking at everything else and there's several advantages to doing that one uh is is um performance. So you would allow smart contract developers to access risk 5 directly without the overhead of the VM and you might get a 10x improvement. So you'd be paying 10 times less gas uh in order to make use of of of Ethereum. And the other cool advantage is that you dramatically simplify Ethereum, right?

all of the technical debt that Ethereum has, the EVM has, is basically uh it dissolves and now you just have to maintain risk 5 which is super simple and you know largely unchanging and immutable. Um if we're going to switch um ISOs, why wouldn't we switch for one that actually you can buy hardware for today and you can run it at a hardware speed like an ARM? Yeah. So the the two main ISAs that we use in practice today are x86 and ARM. Unfortunately, neither are like permissive. Um, so every time you wanna like do something with with those like you you have to you have to pay licensing and it's just not part of the

ethos. Um the other thing I'll mention is that x86 and ARM are both actually very complicated iss like x86 is extremely complicated like I don't know hundreds if not thousands of op codes and uh and ARM you know even though ARM is kind of marketed as risk is actually a CISK like a complex uh it has many many up codes nowadays um so I don't think the ZKVMs would really enjoy implementing either x86 or or ARM uh but the other thing I mentioned is um is this so that if you had asked me you know two months ago uh what is like one of the main bottlenecks for proving I

would have told you the execution is the bottleneck right because there's this sequential thing uh that you have to do which is generate the minimal trace and that's much much slower than uh running a CPU but but one of the big breakthroughs of of the the the the guys is that they've accelerated that to almost native speed. So 1 ghahz is like roughly within a factor of like four or something within native speed. Um and so there's less of a need now to go build uh custom snark A6 that will handle the the execution.

Running out of time, so we take one last question. Thanks. How how do you see this uh ZKVM road map affecting the L2 space? Do you do you think this is conflicting with the current layer 2s or do you think it's complimentary? Yeah, fantastic question. Um, so having the L1 uh be like a very like powerful chain will will definitely have consequences for for the L2s. Um, my hope is that it's very beneficial for the L2s. Um, one reason is that it's going to lead to much more TVL on on on the L1 and that will mean that the L2s

will basically benefit from this very u rich and and vibrant hub. Um, one other thing that I hope will happen is that the fact that the L1 is so economically strong is going to incentivize the L2s to adopt the same sequencer as the L1. because when you have two chains that have the same sequencer, you can unlock what's called synchronous composability and like these very interesting network effects. Um, and with real-time proving and shared sequencing, you do have um you do have synchronous composability.

And then the other thing that I'm hoping will happen is that um just having a very strong L1 will be like net positive for for Ether, the asset. Um, and what tends to happen in practice is that the L2 assets, the tokens are very much correlated with with Epher the with Epher. And so if if if EH does very well, I expect all of the L2s to also do very well. Second quick question, do uh do you maybe have a favorite ZKVM? Uhhuh. Do I have a favorite ZKVM? Um, I have a set of favorites in my mind. Um uh but um uh no no no one specific uh favorite.

One of one of the things that's that's really amazing is that um a lot of the the teams are doing different things. So if you look at succinct for example they introduced this innovation of the subblocks and the mini blocks. ZISK, they did the uh the executor. Airbender, they have this um GPU prover that just maxes out the resources on on the GPU. You just can't go any faster. They have like really hardcore GPU engineers. And um the one of the unique things that RZero is doing is that they they're building a cluster in in their offices so that they can do on-prem uh proving and like improving the the the

orchestration of multiGPU proving. And when you combine all of these ideas, you get something which is going to be like really really monumental. Um and so you know right now we can do so sync did real time proving on 180 GPUs. Um, ZISK I believe was like 50 or 64, I forget. Um, but you know, Risero believes they can do 16. When you combine everything, I'm hoping that we can do real-time proving on like six GPUs or something ridiculous. Um, and I think that will be a very glorious moment for for Ethereum.

Thanks,