Verkle Implementers Call #21

Transcript

all right welcome to veral implementers call 21 uh issue 1092 in the PM repo cool um so yeah we have a somewhat lighter agenda this week uh starting off as usual with updates from any client teams if anyone would like to share anything small or large yeah I going to start uh um I've been working on polishing a document that I will share more later in this call regarding the code access gas overhead for baral in mainia transactions and uh I've been working on some

um more Focus test vectors for the state conversion from the merel Patricia tree to the veral tree um maybe I will mention a bit more in the testing part of the call and I been working on a first draft of the state conversion EIP uh which we didn't have that yet and hopefully this will help other people implement the state conversion and also have a source of Truth for test vectors um yeah adding to this I've been working on collecting uh witness size data and implementing uh the missing PRS

for for the test net relaunch and also really really busy trying to merge more veral stuff into G so that we can have uh a a test net on top of Cancun uh like hopefully before the end of the summer uh yeah that's pretty much it okay I can I can say something from bizu side um we are uh currently mostly working on on optimization concerning uh

storage in the database uh uh and uh trying to to do some of the work in in background Treads uh in terms of floating from the database so that's what we are uh and I think um some of the some of the people fromo are on vacation but they are they were discussing um finishing uh gas cust uh stuff cool thanks Thomas anyone else anything on the testing side of

things things Spencer anybody else it's okay if not Hey so uh not much from my side I've uh taken some expected time off the past couple weeks and but the same same Focus um will be placed on getting the Genesis test vectors that ignasio has been writing avilable um so that's that's the priority um I have a question um because I have a couple branches to test that I would like to to test so I know you did

the release um but I've never managed to get the release to work on my machine uh I mean this is something we already had as an issue back in back in Kenya um could you do me a favor and update the machine that you uh created for me back in Kenya so that I can just try my new branches that would really be useful and maybe make it accessible for more people uh the reason why I'm asking is because we would like to do a test net relaunch which is going to be the next topic I think uh and this time instead of going the very inefficient way of starting the test net and hoping that everybody will be able to join uh I would like to be able to

fill the test make sure we all agree on the topic and then do the relaunch instead of uh yeah hoping for the best like being sure yeah that sounds a sounds like a great idea I can um write a document on how to consume these thefts um I think currently at least the way we've been consuming them is kind of using a weird Hive workaround on um something which is unfinished on the I guess the testing framework side from us uh but ideally ideally clients should have a way to just consume the test

fixtures um very easily I think so on gu there's the evm block test command and other clients I believe have similar similar commands to consume the blockchain fixtures uh so that might be it might be a good idea to focus on that after getting the or yeah okay okay so it it'll be good for us to just have a generic way for all clients to run tests very easily I can set that up and then afterwards um I guess after the test net

relaunch we can maybe look into making sure all clients have a an easier way to consume consume the tests just like the E block test and but isn't that some issues isn't that already case because you have high so I know I understand you've got some special setup for Hive which maybe we I can help you normalize uh but because you have Hive Hive is supposed to run every client I think they support every client out there um could you just not or could we not get guess to fill the test and check that every client can import that in in turn is it not already an option yeah definitely definitely definitely

with G um so may maybe I can chime in um so that's the end goal um the way that we work right now is that uh Hive The Hive simulator it goes into the release page and tries to fetch the latest release for us um it's a little bit not uh it's a little bit finicky because it tries to get the latest release and since the worker release is not an actual release it's just a pre-release that's what we're trying to sort out right now um to get this process a little bit smoother we are working on the consume um the engine consume what it will do is basically just it's calling the

interface that g that sorry that Hy provides for us to immediately consume the test with all the clients uh this is about to be merged in the next couple of weeks I would I would assume so with this we can uh ourselves run luckly us um but right now what you guys can do is I don't know if you guys are familiar with the um the release uh the releases that we're putting out if not I can just quickly just share my screen and just show you where you can find this this these files if that's okay oh yes please yeah all right um I'm not allowed to share my screen um how going to do that uh Josh are you the yeah yeah sorry give

me one second let me enable that okay should be good now excent yeah yeah okay so all right so this is the page um I don't know if you guys formula let me share the link uh which is the execution spec test um this the one all right right so when you get here you will see um down here you you will get the releases uh releases uh uh page um so when you go here you will see a lot of different releases right now we're working on three different ones which is the BMA one which contains all

the eips for price and the e one which contains only e plus plus price if necessary and then here uh we got the release that uh uh spener repar uh so this is the one that you guys guys are interested in so inside of here you have you will see the pictures you will see the the the Tarbell file so inside of this you will see the state test and you will see the blockchain TKS so this you should already be able to consume using any any of the clients because um right this is basically the same format as etherum TS so every single client that is is now available should have a consumer that consumes this uh this picture so if you don't download this

this this you go inside it and you get you you will have state test and you will have blocking test and then you should be able to consume them with your client uh and maybe there will be some modifications that are required because uh this this uh the fixtures inside will point to a specific vertical fork and maybe you will have to modify something in your client but I don't think it should be that complex uh so this is what you you guys should do in the meantime before we prepare the consume command which will uh interface with hi and will make it easier for us to run uh tests but I I think right now this is everything that we need so uh because that's that's my question like currently everything all

the fixtures have been generated or at least the test have been filled with a branch that was for caltin in six and we want to test C ctin in 7 um so if we want to regenerate everything uh can we do this with that TBO or is is it just the output of something that we need like the field no no no it has to be regenerated if you're using another Fork as base you need to change it um I this is just a small configuration file that we have to probably change um but it's pretty easy yeah that that will probably require another release um I don't know what's the base of this um do do you remember

Spencer uh if it's uh I know Sor go ahead no it's uh you're probably going to say the same it's uh the base route last miracle BR merge branch that we're filling with uh on um it's all yeah it's worth mentioning as well it's only blockchain tests in here no State tests and uh says it in the release but just uh make sure you have the Shanghai to prag at time 32 enabled on your uh for configuration um but I guess that's for this release maybe for the next test net um will it be the same for configuration

and also when when do you plan to to launch the next test net just so we can prioritize a bit I mean ideally in two weeks uh I don't know if we'll be ready that's the next topic but uh yeah I the the goal was uh was to be end of July I mean if it's middle of August it's it's okay but uh we also want to relaunch one after that so yeah that would the sooner the better but um there's going to be a lot of back and forth so the this yeah this is kind of blocking us uh I mean we can still go the old way like start gu and uh wait we don't it's not blocking us in a way but it would really uh it would really help speed up speed things

up for us sure yeah I think I G you messaged about um testing the the branches that you had merged and so yeah we we can focus on focus on that and getting this new release um launched and then also um assisting with clients being able to consume the tests um over the rest of the week if that that works for you guys uh that would be awesome yes awesome thanks Mario and

Spencer uh cool next up test net Readiness I think we wanted to do a quick check from any of the client teams around test night Readiness and see if we think the next few weeks might be practical uh guon did you have any other I guess specific thoughts or questions around this um I had the list of uh tasks to be wait I'm looking for the for the window uh with my list um as always every time I want to show something okay yeah sh um I don't know if you guys can see my screen yeah so uh yeah I I guess I can start

with with with gu uh field cost is not currently implemented we're we're struggling with it uh the naota cost also have a weird bug that I'm currently debugging the 164 gas gas subtraction we we have uh the main net version of 2935 we so the 2935 version that was on um on uh on ctin 6 U is an older version so now we need to bring it bring it up to speed uh we have the code it's not integrated but we we can integrated and uh State TR in witness gajinder and I

worked on it last week so we are ready for this one and the self District warm cost um yeah I don't do we have a I don't remember do we have that uh no it's uh okay we we haven't implemented it I'm not sure we should uh but yes we we have implemented it sorry we have not implemented uh I've been told by tennish at it that everything like he says everything that was discussed in Kenya is implemented so he needs to do some checks but this is exactly why we we would be using the the the test uh the test framework but according to him everything is

implemented uh yeah that's all that's all for me and well gu and uh and Ne mind cool I guess since maybe most of the teams aren't here unless more people have joined we can either go through it right now or maybe continue the call or continue this topic async in chat oh I think it's y sorry go ahead I was say I think Thomas might have um some more detailed perspective but I think uh Basu is similarly not ready for uh a test net that has Phil cost and

Niota costs um yeah I think we are probably we're still waiting on some of the um database work that we are refactoring before we uh you know get the Fill cost and Iota costs and so forth in uh so yeah we would probably be joining the test net after it started if it started with criteria gotcha anyone else want to give their status test net wise

B3 is already part of our Mon and for uh for the gas also I think is working on couldn't hear you super well but maybe someone else was able to get that uh it was also quite garble for me but it's okay I'll check I'll check offline with with Ginder okay cool all right well I guess that was uh

everyone that's on the call at least no worries gender um okay cool anything else on this topic Gom or anyone else maybe we can uh yeah just make sure that we get updates from everybody at least offline all righty uh next up witness size measurements from Gom yep uh so I uh wait I need to move a window yeah um right so I wanted to talk about some experiments I've been doing uh they're

not complete they take a lot of time to run but um I was just curious how large the Witnesses are for a an actual payload so I'm still replaying at the begin at the beginning of chappella so that's a data that's a bit that's like a year old uh nonetheless it's uh more representative than uh what we used to do before uh so this is uh and yeah that that brought to my attention some uh some possible or potential optimization um this is currently how we store the state diff in uh yeah in the current version of the spec so you for

each uh for each uh stem you have a list of uh uh State diffs and each state diff has one suffix and then the old value which is an optional and a new value that is an that is also an optional uh so yeah just as a reminder if current value was null or not present that means that uh the tree was empty before then uh and if the value was if new value is null that means the whatever was there before was not updated if current value is not uh was not null that means there was a

value that we read and potentially over overwrote and if new value is n n that's the value that we overwrote the current value with uh so there's a couple issues with this approach one of them is optional no very very few I know of a single library that supports optional uh SZ Library I mean uh and and uh it's not uh it's not used any client and uh yeah like there's a push to replace optional with a stable containers I think so the the semantics of optionals are switching a bit uh but

the most important uh consequence of this of the lack of support currently is that gold like the go libraries that I used uh will just WR zeros instead of using uh of really implementing optional and that makes for very very large Witnesses so one thing that was proposed uh by Peter actually is to actually uh right the name is wrong it should not be a suffix State diffs well okay I guess it could be suffix State diffs but the idea is to get rid of optionals by uh using like collating all the suffixes together grouping them in a in an

array of bytes and Al doing the same thing uh uh like cating all the current values and all the new values in their own lists uh no and if the like so the semantics are the same if a value in the list is null for current value that means it was not present in the tree if it's null in the new values list that means it's not been updated and if it's not n that means that there was something present or uh and or that it was overwritten uh so I've done some tests with this it took quite some time to collect the data but if you compare the current version of the library so using

the the spec version with the the new proposal by the first proposal by Peter uh you can see that uh the so the this is a box plot so the the red line here represents the the median uh that means half the half the points are below this and half the points are above so we we have we have an average median that is about at 700 kilobytes uh for for the witness uh and it's mostly zeros if we use that new method which is not perfect uh you still you still have nulls and things like this in the in the in the encoding uh you already get a

huge benefit your median is now around 400 kilobytes uh a little bit under that so as a quick uh approach as a quick optimization it's already quite useful uh one thing to understand or to notice is that this is actually almost double from what was initially promised as a witness size because that was around 150 uh kilobytes but those estimates with the witness size were actually without the new value so if we uh remove the new value we would on average get half not exactly that's an estimate of

course but but that's the that's the general idea and because we get half we go to about 200 so that's more or less what we what we expect um there's uh right so this is a preliminary uh analysis of uh of this I'm I'm preparing another document to to be a bit more thorough but I wanted to share this there's another proposal that I have I haven't had the time to implement yet because like I said it there's a huge turnaround time for for running those tests uh but the idea is to remove nulls Al together um so you have there you you have one list for

everything uh for everything it gets updated so something that had a previous value and a new value you have something like you have a list of suffixes and list of of pale of values of leaves uh that uh for for everything that was inserted so something that did not exist before and was inserted and then um the opposite something that existed and was read and actually the name is terrible untouched suffixes uh it should be missing suffixes so this is for this is the list of all the suffixes that were not present in the tree and were not updated um so because you do not uh

really store uh any NS or any empty values uh and you you should be able to amortize the the list header quite uh quite quickly and so I expect this to be a bit uh I mean even smaller but I don't have the numbers for that yet U but yeah just FYI this is a new proposal I wanted to suggest to use the the better one so the one that has been implemented so this one for the new test net uh that would require CLS to to implement it uh but yeah we don't have a lot of client devs today so let's push the decision to a to a different time I guess but yeah

that's uh that's the idea cool if nothing else on this topic we can keep going cool uh up next we have a agenda item for Phil cost updates yeah yep uh we can actually skip this one because the only person that I from what I understand the only person who implemented it is Tanish and is currently not here so let's move it to the let's discuss it next time all right and the next one is also

you is I think you had a few updates on some eips or PRS that you recently you want to go through uh don't necessarily go through but make people aware that they exist um there's a a proposal for eof so I actually just saw that Dino answered sorry I I just realized so I did not uh I did not get back to you on that uh but yeah the the idea here is to change Chang Chang the the format a bit in the case of e to get a uh to get a version marker or any any bite that would uh tell you that you are looking at an eof contract so that you don't need to go

and read the the eof header because uh otherwise that's a bit more expensive for UF contracts uh because you have or actually for every contract because you have to go and read the first bite of the code for many operations including the code hash um which is uh yeah which is a bit wasteful uh in terms of gas uh so yeah like I'm I'm not trying to discuss unless of course Dano or ignasio have a have a comment on this but uh but yeah if you could go and have a look uh just to give your opinion that would be uh that would be appreciated so same thing with uh with the next one um that's more like

something that was uh proposed or asked for by both Gary and Karim from bisu and also the the rest team um this is actually a fairly perfect proposal it's quite it's quite uh flawed um but the idea is to just add per um per uh stem diff add a bit list of all the transactions that access this number uh I don't think this is the best way to do it actually so I want to make another proposal which would be to have uh a bite list at the beginning of the of the proof that says this transaction like uh

breaking already breaking the transactions into groups that can be executed uh in parallel but uh yeah that's that hasn't been really updated I'm still thinking about it and I'm just saying this thing exists so have a have a look at it ignasio doesn't like it for for the record um so so that's completely fine uh yeah just please have a look and uh right so this one would be nice to have for K stent but it was already in the list of uh of eips um and the idea is just to add the add the top of the execution witness so that also requires a CL update at the state route the parent so that stateless

clients don't have to go back and uh get two blocks to execute one block you just put this information straight into the execution witness and you see if that uh you see if that works uh this was something that we decided on during uh during the interrupt in Kenya so yeah also have some feedback on it uh implement it if you're okay with it so that we we can include it in ctin and 7 and the last two eips uh it's actually they should be merged uh sorry not EIP PR but this is just an EIP an update to 2935 so there's been some back and forth between the proponents of the 4788

method people who say no you should call system contracts and um me and a couple other people say no you should not because that's going to make you're going to have to do some complex filtering but we agreed uh to to split the issue in two parts um so we make uh we make 2935 exactly like uh like the 47 88 people want it uh so we just say okay just um just use uh the 478 mechanism and then just be aware that in the future this is going to come back and and bite you um because you're going to have to implement some complex filtering

and there is another update to a779 which is the veral enabled 20 2935 where the wording is also changed to say the same thing your uh uh like system system contract execution is no longer favor favored over direct State updates uh so once again just please have a look give some feedback if you're not if you disagree uh so that we can can actually merge those uh those eips and be done with this uh with this uh question uh yep that was pretty much it you mind sharing the link to the hack MD and I guess opening it up uh yes I

should do that absolutely I will do that in a minute cool I think you have to update the permissions to it as well cool thank you and last up we have a uh gas overhead analysis from ignasio so I will share my screen um so earlier I forgot to mention that I also work on this document regarding testing uh this is um I sh in the chat so everyone can look

at it if interested but it's basically trying to go through all the order cases that might happen for um the state conversion so today we have some State conversion tests that are more like generate some big state R the conversion and check if like if um if if things go well let's say but uh actually during the conversion there are a lot of things that can happen are quite hairy let's say so I basically went through all everything that I thought could happen and I explained like which are like more focused spectors that are worth

creating uh so we have like simple test cases uh we have um cases to test um um State conversion where like between blocks you have partial account migration we have two account for special accounts so for example uh accounts from EIP 161 are accounts that we won't migrate during the conversion so we have to test that this works correctly in non implementations there are some border cases that can happen on the last block conversion uh we have also to test for uh what will happen whenever

you will move e values from the Merkel tree from to the veral tree that are stale because another transaction before has written things directly to the veral tree so those things shouldn't be moved you also have test cases for what will happen if the keys that you will move in a block also are going to be written by transactions in that same block and yeah so there are like a lot of these kind of things uh so if anyone is interested in understanding a bit more what could happen in the conversion uh this might be an interesting read as I mentioned earlier I was I am

working on I have already like a draft of the EIP for the state conversion so we have a source of truth of what is really the conversion so that will be helpful for um yeah knowing what should happen and also for clients to implement it so probably in this week or the next week I will share the the CIP so everybody can understand what the conversion is really so yeah just wanted to make a quick mention about this so regarding this other topic of the uh cais gas overhead for Bal um so as everybody knows in this call

because this is like a really technical audience that knows about bural um in the bural change we have to um whenever you do a transaction apart from paying gas for computation or state access you will have also to pay for including the Cod chunks needed for executing transactions so this is a kind of gas Dimension that doesn't exist today and I think that probably everyone might be wondering okay how much of this new uh Gas payment uh might be expected in a real transaction right so this is one of

the questions that this uh document tries to answer so um what is the expected code access G overhead on the current mainnet transaction access patterns so I I mean you can try to answer this question by thinking theoretically or or using test net transactions but the the best way to really try to answer this is to use main access patterns because this might be different from test ones and the other question I wanted to answer is today we have this 31 white code chunker uh that we use for chuning um but we also have these other proposals like the 32 by C chuner

proposal by the Epsilon team and it's despite this really it's not that hard to compare them theoretically as usual uh if one is better than the other whatever that means can only be answered by real access patterns not really like theoretical ones um because there will be always cases in which one will be better or worse than the other so the real question is what is the average case or or something like that um so yeah I want to thank pwell because when I was implementing the 32 by called

chering go um he had a like a slight SAR comment that really inspired all this work so yeah just wanted to mention that so I won't go into full detail on this document it might seem pretty long but it's full of charts uh things like that so if you like looking at charts maybe that's interesting but I just want to mention like how I like which was the method to really do all this analysis and it's quite simple considering that most people here are gevs so basically what I did is I created a GU life

Trace uh life Tracer that for each Main trans action records what I call the PC Trace which is basically saying um let's say like you have a transaction that only executes code from one contract the PC Trace is basically the program counter that um executes instructions in this um in this transaction so um like a sample PC Trace might be something like this like 1 2 3 10 15 or whatever so you are executing instructions then maybe you have a jump

and you keep doing stuff okay so of course in the if in the transaction you have more than one contract you will have a PC Trace per contract in the transaction um so basically what you can do with these numbers is you can see you can exactly calculate which code chunks you will access in a veral world for this transaction execution um so basically what you do is you take this PC numbers you map them to the corresponding Cod chck number uh and this depends on which kind

of chunker you use so that's the idea of this method allowing you to compare different code chunkers and after you have the code chunk number you can map that to the tree key and calculate the gas cost so you can see if um a particular cold chunk access is cold it's warm has been charged before or whatever so you can have like an exact calculation of how much gas you will pay for the accessing c um so yeah I basically export these PC traces for a million transactions and I wrote some other

programs to analyze this data and use a jupyter notebook to generate some analysis and charts so all of this thing is pretty much automated so we can run it again in the future or if we have some other code chunker proposal we can also run it and compare stuff again so all this data is based on 1 million transactions um between days 24 and 25 from June this year um and basically there are two main conclusions the first one

is basically um if we simulate how much gas it would a transaction would pay um for Acy in um how much that would be compared to current main gas consumption for that transaction and the answer to that is that on average that would be around 30% so basically if you take a a random main transaction and is consuming 100 gas uh the amount that you will consume regarding code accessing will be 30 okay

that's kind of the super simplified TR the ldr you have here a histogram um that really shows like how many of them will have like a 20% overhead May there are others that will have a 80% overhead but it's not really that many um things like that I also show show here like worst case scenarios that I found uh like there is a transaction that has 130% overhead these are like outliers so these kind of things might be useful to maybe better understand uh these weird

cases um so yeah like tldr is is basically that number U um of course there's much more detail that you can find in the document [Music] um then regarding this comparison between the 31 by Cod chunker and 32 by Cod chunker uh if you don't know how this 32 by Cod chunker works you can read the original proposal from the ipsilon team or I give a tldr if you are interested in a shorter description um so

basically you we can compare these code chunkers in two Dimensions um the first one is if using one code chunker or the other makes any difference on gas usage for a transaction and um the conclusion here is that the third2 by Cod chunker uses around 1. 5% less gas than the 31 by Cod chunker so it has an improvement it isn't like super crazy Improvement but it's at least one one and a half percent and the other um Dimension that

you can compare them is the chunked contract size so um basically you take the original code you uh chunk chunk it on each um chunker and you compare the final size of both and on that Dimension the 32 by Co chunker is using on average 3% less space um which is I guess nice again it isn't like a super crazy saving but um it is saving space um of course

like to to make any kind of decision you have to take these numbers compare that to any kind of complexity um analysis of the implementation of each and maybe come up with a conclusion but I want you to leave any kind of discussion out of the document and only show um like data or results uh and finally I said okay well maybe um apart from like showing average cases or even if I show histograms of everything let's take a look at like more

concrete contracts so I said okay maybe looking at the burners um like if you go to Ultrasound money uh website and you see which which contracts are the most used of course you will see uh the Unis Universal router being one of the most used ones uh or like the one that burns gas um bar more e uh regarding gas so in the in the case of Unis swap we see that Co access overhead is greater than the average is around 54% and we see also like have there we

which is below average is around 21% remember that the average was around 30 and after some digging of okay so why Unis swap might be higher than the average the reason for that after some can be found in something that I show here which is basically something that makes a lot of sense in hand sight which is the more your transaction calls um the the more calls your transaction has so the more contracts you interact with usually the more

overhead you will have because calling a contract usually means forcing you to pay at least one C Branch access which is pretty obvious uh because for the contract for the for the contract that initiates the transaction you have to like always waay for the um the contract header because you will have to touch the Nots the balance and everything but uh in in Unis swap it's pretty common to call a lot of contracts because obviously the idea of Unis swap is if you want to swap two

tokens there is usually no direct liquidity pull between both and you have to switch token a with token B and B with C and C with d to really achieve what you originally wanted of swapping A and D so in Unis swap is really common to do a lot of calls to access liquidity in different contracts and accessing too many contracts basically means you will have to probably pay for a lot of cold branches and this uh accounts for like highish um um gas costs compared to the average

case which usually maybe interact with one or two contracts um so yeah if you are more interest see in details about all this I will just invite you to read this document which I will share in the chat um well I see a lot of comments here um and yeah if you have any other further question uh just let me know thank you awesome any questions or comments before we wrap things

up uh I just have a quick answer to Gary um I copy pasted the list uh like my presentation and if you go back this is page five of my presentation if you go before you have all the described uh proposals cool thanks Co all right well then we can end things there thanks everybody for joining thanks play see you see you thank you