Verkle Implementers Call #15

Transcript

hey everybody welcome to veral implementers call number 15 this is issue 977 in the PM repo uh I will share the agenda here in the chat and in the meantime uh anyone from any client teams want to start things off with any updates I guess I can start uh yeah so there's been continued work on getting the the conversion process to be tested in the test framework so I assume that will uh there will be more details during the

testing update but um yeah I met with Spencer and we made some progress finding the bugs that I had so that much that much made some progress um otherwise I've been working on the test net relaunch um decided that instead of launching a test net and figuring out if everybody could join um we would dump some test blocks that were produced by my code to see if others could actually execut it which would save some uh devops resources so we've been iterating on this and uh we just came to an agreement like five minutes ago um there's still another

fix to to include or at least uh something to investigate but we're we're starting to look good so I I assume we'll be relaunching the test net like today or tomorrow and um otherwise yeah that was I think that was all for me nasio you've got anything else to add no not really I mean there's the MSM stuff but yeah we'll be talking about it afterwards so yeah that's all for us I can go for eum JS uh as G mentioned uh etherum JS uh has been trying

to run the blocks run the test cases uh that game has provided before we launch the next version of test net and sort of debugging that so found few issues in ejs fixed that and lighted few issues and I think uh once they are resolved then I'll basically [Music] reverifying I'll go next so at NE mind also like I was working on figuring out

the gas model clent because the code is a bit

complicated over there so we're doing a basic integration for now uh this seems to be going fine so will be able to join con hopefully the next few weeks on on bzu side uh we are trying to prepare bzu in order to be able to join the test net so we did some gas cost modification we also modified in order to have the C for the block Ash uh we are also doing some modification in the treat generation part and we are also working on some performance stuff in order to patch some call uh in order to optimize the communication between the

Java side in the native side Avid doing some Cy Etc so yeah we continue and we hope that we'll be able to we be ready for the new launch anybody else if no other updates we can move on uh as far as testing updates uh I don't want to put you on the spot Mario but

are there or anyone else uh anyone else would like to share any updates on the testing side Spencer yes thank you hey yeah um so we now have a um a transition tool which generates generates a test and verifies that the veral tree post state is as expected um so this is this is good um to do this we used a a sub command that GM added to get so um ta10 the transition tool is a subcommand so a separate

subcommand um that's used to um on our side generate a a verical tree to compare against the verical tree that has being generated by the transition tool um uh so by doing this we we essentially call the sub commmand maybe like um 250 times for this test and uh so we have generate we have generated a test but it takes um two minutes to generate a single test which is a it's not ideal so I think we'll maybe need to update how the sub command works and and try and get it down to the 1 second second Mark

um but yeah so we still have some more tweaks to do on our side um to kind of optimize um how we're verifying the post state of the test but in general what we have now seems to be seems to be good um and as a general Next Step um we want to try and test I guess the consumption of of the test so um so now that we can fill a test we want to check that we can test the consumption um do we know why it takes so long to generate the test at the moment yeah so essentially it's because um we're calling a binary like over 200 times and with python it's not ideal um

and we could look into optimizing it but um I think it would make more sense to just change how we use the sub command instead of calling it 200 times we just call it call it one time and but we can uh we can resolve that internally I think yeah yep G uh yeah just uh to I mean I understand yeah that that's that's a huge slowdown and uh I think yeah we we have the right direction I just need to understand what you would do so you would pass me an entire aloc like genesis aloc object serialized to Json and I would return

that like the conversion in verco into in form so key values is that what you're expecting exactly yeah so that's kind of that's what we're doing on our side exactly right now and so my question would be um will would the would the state like the alloc be considered complete or would you be a willing or would you want afterwards to be able to add more stuff to it or to to change some values so far it would just be just a direct conversion so just an Alec to a vertical tree conversion okay so I'm I'm just my my question is more about the code actually

so if you have code you would pass me the entire code uh as it is um but what I'm trying to understand is because I would return you know uh executing the block I would return the veral tree as is so I'm just wondering how you would maintain the aloc yourself uh yeah I guess okay you I guess you are actually expect you know what to expect right from me you know what should be in the tree and what should not be in the tree yeah exactly so we have a um I guess so when we write a test we have the post the postate AL allocation so what we expect at the end of um end of executing a test so we'd be

passing our expectation to you um and then we would ideally get the our expected and veral tree back and then we'd compare that with the veral tree that um G generates with G10 okay yeah no that should be able I I don't know if I'll be able to do that today but you you'll have it uh yeah I guess uh before the end of the week for sure yeah I think we can also think on it some more but I think that seems like the best option um for me at least currently cool anything else on the testing side

of things GM did you have anything else there on that topic all cool okay uh next up on the agenda there are some uh performance updates that Osio has been working on and he has a doc um yeah you yeah uh thank you I will share my screen a bit um let me know when you can see it yeah yeah okay so I will just go I will give like a really brief overview of

this argument because the details might not be interesting for most people in this call um so what I did last week was uh I call it like taking another iteration on 3 msms and this work was motivated by a document that goit goit wrote a while ago um well I do this I think will be better uh which is you won't see that is another hackmd dog with um what I think is a noble idea of how to calculate MSM with precomputed tables and I had that in my yeah to-do list to really see if this can

be uh used for improving the performance for the go implementation or any other implementation actually so what I did in document is basically um walk through all the thinking process and that led to the conclusion that I will share at the end so basically in this document I go through some like refresher of like what is this MSM thing and how it relates to B trees because maybe some readers might not really connect both things so basically in in Bal trees if you separate the Crypt in true groups you have all the proof related things which is the IPA and the multi proofs and the

other thing is mainly doing msms like whenever you calculate a trick key for an account or a storage slot you have to do an MSM MSM stands for multiscalar multiplication whenever we have to do this state migration from the Marco Pia tree to the Perle tree and we have to create a lot of new Lea notes we have to do a lot of msms for the new LIF nodes whenever we have to update the tree and we have to recalculate the root commitment we have to do this um internal no commitment updates and those are like extra msms so that's why we once in a while I

think we revisit if we can improve the performance of this part of the cryptography because it can have a big impact on the client performance so since the idea of this document is to come up with a new strategy for an algorithm I go through like what what what are we doing today in gu uh just to know like what is the baseline or the algorithm that we are trying to beat in quotes uh and I go through like yeah what are we doing now and some summary of the cost and the memory usage and things like that then I go through like some overview of what is new this what is

this new idea from gotf uh for a reader that might not be willing to read his document which I highly recommend but at least to give some like shorter maybe explanation um and simply stress the fact that this new algorithm has two parameters that are quite relevant which are called t and B and I just to give like an intuition on like what it means and what it means for the performance of the algorithm and things like that so then I simply show that yeah I did an implementation that you can see in this link if anyone is interested I

think it's very easy to port to other languages it's not like a it's not like a really tricky thing to Port uh maybe it's hard to understand what what what is happening just by reading code but uh it's just like some code that does Point additions and doublings you know tricky way maybe um so I basically did implementation and and did some benchmarks to understand better how this looks like and I put the result in an appendix because it's really long um this is really long because as I said um this algorithm has two

parameters D and B and the performance of that really depends on the MSM length so um basically what I do here is um yeah you have there the result I explain a bit how to read each line of the results of the Benchmark so for example for this case where we have an MSM length of four and we use the tal 32 and bals 10 you can see what is how long it takes to run the algorithm and I also added some custom matx which also counts the number of

Point additions and doublings which is interesting for two reasons the first one is that this is more a neutral kind of metric of performance because the time it takes really depends on the CPU in this case it's my CPU and yeah if you have a faster slower CPU this number might change but the number of Point additions and doublings want so that's better um and also this algorithm has some particular behavior of uh we call it like wrapping Windows which is really hard to maybe it's not hard but this message should

predict um how many point additions and doublings might happen be depending on which value of T you use because um depend depending if T um divides 253 which is the number of bits of the scolar field then you will have like some um differences and I also show how much how big is the table size for this configuration of tmbb which allows you to understand how much memory this configuration is using um yeah so I explain a bit a bit that uh then I have another section

which says okay so you have this long list of results and like what is this number same and um I'm here so I hear for example try to explain things like okay um if you only increase B by one let's say and you keep the rest the same and you compare both benchmarks you can see that okay maybe you are only adding one point addition or doubling and you are cutting the table size by half and what that means and um things like that because uh you have you have to understand well the

trade-off between memory usage and performance here and most of the document is trying to unpack that because it's a bit tricky and then I simply say okay after we understand how this algorith Works in a vacuum let's say how we can use that for veral trees msms and I go through the correct what I think is the correct way of looking at this problem because at the end of the day the thing that we want to do is beat the current algorithm and the current algorithm already has some optimizations of using like different windows sizes depending on where the

points uh which are the points that you use for the MSM so it's not like a really simple single Benchmark case that you have to do and yeah I simply go through all like each of these cases and explain if like the current algorithm can be better or not and I show that if that's the case which configuration configurations for that case um might be better and at the end of the day I say okay so it seems like the final strategy is in this case like a hybrid strategy in which for some cases we'll still use this current algorithm but for many

other cases we can use the new algorithm with different configurations and the bottom line is the following so if we are willing to use 144 megabytes of extra Ram which doesn't seem that bad uh we have that for msms between length one and eight we have like mostly the same performance here it's saying it's a bit faster but this is probably noise because it's calling the current algorithm anyway and for um the rest so between nine and 156 so it's like a widish range we have

like between 20 and 44% speed up um so I did the same kind of Benchmark in a rock 5B just to double check and we have like a similarish performance gains so that's okay and if we think that 144 extra megabytes to get these speed UPS is too much uh there's also another variant where we only use 16 megabytes of extra Ram and we get like kind of the same performance but only for the range of 33 and 256 we are not like getting this lower range

um so yeah I think that 144 megabytes is a good it's not really that bad and um we are getting like a good speed up for these ranges then I go through like other more gory details questions on why these implementations aren parallelized which I think I would recommend for our clients to read the section because I kind of explain what we do in get regarding paration um yeah I go through like other question regarding some tricks that are explained in the um in go document or reduce the table sizes but I don't think we can use

them in our case um but that's still to be maybe I have to think about this better but I don't think we can do that um and I also explore if all this new strategy affect table in initialization times because this is this are this is using precomputed tables have to do some work at the start of the client and the reality is that this doesn't change that much for my CPU theur current strategy uses 400 millisecond to to calculate the tables and now we use 528 so doesn't change really that much and for a rock 5B the current implementation uses like three

something seconds and this is still Landing for seconds so the rest of the CPUs will land in the middle of this some point in the middle so the conclusion here is that like from this raow benchmarks seems pretty obvious that this is like a good like new strategy I'm a bit sad that we have to still keep the previous implementation to not really have like the goal of all this was to not really have to not really like accept that any other case might be slower uh I had that as a constraint for

this exploration because if I allowed that maybe um like allow some L lose of performance in these cases maybe like things can improve in our Dimensions but I just wanted to only make gains or to really simplify the the analysis of everything because um it is a bit complicated to say that like a 3% loss here it this worth a better thing here because um we we probably will be doing more of these cases in real life than these cases so I just wanted to avoid all that

discussion um so what I will do now is basically like polish a final implementation of this and try to do some extra benchmarks in go work call and maybe run um um a replay a chain a chain replay to should really see if we can see an improvement at that kind of higher levels of the stack and yeah simply like solidify if we can merge this to to main it to like to master let's say yeah that's it and I want to say that if anyone

wants to ask any question after reading document if you're interested um just let me know and want to say a final shout out to godre that was the person that created this new algorithm that uh could allow this performance improvements I basically just walked the extra mile to pull this from research to practice let's say awesome thank you ignasio cool uh next up on the agenda gum had a summary of some of his discussions from East Tai an update to the spec

G hey um yep let me just try to share my screen yeah so I slpt together a very quick presentation it's probably not as good as it should be um but I had a couple discussions with with Vell and Jordy and other people at um at East I and I wanted to to share some of that um so it's not actually so much an update to at least okay so I mostly discussed three eips uh 4762 which is the gas the veral gas cost 2935 um which is the history storage and 7445 uh which is the

precompile so I'm going to just talk about uh yeah some of the some of the insights I I got uh so the the biggest one is 4762 um so I asked vitalic what was the the design because it wasn't clear to me what was the the design principle how did how did they choose those uh how did they choose sorry their numbers and they what he told me is that it's I mean the the general Insight is that they try to not change anything of the any of the gas cost so contrary to at least what I was believing um the the veral the veral cost should pretty much be the same uh before uh I mean the same as they used

to be um it's not it's not 100% perfect but it's a it's pretty much the same so uh for example if you look at s load um you have uh the you read you have the branch read cost and the trunk read cost and if you add them together you get the old storage uh Cold Storage cost which is uh 2100 um and if you access an account let's say you only read the the code hash the the balance and the nons uh you get 20 2500 which is about like slightly under the cold account access cost which is 2600 um but if you read more of course it will be a bit more expensive so

depending on what you do um it's not it's going to be more uh more expensive or less expensive but it's roughly in ballpark and another real realization I I didn't or at least I had at the while talking to to vitalic is that if you look at the cost of create for example the field cost uh which used to be 20 gas per bite uh if you have 31 bytes you get exactly uh the value of fi cost and if you check what it cost to to write to the to the state uh to write an account to the state you uh like the the contract header so version balance nons Etc uh you will

also find that uh if you multiply it by the by the FI cost you you find 31,000 which is effectively uh almost the the cost of the old well the the cost of the current uh instruction like create instruction and the difference is one 1,000 and this is what the new cost of the create instruction like the new static cost of the of the creating struction is so yeah um basically the realization is that the the gas cost should be pretty much the same so there's no huge increase in gas cost with veral um so yeah I wanted to to share that so this yeah this is not this is

not an update to the to the spec per se but at least for me it's a new reading uh and I'm going to use it to try to to clarify this EIP which is pretty messy um try to make it a bit more streamlined and in fact Josh with your help I'll be recruiting you uh to to help me do that um the second thing uh there was a discussion with uh with Jordie uh so Jord Jordy from polygon ZK VM and and all um about 20 2935 so until now we had this conversation that we decided it was okay or at Le mostly okay to uh to have a

buffer of 256 values but Jordy um said yeah that uh that 256 blocks that's way too little for us because of the time it takes them to to generate their proofs so they would rather have two weeks worth of blocks uh instead of just 256 so we would still have a ring buffer but it would be a much bigger ring buffer buer um I actually didn't compute how many values that was but yeah it's like 256 blocks is just under an hour so you would have uh 256 time two so five 512 times uh uh times uh how many hours there is in a

week week um yeah I don't want to make the calculation right now but you get uh you get the drift uh so yeah the the block would just like the the buffer would be much larger but not so large that it would start having an impact on the overall State size and I think I mean yeah I wanted to share that maybe there's some push back but barring some uh some push back I think we should just change the EIP to to do that um okay and the last uh the last comment or at least the last uh proposal for for a spec up date was with EIP 7545 so it's the precompile so once again it

was a conversation with Jordan um and his comment was that uh I mean he didn't know about this EIP he just said it would be great if we had this and their idea or at least their request comes from the fact that what they want to do is update their contract to user pre compile and they don't want to be rushing to update their contract at the moment when um when the Fork happens so what they would like is to have a a format a contract sorry a proof format agnostic precompile that they can just pass a blob to and then the contract is aware of whether or not the

fork has happen or where in the where in the conversion it is and when that happens um when the fork happens it so before the fork happens it will expect an MPG proof but you know just the the contract itself just receives the proof in the call data or however however it gets it and then um sends it to the pre-compile the precompile verifies the MPT proof uh says okay that's valid and as soon as the fork happens it receive uh so during the conversion it receives both a vertical proof and a MPT proof together uh but once again it's trans it what's important is that it's transparent to

the contract and then once the conversion has uh termin completed the you only receive one recal proof and that's uh once again you don't have to deploy the you don't have like the contract doesn't have to be aware of what's going on and that's at the L1 level but it's also true uh on L2 they want to do the same thing so they would like to have this uh this EIP so that you can deploy the same contract wherever you want but for example U L1 would be switch to veral but L2 some L2 would not have switched to veral yet so they would still use the the old MPT proof format or whatever a new one a ZK proof whatever they they want as long as

it's the client that knows where it's at and how to handle it and uh the the contract itself the same code can be deployed anywhere uh that's what they that's what they would like so yeah uh that's uh pretty much it uh with the the the bigger change um is well first it's in the API of course although ignasio was already pushing for a change in API already um it's the so we would just get rid of of the version or at least we would not make the version uh like the contract would not care about the version it would be for the The Blob payload or whatever payload they used that would say this is a version and uh

the other uh losing my thread of thought um yeah the the other change is that instead of uh activating it in Osaka the verical fork we would need to activate it in Prague or whatever uh four comes before veral to give enough time to the l2s and other other contracts using this precompile to update their code to use the precompile and then they could uh they could go through the Fork un unimpeded and not having to rush to deliver a an update to their contract at the fork block or after the fork block um y so that's

pretty much it for the for the update or at least for the for not for uh sharing what I what I discussed um I don't know if there are questions but otherwise I will work on uh on updating all these eips to to try to to talk about them during the next ACD yep um yeah I have two questions uh the first one regarding the first slide um or the first topic about that the gas costes of work should kind of approximately match the current ones so this is

true um like ignoring code accessing cost right yes I yeah okay right that part was missing but now it's covered cool and regarding this last point about the pre-compile or the contract for verifying proofs uh do you know if they have like a desire API for the precompile or the contract because it's a bit tricky because we have to include all these which are the keys that they are EXP expecting the proof to prove and all things like that um or they they are just like talking about their desire or

maybe they already have a proposal for the API or how they use it today no they don't really have uh at least we like Georgie has not described as a very specific interface he just told me I want to be able to prove uh that what I'm looking for is in the is in a given St state route that can be two weeks ago um I would like I mean I was going to try to update the the EIP itself because it's quite far from from this use case and then approach him again to to ask him for input but um yeah maybe I should uh write ask him for so yeah the short answer is no but we indeed need to get this uh API properly designed before we

before we uh before prag basically so okay so and this means that the first implementation of this precompile should only have cryptography related stuff to the merco patri tree right not necessarily the veral tree because that will never be used until the fork really happens uh yes absolutely uh this being said yeah we need to make sure that we don't change the interface that's all we need to make sure it works basically before we uh we we deliver this uh this EIP yeah uh I just have a small question

regarding the E with the block hash should we not create these two different eips like one for like switching to a ring buffer and then another one to increasing the size of the number of blocks we are the block hash code is supposed to return because this seems like two different changes to me um right so I mean okay I'm trying to make sure I understood so you would want to a IPS one for the ring buffer and one to increase the size of the Ring buffer um we could do that in eips but I'm not sure I understand the logic of because you know the CIP does not exist yet so

that's why I'm uh I'm not sure I I mean this EIP hasn't been delivered yet so we could do everything in one go uh I I don't mind doing yeah no so I also like I generally don't mind but the the thought process my thought process was like one EIP is just to change how block cash is implemented and other EIP might other change might have other issues with other implemented contracts where we have we are increasing the number of uh block has that we provide right now with the block has op code so yeah that's the reason I have but yeah we can still do it in the same but still like right now the behavior is that like someone asks for a block has that's not

within 256 it returns a zero value a null value but then the behavior is changing so yeah yeah fair enough um yeah I would have to think how to format those things but yeah that's that's a fair that's a fair point cool if nothing else on this topic can move on to the final agenda item uh bugs ahead of the test net relaunch I think that was also

you um yeah was not exactly me as much as uh yeah basically I wanted to take some time because we we had this conversation this backs and forth with most of the client devs uh so I think we the main the main course of the of the Vic is pretty much over uh but I wanted to see if there were questions about the the blocks I produced the test blocks I produced from other clients um that we could uh you know discuss right now and not necessarily keep everybody in the call but just have because we have this time to talk we could we could do this so

that would be like some kind of peer programming uh session if there's a need otherwise so yeah we just call it off early cool I guess does anybody want to stick around for that is uh I don't know if what the interest level is thing is we just solved a lot of problems right before the call so I don't know if it's really useful but it could be sure got it okay uh I guess we could also maybe coord a separate time if folks prefer happy either way maybe best to do it

separately yeah I guess I guess we should do this I mean I know I know G jender for example is waiting for tennish to be able to verify 10 is just verified so um maybe yeah the timing is just bad I mean we fixed bugs so it's not a bad thing but the timing was a bit bad for for this to happen so I guess I guess we can call it a day okay cool then I guess we can end it there if nothing else thank you everybody for joining and uh yeah we will see you next time thanks take care thanks everyone bye bye

bye