ZK Attesting

Transcript

It will happen when perfect good morning everybody laus part of the EF protocol coordination team today global demand preserve un validator set so

technologies we identified on the on the roadmap for many years on the one hand data availability data availability sampling Z cont staking quick reiterate zero knowledge proof of you heard of in the context of rollups of the past five years the technology has matured along the way and we currently feel sort of confident ir

roll road s perfectly on track as we trying to make L1 roll itself and so what this means for notes essentially is that instead of every note on the network reexecuting all of the transactions in a block they will instead verify these zkm proofs and this is one of the probably One of the biggest architectural shifts in the history of the Etherum protocol. It touches the consensus layer, the execution layer. It touches cryptography, networking optimizations, the economics to it, governance if you will. We introduce KVM vendors

rollups affect CL teams this is a big shift. Why would we do this? What is what what are the special properties of CKVM proofs? CKV extremely efficient and by the virtue of the technology will what we are particularly leveraging here sort of compute compression so verifying proofs is extremely resource not resource intensive so you think of it as verifying these proofs on on smartphone type devices and the beauty is that we can do this consistently fast so regardless of the block size we can we can we can verify these proofs extremely extremely cheaply and so what

we effectively get is the standardization of the cost of block processing which is which is a beautiful property and as Carlos has alluded to in the in the previous talk we introduce this notion of statelessness with KV improved as sort of the by verifying the by verifying the block DKV improv we can guarantee that the block is valid so there's no need for Carlos talk the previous talk.

So why would we do this? What are the big benefits of first of all users benefit we can drastically increase it allows us to drastically increase the gas limit which is beneficial for for all of for all of us in terms of higher throughput along for more economic activity happening on etherum obviously also cheaper fees rollups benefit significantly from this sort of they now are inheriting sort of this zk mainet gray technology from itself and validators first and for so z test sort of we lower the resource consumption and the cost of running a node significantly

and so in more detail what this means for testers for stakers as I mentioned earlier the CPU requirements to verify these proofs is extremely minimal as we sort of get rid of this notion of holding the state state cashing is RS minimed obviously is the evergowing execution layer state so terabes today maybe 4 terabytes and as we yeah as there no need to hold the state anymore we can we can get like mostly rid of this requirement and also and car was alsoed to this a little bit

there this significant advantage download set of recent checkpoint up to the tip of the chain immediately. So in conclusion for stakers we lower the barrier to entry to run a verifying node massively while at the same time scale the network dramatically as well.

Sorry was so where are we at? We have an EP 8025 optional execution proofs. There is feature branch on the consensus specs I believe already there also spec changes to the execution layer which been published as well. And basically what this EIP introduces is a shift in the node architecture itself. So on the le side you see the ordinary like full node completely bundled with all task and studies as of today and on the right hand side you see this z test architecture basically what this is a stateful consensus layer client not things change there but instead of this engine api interactions

with stateful el you have integrated execution verification functions think of it this is lightweight verification function to verify these improves and you can do this statly and notice the hand symbol. Oh so well I mean why would we do this? Amaz remove a ton of lines of code right most of the engine if you will and notice the handshake symbol not sort of full note as we know today so we ex effectively leaning into this unbandling of node roles going forward

and I go into this a little bit So zooming out like we have this ZK testful stateless verifies the tip of the chain but someone still needs to hold the state like right so someone still has to be able to build a full block and and serve state if you will so the role of the builder will continue to exist in in the future which is okay because we have fossil so all of the guarantees we want from from a full node introduce

role you ask if a testing becomes super lightweight who does have a lifting right so we have this asymmetry in node r and the proving task is heavy duty resource currently GPUs current gas limits craft block and also like an additional additional constraint that this needs to happen within slot right because we need sufficiently enoughestations on these proofs in order propose the next block so we have this notion of quote unqu real time proving so we need proofs within 12 seconds to happen

so you may think okay Isn't this isn't asymmetry a bad thing? introduce centralization vector right here sort of we only need one entity with etherum like one stakeholder one one prover on the planet to craft these blocks in order to stay life and so this is very generous and and fortunate assumption to make by contrast for example to the honest majority honest majority we need in order to keep consensus Right. So for stakers bit of a deep dive like most of this will be abstracted away from you. But I wanted to show you

I guess a little bit how the how the backend works right the whole flow from crafting a block until it sort of is gosped and received by the ZK tester client itself. And so let's let's go backwards. On the lower left hand side you see the ZK tester client which verifies ZK as I earlier and then in the gray rectangles you have this prover maybe bundled with the builder maybe not could be two entities so on the right lower right side prover who runs this ZK virtual machine and think of this as this proving backend like the

cryptographic happens in correctness of execution inputs needs to feed into ZK virtual machine a guest program and basically technical term for an execution lay client so it's basically the etherum state transition function which can be like gath STF WH STF etc and this gas program needs another input the block and so execution witness execution witness produced by the stateful execution layer

client which would be a builder for example so a the block and b this witness and the witness is basically just a data package to validate the block statelessly so these are all the inputs and the prover takes all these inputs generate these proofs and sends it to the tester mean client diversity basically we want to preserve the notion of client diversity protocol going forward so in so and how do we do this so basically the idea is to introduce this multipof logic so you may have heard of vouch or vero in the context of cross cli cross

validation Z testers in future will automatically basically require them to download five proofs and as soon as three of the five proofs are deemed as valid verified proofs locally they attest to the block so yeah I mean there and this is important because provers can prove bugs proofs can proofs can sort of late there all sorts of like we rely on still on nan cryptographic solution so yeah proof diversity is sort of our our

hedging mechanism against right so how g roll this out and yeah as i mentioned it's gna be a fac rollout like there are going to be multiple eips along the way we start with optional proofs as i mentioned earlier 8025 we currently targeting this for for the star for and basically what what is expected to happen is that only a few valid datas will op from the beginning and the basic reason is that proving in this regime is effectively alistic right so there is it's not incentive to to prove these blocks just yet so like for a testers you may like if a block doesn't arrive

in time you will miss out on on timeliness rewards for example shift in architecture protocol to do a safe rollout right so probably in the beginning stakers will continue to run this execution layer state in parallel right as for the fallback mechanism right so this is valuable for us to sort of have this hybrid testing word if you will and sort of there still this execution will

introduce notion of mandatory proofs what call native proofs and reason native basically means all the testers are required to to prove to verify incentive compatibility building a block and proving a block right so in this regime a builder has a strong incentive that all of the attesters indeed verify proof of the corresponding block in order to land the block itself right so yeah this is sort of the the mandatory native proof regim blocks

on high requirs not required anymore eh talking about native proofs mandatory proofs eh there's this need concept Et native rollups basically sort of connection complementary notion is that once all of the L1 validators sort of aware of ZKVM proofs what we can do at the L1 is we can expose the EVM itself to rollups with for example

preomile functionality and why would we rolls trym equivalent at least many of them and this is engineering heavy task whenever the evm changes they have to change their proving circuits around implementation themselves so what we could just have them call precompile and basically whenever the L1 governance changes the EVM rollups automatically inherit this functionality basically get automatic upgrades can get rid of all of their security councils to protect for changes

to their EVM themselves and so as a good rollups like all rollup transactions would be verified by the L1 validator. make rollups much more secure because we have infrastructure for proof verification on the L1 and ja so economic benefits security benefits for rollup this is a super exciting topic make sure to check out Lucas from Lobbeat work on native rollups and do reach out if you wan collaborate on this okay fin I Zm team foundation

basically for 2026 we a have to make standardize a lot of inputs for the proof generation process so the execution witness as Iuded earlier we need to have cross compatibility amongst the CAS programs right the different state transition functions we need to have standardized interfaces between the proving backends like ZKVMs and the execution layer. We have to build the clients and the good news is we have prototypes for 8025 in lighthouse already in prism already so we hoping to get to a definite multicent definite fairly soon.

>> [fnyser] >> We also have to the prover infrastructure this is particularly software software development I guess question less than a hardware thing and at the end of the day we need to benchmark these have to be performant so yeah data collection is is is one of the another sub major subjects and yeah at the end of the day security security security we rely on modern cryptography before ship on we need to have the highest highest possible security guarantees we can [fnyser] basically it make sure to join the technical mostly technical discussions

on the ERD discord in these two two channels. Make also sure to to take a look at the ZKVMs ZKVM teams website. We produce a ton of block regularly and yeah I think we have a couple minutes for questions and yeah that's basically it from my side. Thank you very much. Hello. [harklar sig] So if we can do remote attestation of computation and storage at what point do

we not need a blockchain at all anymore? I guess there is a use case for strict global consensus. So eh I think yeah like from my perspective there will always be use cases for for like global content. So essentially for blockchains. Amazing. Thank you.

[applåder]