Stateless Implementers Call #27

Transcript

hello welcome to stateless implementers call 27 issue 1196 in the PM repo thanks everybody for joining and let's kick things off with any updates anyone like to go first yeah yeah I can start um so we have been doing some internal workings in gu um in the way we generate all these partial witness situations um so this is like mostly internal get work um then uh we also enable uh witness checking whenever get consumes

tests um this is like um doesn't sound entirely useful now because G is the only client that can feel tests but whenever other clients might be able to fill fixtures um checking for the witness makes a lot of sense because uh we we didn't have like the same client feeling and consuming the tests um and also um I just an hour ago or something like that I released a new version of the fixtures uh O7 and in this version I included the parent state root as a field in the

witness which is something that we have in lebet 7 uh so whenever you do um witness checkins in blocks you should also check for this new field because that's part of the consensus and I remove uh the witness generation for um backported tests that were running in overlay tree mode uh which is a mouthful um um but basically whenever you are in the transition the if you're execution tests in a fork configuration where you are doing kind of a transition of a state it makes no sense to generate a

witness because this witness would be kind of partial because you have state in the mer Patricia tree and in the verle tree so we shouldn't actually have these windowes there so I remove them to just to avoid confusion and yeah I also rebas the witness Explorer so we also have that for devet 7 so that should be already running and yeah the usual thank you for all the testing crew Spencer Danish and other people that help me verify all this stuff um yeah adding to this uh actually not much more collecting some data

merging merging some stuff into Main L and having some conversations about the rebase um yeah it's a slow process so no announcement yet just just the back work in the background and there was something else um oh yeah there was this issue that we're going to discuss uh at the end of the of the of the sick and uh yeah we relaunched the test net the yeah kudos to devil so that in in this sides so uh we are trying to work on several stuff so the first stuff is we

implemented the majority of the gas cost uh modification we still have some more to do in the block Ash but uh we are passing a big part of the reference test uh we are also trying to join the the devet so we had an issue in the first block it was related to the historical block Lo contract when I checked uh at the beginning I was saying that get is not pushing the basic data Le and the code Ash but I found that today it was uh an issue in bzu and when I fix this issue I can have the same state tro as guess even if I'm pushing the basic data leave and the code AS but something that is

strong is these two lists are not present in the witness it's why I was thinking that get is not pushing that um so it seems some data may be missing in the witness uh because clearly it seems that get is pushing everything in the state when I was able to pass the first block I had an issue in the block four so I'm still trying to understand where is the difference when I was also checking in the witness I saw a lot of strong stuff but I prefer to to investigate more and also I will compare with the Explorer instead of comparing

directly with the witness from lar to see if I can detect a difference or not we are also trying to uh to refactor the proof validation so we have a first implementation but we want to refactor this part uh we are starting by using R verel but the same time we are doing the same stuff with Constantine so we are trying to work in the two libraries at the same time um it will be also a needed work for the stateless parts and um yeah I think it's all yeah it's all on the BS

side uh I think I can go next so NE mind we're just trying to join the test we had some problems with the Genesis State root but that's resolved now and now we are having a state root mismatch and block like 5314 just trying to debug the issue and yeah that's it cool anyone else I see that sth just joined I don't know if you have any updates you'd like to share no pressure cool no updates all right

excuse me I think we can move on next up on the agenda do we want to excuse me touch on uh testet relaunch and any around that or we all good to go um yeah I mean the we we have some issues um just uh wanted to to list them so initially the the test not sorry the the witness expl explorers were not working but we sorry not just the witness all the Explorers were not working those who used to debug uh that was fixed by Philip over the

over the weekend so that's uh that's great um and then yeah to just uh to if anybody runs into the same problem as Kim there's an issue with the test net that we don't want to restart the test net for um simply the history expir contract of 29 sorry not history expir history uh uh history called root storage root contract uh is not um is not deployed at Genesis so it is effectively recreated every single at every single block but because uh the code and the nons and the balance are zero um we uh recreate it all the time

so there's a couple things we could do I don't really want to do any of them but uh one thing would be to uh send some funds to that contract so that it would be created um I think it's a bad idea in sense that now it would behave like the normal way but uh but historical blocks would not have this issue so I think it would be even more confusing to people um and uh yeah so that's that's the so effectively what happens is that those locations like the contract gets created but EIP 158 deletes it it does not delete the the storage hash so the the

buffer FS as it should um but the the how do you call that the the account header itself is never created I mean it's full of zero so it's it's never created um so be aware of that uh I think yeah okay Kim you had an issue uh like do you want to just go over it quickly or not uh or yeah you still like you said just uh want to do some investigation I prefer to investigate more I don't have enough information to share okay um yeah so that's just something to be aware of we're hoping to keep it R

running for some time because the next uh the next test net is going to be U another you know step so I think it's valuable to to keep it running even with this uh this flaw I describe um but yeah if uh if you have bugs I mean just just try to join it just try to to use it and if you if we find bugs we'll uh we'll tackle them one by one like we usually do t uh yeah just wanted to mention that the the Explorer is still not working uh the yeah which one block sorry

yeah the uh I'm not sure with the Explorer we used so Dora is working uh exp for the El blocks is not working oh yeah this one will uh yeah I I don't know I mean it should not be deployed um there's no support for for Recco and that stuff oh okay um yeah it should not it should not be deployed deployed at all um simply I guess uh every time we're hopeful and we deploy it anyway uh I mean there's no real reason for it not to work uh but yeah we haven't really tried so yeah block Scout block Scout is not really working never has been so I guess it would require us to to spend

some time on that if there's no urgent need I think it's better to just remove the the link to it cool anything else on this topic or should we keep going next up on the agenda do we have anything that we want to touch on around the execution spec test there was a new release version 0.0.7 uh is it just mostly announcing that or do we have anything else we want to touch on on that topic I think oh

yeah uh go for it yeah I think I kind of cover it in my update but yeah maybe Spencer I want to add something else oh it was allasio um yeah yeah maybe the only thing I would add is that probably this is the last version for the Net 7 um if we are start talking about spec changes uh later in the call or in future SE calls probably they will be for definite dat so um I mean there's a big chance that this release version will be the

final one for themet 7 uh as not to confuse other people for maybe new releases that will come in the next weeks um so yeah things like that s uh then next up on the agenda there was a uh topic on EIP 158 and deletions I think Gom yeah U I just realize I'm on mobile so I'm not sure I can share my screen let me see if I can do this uh

okay granting a ton of permissions um I don't know if you guys can see it yes we can okay cool um yeah so this is a simple um a simple description of what the problem is um we while while merging some some coding gu we found this this corner case that's not really covered by the by the spec um and it has an issue uh yeah it basically the consequence is that we might either have to disable EIP 158 or allow for deletions and the way it works is uh you

you have this pattern that is pretty common where you can send um you can send funds to an address and then deploy with a create two you can deploy a contract at this pruned address and the question is what happens if while you uh deploy contract um during the same transaction a self-destruct happens you uh find yourself having to uh drain the contract's funds the nons will be zero presumably um oh wait no uh right because when you deploy a

contract right no because it's in during the same uh the same transition of course no no so yeah so exactly so um so you the NS will be zero the balance will be zero because the self-destruct drains it so this account by EIP uh as per EIP 158 this account must be deleted uh but that means we effectively have a deletion in a vertical tree so either we do what we used to plan which was to disable EIP 158 um we discussed it back because that was already a topic because of 7702 that was no longer um Turned out to

no longer be necessary uh but now this comes back on the table do we want to uh disable EIP 158 or do we want to allow for deletions in the veral tree uh knowing that delions in the verle tree is something that the guest team is pushing for uh a lot this is uh something that should be that should be discussed at the at the workshop uh in Bangkok um so both options are possible um like clearly I think uh the guest team wants uh the second option deletion so not disabling EIP

158 uh but yeah that's that's a summary of the of the issue I um yeah I just wanted to notify people that this issue exists it's a spec issue um I don't know how that would react on the test net actually we should we should try that uh but in any case yeah are there comments are there opinions about this uh yeah that's uh that's the that's the the reason I wanted to to discuss that uh yeah uh can you refresh a bit why the GU team wanted to enable the editions as you refresh a bit yeah yeah absolutely um

okay so there's document that's uh in the works I don't think it will be ready by uh by Defcon but um the idea is that deletions so when we looked at deletions we replay 200 uh 200,000 blocks and deletions are kind of acceptable they're not taking that much space but um they're accumulating at a steady steady pace and if you look look at how much space they're going to uh how much space they're going to take over you know over six months over 10 years um this is going to to balloon um so the idea the reason why deletions were okay there are several

reasons why deletions were disabled in in veral one of them was that veral would be enabled would be coming around the time of State expiry which we're still working on but um yeah things have changed like this was four years ago State expiry is is a topic but there's no no know knowing when this this will happen and so the what the guest team guest team's position is is that yeah okay uh once State expiry is a thing this is no longer a problem but if it takes 10 years for State expiry to happen um we have zeros accumulating over and

over for a very long time like like I said over 200,000 blocks you don't really notice it it's not that big but if you because every location that is deleted in the historical state is never recreated and deleted I mean there's very few of that that means those zeros accumulate and the you for example Gary has replayed uh so not in veral mode but has replayed historical block and even if you look since Shanghai you find that yeah it's going to balloon to T if the hundreds of gigabyt over a fairly short time so yeah that is the position um basically unless we have a state expiry

this is not uh viable approach that's their argument right so he even if you serialize this Leaf node with 256 zeros as a single bite you still think this is a significant amount of storage uh yes exactly the yeah absolutely even if you could even if you could store a single zero um because yeah you still have to group and all that stuff it would still uh it would still take some some it will accumulate over time so there's there's uh there's document that's work in progress um and

the one side of the argument the other side is how much is this going to increase like storing the the the information that something that got deleted how much of an impact is it going to have on the witness this is why we haven't published it yet because we don't have any answer uh but yeah there's there's document like be aware some document will be shared in a not too distant future uh requesting that we we get rid of uh like we we keep deletions in veral um is it keep deletions or enable it because right now I believe there's

no deletions don't happen like values don't get removed right values do get removed yes they are so they're not set to zero right now okay maybe we're not talking about the same thing I'm talking about in the MPT when you write to zero oh I see okay disappears but in the vertical tree when you write to zero it writes to zero right right right yeah and exactly so it doesn't delete anything I mean okay it's uh you could compress it and in fact I'm working on something like this to to save some space but uh there's still a significant amount of data that remains

in the database and it doesn't look like much even over 200,000 blocks it doesn't look that like much but over a year it starts to show and um you know it keeps it keeps growing it there's no it's not the same location that gets written like deleted twice so like I I mean ideally for complexity reasons it would be better just to not enable delions because enabling I conditions um it means that we should cover a new case in the witness generation because if you delete a value then you might have to compress a

branch um or something like that so we will have to do something there and I guess it might have some impact in this spec regarding gas costs um or something like that right because if you can delete State maybe you should get a refound or get some kind of similar logic as today I'm just trying to like quickly think what is the impact of Ena this right so um that's indeed the argument I made and but they made the cter argument which is completely valid that this is a vertical comp like it increases the complexity in vertical uh which is something that hasn't been

delivered but uh the entire layer the entire database layer is built around this assumption so having to modify the whole G uh infrastructure or okay database layer uh to be able to distinguish between a zero that was written and something that was never written uh is going to have a huge impact on um on uh yeah on the design of clients and this is the of impact that's going to set veral like back like at least I mean veral or whatever uh back a couple years at least it's it's a

huge undertaking um so yeah like indeed we have to move to modify the proofs the proof format to to handle deletions we need to know uh I mean some commitments need to go back to zero um it it's not impossible it's less streamlined it's less efficient in veral but this is veral specific it's not propagating to the entire uh code base basically that's that's the argument which I think is completely valid yeah I think it'll be good to talk about it in Bangkok um my

opinion uh I don't really know what the like I don't have a full view but my opinion is that uh the it's better to not have complexity narrow to the cryptography um just because ideally if that breaks it's like the most opaque usually the most Opa opaque part of the system um so if it's possible to like compress the zeros which seems like it's not enough then that would be like preferred um yeah why would that okay I mean yes okay we're definitely going to talk about this in Bangkok and we we don't need to talk about this right now for for hours

although if people do have opinions we we want to hear them as soon as possible um but yeah what would be the difficulty in terms of cryptography that doing this would incur uh I mean I don't see it maybe you do so that's why I'm I'm curious um no I was saying that in terms of where complexity uh should live it's like further away from the cryptography is much better yeah yeah um but yeah absolutely it's just that I don't really think that is the case in this request but if you think otherwise yeah please let us know

I mean you know think about it we we discuss uh we discuss it in Bangkok um but yeah so this being said um I don't know there's not that many client deaths today uh but do you guys have an opinion on what you would prefer um yeah so just to clarify what would prefer between dels and EIP 158 knowing that uh e disabling EIP 158 which is I keep getting it wrong it's EIP 161 um is U not probably not going to have any Major Impact like contracts

that will be sorry uh accounts that will be deleted will also pollute the the state but it's not the same rate as locations that get uh deleted like storage slots that get deleted apparently uh most of the creation comes from um erc2 is that get transferred and that happens way more often than contract creation so okay I'll stop talking Ken you are going to say something now just wanted to say if I'm only looking at the B database layer I will say it will simplify the bizu code uh we we also need to do some delation when we are doing roll back so it's more

related to how bizu is working with the Bonsai Bonsai logic Etc so majority of the stuff is already implemented if we want to move to that and uh only looking at the bus baser I will prefer that to to delete uh that's that's a very good point so yeah g also impls deletions because of what you just said the database roll backs um but yeah like the issue comes more in terms of uh you know the original state of a storage there's there's a few operations in the database layer that are extremely complex and this is what uh this is what makes it

extremely difficult so yeah for us it would be easier to do deletions as well and yes the code is already implemented and just to add when I say the code is to delete from the tree it's not the it's not a witness generation and things like this was one of the issues as well with um not having deletions not just the zeros but the path to uh sort of the deleted

value yeah so we can always um we can always adapt to this uh but the we we could keep the inner yeah okay so that's that's a good point we could either delete everything um like the whole path or we could just say well we're going to have empty Branch nodes because they're um yeah or you know sing Branch nodes with a single leaf that's probably going to make uh stuff a bit more nasty um but yeah okay I guess we just need to sit down and think about it I mean I wasn't

planning to talk about this topic today um but yeah if if there are issues in the path deletion I don't think anybody remembers because I I as okay at least I asked Dan C I didn't ask Vell that's true um but uh if uh yeah if that causes issues in the in the proof uh we should definitely think twice I'm just saying that uh yeah this is going to be a big push back from from the guest team if we don't uh if we can't make it work right I think that makes sense I guess I'd also ask if it's possible to

separate the verical logic from the underlying database so i p a zero to delete in the vertical logic and I delete it in the underlying database the paths would stay the same but I just delete the zeros um instead of storing does that make sense that's why I asked if the path if the issue is also with the paths as well U right so I remember because uh we mentioned that with then in the discussion he was saying the issue with uh doing this not deleting the whole path was that you would not be able to reconstruct the tree um without knowing the history basically you can't reconstruct the tree

without a full sync because there are locations in the tree that uh would not be known unless you know what happened in the in the past uh I'm not sure I actually answered your question but this is something what you said reminded me of now oh yeah uh separating the path the the concept from uh like of writing a zero from the database um how would we yeah I'm not sure how we would we could do this because if the zero is not in the database how do you know it's there without having uh yeah prior knowledge of

it how do you you know like what I mean is if you're syncing like if you're a uh a node and you want to join a network you need to sync the data from another node um how do you how does that other node tells you well they used to be they used to something here um but it's been deleted and um and yeah like either you have to trust me or uh or yeah replay the chain yourself it's um it's not great okay maybe I'm just rambling right now there's definitely something to discuss and we need to sit down and and um and discuss it um but

yeah I don't think in short Kev I think the answer is no but I'm happy to be wrong cool uh then we can move on to the last topic which is just collecting any other topics we would like to discuss Al together in Bangkok uh one of the ideas is to have a session that's a little bit maybe sort of higher level focused around the path to statelessness and uh making sure that we're looking at and just aware of the design space and asking all the questions that need to be

asked as we navigate and make sure that we stay on the right path which also touches on this discussion around uh exploration of binary trees with something like Poseidon or Blake um so that will almost certainly be one of the topics discuss but uh also wondering and Gom flag this um just uh in apologies we should have done this probably a week or two ago but if there's more specific perhaps veral related topics or anything just more specific sort of uh more uh yeah just more technical topics that we want to make sure that we cover when we're all together so just wanted to flag that also shared a document we can just drop Topics in there if anyone has

anything they want to talk about right now or we can just keep keep this async yeah if you could uh please hear the document also in the in the main veral Channel and then uh people can add their their ideas to to it sure and the Matrix El um I mean yeah both the Matrix and uh

and the more public one I mean it's not the Matrix is not public but it's more focused uh the the Discord one sorry we'll do all right well then we can just end things there y cool thanks all for joining thank you see you see some of you in Bangkok adios