Stateless Implementers Call #35

Transcript

Okay. Uh thanks everyone. Uh this is stateless implementers call number 35. Uh I will share the agenda in the chat. So as a brief summary of the agenda uh we have the usual team updates. Um we have some last minute cancellation of the presentation that Hans uh was going to do and that will move to the next call. Uh then Carlos wants to discuss uh a bit about this fat net um uh network uh that we are planning to do to gather some metrics but I let him uh talk about

that. Then we have a followup on EIP7748 um regarding some special accounts uh that we have some custom rules about how to convert them. Um then we have this EIP 7612 uh and some we have to discuss some rules about how to handle 7702 um delegations there. Uh then we have a followup on a topic that we discussed many sick calls ago about uh the atomicity of cast charging in 4762. And finally we have also for that

EIP uh some discussion regarding access lists. So yeah let's start with team updates and I can start as usual. So from my side, I I've been working for a while uh on some refresh on by code chunking in general on the protocol level. Uh most people here already know that code chunking is already part of EIP6800. Um but I also to do some kind of refresh of like what this is this problem about for the community and our potential solutions. Uh mostly

motivated on some later sentiment on some people on maybe being less aggressive with protocol changes and just thinking about which are other options and different trade-offs. So this article was published last Friday. I will share it in the chat if anyone is interested. Um I don't think it is worth maybe presenting this in this call because I think most people here are already quite experts on this topic but yeah the idea was to open the the discussion for for more people uh to be aware of this problem and I've been also helping

um Kev on some worst case scenarios benchmarking for CQVMs um which are mainly the same worst worst case scenarios uh as for any kind of proving system in layer one. So yeah, this will help to understand better the the potential challenges on these other kind of uh potential stateless solutions. Um yeah, that's mostly it from my part.

Yeah, I guess I'll go. Um, I was working mostly on getting PRs into GU. Um, now I'm waiting for them to be reviewed and merged. So, I'm going to stop for now because yeah, there's already like five or five PRs uh awaiting uh review. Um otherwise I was also working on um trying to rebase nonetheless rebase guess um that sorry rebase the the calian with chappella branched onto uh onto let's call it calian with spectra um and uh yeah that's ongoing and otherwise uh yeah there were some spec rewrites uh

but I called in guru for help um so I guess uh we're going to um yeah, we're going to discuss that this week, I think. Um but yeah, like the goal is to rewrite EIP 4762 because it's um it's quite unreadable, frankly. Um and then on top of that, we want to add 772. So, there was some investigation on 7702 that needs to be added to that EIP, but we're going to do everything at the same time because like I said, the old format of the like, okay, the current format of the EIP is pretty ugly and unreadable.

So, we want to revamp it to to add 772 there. Um, yeah, there's probably a ton of other things, but that's the that's the main stuff. Um, so I guess I'm going to go next. From my side, I've been mainly trying to work on two things in particular related to the test net that the people from Nethermind have uh put out recently. The idea is mainly to try to recreate uh a similar thing but we actually explore uh state growth limits. I'm trying to do two things. The first one is assess the data that we want to collect. So basically there's a

bunch of data that we we can just collect from the chain history but there's a bunch of other data that will just get evaporated if we don't collect it on time. So for instance RAM performance anything related to networking and I don't know not not particularly interesting in any case but mele data could could be another good example of that. So the idea is to try to see which is all the data that we can collect. Uh behind the scenes the goal is clear. Uh if we want to achieve uh statelessness, we definitely need to know with which urgency do we need it and with the EIP that Dankrat um filed a few days ago uh proposing to arrive to 100x if I remember correctly the gas

limit. It would be interesting to see where clients actually break because they cannot hold the state anymore. Uh when hard hardware upgrades are needed and all that stuff. So for that I've been working on spam uh the tool from if panda ops and basically I've tried to compile the cheapest ways to include uh state or to make the state bigger on ethereum uh on a gas per bike uh level and I've been writing uh the scenarios for that to bombard the network and on another side I'm trying to work on a on an application that allow us to replicate a more uh realistic state growth uh replicating mainet

transactions mostly and trying to block the state by two three 4x whatever we we need. So that's basically it. Uh I think I can go next. So another mind side I completed the rebase on pectra and now I'm uh merging the transition code in it. So this week I'll finalize those changes and then I'll start uh working on the binary implementation. on business side I was able to also replace uh ver with spectra so thanks to that I was trying to do a migration on hoodie um I'm not able to validate the state route we are generating for the

moment but just to see how the current code is working when we have to migrate some leaf for each block uh thanks to that I was able to fix several issue in my transition code and I also saw some performance issues during the stateood computation when we have a lot of uh leaf to to migrate in the tree. Um I'm trying to do some optimization on this part. Uh not a lot because maybe the cryptographic part will be modified in the future but yeah a minimum kind of modification and uh yeah still working on that. still have some issues to to fix and uh on the stateless part. So Toma, I don't

have the last update, but Toma is still working in the uh stateless part of Bizu and mostly uh regenerating the tree from the um witnesses and Anyone else has some some update to share? Okay. So, let's move to the next

uh item in the agenda which is data collection points for FATNET. Um Carlos already touched a bit on this in his update but I will let him explain maybe again what is FATNET, what is the goal here. Uh yes, I I'll be very quick. Um Nethermine basically uh as you might know uh set up some perfet couple weeks ago. They did an amazing job and basically they they were trying to see how much how big of a block the the network is able to to handle. The idea is to create uh a similar network or a fork of it or something like that where we can actually uh specifically target the state growth metrics and state

growth as as an issue to see how much the network can handle when things break and to collect as much data as we can that we find interesting. So in order to do that I've put up uh this hackd uh I've already added some stuff uh that I had or or the team mentioned that I think would be interesting to collect. Uh I would invite you all to basically add anything. Everyone has uh edit rights. So please share it with anybody that you think can have any ideas or we'll have the I don't know we have some some valuable insights of what data will be interesting to collect as basically it's expensive and hard to run these

things. So we will not have many chances to to collect this kind of data and I assume it will be valuable to do so. So I invite you all to to please collaborate and and add any data points that you think are interesting to be collected. Thanks. is anybody already thinking about some particular metric that they think is useful uh regarding the state growth in this kind of high pace uh kind of dead nets. um if not we can touch again in a in a future SQL but you know maybe

already there's some idea here I think probably the first thing is sync breaking like we want to know what state size sync will break or snap sync I guess yeah that's a that's a good point and a point that Gon made too so for that I will probably chat with party because um since everything that includes networking is a bit tricky here because we try to have not many machines but those machines doing a bunch of work um and as to my understanding a snap syncing

uh there's a big component which is network and your view of the network uh so I will chat with party and ask if we can have I don't know many more machines that that don't do the same amount of work but they are there to to kind hold or or participate on this process. It will be a bit tricky I assume but but yeah I agree it's it's useful information. Thank you. Do you mean sorry do you mean the work of generating the transactions? Oh no no I mean the work of supplying you uh like history to some way so that you can sync.

Uh yeah. Yeah. Um yeah, I was just thinking we, you know, like a client that downloads uh that downloads uh that tries to snap sync usually doesn't have a lot of peers to download from because they're still looking for it. Um and I I think most clients I forgot there's a cap for clients. It could be 20 or it could be 50 or maybe 100. But what I mean is we could create, you know, if it's about creating 20 machines and spread them all over the the world. Um, sometimes in data centers, sometime with just people uh just people running like a machine for us. Um, it could be

actually pretty easy to simulate, I think. Okay, let see what Perry says. But uh but I think even with 20 machines, it would not be too hard to figure out what it takes to to download uh to snap sync the the state. Uh another thing I wanted to mention is that to test the snapsync, you actually need traffic, right? Because if your blocks are empty, then snapsync will not have a healing phase and potentially that's um that's going to be uh not very realistic. Um so we need we need like uh a lot uh of transaction touching different locations of the state to make sure that this is this is stressing the

the snap sync. Thanks. Okay. Uh let's move to the next discussion which is yeah a followup from uh a conversation we have in the last call regarding um skip uh some conversion of state in some particular accounts. So as a refresher in the last call we have some confusions about um okay so originally the EIP7748 which is the conversion

EIP said that um whenever you find an empty account um you basically skip them in the conversion. But after some discussions uh we already knew that these accounts uh do not exist in mainet because they were already deleted um by some action that Peter did some years ago I think already. Um but we also knew that Gary was interested in other kind of accounts. So there was a bit of confusion there. Uh so after the call um Giam kind of got more into the details and talk with Gary

and I think we now have a more clear picture of what we really want to do in the EIP and he already did some changes. So maybe you want to give a summary here. Um yeah I just realized I should have prepared the EIP itself instead of the but yeah just as a summary. So, um the type of accounts that were um that were not uh okay, sorry, I'm typing at the same time. I shouldn't be doing this. Uh let me share my screen. Um uh yeah, this one. Okay. So uh to to start the I don't know if you guys can

see my screen but to get back to this conversation there was uh the CIP7610 where uh it tries to delete uh or it wants to delete actually that's not what it does. It's trying to avoid a specific corner case that would happen when um okay for this to happen you would need uh a hash collision to begin with. So it's also not very uh likely to happen at least at the moment. But in the long run um it turns out you do have uh accounts in the state that do have balance right and they have storage but

they have an empty code hash and uh those accounts were not deleted by Peter Miller. So what we want to do because it's effectively inaccessible at the moment um it's um we want to to delete them during the conversion and the reason uh the way we do this is by changing the spec. I'm looking for the line that was uh that was done. Um it's uh just checking if the account if the the account nons is zero but the account and the account code is zero we just move to the next uh to the the account

conversion phase. So we we skip the storage conversion and this way uh if you do have an account as described in 7610 that is basically an EOA with storage you will not convert this um there's actually I realized saying this a potential issue um with 70 uh with 7702 exactly uh accounts because if they get uh deleted Um yeah if the if there's a delegation that happens some code that runs storage slots being created and then the delegation is deleted uh we lose those

things. So in my view that's fine because we are uh still having an account that is not uh that is not um yeah like that that has storage that cannot be accessed but it could be accessed in the future. Um, oh right, that's true. The nons is not zero in that case. Good point, Karen. Uh, yeah. So, okay, that solves the problem actually. Um, so thank you for that. Right. So that's just what it is. There are some slots that we will ignore and that's because they they cannot be accessed. So um so yeah, that's that covers 7 uh that is not related to 772 is very good and that's all there is. Um

so I think unless you had a way to talk about those accounts that was nice. Uh yeah it's an invariant. If an account has zero zero storage sorry as a nonzero like non- empty storage and a zero nons then uh it should not exist and will be removed during the or will be cleaned during the the conversion because uh the the account itself will be translated but the storage will not. So it will be it it will disappear. Um yeah, that's pretty much the there all there is to it unless there are questions. I guess not.

Okay. Okay, cool. Um yeah so eventually we should add uh tests for these changes so I will make some notes to eventually cover these new scenarios. Um, cool. So, the next discussion is about something that we kind of touched in the last [Music] sele. So um in the previous um call we were talking about implica like some side

effects of 7702 and at some point we discussed what will happen in the overlay tree whenever a 7702 delegation is removed right so let's imagine that we have a new some 7702 to transaction create some delegation. When that is when that happens, we need to write um the delegation as the code of that UA um and also update the code size right and the code hash. So the question is whenever that delegation is

removed clearly we should change the code size again to zero and the code hash again to empty but there's like this question on if we really need to clear out the delegation itself in the code of the UA or not really because technically speaking if you see that the code size is zero, you can assume that there's no code.

Um, but yeah, uh, like my personal opinion about this is that I would prefer to clear out the code in any case. um despite it might not feel entirely entirely like needed because I feel like it it kind of keeps the tree a bit inconsistent. um because I know if I make a proof of the first chunk of the code of the EUA I will see that there is a delegation but actually that delegation doesn't ex is like doesn't apply because I will have to also check the code size uh so I don't know it's most it's mo

like my opinion is mostly based on some more coherency argument rather than a strict need of doing that so I if anyone else has an opinion about it. Um, I do have an opinion that uh is contrary. Oh, was Tanish going to say something? Okay, maybe there's just a flicker on my screen. Anyways, uh yeah, my my opinion was uh we that the reason why we should not is a bit uh trying to do some, you know, keep things cheaper by not paying the gas because if we

update the if we change the value to zero, we have to recomputee the well, we have to add it to the witness. We have to recmp compute the the commitment and so we have to pay the gas for it. Um, and that makes the operation that much more expensive, which is okay, fine. It's 200 gas. Sorry, it's 700 gas. Uh, yeah, it's just that the question is um I guess I'm going to contradict myself and I guess and change my mind. Uh, the other argument is that yeah, some implementations that want to check for a delegation might go straight to the to the code hash directly.

uh and decide sorry not the code hash but directly the code itself and if they see that the first uh bite is a delegation and they don't check the code size that could be that could be a problem. So actually, yeah, I'm changing my mind and uh I agree that we should clear it even though it's more expensive. Cool. Yeah. Uh okay. So if that seems to have some consensus, we should probably yeah add this uh clarification in the EIP whenever we do the whole set of 7702

uh updatings in all the APS. So we we leave this clear. Okay. Um let's move to the next topic which is uh yeah talking again about this atomicity of gas charging. This is a topic that was discussed some sick calls ago and there was some um testing that Giam wanted to do to really assess the complexity of doing this change in G and share that with the rest to to really decide how to move forward. Maybe you want to continue on that.

Uh yeah, I'm just sharing my screen again, but it's going to be very short. Um here we go. So like we said, uh we have I created the NIP. Uh I still have some testing to do, but from what I can say, I can tell it's pretty it's pretty uh it's working very well. Um and it does simplify the code, the guest code. um maybe not significantly but quite a bit. So it's uh it's always nice to have. Um so my guess would be my suggestion would be to change the spec. I think last time everybody was more or less okay with it already. Uh but I just wanted to follow

up on this and say yeah it's been looked at. Um so one thing I would mention is that I did that branch and I I tried um running all the all the execution spec tests that we have um and out of the 530 and so test only 99 failed uh I've started looking at them one by one. It's pretty tedious. Uh so far I could every single test I've looked at uh confirms that uh it's like the atomicity um is why the test is failing. Um but yes, I'm going to have to go through 99 tests to make sure that I didn't uh get into a

corner case. But from what I can see so far, um it's um it's correct. um or at least it's it's doable and and and it simplifies. Uh so my suggestion would be for other people to have a look at it because yeah, it's going to take me some time to to go through 99 tests. Um but yeah, from what I can say, it's worth that other clients implement it and hopefully we can uh we can resolve this this question fairly quickly. Um yeah, that's pretty much there is to it. Um, if you have questions again, now is the time. Um, right. Tanish was not

convinced. Um, but I think that was for a different reason, right? Tanish you remember? Yeah. Yeah. So my reason was that if we are uh like if you're charging gas and in atomic conversion what happens is like let's say you need to add two leaves and you don't have the gas for two leaves but you're paying for one leaf so that one leaf should end up in the witness. That was my argument. But again the thing is that like I'm not sure if that one leaf end ending up in witness is useful to anyone. It's just that it's feels like a more correct way to do it because someone is paying the gas for that leaf. So, it should end up in witness. But, uh, yeah, I think I'm fine

now either way. I can try implementing atomic charging in Netherland as well. And yeah, we can Yeah, I mean, it's true. It's a bit unfair. Um, at the same time, like you said, no one's going to no one is going to use it at all. Like, there's nothing you can do with that really. um it's making the the witness that much bigger for no good reason. And um yeah, it's like you know if if you have I mean the counterargument to this would be for example if you if you write um an S uh you do you do an S store right and you only have half the gas available do you write half the half the data? uh you don't right you just have to either

you've read the entire data or not so I think making those things atomic given the complexity of those uh of those tests we have to write um I agree it's a bit unfair but it's not making any difference to the to the end user except uh yeah they don't see their pretty they're pretty um leaf in the witness but that's is so it could it could be a pain for debug. That's true. But yeah. Yeah, I think it makes sense. But I don't think we'll be able. Do you also want to do this for the uh code copy or Xcode copy hash codes uh op codes as well? So in my implementation uh and unless I made a mistake that's

exactly what's happening. So if you look for example at uh um where is that going to be? Uh yeah probably EVM. Um if I uh right I have a to-do but um yeah at the moment I actually don't Yeah, I'll take that back. Um I uh I Yeah, I checked. Exactly. Uh I do it one I do it leaf. No, it's a touch code chunk range from zero to uh Right. Exactly. Right. So indeed like for a code copy or even contract deployment what happens is that uh I will not deploy any code or uh if I

can't get the entire thing that's um yeah that's that's unfair I agree but once again witness bloat and uh maybe um how do you call that consistency with the behavior of writing uh half half a you know a storage slot. Yeah, that makes sense. Yeah, I just want to say regarding the tests. Yeah, definitely if we do this change, you must see some test failing because in the test I actually had to cover all this like partial witness scenarios.

Sorry. And since this was filled with this non-atomic charging, the test are is is it is expecting some partial witness, right? So, um yeah, just yeah, maybe try to do some quick confirmation. That seems to be the case. Hopefully with the test names, it should be pretty clear. Uh but if not I can help to yeah double check if those are the right tests that should be failing. And if we do this change um the only thing that uh that we have to do is to actually refill the existing tests and yeah just um like make a new release.

Apart from the testing side, we have to actually explain this in the EIP, right? Because the EIP doesn't have any kind of explanation about automicity of charging regarding the witness. Uh the current style of 4762 is simply explaining um yeah kind of individual additions to the witness. So yeah, this should be explained in in the IP maybe as part of this refactoring that we'll we'll do regarding using Python for describing the rules or something like that.

Exactly. That that was my plan. Uh precisely because when it's going to be written in Python, you will have to make it super clear. So that's that's when it's going to happen. Um, one quick question is, um, since you're here, uh, 90 like those 99 tests, is there logic, you know, when you when you've wrote all those tests, uh, and where they are, um, they were designed specifically for for failing on on an on the boundary on a leaf boundary. Um is there logic for them so that I could maybe you know cross them out um like cross out multiple tests at a time and not go through every 90 99 test in which sense

like um yeah like are they grouped in the same file? Uh, do they have this a specific name that I could use to Yeah, I think yeah. Um, I don't remember from the top of my mind if they're in the same file, but definitely with the name it should be pretty clear, but yeah, we can check offline, but it should be easy to identify them by name, I think. Okay, cool. So this basically means that apparently everyone agrees on doing this change. I just trying to make this clear because all EL clients will have to do some work uh around this.

Um yeah so if anyone is opposed to this change this is kind of the last call for Okay. Um I will still say that the conversion work is the most important part I think for now. Uh but yeah, if in the background we want to do this change probably it will be included in a probably the next DevNet that we might plan.

Um cool. Um okay so the last item in the agenda is uh 4762 and access lists. So I will explain a bit this. So I was working on yeah some other stuff and I realized that 4762 doesn't explain anything about the relationship with the access lists and what I'm referring to concretely is the following. So today if you use access list to warm a storage slot you pay uh 1,900 gas for that right so technically with access list

today you can yeah warm up and a storage slot with 1900 gas uh I was looking at with 4762 implemented and the way it works is that we basically disable all access list logic basically. So that means that if someone sends that same transaction with access list trying to warm up a storage slot, we won't charge 1,900 and we will simply charge the new 14762 gas costs which is uh 1,900 from the branch uh and 200 for the chunk

access. So this basically means that if someone is trying to use a a storage slot through access list, they will pay more uh than today for that and that means that we might be breaking some contracts. Um so yeah, I mean since the doesn't clarify this at all, I think I I wasn't sure if this was intentional or maybe it was a miss. Um but definitely we should make it clear uh in the epic. Yay.

Um yeah, so I went through the history of all those things um that um all those updates to the to the EIP and in the original draft there was a mention of access lists. Um but yeah, I I guess that was me or okay, I don't know how it got dropped, but it was definitely dropped. Um what I can tell you is that it wasn't saying much. Um but just basically we like access well okay one of the reasons why it got dropped for sure is because uh it was saying access list should be an SSD um and that wasn't pretty that wasn't clear at the time there was I think Ethan that was trying to push for SS type transaction so there was a lot of

visibility so maybe that's why me or whoever um did that change uh dropped it um so we could reactivate this uh okay we should reactivate this and we should implement it um yeah I guess that's it that was just a historical context right so I guess that the idea is to like not really this wasn't like an intentional drop of of of the charging right so we should probably add to the IP that whenever a access list transaction happens we will keep charging ing those cast cost as usual and in the EL client

implementations we should add them to the witness right that will be kind of the TLDDR of the spec change. Mhm. Yeah, we still have to think about it because there was something you didn't do before with access list. Okay, so the initial access list uh mention I I went through to look for it. It was not mentioning um gas cost whether they were disappearing or not. It was just saying access list are SSD based and that's uh that's pretty much it. Um the question is should we add um you know the value to the witness? I guess we do because we're adding the access list uh to the because we're paying the cost anyway via the access

list. We should add them to the to the witness. But at the same time the access list is going to be to to be found in the block. So we could bloat the block for half the price basically. Um I think we have to to dig a bit more into this like we we have to think uh more into this. Uh yeah, I think we can also simply like um maybe this is complicated things, but we can definitely warm up the cost and not really include it in the witness and just let the usual execution do the inclusion if that storage slot is ever accessed.

uh that will be better for the witness size because if you put the storage slot in the access list and you never actually access it uh we are not blotting the witness but I'm a bit more yeah it sounds a bit complicated to add this border case of like warming up some gas cost without including the thing in the witness I don't know I I feel a bit more um worried about that creating bugs maybe. Uh yeah, me too because I'm not sure I got what you said. You say like if we you if we put the access like if someone sends a transaction with access

list, we would not uh add the thing to the witness but then we still need to check that the what whatever was passed as the access list is valid, right? So we still need it to be added to the witness. Did I understand that correct? I mean, do I understand what you said correctly? And do you agree with my problem? I I I mean yes, like not including anything in the witness up front even if it is in the access list, but just like keeping like some mark somehow that if that storage slot is accessed, the call cost that we should charge is access list cost and not really 4762.

Yeah, but that's where uh I don't think that's going to work because when whoever reads the access like the the cost, whoever re-executes the block to to validate, they're going to have to go and check that what's in the access list is indeed what uh what you know is presented. Ah, no, wait. They don't have the value. They don't have to go and read. Yeah. True. No, no. like they they just have to keep in mind that whenever an a storage slot is accessed they have to check if this is in the access list and if that's the case instead of applying 4762 they simply apply whatever the access list EIP said just that yeah

true um okay I think what we should do is have a spec update proposed spec update and see if people agree um I don't know if anybody else has an opinion on this, but I think it's actually Yeah. something that was in our blind spot that needs to be uh needs to be dug dug out. Yeah. Cool. Yeah, I agree. Let's let's do like some kind of a spec uh proposal change and we can discuss it in more detail and more clearly maybe next call and we can check that everybody agrees on

that. Okay. Um this was the last item in the agenda. Uh we have around 15 minutes left. I know if anyone wants to raise some other points uh feel free to do it. No. Okay. So, we can finish uh earlier. Um yeah, thanks everyone and see you in the next call. Cheers. Bye-bye.