Verkle Implementers Call #14

Transcript

Cal implementers call number 14 and issue 972 in the PM repo uh a link to the agenda will be shared in the chat as well as in the notes on YouTube if you're watching the recording uh we have a pretty light agenda today so this may be a shorter call um okay uh any client teams want to start with sharing quick updates since the last call I think I can go ahead yeah you go

ahead uh yeah so uh there's no big updates from NE mind last two weeks most we been spent like uh running status execution on the current test net so identify the problematic blocks and like find any more issues that might be there that we did not see in the initial blocks so we are just working on statest processing and that's it yeah so on the I'll do on the bizo side uh very light as well so we uh we managed to follow test net to some block number that I forget but uh stopped uh

waiting for uh the relaunch um and meanwhile we've been working on uh on optimization because the the timings were not so great or not so bad but not so great so uh so we're working on that at the moment and making implementation as much generic as possible yeah I'll go next um yeah so we we had the shadow Fork last time um so now we've been working on uh well first helping other understand bugs uh when they try to SN the test net uh also cleaning up

code uh we uh I mean I started on the den kunri base it's going to take forever so might as well get started early and uh yes um basically working on the gas accounting layer because currently the the gas model is is a bit it's definitely not following the spec so trying to to clean up in the in the hope of making it uh making the next testnet use the the standard um gas accounting it's going to it's been it's been more difficult than anticipated but yeah we're getting somewhere so I'll

have a question about this later and uh ignasio uh do you have anything to add um not much but we made the replay of the chain work again on the rebase branch and we discover uh two panics related to some bugs that we have in gu um and yeah some extra maybe Coter and bags that were found by others that we fixing gu to so on ethereum GS side we basically wanted to uh syn constant for uh B uh in the in the way that to Hope over the

invalid blocks that we see and uh so we were able to achieve that and uh we are basically now waiting for new network so that we can test uh the fixed Network and evaluate wait against it because for the few blocks that we randomly inspected it seemed like we were seeing the old issues which have already been discovered so uh for us next step would be to uh test on the new network um

yeah yeah I just wanted to Ping tannish and the Nimbus person uh to modify the Patterson hash function uh there are currently PRS in Basu GF and if MJS but there's none in nevermind and ners uh is there a like change in the way we calculate or the the output is also changed now or just an optimization uh it's a breaking change uh yeah pedis and hash is a bit

confusing but it's like get tree key hash uh it changes the output oh okay I I'll have a look at it anyone else do we have anyone from Aragon I'm not sure if snath is here I don't think so any other updates okay uh if not we can move on to

agenda item two uh testing updates Mario yes hello um so last week there was no that much work from our side uh to bco but I think one important topic that we can cover today is the changes to the the way that we feel tests and the way that the clients will consume uh beral tests uh I mean normal test blockchain test and state test after burle has happened um so the main change that we've been working on the past weeks with gam is that um since uh verle can no longer output the post the lock um we

have to make some changes to how we uh receive this information from Bal from the transition tool um and how we process it internally uh while tests um if anyone is not familiar with the transition Tool uh it's basically just a tool that uh in this case G provides for us to to be able to um do the transtion function and get the output uh allocation so the nice thing before burle is that we have the preall looc uh so it's basically just a dictionary with all the addresses as keis and we have all the storage and balance information available for us and this is the same as the so you give a pre- allog and the post alog and you get all the all the

changes out for us and we can then according to our tests check the storage of ever key and make sure that everything makes sense in accordance to what we have have written in our tests so now um the big change here is that um we provide a preall loock a pre a preal h but the output is going to be uh the vertical uh key and also you stop me if I make some mistake just let me know I I can uh you can intervene if I say something that is not correct but yeah anyway the output is going to be the dictionary of the uh uh that contains all the all the tree all the vertical tree structure um we we're going to have

to make some big refactoring in the way that we write our test because we now have to check uh the pson hash to get the actual position of the storage keys that we need to check in every single one of our tests um so we're working on that and we're working on some refactoring to make this easier uh for us in the in the long term um and that's um this the the the change to trans tool I don't think they concern most of the clients but the output of the blockchain test and state test are going to slightly change too um and these do do concern uh most of the clients because how of that how they consume um so the idea is that um now on

the blockchain test that we the blockchain test are basically just uh we have the Genesis the block block one two and three and so on and we do some polock uh verifications um and the idea now is that with Burl we can also introduce the witness in every single block and what this will allow us is at least on hi um we can um we can run the tests with the normal client and we can consume the blocks one through n but also we can um run with the stateless clients so in hi we can configure U the same maybe the same or a different simulator and we can

just start parsing the test that we already filled with the transition tool before and then depending on whether we are running with the full client or the stateless we can run one test with the with the full client and a stateless test with the with the stateless client um this will allow us to just write a once but it will be able to be consumed and verify both types of clients so yeah this is very good and uh um this is the main idea um the the disadvantage maybe in this case and um is is that probably that the consumers of the current U blockchain test format are going to be

affected so there will be some modification to the consumers that every single client um implements and it's going to be important for uh all all the clients to adhere to this uh this changes in the in the blockchain this format it's not going to be big changes and I think it should uh should not matter if if for example if you have you're a full client you can ignore the St lless or the witness part and I'm not sure it's that necessary but uh it shouldn't be a breaking change um and yeah I think that's that's basically the two important things that I wanted to share um and also just to open to

discussion if anyone has concerns about this two ideas um they are still being work on so there probably going to be changes uh but if you have some feedback just uh just let us know uh just to add I have two bugs that I need to fix for you I will try to do them this week uh but yeah I can't promise it just yet but that would be uh that would be nice to to be able to test the the full chain yeah cool thanks um we're we're still working on the refactoring so it's

going to be a little bit maybe a week or two uh so it's not it's not a problem but if anyone else has like feedback or or or has any questions or about the mainly the fixture uh test and something if uh if you have questions just uh let us know thank you Mario cool uh next up we have a followup from the last call discussion on potential dos Vector around tree branch

attacks either gati or ignasio yeah I mean just can to basically say a bit of this um this was a bit cut short because I had microne problems last week and just wanted to give a bit of an update um on this um yeah um this is basically a bit of a followup to what um ignas Josh has basically um shared in the chat I mean ignas has made a write up I have started a wrer of my own we'll just link to it this is this is work in progress I mean at least both um documents that were basically shared are work in progress um haven't yet written up this uh in full detail but um one thing that um we have

to bit um concerned is that basically an attacker who wants to basically dos um the tree could just create uh very deep branches in the work tree and there is a bit of a distinction that one needs to make whether the attacker actually um targets a particular tricky essentially and that is or whether we actually consider multitarget attack I mean um if an attacker is basically willing to spend 1 million US Dollars on basically searching for Tre keys that basically um collide with large prefixes of our hash function and thereby pushes something

down below the tree I mean they can actually also clearly make ex make a lot of excesses to whatever um trees they insert themselves into the tree so I think that um depends a bit on how we actually model the cast for this um um but we need to actually take these kind of multi-targeted T more seriously um I have explained this a bit in the um second um link that I've um posted in the chat I said that this is work in progress but um just to repeat what was said last time the upshot is that if we have a um 2280 attacker which seems like a completely reasonable um thing to do

with um an attacker that has a budget in the millions um given that an individual evaluation of the um well hash function that is basically than hash function is essentially a single group operation that's super Asic oh permission guide oh sorry can I have to probably share this uh yeah sure link can you TR the link now I'm just wri to the chat whether works okay so um yeah thanks um so the um the thing is that uh um the

individual the single individual hash function evaluation is basically a single group operation and this is and the attack that is is in fact super super Asic friendly with as6 with an Asic design that probably already exists because actually the same that one would use to break block so I mean the million budget of million to can basically expect to have something like 2380 or so evaluations and this in fact allows to to um basically create a a branch that has a depth of something like 14 in the bule tree um it's not possible to do this for for a chosen Target but um it's possible to do this for an attacker for the

attacker's own targets and in fact the attacker can create not just one such deep branch in the tree but a lot of them something like two to the yeah I don't know something like say two to the 16 to two to the 32 of them and of course then an attacker can basically just mean if you have a million of budget I can just write I can just make transactions that access them heavily which I guess since we are not um doing this within the price gas price Model we do not take the um actual witness sizes or and all of this into account actually may cause for massive um gas Miss pricing unless we are sort

of willing to assume that basically as a worst case that well basically branches in ver tree have a depth of something like 14 which may be doable I hope so but this is kind of the ball park that we need to Target if you want to sort of make this work in the worst case yeah that's just my side thanks C any questions yep yeah I'm just trying to formulate it but basically if we manage to just to confirm if we manag to

do 14 a depth of 14 in a acceptable time we would be fine yes pretty much I mean 14 acceptable time maybe 15 I mean this is really probably really feasible 8 14 maybe 15 16 would be a bit better but yeah that's basically the Target right um because in um in gu we have this thing where we we try to share as many um as many of the calculation as possible um so it's not that we only care about the depth only and we don't care about the wide attack but it's less likely it would have to be really worst

case I'm not sure um if an attacker can actually Target this use case find a lot of uh um keys that are not in the same location in the tree but are really do not share any um anything in common any computation in common um yeah I guess it's doable too yeah okay so what would be the next steps you advise for us to to settle this question well I mean as you said I mean make sure probably really assume this

worst case I guess okay so uh one extra thing that you mention Gotti is uh that like an attacker wouldn't have a problem to not only generate one but potentially a lot of them right yes yes yes okay so the worst case will be actually a lot of branches of Dev 14 that probably don't share that many common internal nodes so um it's not yeah not only like one really deep Branch but potentially many

of them yeah I mean some kind of back of the the envelope calculation I mean that 2 to the 80 attacker um can basically create something like 2 to the 32 um branches completely separate completely separate branches each of the deps as two 14 I mean two 32 is a lot I mean you probably would go for Less because then you can basically optimize your attack to be more Asic friendly but still go to the 20 or something is completely feasible of course he would still need to actually write all of them to the state

which takes a bit of time but it's probably within the budget I think that keev had a question on what machine what do you mean K on what machine the attacker can do this thing or for I mean I'm assuming here that the attacker can carry out two to the 80 group operations basically um The Mach I mean uh the attack is super super parallelism friendly so probably an attacker that is that determined would build an Asic for

for um for the group uh I was uh I think gam said that uh if we can do 14 levels really quickly uh this becomes not a problem or 15 or 16 so I was referring to what machine are we talking about when we save really quickly I when we say really quickly um yeah it's I don't know we our test were on in nasio machine I'm not sure I like I don't remember what it was it was some rising from a few years ago yeah I I will put in the chat a link

to a section in my document where I run a a benchmark for updating a branch of different depths in my machine in and in a rock five b one [Music] um so yeah we can run this Benchmark in other computers too to have an idea of what is like a reasonable low setup low Hardware machine that we should Target and see the times there maybe yeah I mean that would definitely spell the Doom of the rock 5B although Nan second yeah um actually not

even maybe um but I think we we have some leeway I don't I don't want to say it's completely uh it's not a problem but I I shared with the the timings with with Peter and he was like yeah if it's a worst case scenario um it's it's manageable um so yeah yeah I think that maybe the concern is if we have a lot of these branches um yeah I understand uh I just assume we wouldn't have more than 1,000 branches being touched so that would be okay still but yeah um I would still

uh yeah it's it's better to to have even better numbers to be completely safe um I'm just saying uh it's not preventing me from like it I won't lose sleep over that but I would be more I would sleep more comfortably if we had better numbers yeah and also it will be useful to run this kind of Benchmark in other implementations uh other than gu well anything else on this

topic if not uh we can move on to the final item the n relaunch right thank you so I have a very um Bare Bones presentation always looking for my window okay here it is um can you see my screen yeah okay so yeah um there's been a few things going on on the test net uh people have tried syncing it really uh found some bugs um and there's actually a lot more uh okay there's a lot more blocks that

clients seem to have an issue sinking uh at some point bisu stopped trying because as they find bugs they were patching their code to follow gu but some stuff had to be fixed in guas so uh they they gave up and that makes sense they're waiting for the relaunch they're keeping busy doing other things in the meantime which is fine um and then uh tenes and Ginder I think I think that those were the two um tried to do a sync maybe Gabrielle too uh try to do a sync to like stateless sync to figure out which ones of the blocks were um were causing problems and

they found um not a huge list but a significant one uh so from what I understand if I understood your update correctly gender you say let's not worry let let's worry about the the amount of blocks differing after uh after we relaunch is that what you said yeah yeah because uh it seems like the same issue is cropping up in most of the blocks okay yes that makes sense thanks um so yeah so uh in the meantime something else happened we had a network split um that actually happened shortly after the the last Vic but because half

the network was still holding uh we we didn't really notice uh so I guess that's uh that's some we should get this kind of information like we should get paged when something like this happened um but yeah the the test net was still holding and so the suspicion given the block height um is that happened when um um when opens open zein deployed some of their test contracts to to the to the to the test net um so it looks like G got overwhelmed some of the machines missed their slots and this thing happened but we relaunched everything uh it's back to normal except T first sto

working as well so yeah the the only reason we keep the test net alive currently is to because there are some things that some people myself included that want to try some uh some new codes for the relaunch and and want to to keep uh sinking but it's going to it's going to to be terminated soon um so um we this is the the series of um of updates I would like to to have in this new test net if everybody agrees so there's the All the known bugs so uh all the bugs that can I show this or is it going to open in the no okay I click nothing happens great but yeah if you go

to the to the spec page you you will see the list of bugs that have been known identified and uh and uh fixed so those are are fixed on the test net um and then uh yeah my question is like this question is has already been answered by Ginder at least gajinder and tmjs are not going to bother syncing anymore um they there was a couple blocks that we thought would reveal more problems but those blocks did not did not reveal anything so uh that's fine and namely those those blocks where those who split the network um and uh yeah so there are two

things I would like to add to this relaunch the first one is fairly simple after the discussions we've had uh about uh um well okay we we just had the discussion again but I think it makes sense now to go with a circular buffer in 20 2935 if everybody agrees uh the first question I have for that is what is the start offset like do we want to have an offset of zero at the fork or do we just uh take the last bite and this is where we put the the first block and then we fill the the parents um so in um yeah like we will presumably be in the middle

of a group and then we put the parents um like in the circular buffer we fill it uh in the circular buffer this way or I think that's the simplest solution or um do you want to to start with offset zero at the the fork height so sorry at the fork block uh so if um yeah if anyone has an opinion otherwise uh I would go with the default star of set which which is just the last bite of the of the fork block number yeah I think the mod modular ring size is the correct way to go for it yeah cool okay well U unless anybody

dissents then this is what we're doing um and then I would like to also use the gas cost so until now it's entirely because of of me uh we were just adding the EIP 2029 cost to the veral cost so that would inflate the the gas cost even more um and we would also not uh PID the pay any attention uh not not treat the the center of the transaction and the and the recipient of the transaction uh any differently so basically the the payer the the user would have to pay the gas

cost for the ining intrinsic gas cost of the transaction plus the witness cost for two for his two address and his from address and that that was a bit unfair so we've had a series of discussions over the the past few weeks um I think we should go and have this uh this uh new gas cost I still want to leave the trunk fi cost part out because that requires a lot more coding on my on my part um but yeah otherwise I propose that we go with the the pure veral cost everything that has been ins spec except chunk field cost that would be set to

zero and yeah there was uh um yeah so before I move on is everybody okay with that or is there a reason not to do okay and um yeah so the next thing it's kev's change um so now uh ignasio has actually just pushed an update to the EIP this morning um we would not use the serialization I forgot what the name of the function was called but there used to be a uh one way to serialize the the commitment in the sorry the commitment in the pon hash the values in the Pon

hash and uh when okay sorry when hashing um a commitment we would use uh I'm trying to remember but the two bytes uh and um and now we would we would use map two field um so yeah just be aware of that because if we're going to relaunch this is what we this is what we do um and uh yeah so the question is dun so the this um this meme courtesy of Barnabas from from the panda Ops um I'm I guess is not ready to do this so I suggest we don't do that for the relaunch although that's what I'm going

to work on I mean I'm uh me and in asio presumably are going to work on in the next the next weeks uh get the the rebase on top of of denune uh we are not it's not going to be easy so if since B for example at least is waiting for for relaunch uh we should not consider denune just yet uh but hopefully yeah in the in the next iteration and uh yeah is there anything else people want to add to this test net um any timeline and I I can't promise it will be done this week because I need to finish the the gas accounting layer but yeah it would be nice to have

it in the next two weeks if uh if if everybody agrees and yeah that's pretty much it yeah Tanish uh just one thing that I like to propose is like for the new test net uh in the starting at least now so like ethereum is also another mind can like process stateless Le and hop over in valid blocks so at least in the first week uh we can just like try to figure out if there are some issues and if we find some issues we'll like relaunch the test net because like so this test net was a huge one like it has a lot of blocks so it was a very good opportunity to test veral sync but due to issues I was not able to so for the new test net

like it'll be good if you can like in the initial phases just figure out if there are some major problems or major issues at like require a lot of things on other client side to sync and then we just reoun the test if we find some issues right so just because the the sound was a bit garble for me so uh yeah you you said that you would like to launch uh all the the test features as early as possible is that is that correct uh no I was saying that like whenever we start the deset and since ethereums and Ne both has now capabilities to process stateless blocks and also hop over in inv valid blocks so let's say like for one week we like let

the test running and if in a week we find like any kind of issue we relaunch the test net and we don't wait this much longer like this time okay like yeahor so in the last testate it was a big testate and it was a very good opportunity to test voal syn but due to all the issues I was not able to so like in the new test net like if we just relaunch with the issues we sign that'll be uh good for testing yeah cool yeah yeah absolutely that would be nice to to have uh to to find those bugs yeah uh I agree Let's uh let's res like it doesn't have to be long LIF let's just make sure it it it has as much content as possible so that we we can find potential bugs uh

as quickly as possible which means that for example we have um I didn't mention that but we have a block hash issue uh on the current test net but because no one called block hash it has not been found um so we would need to make sure and I have to talk to Adrian from open Z plan about this um if he could just uh create a script for us to release all that stuff right off the bat I think that would be a a good way to indeed um just uh just figure out if uh if there are some uh some problems early on and indeed we we don't need a very long running test net if uh if we can identify bugs right off the bat

yeah or what we can do is basically have a very short LIF iteration or couple of them before basically launching the next version so we basically keep the constant in for running and have these short iterations where we basically do sort of bug hunting and uh maybe after two iterations or three iterations we again relaunch sorry I was muted yeah yeah that's uh I wonder is barab still around um no yeah I was just wondering if uh we could just be like if there would be an

easy tool to to be notified if an error happens so that uh yeah we we can build a list like uh this test net you know I had to I had to insist that uh people should try to sing stessy all the way and indeed it was very long etc etc uh if we could somehow automate this and get the list of blocks right off the bat that would be that would be quite useful uh but what do we need to get the list of the filling blocks uh yeah I mean that's the point isn't it um like just yeah exactly just failing blocks um like to figure out if

our test net is stable and everybody's in agreement which I figure it will not be um because the gas layer changes so there will definitely be some discrepancies um and yeah it would be nice to identify the the failing block as quickly as possible yeah I think uh we and Ne mind eum JS and Ne mind should be able to do yeah uh yeah not sure about automatically but like we can definitely get periodic updates yeah okay yeah good enough uh just adding that yeah maybe one week

is a bit short as a turn around but yeah we we should be able to do it every two weeks at least cool thanks gam anything else if not I think that is it for this week thanks everybody see you next time see you by