Introducing zkBlob and data-compression to the zkEVM

Transcript

[Music] foreign yeah can you hear me yeah okay perfect okay so I will start my name is Carlos Pinar I'm the team lead at protocol integration team in polygon and today we will work we'll be talking about a new data structure which is the zq blob and the data compression in the zkbm so what are the powers of this talk basically in the introduction I will be talking about which is how we put the data availability quarterly on chain and what are the layer 2 Associated construction

cost later on I will introduce this kind of ZK blob data structure and later on I will talk about the data compression and all the functionality that we have specified over there okay how in polygonic VM Google looks like the data availability that we put on chain so we have a Smart Control call which is the SQL watches and inside this sequence matches Smart Control call we put an array of batches and what is inside those patches so we have a bunch of transactions and those Dimensions how are they represented in bytes so basically what we put is all the transaction data encoding as LLP okay

and the signature is concatenated at the very end of this data this is very convenient to us because inside the zika circuit we already have this transaction data the LLP so it's very easy to Hash it then get the ethereum segment method and then perform the server cover the trade-off of course is that you put a lot of data on chain and this will fix it with a data compression and here I want to just explain why the cost of a layer to transactions come from I would say that there are four different parts the first one is the

data availability so you pay for everybody that you put on chain The Single part is the sequencing when you do the sequencing you put that availability but it also has a constant cost gas the third one is approver the Brewer basically is a specialized Hardware that you spin up on Well normally in AWS and then you take some time in order to computer proof and this time when you rent this specialized machine it's a big machine um then it has a cost Associated to it and the third one is when you have the proof you need to provide proof on chain so there is a Smart Control call which is the verify watches and of course this has a cost Associated

we will see later on that this cost is very small since we have Stark precaution and later on we provide the Stark in the snark which cause a lot less than the in instead of refiner Stack if you verify a snug it costs much less so basically those are the numbers okay I just did some measurements and can I showed the ethereum transfer yes which is a quite common ethereum transactions and you can see here that 95 percent of the layer to Temptation cost goes to that availability and this is very important and if you see the third row the proverb this was

the hardware the hardware that you rent on AWS two years ago this cost was very high okay and you can see now that it's almost nothing you can it's it's almost negligible and this is very important because two years ago um a lot of people thought okay this is impossible the transaction the latest transmission codes will be very high because in order to run the property it takes a lot a lot of time so you pay a lot of money and now it's no longer like that okay so we can see we can say that the proverb is no longer the bottleneck this is what we said so clearly here the datability is what we need to reduce and in order to do

that we are going to use of of course the eip4844 and data compression okay those numbers are not random okay they are computed in the following the slides but the foreign is just about numbers you can check it you have a link at the end of the presentation so you can ask me later on there are several of these uh how to compute those cost of that availability sequence Improvement and aggregation about the use of the transfer and the swap confusion swap Okay so how to reduce that availability cost so first of all EAP for info for this basically will introduce these block

transactions in the consensus layer um from those transactions basically it will reduce the gas cost provide that we put and change since it will go to the consensual layer in the block transaction and directly it will cost from 16 gas per white to three gas per White also the mechanism in order to price those transactions is different from ethereum so probably will be a little bit more than this radio the radio is uh if I don't remember well is 5.3x and also data compression data compression basically is instead of putting the whole ethereum transaction on chain what we're going to put is less bytes and those small amount of bytes we are going to apply some custom

functionality in order to recover the original ethereum transaction byte okay so in order to add this VIP for 844 we introduce a new data structure which is what we call the zika block and this SQL verb will allow to polygon CBM to quickly adapt to the eap484 once it goes to ethereum will happen in grade also inside this new blob structure what we will do is just to verify the polynomial commitment of The Blob in order to assure that the data is correct it allows more things and I would say that the most important one is that it

will allow to us to aggregate all the signatures of all transactions and make a proof in order to check the validity of the signature so instead of putting on chain 65 bytes of the Singapore of each other transaction it will just be a smart proof which is a small amount of bytes okay so this is not proof it's it's a little amount of bytes and the cost of this amount of weight will be shared among all transactions and the next cool thing is that we are kind of the coupling this I would say data parsing from the data execution we will see better in the next slide so

this is the current approach sequence watches so we have what we call the batch the bat is in charge of doing all these kind of LLP parsing is a recovered verify the signature later on it does the evm processing and we switch to this other approach once we have the circuit on the left it would be the ZK blob and the circuit on the right will be the batch you can see that now the batch it only does the ebm processing and the circuit on the left basically it will take the data and chain it will do this kind of data the compression in order to recover all the original data on the variant transactions it will do the encoding of the LLP we'll

do the AC recover and it of course it will verify that the data is correct in the eip4844 the cool thing here is like we can remove this kind of computing construction training message under the detail cover for a snark as I mentioned before okay let's go to the data compression data compression as I mentioned we can remove the signature this basically saves for each transaction basically it's safe 65 bytes which is a lot of money and then we apply we specify a set of functions it will be it's I mean with with thought in uh in a

protocol in order to apply a small set of functions very minimal in order to compress an Ethernet transaction there are different ways in order to compress data one of them is doing just like Delta States another is to apply some well-known libraries on compression but we took the path to do some kind of custom compression and for that purpose we introduce two new I would say three spasmicult restructure which is the address is the address three and that three basically the address three it's a sparse Miracle tree and it it's a mapping between an address and an index

the address occupies 20 bytes and the index it's incremental so it will be zero one two three so you can encode those index in probably one two or three bytes and the data tree it does exactly the same as the other three but it does a mapping between 32 bytes and an index so for a netherium transactions is instead of putting 20 bytes into that availability what you will put is just one byte which will be the index how to interpret that we will see in the following the slides and here basically it's all the function sets that we Define in order to do the data compression okay

so we have the first byte the three first bits of this byte defines what function to apply and then we have the less significant 5 bits which which we call the header payload so in north for example the first one in order to encode 32 uh byte we just in the header payload we put the amount of bytes to read if you want to go more than 32 bytes then we put in the header payload the amount of buy storage which would be the length of the bytes to read it's kind of the LLP encoding of the long list the third one is a small value if you want to go the small value between 0 and

31 with five feet it's enough so it is recorded by itself in the color payload and here comes the two regarding the other the sparse Mercury of the others on the data here the function basically says okay what you are going to read is the index so take that index goes to the specific tree of the data tree or the address three and then convert it to 20 bytes or 32 bytes okay so we save a lot of data here then in an ethereum transaction there is this kind of a value as price which is normally has it's a value that has normally a lot of sales so you can put

this value in a different manner like this floating Point thing with mantisa and exponent so you can code exactly the same value but with less byte then you need the way to say hey admit at this 20 bytes this address into the data tree so do this kind of mapping in order to be used later on so we have this uncompressed address 32 bytes which basically are in church to put 20 bytes in the other three and two divides to the data three and the last one we did a lot of tests of the previous one and and the last one we realized that when you encode the call data in

solidity basically you encode the selector and later on you would code all the parameters in 32 bytes but the string and the bytes type are padded to the right until 30 divides so we add this in order to save basically all the zeros that we put over there this is very important to say also that some of these functionalities when you apply those functions inside the data field of relative transaction we Pat them to the left 32 bytes in order to fit the call data they are being calling basically okay so let's see an example this is a near C20

token transfer with all the fields this is what we are putting right now on chain which is basically the LLP of all transaction fields and this is what we are going to put thanks to this data compression okay um you can ping me afterwards so I can explain byte by byte but uh basically we are producing a lot and and the field that we are reducing a lot is basically the two and the data okay because it contains some addresses so we put instead of the device just one byte which is the index of the address tree so what is the gain what is the gain if we apply data compression the the

transfer the gain is about 7.5 x the yes well and the swap on unit swap it's about 10x so we save a lot we save a lot over there and thanks to the EIP for 844 we perform a five acts over there at least I would say that this is regarding the ap4804 is a very conservative number and how it will end this is exactly the same table that I put at the very beginning so we can see here that the data availability cost is reduced automatically okay it is reduced it a lot so instead of going to a few cents you are going to 0.0064 dollars in the

case of ethereum transfer so we can say that the final value but over here I mean we are already using a lot of data compression okay and for the user basically the user will benefit from that and that's it this is the link of the slides if you want to share if you want to check all the numbers in order to get all the values that I shared at the very beginning and you can ask me afterwards if you want thank you I don't know if we have time for questions one minute one question no yeah over there

hello yeah uh just very quick question how many um or how many blocks or transactions did you test your your numbers uh when you showed seven eggs or not um how much data do you use for the experiments I mean this is uh I would say this is a standard ethereum transfer uh uh I mean if you take anything on Stanford that the data of an ethereum transfer and then you reduce it uh basically this is we are from the 111 bytes if we if you take 65 less which is the signature and then you reduce the two from 20 bytes to one then you get this 50.

all right thank you you're welcome yep okay thank you [Applause] [Music]