# How EIP4844 Will Affect the L2 Rollups | Eduardo Antuña, Héctor Masip - Polygon

- Channel: [Ethereum Denver](https://streameth.org/ethereum-denver)
- Date: 2024-10-09
- Duration: 20:14
- Topics: blockchain, web3, ethereum, Entertainment
- Watch: https://streameth.org/watch/yt-sU2OHndKVQ0
- YouTube: https://www.youtube.com/watch?v=sU2OHndKVQ0

## Description

we explain how ZK rollups will benefit from EIP-4844 to reduce the prices for L2 transactions. I'm going to dive into the challenges to implement this EIP. I'm also going to talk about data compression and how it complements this EIP.

APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN


APPLY NOW
https://ethdenver.com/apply

## Transcript

hello everyone um well I'm Eduardo his sector we are not Jordi Jordi is over there we switch our talk but uh mainly the topic is the same we are going to talk about uh how the AP 444 is going to affect rollups and as most of you know this is going to be the end game for cost uh transaction cost so we are going to give kind of um overview what that means for secet robs uh I going to make a kind of a summary and put some numbers in the table later on ector is going to explain how this affect to to our rollup so let's start by talking about some key points about the 4844 the first things the first thing to know is that um right now currently chikar are using C data to publish uh transaction data or state diffs and now we are going to switch to a new paradigm in which we are going to start to useing blobs for publishing this data so each block blob uh it has available 128 kiloby of data uh we are going to have six blobs per block and one important thing especially for note operators is that uh The Blob is going to be only available during uh 18 days mainly this is to not blow up the hard drive space of validators uh and that means that probably we are going to see how uh AR BLS provider are start to happening because if you want to have this data after this this time you need to ask to this provider for that for the data an important thing to mention also is that uh we are going to move from uh 70 17 gas per bite to three gas and mainly this is the main benefit of this and another important thing to mention is the fee Market the the fee that you are going to pay uh using blobs is different to the fee that uh is computed on the execution layer here we have um um schema basic schema how this look like um we still have regular them transactions as you can see here but now we are going to have a new type uh of transactions um the the data transaction that contains a blop and these blops can be um verifi on chain due to the commitment actor is provide is going to provide more information about that so yeah the first things the first thing to know when we talk about H the the data cost of transaction is the the pro usually people believe that the pro is about a neck neck in terms of cost but I've been talking about this since last year Pro is not the bottleneck anymore uh you can repeat with me Pro is not the bottleneck um as you can see the cost of a transaction is quite quite neble and this is some numbers of our current Pro it takes 2 minutes to make a proof of a batch a batch is more or less 500 transactions and we are going to add a lot of uh improvements on on on our proven system like backups and other things that probably is a topic for another talk not for today but that is the key point that the pro doesn't represent uh the most part of the cost of a transaction so what what uh what are the costs of a transaction then so we have four costs here we have data availability we have sequencing we have Pro and we have aggregation the is paid per uh for every bite Poston chain sequencing is when you publish the transaction on L1 and you need to pay this Con constant L1 transaction but is shared among all the batches that you are submitting to the network then the Pro cost is constant Hardware uh cost and is for each proof computed and finally we have the aggregation that is also costant like the sequencing and sharing among all the sequences aggregated um not don't get confused by the this um scale is this is we will see later on but uh it's just kind of um Glimpse that the data vality is the most important part on this cost so this is our current numbers um before going to the 4844 we are paying a 16 gu by C data and uh well as as we prev mentions we are going to use 128 kiloby for sequencing these batches uh internally in the CBM we have the C counters mainly this is what limit us to group transactions um and the thing is in with backups in the coming months we are going to remove these counters but at the end it's just a way to um make groups of taction that are being able to be proven um taking a look to this number as you can see for instance uh 350 E transfer is um around 39 K bytes per batch and um well you have that you can see here that depending on the on the type of transaction we need to submit more or less data on chain and uh finally you can see more or less how many transaction we can include in just one block so for instance we can uh submit the data for 1,127 transactions in the case of f transfers or 3 around 350 in the case of Unis swaps it's important to mention that obviously well the price of e for these estimations is well some time ago but um obviously the the price of ether has an impact on the price of the transaction on L2 so let's put real number here right uh this is what we are paying currently currently we are paying the 95% of the cost of submitting transaction to L1 because of the data viability if you take a look sequencing is just a 4% the pr is enable and also the agregation so this Pi represent more or less where are the costs and and why this is so important the thing is with uh the 444 and this uh etherum rollup entric Ro up that we started in two in 2020 uh we are decreasing this around three 7% uh three seven times less um and that is why this is the game for transactions conses for rollups so for instance well it's hard to see but I will try to explain it this is an encription scription of The Blob scan um I our site in which you can take a look to the blops that are happening this is for instance uh something in sepolia and here even it's hard to see but um mainly we have uh I gr five blobs it's uh one is uh is not in the screen and uh the thing the the first thing that you can can see here is the the free market price the thing is if the P if you include three blobs in a in a block that mean that the price is going to be constant if we include more than that the price of the the gas price is going to increase and if it's less than three the gas price is going to decrease now it's hard to know what is going to be the price that depends on how many rollups are using blobs but uh we expect at the beginning uh the price is going to be really really low um another important thing uh to to see here is that if you take a look to the blob as called datag gas that is this this thing um you can see that is uh seven times less that if you use SC data and that is why is so important this for rollups and now ector is going to give you more details about how this affect our system hello okay H let's start with the funny part uh so to be slightly more specific at dat plop well I like to see the DAT plop as a as a vector of field elements Each of which are over the BLS scalar H field order and the the vision I like more is seeing these elements are ring evaluations of a given polinomial under some sets of prein values in this particular case are the is a set of root of unity but also it's important to notice that from the from L one we are not we are not going to be able to access any elements in this Vector but the only thing we are going to be able to retrieve H from any smart contract is uh through this H through a new OP code which is called blob hash okay and it will basically give you the Share 25 F of the commitment of the polinomial that represents this Vector okay and only with this information we are going to be we need to be able uh to prove to prove or to be H yeah to prove that H what we are proving of chain in L2 is the same that what you can retrieve in L1 okay so the the the main issue here is that in in L1 you are forced to play with what you have in particular you are forced to play with the KC commitment over the BLS but in L2 we do whatever we want we do whatever it fits better for us okay and in particular we are not using the KCC commitment but we are using our Ro proven system so in some sense we have to we have to fix the inconsistency between what you have in L1 versus what we do in L2 okay and we will see that thanks to a new PR compile that we will be introduced in this AAP we uh we will be able to fix this inconsistency okay and well in particular the trick is well known to to fix this inconsistency which is called proof of equivalence protocol okay and basically the idea is to prove that what you have committed on chain is the same as what you commit of chain in L2 okay so basically approver sends to a verifier the two commitments okay then for sure this protocol will be not interactive at the end but just to I think it's more intuitive in this interactive then the verifier will send uh unpredictable and random point and then the proy to do is to prove that the evaluation of the of the polinomial of both committed pooms and under this point are the same in both cases okay that's why he's sending back the evaluation and both proofs okay and trying to be slightly more precise in how we are going to work with the Gip so basically the the idea is that first we we we are going to compute offchain everything that we need H for proving the correctness of the kcg commitment okay so basically we are going to be Computing the random Point as the linear posid or the information inside the blob okay this is all offchain and then we are going to compute the proof and the evaluation okay and this is the information that we say on chain okay at least in the first part of this data flow and basically the smart contract what we'll do in the first instance when we sequence all the batches is checking that this information is correct okay so it's like a f guarantee that what is h on chain is what we we like to prove in the in the next step okay and in the next step is where we th all the word loged in the L2 okay so it's more or less the same but basically H we are going to use our proving system to prove that Z so the random point is well computed meaning that is the linear posm of the information inside the blob and not only this but also that evaluation of the polinomial that represents the BL BL is precisely what we have verified in step one okay so basically if in the next step when we prove that the batches are correct we are able to verify this proof that will mean that well not only that the the the evaluation is correct but also that that uh it concd with what we thought in the previous step okay let's see now the proving architecture okay so this is more or less the summary of the architecture that we have from from the proving perspective okay not notice that H well basically what we do is we prove the corrent of one batch of transactions but not only one but using H using aggregation we're able to verify use by sending one transaction just by sending one proof on chain that all the transactions inside all the batches are correct okay and we basically aggregate all the proofs in what we call the aggregation stage okay and this is what we have right now but now with the AP 444 we will need to include the proof of The Blob okay which is the proof of the correctness of the evaluation and in particular what we are going to what we are want to change from the the previous architecture is we are going to cut off H after Computing all the aggregations of all the proofs of all the batches and in this point we are going to introduce the proof of The Blob okay we are going to introduce the proof of The Blob which is the proof of the corness of the polinomial evaluation and we are going to aggregate this proof with the output of the previous aggregation okay this is what we call our inner block prover and then not only we are not going to stay that but we are going to also agregate the proof from one blob of a set of a set of batches to proofs of other Blobs of other set of of batches okay so uh at the end we are just going to send up one transaction 12 one proving the correctness of many blocks that points to many batches okay and well just going a little bit in inside the details these are going to be the public inputs that we are going to add to the inner block prover okay there there are more of them but just H to mention a few relevance we have uh the blop State Route and the new State Route blob State Route sorry and we also have the accumul input hash which is important because here well the accumulated input has basically is it's like what relates one blob to another one like like in a blockchain okay we are going to relate the previous blob with the next one and in particular here we are going to be able to decide if we would like to go for the AIP for F4 or not because for example let's say where we have a period where the blob cost is much much expensive that they call data call data a price so here we will be able to decide if we are going to keep putting things inside the blob or we prefer to for a short period H come back to the C data solution okay and in the in Blob we have all the public input related to the to the to the blob itself but then here in the in the OU blob part we have public zut not only related to The Blob but also to the h to the set of patches that you are proving okay so here for example you can see that we again have the block accumulated input high but we also have the state route the new one or the old one okay it's basically the state changes that you encounter where you when you process all the transactions inside the blob okay and well in order to prove all this stuff uh our solution was to create a processor that is able to to interpret all the let's say stage State changes that are done H due to the transactions inside the inside the batch okay so basically we have like a jiga brain okay which is what we call our jkvm processor H which is avable well we we we design it like in a distributed manner meaning that we are not encoding all the logic inside the inside the same processor but we are Distributing them among different Co processors okay for example we have a part that deal with arithmetic operations we have another part which deals with binary operations for example and and uh well the let's say that what is able to do and what is not able to do this main processor is thanks to H the r part of this processor okay this was the all processor but remember that I tell before that uh The Blob proof is in some sense independent to the to the batch proof so we needed to create h a new processor which uh in principle it can be thought as a subset or yeah as as a subset of the original processor so for example in the left site we had some a specific machines or a specific coprocessors to deal with padding operations and cimp operations and here in the new processor will which which will be much shorter than the original one we will have just a subset of the coprocessors that we had in the original one okay in particular the arithmetic stay machines will all need to deal with a with a much less equations than the original one well and finally just to give you a glimpse of how we are doing these things this is like the bunch of the comp computations that are encoded in the RM of the new processor okay and in particular as I have explained before uh the main object the main objective at least for now of this new processor is proving the evaluation of a polinomial okay and here in the upper right side we have H the formula for computing uh this evaluation and here we have the assembly code that is performing uh basically this evaluation okay as you can see is the evaluation of a polinomial of degree 4,996 which is the size of The Blob yeah finally I would like to explain a little our road map this is not a commitment it's just our intentions that just to make that clear uh well as you can see right now we are on boarding CD case on on the new aggregation layer um you can we can talk about that in the booth uh we have promoting that a lot we are working on the P 444 currently and also in parallel we are working on Theon RPC that is going to happen very soon and also we are going to check our infrastructure to addon as a new sequencer of our network with the idea to increase the DPS of the of the ckn but also of the CD case we are also working in P2 and backups variable degree composite polinomial that are the thing that I mentioned before in regard of uh improving Pro performance and uh we are developing the aggregation layer V2 aggregation layer V3 and especially also important and and interesting for this talk is the data completion we have show that how easily we can decrease the cost of transactions by a factor of three or seven or something like that but we are also going to add data compression to the data that we are submitting to the blobs and with that we can achieve um bigger Factor completion and cheapest transactions so yeah mainly this thank you for coming and if you have any question you can find out around thank you [Applause]