How EIP-4844 Will Affect the L2 Rollups | Jordi Baylina, Polygon | ETHTaipei 2024

hello everybody uh well I am J Vina I'm the technical lead at polygon ckvm and uh today I want to talk a little bit about the 4844 at the end of the presentation I will speak also about other things that we are doing in the team but uh 4844 I mean it's a it's a really important uh EIP in ethereum because actually uh take off enables and take off the the data availability the data availability race um what's 4 a44 the 4 a44 the idea is the introduction of these blops I mean a blob is uh about 128 kilobytes of data that uh they go directly in the consensus so you can put this data and make it available okay this blob are going to be available only for uh about 18 days uh but this is enough for anybody to capture that and this is enough for rollups to scale as you know in rollups there is two pieces that are fundamental to scale one are the ZK uh proof the validity proofs and the other is the data availability I mean data availability is the important one okay so here um well uh as you know e 4844 uh started in the last Fork that happens uh less than two weeks ago okay and well this is uh internally how it works but this this is the evolution of the last day so since the day started of course the first day everybody was excited and people probably was testing and so on but here you see the quantity of uh uh uh information that's that that's about 10% it's about 10% of the capacity uh of the blobs actually it's not the capacity it's the standard capacity um in a block uh it can be up to six uh blobs but uh the price stab tries to stabilize at three blocks okay so you can you can see that there is three blocks currently this can scale maybe in the future but this is how we are okay and right now is 10% and I would say that uh not all but most of the rollups um already are using that uh the Z rollups uh we are a little bit more in the delay we will see later why because I me implementing the this AIP for the Z rollups is a bit more difficult that uh for optimistic rollups but yeah probably uh the remaining teams in the next month or month and a half will will have but what we will see here is that we are very much below the capacity okay and that means that the cost is uh even much lower than what was expected right now um sending data with a blob is about 16 times cheaper that it was with the call data with that availability okay and this is we'll see later that this is the main driver for the cost of a transaction so this will have a huge impact in the user in the user in the L2 transactions in the cost of the fees all the user transactions okay a reminder okay ZK roll up uh the Prov is not the bottleneck right now generating proofs in in in generating proofs is really really really cheap okay and really fast is are reminding numbers with in less than two minutes we can in less than two minutes in a in a big server in a server that's about $1 per hour um we can generate about 10 10 10 million gas okay and if you do the numbers the cost per transaction of the proof is really low and they can be um uh they can be spined up in parallel so if the if the network grows uh if the network has more more transactions you can spin up more Pro proofs and and you can generate these proofs in parallel so Pro is not a bottleneck for ZK rollups so what's the bottleneck well here are the different costs that we have we have data availability of course sending data this is the main topic of the 4844 so putting data on chain is expensive but there are other other costs here sequencing for example while you need to generate a transaction that actually put the this data there so there is like a kind of a fixed cost well it's a variable cost because I mean for each blob or for each set of lops you need to pay the transaction the transaction fee of the transaction and do some computations inside this transaction so you have this sequencing part uh we have the the proving part as I mentioned Pro is still a cost but this really really low cost okay and then we have the aggregation agation is very much sending sending the proof on chain the cool thing of this is that this um this proof is quite a fixed cost right now we are sending one proof every half an hour so these are relatively fixed cost and the good news is that polygon 2.0 all the proof can be all the proof of all the chains of all the CK of the chain can be aggregated in a single proof so the cost of the aggregation uh can be really really low when the system when especially when the system scales okay um well let me just jump here so this is the mean this is the normal ERC transfer so this is the cost before the iip 4844 you see that most of the cost it's important to check not the not only the percentage but also the the re the the the the real I mean the real cost I mean that availability when you are doing a e transfer again this depends on the gas price and so on but more or less is 30 cents in a in in in a in an L2 which is you see that's most of the cost is this thata availability what happened after thep 4844 well you see that this is reduced a lot still is like 50% of the cost is that dat availability sequencing can be done some things to optimize you see this yellow thing this is the proving cost is really really really really really really small and the aggregation again uh if the system is scale this kind of a fixed cost this can be reduced a lot okay so here we see the the the huge Improvement okay but the good news is that uh thep 4844 in the rollups will not come along okay when we are putting U um compression and here well there is like two types of compression normal compression which is very much for example what uh I think most of the optimistic rollups are using that just doing a kind of a zip I mean a normal compression algorithms you can reduce not much maybe like one and a half X because the data is very have a very uh low entropy uh but if you are doing stateful uh compression mean that's you do that in a in a more intelligent way you can do an extra 7X on top of that so altogether so you see that well that availability is still the cost here I apply also that the fact that you are compressing the fixed cost so the fixed cost for the sequencing and the a uh and aggregation is is is more is is lower too but you see here important to see the cost the absolute value of cost here we are uh see that with both things we are very much below a 1 cent uh per transaction Inc uh 20 this I mean this is makes me feel very optimistic I would say that uh with these numbers um prob validium most of the validum will make no sense I think that most of the validum should think in really being real rollups and putting that availability uh on chain uh uh with this cost uh with this cost and also we are starting the IP 484 four so this is the first iteration where is there is only three blocks here we can expect that maybe I mean in the in the next car Forks maybe this can be increased to I don't know six 10 blobs easily and when there is full sharding uh then uh having a 50 100 uh shards is perfectly possible so somehow the data availability here we see a path in ethereum that availability will be solof and it's not going it should not be a a a limitation of course this depends on the market depend on the applications if there are other applications that happen but we see that the the cost for that availability is going to be really really really low here the just to this is the what you can see here the number of transactions that fits in a in a blob okay just to give you an idea of what's in a blob okay so let's see what's the well here of course if you are interested here there is a if you want to check and and and deep a little bit in the blobs there is this tool about the blob scan where you can see the blobs that are happening there is a lot of libraries for sending blobs there is a full tooling that's happening with The Blob with with the with the blobs itself okay so let's go to the little bit to the detail and what's the the issue or what's the the specifics of the implementing the E 4844 in a ZK rollup well the idea is that so this data is available but actually it's not uh so it's available that anybody can recover this data but it's not available from the smart Contra perspective when you are calling blob what you have access to is to a commitment of this data kind of a hash of of of of this data actually what you have is uh well this data is actually is this 4ou 4,000 um 48 uh values this are finite field uh values and this is a a polinomial these are the evaluations of a polinomial of degree 2040 4043 okay and so this is generates a a polinomial and the difficulty is here okay so we have this this polinomial where we have only the commitment and we have a proof that actually using the data of this blob but we need to be sure that whatever is committed is actually what we are using in in in the data so who we guarantee that the the data that's committed is the actual data that's used in the in the proving in the Pro and we are not proving something else well the trick is very much this explain you the big the big idea the idea is there is a kind of uh F Shamir interaction protocol that's converted to F Shamir but the idea is that um this commitment um we have the tooling that we have in the smart contract is that we have this commitment and we can do an opening an opening of this polinomial means that we can uh evaluate this polinomial in a given point in a in a a random point we can choose in the smart contract we can choose okay I want to evaluate in the point 43 and then this evaluates to uh B of C is number okay so uh what we do is okay which point are we using for uh evaluating well we what we are doing is we are we are we are creating we are doing the a hash function a poson a hash function that's very uh ZK friendly so we get the blob okay and we hash all this function with a posidon with a poson hash function and this give us a number okay this is the point where we add opening that means that if we change the data so if the data changes this opening point is going to be different okay so what we do in the smart contract in the smart contract when we are committing to when we are sending a when we are sending a blob um we are also providing uh providing the the hash function this poson hash function as a parameter and we evaluate the opening of that parameter so we have this U we have a uh X and uh so X and Y okay so we have the point where we want to openen and evaluation and we do that in the smart contract so we know that whatever is committed uh the polinomial at this point is uh is correct so mainly what we do in the in the prer in the in the ZK circuit what we do is um well first we do the the poson so we take all this data and we hash all this data we compute this x this evaluation point so it should be exactly the same x and z are like input public inputs of the circuit so we guarantee that what that the data matches with the the X if it doesn't match then the proof the proof is not is not valid we need to evaluate the polom the evaluation of this polinomial with the data we need to evaluate this this evaluation we need to evaluate why we need to do that in the circuit this is the hardest part because we here we are Cross Field we are working with a cross field uh Prime and here we are using the well the the bicentric formula for computing the for computing this evaluation and then we check that of course this output matches with the with the Y if it does happen that means that the the data that we are using is is correct is that if we change the data of course evoluation is different and if if if I mean and if the evaluation is is wrong that means that we are using a different polinomial okay so with this we warantee that the data is is is is the same okay so but this is not all okay because I mean the other difficulty is that um this data I mean it's quite it's a fixed length okay it has a a blob has 128 uh uh kilobytes okay so we need to change a little bit the recursion structure that we had in the in the in the rollup this is the the recursion structure that we have we have batches in each batch actually we prove different blocks okay and each block each transactions but we have the basic unit of proving is a proving a batch which is about 10 million gas more or less depending the things we have a first stage of uh compression this is very specific to Starks just to reduce the the sides of the of the proof and then we have a an agregation proof I mean this is a recursive circuit that you can take from two proof we compare to a single proof or and then to proof more and single proof and we can hand of a three okay and we generate a single proof and finally we have the the final Pro we conver this a star to a snark with okay so this is what we have right now but with the prover when when we have blobs this changes a little bit we need to take little bit the same structure that we had before just to aggregate many batches of so all the batches of a single block are aggregated we have a new proof that's actually the proof that generates this uh polinomial evaluation of the polinomial here also in this proof we will put all the compression and this already prepared for the compression and other things that can happen here removing signatures and other things that can happen here or even Computing the with the pting you can avoid the having to do this evaluation uh in the in the smart contract okay so we have this this this inner blob okay we aggregate all them to the outer blob so this is a proof of a blob actually it's proving all the batches of The Blob plus this um uh inner blob and then again we aggregate many blobs to have a single proof and finally we have a star so we go from three proofs to six proofs uh uh Al together okay well this is this is this is wasn't supposed to here so for this new circuit I don't know why okay for this new circuit um mainly what we're using is we're reusing the same infrastructure that we have with for the batch proof we are using the same ZK processor that we are using we modify a little bit the arithmetic uh circuit just to work with this specific brain field for the evolution we remove some of the some of the state machines that we don't use any anymore okay but the idea is that we're using the same infrastructure okay so at the end we have a kind of a um an assembly a ROM that's running in this ZK processor that computes uh that computes uh this okay here is the but this is the the bicentric function for for the evaluation of polinomial okay so this is one of the takeaways the presentation I mean talking about 100 tax cost reduction uh is really a a fact right now uh I 4844 opens this uh data compression is the The Next Step okay so this is one important takeaway just to mention before ending the presentation that we are also actually yesterday we we in testet we're working very close withon for the zkm so that the the the node right now we will we will expect a 50x performance increased right no open source is already running in Cardona or testet and yeah and very soon we will make it that official so here the the the the throughput of the sequencer which was one a little a little bit one of the bottom necks that we had this uh is going to be solved in the upcoming uh in the coming weeks okay the other thing that we are working we are working in the bcops bov means variable degree composite proof this is a kind of um an improvement of the of the Pro System the idea is instead of working with a big monolithic proof that's a dis batch proof the idea is that uh this proof is a composite proof of many sub proofs and with aggregation you can do variable size variable variable sites proof so this allows us to uh use better the cells the I mean the the cells of the the cells of the of the pro so it's going to be much more uh Improvement and what's better this will allow us to do variable things so the me some of the limitations that we have in the in the type two that's for example if you are doing Sage cases like a loop of cats or things that you don't have enough resources in the proof to prove that right now we are checking that I mean we have like we got this idea of Z counters okay so the idea is that if you cannot generate a z counter if you cannot generate a KCK then you still have a proof so but you prove that you cannot generate the proof okay so we can we can do these things but with these B cops this uh remove we remove very much this idea because we can do variable sites of course this have we need to keep still the counters because the variable proof means that we need to charge so we need to pay the the the pro according to the difficulty of the proof so we need to count but the from the user perspective they will not be limited by this by these counters so that's that's why also this this bcops is import is important okay and of course we are working a lot I haven't talked in this presentation but we are working a lot in the polygon 2.0 uh idea the CD case and the aggregation layer that we presented very much just a word here is that all the ZK proving all the all the ZK proof is fundamental for uh this composability between chains I mean we are targeting in the aggregation layer uh not now but in the next version to uh have a composability between chains uh of less than 10 seconds uh in in in in between chain Atomic transactions I mean there is a full topic that we are really working hard on that this is a little bit the road map that we have again this is not a commitment this is just or or planning that that that we have but I think is is U it's saying to to to share what we're doing right now we're on boarding a lot of uh cdks right now uh we are working really hard in the 4844 right now we are integrating the the 4844 after the 444 very much we will start with that uh compression in parallel we have uh Aron the Aron RPC and Aron sequencer that's working parallel and there is another team that's working in the pill two but cops let's see if by June by June we have a first version of that this is quite Advanced by the way so we hope that this is doing good progress and of course the aggregation layer is the other path that we are working hard uh from in in inside polygon so that's very much my presentation thank you we have questions we have five minutes for QA time does anybody have any questions okay thank you for thank you for your presentation just wondering for the aggregation layer do you guys plan on I guess opening up the network to a network approvers or what's the road map for yeah for the the future of Prov yeah so right now what we have is uh we are aggregating so right now what we have and we will enable so everything is done uh but we are very much in the in the auditing phase but what we will enable very soon is What U what I mean agregation of the proof the idea is that the cdks they can they can send the proof themselves but they can also send the proof to to to to a sing centralite server and they will be aggregated with many other proof and a single proof will generate uh single proof this I mean this is the version uh this is the version the the version two in the version one is just the what we have right now is the the lexel y bridge so you can you can already transfer between chains and you can transfer okay but you need to White um but but I mean you all the chains they need to generate their own proof so version two is this and the version three this is the one that uh this is the one that uh we are working uh uh really hard I mean it's a more complex project but the idea here is me explain you the the big idea here of the of this aggregation layer the idea is um that um another chain in order to use the funds of a single chain is not necessary to have the proof of course you have the proof that this state is the commitment and the proof that this state is is valid they can already use it but if the other ch can generate the proof they already can use the proof because the idea is that if nobody gener sends the proof of the chain a that's you're relaying the chain B can um send the proof so they can guarantee they have a commitment and they guarantee that the other chain is having so that means that um a chain that's following another chain if they can generate the proof they can uh generate of course this scales bad but then if you wait for the proof and you have faster proofs then uh you just don't need to follow the chain you just can follow the you just can have the the proof this has a I mean it's a full topic there is a dependency problem this a chain can depend on various chains and then you need to solve these dependencies this will work in a it's not really a blockchain because it's scals much scales much better but a kind of a blockchain just to coordinate these things okay and this blockchain also will have all the all the all the incentiv I mean all the all the economics for the proof building and uh uh all that and uh yeah and also will coordinate the aggregation of the proof and we generate the proof with two two to main n okay so this is very much the the the the idea of the aggregation layer mean it's a full topic but this is the the big idea do we have more questions thank you um yeah I had the like when you were showing how you build a Fiat Shamir um yeah think it looks only I mean if I read the slide correctly it uh seems that you're only using the blob as the as the source of the Fiat Shamir well this is It's a summary but the it's a summary but the idea is here okay but the idea is that the the smart contract uh well the the the so there is like smart contract send uh to the to the mean the smart contract sends to the pr the the the the the kcg of the block actually is uh okay the the the verifier sends it zit is the is the is the hash function of the data right so you cannot so you send the data and here is the hash function you send the data so okay you need to open to this point and then uh you do the opening so you you have to pre-commit to the blob before you get the yeah the commit is happens in the the commit happens in the in the in the smart contract so a blob happen you already have a data and there is a commitment it's a casg commitment that's available in the in the in the block so you there there is already commitment of the data okay so you send this commitment to to to to somehow to the data so that's the the idea actually I mean you're doing a step ahead okay because it's I mean it's F Shamir okay but the idea is U the idea is okay because you have the data you have the hash of the data you know the hash of the data okay and this is the the random opening the random opening Point okay so this is in the smart contract we do this opening so we guarantee that this opening in the smart contract uh matches and we do exactly the same in the we do exactly the same in the in the in the pr so in the pr we do the hash also the hash function so we compute like a verifier I mean we we are verifying this in the Pro I mean it's verification of The Blob so this a verifier but in the in the pr side okay so uh so I mean theidea is if you if imagine that data changes okay then the F sham the the the opening will change and because so the Z and so the opening and the result of the opening is a public input of the circuit right okay so right you are when you are proving when you are proving uh so when you are proving so you need to guarantee that this opening that you are in putting in the public input actually matches right okay yeah but this is computed also in the in the in the in in the in the smart contract okay and uh yeah and and you also need to check that the opening point is the hash of the data so with that you have the hash of data you have the poson and this is poson is actually pass it to the B processes actually to I mean it's not it's it's like many B many poons it also many poons for the different batches that's more detail but that's the idea is this the idea is that you need to do an opening so you need to compute an a point evaluation inside the inside the inside the in inside the circuit thank you Jordy thank you very much