Ladislaus von Daniels - Validating With an ZkAttester Client

Transcript

Hi everyone. My name is L part of the protocol coordination team at the foundation. Quick shout out to Jonathan Remy the East crew for organing event and for the next 15 minutes also be talking about reporting back I guess little bit high level overview of what several teams at the eum foundation in conjunction with client teams have been working on for the past couple of month sort of migrating us in this zk era of Ethereum and sort of particular Marios has been talking about the big

problem trying to tackle is obviously straight between scaling ethereum significantly why not giving up sort of guarantees preserved decentralization permission verification inclusion etc. Ja rec discussion going on about what we actually want from our notes in context may rethink the role ofe if you will sort of maybe unbandling of roles which sort of been much more iment part of the part of the

merch and sort of separating building from a testing potentially in the future separating testing proposing technologies not makees rely on maxim uncated val dat on the one hand been data availability sampling which may in the context of scaling blobs and zero knowledge technology which I will focus in staking

magic cryptographic technology in in our context so gu main reason that as ae today runner today when you receive a block essentially what you do is in order to verify validity you download the block and you reexecute all transaction involved includ block moving into ZK world essentially what we get from proof is that all it takes to verify the validity of all transactions is basically we only need to verify this proof which someone else has generated in order to be sure that the chain

that the block is indeed valid and so basically with as this pack has matured over the MP teams ship L1 KVM basically take away for us context ofing that we can that we will focus on snarfying the execution side of things ands quick recap why would want to do sof executionm extremely efficient so what we get from

that we have basically very lightweight verification being being done on very lowped devices think on the of smartphones would the great thing also is the verification happens consist independent of the statement process great things sort of us takers testers enti as we receive a proof which guarantees block validity we don't need to the state anymore and so what this essentially means in

terms of benefits for is that we can massively reduce the cost of running a node and as Iuded to earlier verification of such a proof is super lightweight so the CPU the CPU load we require is extremely low as we don't hold the full state anymore the RAM requirements for example for state cashing also extremely minimized and probably the biggest advantage is that as we don't have to hold the full state of the execution layer anymore we can essentially get rid of this re second benefit right times so

imagine instead of downloading all the state history you can basically download this improve and somewhat mimic this this functionality we have on the consensus layer today which checkpoint syn so similar to that we downloaded proof of execution instead of having to download out of the state history we can essentially a note instead of days on the order of seconds if you will and all this is to allow us on the one hand like massively scale L1 while allowing for anyone to run a verifying node

and so diving little deeper into what this means for the architecture for testers on the le side you see the current world where we have two stateful notes like for the cl and for the el basically have engine api this interface communicating between both layers sort of if we now look at what zk testent would actually look like is that we mostly remove this engine api functionality consensus layer basically instead of

downloading asking state execution layer client can you check validity all you do sort of you download zv over let say gosip gosip sub channel and you have this integrated execution verification function which is the super late weight function to only verify this proof it can be a single binary right not two binaries can be single binary and it runs statelessly so this is essentially client architecture where we have prototypes in I believe lighthouse andu already so so this is not a pipe dream there is work going on on this already

but and this is sort of why put this handck symbol cool super testing home decentraled someone needs right needs to be able to build blocks off of the full state. state builder for moreover will introduce role of what we call so somebody actually doing the work of proving the execution this sort of where I wanted to zoom in

here sort of test become potentially super lightweight like who does the heavy lifting and and very important to proving e blocks resource intensive task takes on the order of 20 GP currently to prove a block on the order of on average 10 seconds that's the second part there is timeliness issue currently we have as in the reexecution word it takes on the order of hundreds of milliseconds I guess to prove and verify the block but provers need to do this heavy lifting and So yeah I guess the interesting

the good news that we have here this example here is that proving time distribution over a certain slot of blocks has made massive improvements over the past 12 month we have hardware optimization we have software optimizations and in this very instance ZVM provider ZKVM discort it takes them with 24 GPUs fairly beefy CPUs on the order of around e seconds on for the average block to be proven and just very morning I saw an announcement

that this number has been there's another ZKVM provider who brought on this number to 16 GPUs so this is sort of I guess this is sort of to say much more to highlight another thing is actually a good idea to introduce new actor in the blocking pipeline and guess to highlight is that it's not too bad because we actually reasons we would only need one entity

valids particularly said requirements blocks such that proving remains accessible and just to contrast this right for the for the for the consensus to work like for the change to make progress we need at least 50% right and half over intressation necessarily valid okay roll pl I guess what you realized when I when I

showed these e seconds average proving time is that e seconds is way too long right it's beyond the attestation datelin for the current protocols to have forest to remain sort of to have timely attestations right and so actually what we see this upcoming Saturday is a live main demo of a community member who will regardless of the fact shut down their execution client download ZK run database which is great sort of great proof right

actually works but yeah I guess the issue is this individual will suffer timeliness penalties and so what we actually need in order to this be like a more rationary thing to have on we would need some form of block pipelin right so we need and which is what we get with with Amsterdam hardbs update sort of bring us the separation of block execution from block validation with this what we will call delay proving will have much much more time to to generate proof and the testers

and testers will economically ir at least some form block pipeling and may second okay now that we want to make proofs what we will call mandatory so mandatory in this means block would have to be accompanied by ZKM proofs and all validators need to need to verify that there are

sufficiently many of these proofs indeed available before the test so this was act this would actually be a change to the for choice rule and sort of yeah some would use this term entry but essentially zvm proves what would become mandatory for for validator So inmuture need more things more zkvm security right proving generating zkes is

on mathematicalp conures In the context of the L1 we wouldn't consider I guess har enough we also need to standardize a lot of ZKVM ZKVMs we have we need to standardize changes to the execution layer clients we have we need to do rigorous benchmarking on the combinations of ZKVMs and ELS and obviously ZK tester clients still have to be have to be built.

Okay, cool. Quick rundown is up on fairly high level details of what the changes to the engine API would look like and I would suggest you to also take a look at the Etherum Foundation CK EVM team the team website. recently published blog on on benchmarking ZKVMs and so yeah that's that's basically it and happy to take a few questions [applåder] yeah the m

first in this future am I hearing rights that local block building Yes. So, so right if you run a Z test client, you don't run the run stat and you won't be able to build locally. And maybe that's also reason to to double down on fossil like this is a personal take but yeah we need to make sure that as we want to scale ethereum as we want to unband roads that there are in protocol guarantees for making sure what we get from local building today which is fast inclusion right mainly fast inclusion among other things this guarantee is preserved agree with your personal take

second have you had discussions yet this means for the bond M right. So the the 32 e requirement is sort of a different orthogonal question to this like this is this will potentially change as part of the snakification of the consensus layer right some of you may heard of this lean ethereum lean consensus effort which has been which started earlier this year and this would introduce potentially introduce like the stockification of the consensus layer and therefore potentially also allow changing Z testingification layer is a separate separate discussion.

Perfect. One question on the other side of the room. >> Thank you very much for the overview. I have the following question. So right now when you run a validator node you have all of the tool kit at your hand. So you got the block you execute the block you validate and you don't need any counterpties or third parties. Right? >> With ZK the proof should come from somewhere. Yes. So you should either trust someone to provide a proof in a reasonable amount

of time so that you can be someh included at the network level so that alongside the block you will also get approve so that you only need to verify that. Yes. How do you see that andraveling into future? >> Yeah, it's interesting. Essentially what I just mentioned it's the second phase is this mandatory proof. So the protocol requires proof to be available with blocks and in the first ways we rely on on like third party actor which by the way again one of assumption comes into play so I would call it like a bad dependency

we like I'm fairly excited on on distributed proving for example so call it squad proving teamed requirs generally high terrible at formula generating even iflify to the least possible extent would still be a

meaningful additional amount of work it's like energy preservation concept right you cannot just save one one space without adding somewhere >> somewhere in the other space so this would be an additional duty and so that it should be like somehow accounted for in the consensus mechanism I believe with the rewards or whatever else Right. I hav touched upon pro incentives. So this is still like a bit of an open research question.

ideas around markets for example so that we indeed potentially in protocol incentives for actors I personally right now maybe a bit optimistic good analogy right now would be poti slasher like who here runs the slasher on mainet great f great this is a purely alistic task not the same admittedly higher than running some people need the network relies on on one honest participant to detect flashable offenses and apparently we

have some people in the room would step up essentially as an artistic task yeah okay I still think that probably I'm not like aware of what separate slasher means, but the validator who reports slashing is definitely awarded for that. So there is an incentive and >> not not the slasher, not the one who detects the slasher. >> Okay. Okay. But anyway, you you mentioned it right that generating proof is probably a way more complicated task. >> Yes, that's >> okay. Thanks for touching it. >> Excellent. Well, I know we have more questions but unfortunately we're out of time and want to get to our next speaker. But L thank you very much for the presentation.

[applåder]