# Scaling Ethereum with Proof Verification Preconfirmations - Swapnil Raj | Nethermind

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2024-10-07
- Duration: 15:30
- Topics: People & Blogs
- Watch: https://streameth.org/watch/yt-zntb24DpH90
- YouTube: https://www.youtube.com/watch?v=zntb24DpH90

## Transcript

yeah cool um right so before we get into this efficient verification we need to kind of understand what uh um pre- confirmations are uh pre- confirmations is this new idea where you know the next uh 32 to 64 eum proposers um and they can opt into additional Services apart from like just proposing a block they can sign up uh say a message saying ahead of time saying like hey I will include your transactions in five blocks when I'm the proposer um and they could do this and this is very this is this topic is being researched into in Bas like in base rollups and trying to make um sequencing for Bas rups like milliseconds instead of like seconds um it also is a very easy way for rollups to decentralize in some sense you're you have a centralized sequencer every slot of ethereum but it keeps rotating between them um yeah so this diagram is from Justin rake's for initial post on Bas spe confirmations um right what we do is we modify this this scheme where um a user requests a preconference a message saying like hey I have verified that your proof is VP right which is a verification of Pi uh and I will include this result in my block in slot n plus2 right how can this fail um so there's three ways this can fail is first is liveness right the proposer at slot n plus2 doesn't propose a block at all and then you did not get your your guarantee was not met um the second is safety um where the proposer did propose a block at slot n plus two but did not include your transaction uh in this case you did not get your proof verification uh and the last one which is actually an extension like the first two are just from like vanilla pre- confirmations the last which is correctness which is where a proposer signs a a proof verification which is incorrect basically let's say they sign on a proof that this is false but the proof is actually true and in that case they should be penalized actually in all these three cases they should be penalized because they lied um cool so we will now see how we can use uh the ethereum pipeline to do efficient verification on on ethereum itself uh in general like to give you like a high level overview of how ethereum's consensus works then there is uh a bunch of validators as you can see committee a committee B um and there's a few aggregators basically these validators in these committees are signing on a block right so they reexecute a block they sign it saying like hey I have verified that this block is correct and then some aggregators like some of those signatures usually BLS signatures into one BLS signature and then the beacon J nodes can verify like hey I know that 2/3 of etherum not said this is the correct block right we exploit this part and we basically this is the offensive part which is we use optimistic uh execution for verifying ZK proofs basically here instead of all the theme validators verifying a ZK proofs we have one the inv validator verifying a ZK proof and the other was the other ones are like task with the responsibility of challenging it uh why is this more efficient this is just a simple system design thing right in the first case which is supposed to be like consensus where we have the red red circle which is the proposer he makes a block um he sends it to the other validators and then they reexecute it and say like yeah this block is correct here I'm signing on it in optimistic verification or in optimistic execution the proposer just sends hey I've done this execution and in the good case the the the other valid is just signs just sign with yeah this is correct um ideally they should check and they should take verify that this is the competion done it was correctly uh but in the good case it's compared to like the current of ethereum which is like a million validators executing the same thing in the in the good case we will only have one validator or a hand full of validators executing the verification of a proof we we'll look into later how we can make sure that this is correct and how can we verify how do we make incentives so that the proof verification is always done correctly Um this can also this technique can also be used for faster finality for rollups uh so in the current world verifying one ZK proof on ethereum is kind of expensive and it's it's very expensive if we want to do it for each roller block so what rups do is they aggregate their proofs either like folding schemes or recursion or whatever but it usually looks like they have like let's say Pi 1 and Pi up to Pi 4 represent proofs for blocks 1 to 4 what they do is they make new proofs Pi five and Pi six which aggregate the proofs from PI 1 and Pi 2 and Pi 3 and pi4 and then they make one final one which Aggregates those regressive blocks by verifying Pi 7 you can verify all those proofs Pi 1 to pi4 um and what you do is basically amortize the cost of verification of one proof across all the proofs right um this is really good for like cost Effectiveness and this is not really good it's kind of need right now if rabs didn't do this they would be more expensive than L1 possibly um but what this does is adds a lot of finality time because let's say block one was done and Pi 1 is calculated but the proof for pi 1 now needs to wait for pi 7 to be calculated to be verified on ethereum uh and what this kind of adds up to is let's say if all the leaf proofs take T seconds and then the second first uh stage of the tree takes X seconds and then the last stage takes y seconds the overhead in the in the end is 40 + 2x in y seconds that's just the proving overhead and then it needs to be verified on ethereum uh and what this results in or what the experience we see today is that Zs have a fin times of like up to 6 hours or 12 hours um and we can change this if you use if the verification cost of uh proofs would be cheaper uh optimistic verification my opinion kind of helps here um multi prooof verification right so this point is about how we have different rollups using or co-processors using different ZK proof systems we have some using um Halo 2 or or plony or Starks and across right the problem is you can't well you can't efficiently aggregate proof across these proof systems because they use different Prime Fields uh they just use different architectures um and it's it would take like years of research to actually figure out either we first consolidate to the same ZK system or we like figure out news new Prime fields or new ways of like doing aggregation across all these different proof systems um which now I think if you do naively it might cost more than the just the leaf proofs themselves but with um um execution uh preons what we can do is just ask the validator send the the leaf nodes right Pi 1 Pi 2 pi4 to the validator and say like hey verify these in your transaction they verify them offchain right run C++ verifiers and just include the results on chain um so we got verification for multiple proofs um in one transaction but we didn't have to do the overhead of actually making um more proofs this is also super useful um because we now do less computation overall because we don't need to calculate pi 5 Pi 6 and Pi 7 we can just calculate the leaf proofs um this is really cool for Prov networks where they all looking into how can they do a recursion and they can do these aggregation techniques across all these different jobs but what's really hard about them is estimating how much time it will take like think of it as a market where like a bunch of people submit proofs and they want one proof in the end the problem is now this this network has to manage all these proofs and it has to figure out what time is most optimal to to scheduling basically it's a scheduling problem where Pi 1 might need to wait five more seconds for pi pi4 to be generated which means that Pi 1 is paying the time cost of pi4 as well U using optimistic execution we can do greedy aggregation we can just say whichever proofs are ready right now just send them right now and then the next batch can go when they are ready um right so now this is the the interesting bit where we look into how do we make sure that the validators can't lie so we use something called fraud proof here um and who who can submm a fra proof in this case it's and the two questions that are important are who can submm a fraud proof and what is the challenge period um so who can s a pro proof anyone it's permissionless it's just verifying a proof on chain it's what we do today we just run a Sol verifier and it tells us the result uh what is the correct challenge period I think this needs a bit more analysis and I'm still working on it if you have any thoughts I would love to hear them but uh I'll give you some initial thoughts why I think this is better than the current status quo of optimistic rollups um cool so so this is kind of the pipeline that I imagine that would fold out with verification beon where we have a user who wants to verify proof by they send their transaction or their to this pre-confirmation so it's a validator who signed up to the service saying like hey I will verify proofs for you and if I do it correct correctly then I should get paid if I do it wrong I should be slashed um the verif the the prover basically the validator has a choice that do I want this reward if so I will um basically do this proof verification for you on chain and then at the top you see they sign a a receipt saying like hey I will include the result of verifying your proof on chain in Block B and sigma is this the signature so you can basically make sure that you can hold them accountable for it um so here we see that actually we get verification or like we get soft finality really quickly in some milliseconds because the time it takes for the validator to sign the message above is probably a few seconds they verify the proof offchain and then they just sign the result uh so at that point you know the Val is already committed to what they will include on chain when their block comes so the Prov already knows the result of the proof right they can also run the verifier and takes like few seconds or few milliseconds and they can be like hey I see that the validator pre-firm validator committed to vpy which is wrong it maybe it's false and then you can just instantly as soon as they pre-confirmation pre-confirmation and verification this also means that the incentive for the validator to lie is super low because it's super easy to check that they are lied because what if in this case compared to optimistic rups we don't have to generate a proof to challenge them the proof is already there Pi we just need verify it and verifying proofs is really cheap um cool so I think for for these reasons the the challenge window of of this system can be probably a few blocks uh or maybe at Max two Epoch which is like 12 minutes which is still better compared to optim rups which is 7 days or for ZK rups where the finality currently is like 6 to 12 hours we can get down the finality of zups from 7 or 6 hours or 12 hours to 12 minutes which is quite a nice step change um cool so what does the system look in the end and this is just the extended diagram what happens here is that we have some validators who like who've already pre-confirmation verify my proof uh uh pi and for doing this you will get um dollar amounts of money uh if the valid chooses that hey they will do this then what they do is when the block comes about they make sure that before including the user's transaction that includes the proof they include their transaction which includes the verification of that proof and it's kind of like a like a dictionary right basically they front run the users's proof transaction with their verification transaction and then that's how we know that this proof was verified on chain uh they also sign a re saying that hey I will do this so that if they don't do this we can hold them accountable um and I think that's it um we working on like a working problem implementation the system is actually quite easy um it's a few smart contracts and a few side cards that in etherum valid will run and this would allow them to do this verification make some more rewards uh provide new services to ethereum ecosystem any questions yeah uh yeah so so the question is what happens if if they if the the chain is reor basically the validity was true it includes this transaction but it reorgs so that's a really good question what should happen like the I think um what should happen is that there's systems basically where we can prove to the smart contract that the chain reor because you can show that there was two forks and the valid and was like was Voting in the correct Fork um they were reor we can also use external finality gadgets so so some different chain could basically record the finality right and let's say we can use T for that chain and it records sayy I verified these proofs and even if ethereum reog you can bring those results back to ethereum in my opinion reorgs here is less of a problem and it's probably a system of ethereum as well we can kind of work for single soft finality where rups is supposed to be derived from from ethereum in my opinion so if ethereum reorgs the RO should reor um yeah I agree that we should it's bad ux but this is the definition of a rollup in my opinion if the rollup has its own finality layer then it's closer to a side chain you have question I'm ussy wees the user to be oper yeah the user can be like anyone it can be roll up operator it can be a co-processor or it could be a user facing app as well it could be like a like a decentralized identity solution where the users generate the proofs like locally on their browser or it could be R it could be anyone really yeah yeah is dat structure true or false like it's either true or false it's Boolean okay basically validor and I see yes yeah and the important thing to notice here is that that the proof like we use ethereum for the data availability the proof is still available onchain so that people can challenge it if he is completely offchain right where like the valid verifies it onchain just puts the result down that's not good enough because he could hide the proof himself and then no one can challenge it in this case the proof is on chain so everyone can see hey this is the proof and now they have incentive to challenge um naively I would say go back to this slide naively I think the cost of this like like let's say it cost 300 gas 300,000 gas to verify your proof on ethereum right now naively I would say this should cost like one over million 30 300,000 because ethereum is million validators and your gas is paying for all validators to run the transaction in this case only one runs it so it should be like a million times cheaper um I think more need work needs to be done where you basically need to incentivized challenges as well so you need to be a bit more than just the cost of one validator verifying it you need to kind account for what would the challenges make it's like a repeated game if I keep playing this game over two weeks what is my expected payoff so you can encode some error value and say like hey you pay by this much margin so you incentivize Challengers to challenge it cool um any other questions cool okay it seems like everyone gets it and everyone's going to be implementing their own versions of this tomorrow uh look forward to like billion implementations um thank you [Applause]