Proof of Efficiency: Decentralization for the zkEVM - Arnau Bennassar (@arnau_eth) @ETHDubaiConf

Transcript

yeah so good morning i'm marno ben nasser working at polygon hermes and we are with building a ckvm role app that is compatible at opcode level and today i'm going to talk about uh consensus for roll ups yeah so i'm not going to fully explain what a zika roll up is but let's go through some basics just for the sake of this presentation so essentially uh zika roll up it's a smart contract on layer one on ethereum and this smart contract holds the different blocks that we actually call them batches to not create a further confusion and so these batches contain basically a list of transactions

and then a root and the root is basically a hash of so like the entire state compress it in into a tiny amount of data but then again like the main idea of relapse is to do not have to execute the transactions on layer one and so that's why we have the zero knowledge proofs which actually take the previous route or the previous state and demonstrates the outcome of processing the transaction list and hence the layer one can trust that the route is actually corrected and processed correctly yeah so how are those batches added into the layer one so definitely we need an entity that we call the rollup operator

and this operator basically collects the different transactions from the different users like the layer two transactions it builds a sequence like it order the transactions into a specific sorting and then it generates this zero knowledge proof once we have that we just have to send to the layer one the zero knowledge proof and the transaction list and so this is how a new batch is added and while this sounds pretty nice it actually has some problems that i'm just gonna explain now so first of all this is quite slow because generating zero knowledge proofs it's very intense intensive in terms of computers and and even if you have a huge machine

it will take some time hopefully technology will get better and it will get faster but still definitely we are talking about of minutes in order like in time scale the other tasks are relatively fast so it's basically um building the zero knowledge proof and sending the layer one transaction and then it's very easily to fall into centralization it doesn't have to be but because euro knowledge proofs takes a lot of time to be built and to build such a proof you need to understand what is the previous state the previous block like imagine you are computing this proof and by the time you're done someone else

have sent another batch to the layer one so your the zero knowledge proof is no longer valid so you have collisions and like you're wasting a crazy amount of resources but still the cool thing about the zero knowledge proofs is that it makes the whole thing trustless because it verifies the signatures and so on which means that this operator cannot perform any action on behalf of the user however definitely there is some censorship vectors here and the network could just be stopped if this operator falls down so in order to solve this we came up with this consensus protocol that we call proof of efficiency and the main idea is to split

the sequencing from the proof generation and that actually enables a permissionless system that anyone can participate so um now the smart contract in this protocol and requires to manage two different states the virtual state which is actually just the transactions only the list of transactions and then the consolidated state which is uh adding the root so proving that the the outcome of processing the transactions in the virtual batches so actually the virtual state is quite cool because

since this is available on layer 1 anyone can synchronize this so you could have your own node and understand this uh this state update without the zero knowledge proof at all so you basically read the transactions from the layer one you process them and then you have a node that understands what is the state like the outcome of processing the transactions and this obviously happens way faster that that if you have to to care about the zero-knowledge proofs um so then like this lab operator i was mentioning it's also divided into different actors first one is the sequencer and so the sequencer just collect the transactions sort them and send it to ethereum and as unlike as i

was saying this doesn't require to build a zero-knowledge proof and hence this process is quite fast i mean it's very close to layer one transaction fast which is actually the better thing that a roll-up has to offer because i mean the roll-up is still inside layer one um so we will not get faster than that at least not in a super trustless way and besides that as i was mentioning this system allows for permissionless so anyone can participate at the same time the reason behind that is that these transactions that we are sending um

don't know or don't care about actually processing them it's like indicating to the network like hey you have to execute these transactions but you don't need to know the previous state before sending the transactions so here in the example we have three sequencers that they are all trying to send these transactions and when they send these transactions they don't know at which position this virtual batch is gonna be added so it may be the immediate next one or it could be like further on and by doing this because the system is permissionless we effectively effectively decentralize the network so it's no longer longer stoppable

because i mean you can just i mean as long as you have access to to ethereum you can keep adding these transactions and also because of that this became um censorship resistance like even if some sequencer was bullying you and blacklisting you and you could became a sequencer without asking permission to anyone and just send your own virtual badge into the network and you may be thinking then why to bother with gk at all right i mean ga is very complicated and and it seems that we have everything well this is not exactly the case uh because the layer one doesn't understand the the the outcome of processing these

transactions and because of that it also makes hard for the for the users for the node operators to know that they are actually in consensus so how could if i host a node how could i know that everyone is on the same page well if we have this zero knowledge present we have the root on ethereum and i can just check if the root that i have built actually matches with the one on layer one and by the way by having this and by this i mean like the layer one being aware of the state on layer two we can build very cool things such a on chain bridge that relies exclusively on smart contracts and like we will have heard like super sad news about bridges getting hug

but if we are able to rely on smart contracts this gets more secure and by the way there is a very cool presentation by jordy valena explaining it if you are interested you can just go to youtube and and search for jordy bylina at lisconn yeah so how are these batches actually consolidated well um again like the batches are on layer one so we have a new actor which is the aggregator which will synchronize the virtual batches to to know which transactions are involved in the in the proof that has to be generated and once the aggregator has that it generates the zero knowledge proof

and it just sent to to the layer one to ethereum and effectively consolidating the virtual bytes so we move from the virtual state to the consolidated state unfortunately this doesn't place that nice in terms of concurrency because for each virtual batch we have only one proof and so the first one who sends the proof is the one who actually consolidates the badge and so here what we expect that will happen is that the the player the the aggregator that has the best technology and will end up winning all the time

because uh this is not like proof of work that has some randomness built in this is very deterministic so if you have the the best hardware the best software you will end up winning always but this shouldn't be a problem because at the end of the day what happens with zero knowledge blues is is that either they are correct or they are not if they are correct the network moves on if they are incorrect the transaction just gets reverted and has no effect on the state and like even if we only had one player and this player just disappeared for some reason anyone could come in again and became like another actor that still makes the network move forward yeah so the overall picture looks like

this we have the sequencers uh sending the list of transactions that has to be processed and they can make it in a concurrent way so it's quite safe and and fast and then we have like the aggregators trying to have the the best technology the most efficient technology and consolidating these blocks or batches sorry so you may be wondering why should people actually

participate on the network right i mean where are the incentives and here what happens is that sequencers collect transactions transaction fees sorry so the gas paid by the users and so they are incentivized to build the most profitable watches which means uh whoever is paying the gas at higher cost and and whoever brings more transactions in a single batch but then uh what's in him for the aggregators well the sequencers have to pay a collateral and which is a reward that will be collected by aggregators later on when they consolidate the proofs and here what we aim for is we don't have the final formula yet but the idea is that the more unconsolidated batches there

are the most expensive is this collateral and so the idea is that eventually we get into a stable point where there is no big delay between the virtual and the consolidated batches because i mean it would be horrible if nobody is consolidating batches so if apparently nobody is doing that sequencer will just have to pay more more tokens in order to to be able to be allowed to to place these virtual batches in the first place okay here's a bit more tricky stuff more in detail but this system could face a front-running attacks meaning that if you're a sequencer sending these virtual batches

someone could read this transaction from the layer one pool just pay more gas and make it before and so effectively the the next batch like the honest batch will get fully invalid because uh the previous one will have processed all the transactions and and so the second time they will be just invalid so in order to solve that what we have done is um we assign a different chain id for each sequencer in a way that transactions are only meant to be included by a specific operator a specific sequencer so if anyone were to front from run this these transactions will be just invalid in particular the signature would not match and so this will not have any effect at all in this state

and by the way yes it's a different chain id but it's still the same network so you are not losing interoperability or anything like this it's the same chain okay so like this chain everything actually opens the door for new constructs that are quite cool basically because because transactions are meant to be included by a specific sequencer um anyone and then and anyone can become a sequencer right so what could happen is like you have an app and you instruct your users to use your own sequencer which by the way right now is quite easy to do i mean you could just have a

button on the ui and then multamask pops up and say hey do you want to switch to this network and well users say yes and what this means is that the fees of the transactions of a specific dap will be collected by the dap itself which in my opinion is great because sometimes it's hard for that developers to find a revenue model or they have to come up with tokens that may not be very obvious in terms of utility but by doing this they are now able to collect the benefit of of this fees so if you are at that and you are able to bring transactions to the network you will be rewarded by doing so and by the way um being a sequencer it's uh

quite easy in terms of requirements you need basically a layer one note and a layer to node and that's it you don't need crazy hardware you don't need a crazy staking so the entry barrier for achieving this is quite low and this is probably like the most basic use case that we can think of but then things could get more complicated and more interesting for instance i imagine if you have like a nft marketplace that it that it already has great revenues by having a cut of the of the cells and so this um this gap what could use is i say okay i already have money and then now i'm able to make transactions free for my users and

so the logic would like if the transaction is directed to my smart contract i will accept it and i will accept it with gas fee zero because anyway i will later on be taking profit off of this nft cell or whatever and i mean this is probably not as easy as i'm explaining it there are more challenges here but we are starting to think on these different use cases that uh i mean we're excited to see what people could bring with this model and yeah that's it guys so maybe now we have something requested thank you very much um yeah uh any questions from the audience

[Music] okay thank you from could you return to the slide with uh different sequencers so when the different sequences are trying to send different transaction lists yeah these ones so um what will happen if two sequencers will send the same transaction will include the same transaction yeah absolutely so this effectively can happen and what will happen is that only the first one will get executed because at the end of the day executing transactions is deterministic so

like this is bad for sequences in this case because they will they will be including a transaction and later on will be invalid and definitely sequencers would have to have a kind of logic to avoid this so um like yeah like you have to take care of it and and maybe um try to ban bad users or whatever but like this will only happen if the user is malicious in the first place because i mean like if you are sending the same transaction to different sequencers you are clearly misbehaving here so this is a risk that sequencers have to manage definitely um and it's a potential attack yeah

but do you already have the implementation of this sequencer or not yet okay so we are right now like developing like crazy uh full speed and like the ziggy vm is not ready yet but i should be relatively soon okay thank you very much and also i had i was a little bit confused about the part where like there is one validator that's basically doing everything because of the compute power um why exactly um can't he just like add some transactions that are malicious they always verify them and basically be like the main chain

okay so here is where the zero knowledge magic came into place so basically what you have is a an op chain computation that cryptographically proves that the transaction has been processed correctly but then verifying this on layer one it's super cheap and fast and so part of this logic that happens in our knowledge realm it's uh to verify signatures so but uh you would tell in so there are sequencers and then validators however aggregators so the aggregators are doing the zika stuff is correct yeah yeah but but they can uh manipulate not the zk proofs but manipulate like what

the blocks that they included over there yeah okay so the idea here is that uh because uh the list of transactions that has to be processed it's already unchained so they have to wait for this data to be unchained and then the smart contract ensures that only this data that is unchained is actually processed in the zero knowledge proof but if aren't there going to be competitions in like those batches that are already on chain or do you trust that all of them are non-malicious like how exactly does it happen yeah okay so um yeah so sequencers uh send transactions but there is actually no check at all at

layer one so you could send like even a picture of a cat there right i mean you can basically send whatever you want but the thing is that if you send like incorrect data incorrect transaction this will have no effect at uh at the time of processing it so as i was mentioning like processing this list of transaction have a deterministic outcome and part of the checks that are done is like is this transaction correct um yeah okay okay interesting but anyway like the guy who chooses okay i need to do more research probably before making any questions uh i have a question uh so how this

consensus algorithm is how this consensus algorithm is like different from the mean as one so where the sequencers or the block producers are chosen for by the vrf functions and then the snark builders are like doing the like the snark work so the only reason that i'm getting here is that you are not answer sequences are not staking here so what's the difference between like pros and cons and why this yeah so i'm not fully aware of what mina guys are doing but basically here is permissionless meaning that you don't require any permission at all to participate it's kind of first thing first served

and and yeah you can just go in and as fast as you can any more questions probably not thank you very much yeah thank you that's really interesting you