Stateless Implementers Call #29
Stateless Implementers Call · 13 Jan 2025 · 26:53
Stateless Implementers Call #29, held on 13 January 2025. These calls follow work on stateless Ethereum and the move to a new state tree, with client teams sharing progress and open questions.
Topics
From Stateless Implementers Call, hosted by Ethereum Foundation.
Transcript
all right hello welcome to stateless implementers call 29 this is issue 1247 in the PM repo uh yeah we can start things off if there are any client team updates maybe guom you want to kick things off uh sure yeah just collecting my thought so uh maybe in um going back in time uh from the from the most recent uh ignasio has been working on a tool to do a lot of measurements about Prides um we can we start getting some results but we're not quite ready to publish them we will definitely talk about it next
time um otherwise before that there was a publication of an EIP draft that you should all have received a link to uh if not contact me offline I will um I will send it to you uh yeah so the the goal was to get some clarity and uh and into what we you know what veral was competing against and um so that we we could have a list of trade-offs and make a proper decision uh so there might be some questions like we we have some time at the end of the of the the sick to to discuss that I'm not uh the one who
wrote most of the most of the IP so uh yeah if you have specific docu questions about the document we we'll wait for ignasio to come back he'll he'll make a presentation but of course I know the I know how it's supposed to work so yeah if there are general questions I can I can answer that uh otherwise I was working on the rebase um to of of our Branch onto the latest um guest master so I I produced a couple PRS but as always in gu they take forever to to be merged and uh yeah that's pretty much it uh I think
yeah I can free if you want I'm going to go ahead okay thanks uh so on bizu uh K you muted if you sorry is it better sorry so I was saying it will not be long for bizu just uh so Toma is still working on proof validation so cleaning this part so he didn't have time to work on it yet but uh normally he will uh try to focus on that that during the next
week uh so when we will have that it will unblock the stateless part implementation in bizu so I started the refactor of bizu in order to simplify the statel integration so I have a pi that is ready and uh I will have another Pi also just to add the stateless part uh we are also trying to clean the ver Branch having all of the new and P test to Green so we are close to have all of the Test passing uh so it's it's it's really it's really it's really nice to have that because before the vle branch was a fork but not really we didn't uh have time to test all of the all of the test suit so
no we are trying to have everything clean and we also mer the flat database based on stem and uh as I I don't know if I already said that but bizu is running in the devet with this uh flat database uh for the moment everything is okay uh Lis is also um finishing the block Ash gas cost modification so it's almost ready uh it should be finished in this in this week and yeah me that on b side uh I can go next on other mind I
don't have any significant updates I was uh looking at other things for the past few weeks uh but like NE my client is following the devet 7 properly and in the upcoming weeks I'll start testing work sying and stateless execution on the new cool any other updates all right we can move on uh agenda item number two Gom you had a jump related issue on the current test net that you
wanted to get into yep um so while working on all that rebase um I was also actually trying to refactor uh the proof generation to be a bit more efficient and we ran into this uh this bug uh it's actually active on the test net so you guys should look at your code to see if you've got the same problem and I'm going to share my screen to describe the problem uh looking for my uh window as always uh is that the one uh sorry just a moment it's always um um ah interesting the window is not
part of the uh uh of the list no okay that's the one okay sorry about that um so what's happening here is that uh we had a problem that when the the code was a valid jum destination was an invalid jump destination we would uh charge access um access cost and uh then it and uh what we did instead to because we thought it was more correct is that we only uh charged this
okay so there was a bug in our Branch it would be charging the the access cost all the time when the jump was invalid when the jump desk was invalid even when this was not vertical so to do this I activated uh the P 4762 switch to to protect this from to prevent this from happening and we this that activated a weird bug in which uh if you are in a deployment context it would um it would um charge the charge the the gas cost uh so if I'm not mistaken but we we can take this you
know to the to the channel of course but just so so that you guys uh should be aware there was no protection for deployment which means that if um if you are and this happens on the test net as far as I can tell if you have a deployment code that jumps somewhere to that is not a valid jump Des it will charge the costs when um it should not or the other way around I forgot no exactly it would not charge the cost um yeah of course as soon as I speak about it in public I get confused but uh the IDE is there there's there's a block around 1,400 where there's a an invalid jump
desk and gas gets charged when it should not uh right because it's deployment so it should not be charged and it is charged that's it um so just for your information uh if so many clients were able to join the test net that means that presumably you've got this bug as well so uh please look into it I can uh I can copy paste this um this uh issue for you to look at um but uh yeah please please have a look because we would like to I mean we will have fixed it for the new test net and uh yeah we just to to make sure we agree uh no none of the execution spec test
was we're covering this because it's a very very intricate uh thing that we just found um but yeah once again please have a look and and make sure we're all compatible um yeah Lis yeah I think I remember this was the last time that we agreed that a failed contract deployment could still charge for has some gas charging for the statelessness uh I think I I need to look into that I'm that that happened the last year so I'm not I don't trully remember uh but what would I mean what would it be charging for because it's got I mean okay yeah we can also take that offline but yeah if if it's
deployment then there's nothing to add to to the witness right because it's not a space that belongs to the the permanent state so you should not uh you should not be adding anything and if you're not adding anything presumably you should not be charging the cost for that but okay let's um yeah that was the point just so that you guys are aware uh we can we can take that offline it was just a heads up cool is that all you had on this
Gil yep um yeah I guess it's uh continue on with you for agenda item number three around rebasing for the next test net yeah um so there's a couple things um I have to look for the window again but the the first one was to uh go like do a round uh of like asking all the clients if we do a rebase for the next test net and once again gu is not quite ready for that yet but do we want to do it on top of Cancun or do we want to do it on top of Petra which hopefully happens in the next two months um I don't know I'm going to call
call out people and you can tell me uh for example carim on Lewis what would you what are you ready for um so what are we ready for uh I think we are ready for the next test net I don't see any well the block hash uh is still not fully working but I'm not sure I don't think get is also has that implemented or does it um because we were following the heads the previous test net so yeah it should be it should be implemented unless I'm not aware of unless I forgot uh um I mean the the new gas costs scheduling for for Block crash with from
the system contract ah right that one uh so that's that's the thing I want to talk about okay next but uh apart from that uh yeah okay so no we don't have that you're right um and it's not implemented in G but yeah in that case that makes no difference whether we choose um pect because we need it on the veral test net anyway so it doesn't uh yeah if it's not completely ready inside the master Branch it doesn't matter because it's it's going to be implemented differently in uh at least for us in uh in a post spect sorry a post veral World from a
post Spectra world right we we're not calling the contract I don't know if you guys are calling the contract but we we are not no no just speaking from Storage yeah um okay Ginder just say we we can do Petra because we have most of oural code in master lucky um I just wanted to say except that also we are close to the main branch so I don't think it will be problem for bizu that's nice okay so Petra would be and I guess it makes uh sense to to stick to Petra the the only problem with Petra actually none of us is ready uh but
that's going to be my next Point uh we need to support oh wait 7702 is part of Petra right I'm not making this up um correct okay thank you um so if that's the case then we need to solve one more issue to do Petra but we we have time we can still do this uh just before I wanted to ask Tanish the same question like what do you prefer uh so I think neand is the current work implementation is already rebased on Cancun so that is good but I think we can do p Petra as well it will be a bit slow on NE because we recently made a lot of performance improvements or like
uh like in General design changes might take some time but I'm I'm okay doing it on Petra as well okay so canun would be your your preferred uh yeah yeah that would be preferred but I think Petra is better else like we'll just keep lagging behind one FK every time so yeah no yeah uh yeah it's better okay I mean depending on how long it takes guest to to merge my PRS we might be uh we might even be talking about OA but yeah um Okay cool so now I wanted to talk about uh the other like basically this question of 7702 so looking for the window
again um here we go so there was this uh update to the EIP I don't know if you guys can see it um it's for eof but actually uh same thing applies to 7702 and the question was uh do we need to like how do we identify an a 7702 contract or an eof contract and um so Dano gave some input here which is uh you should read the E EF z00 approach um I was considering to like at least in the
initial version of this draft to use a different account uh account version but I don't think after all it's a great idea because um you have to you know I ideally the account versioning would only change when you have a different type of account and not when you have a different um code model um so the alternative would be to just read for example when you have a a code an xcode hash you would need to read um first the code like the first chunk of code to check the first two bytes and if those two bytes are ef01 for in the case of 7702 then you know it's uh it's a um
it's a 7702 contract where it's a bit wasteful is that you can guess that just from the hash right you can read the hash directly and say oh this is a 7702 contract so I need to jump and go to to a different uh to a different uh I mean you need to read the code again I guess you need to read the code no matter what so in the case of 7702 yeah it doesn't matter how you do it but you need to read at least the first chunk and the first uh and the code hash uh yeah the code hash um yeah so basically that's what that's where the thinking is I'm also copy
pasting the the link to uh to that um to zp um I was asking Adrian earlier today so I don't know if you want to to talk about this you don't have to but um I I was a bit worried that uh you know we would we would have to spend another 200 gas for just a code hash but Adrian was saying it doesn't really matter because it's not very it's not called very often if I if I summarize it properly okay I guess doesn't want to talk uh that's fine um okay confirm that is your
feeling um so uh G you were saying uh the hash would vary with delegation address I don't think it does or is it an update I'm not aware of that if that's the case yeah okay uh my understanding but it's it dates back from uh September last year is that you have to read the the first chunk and if it starts with ef01 then the next 20 bytes are the delegation address but the hash itself
is uh not the hash of uh of that but it's the hash of ef01 just ef01 uh just the the way eof has the the the code hash regardless of what code is stored is always ef0 which by the way kind of goes into the direction of saying well yeah we should we should use a different version because clearly the contract storage is not exactly the same it's not the same kind of uh of account but um yeah that would Force us to read yet another um uh yet another uh leaf and I think it's a bit wasteful at this uh at this
point even if ideally for future proofiness we should be reading the the version all the time um yeah I think I think we shouldn't really uh we shouldn't do it right now um okay so get gender confirm it's always the same value okay um yeah so okay my my current I mean please have a look at this at this uh PR tell me tell us what you think but the idea is that uh my preferred approach right now would be to just read the first so not add a new version but um read the first bytes of like the
first chunk of the code and the code hash even in in the case of an xcode hash and then return the return that um yeah unless there's comments I guess we can move on so what would be added to the witness would be the like that value you just written you just wrote uh the cat Shack like this would need to be in the witness because the whoever replay the blog has to go to the has to go to the to the code hash leaf and read it to
realize it's um I mean it's being returned if I'm not mistaken when you call the X code hash you need to return Ah that's a good question I don't remember that from the top of my head if you do an xcode hash on a uh an account that is a delegated account does it return the code hash right I remember talking to Matt about this yes it does return the code hash of the delegated account so you need to read both values uh you need to read the code and the code hash no you don't actually so you just need to read the code actually and then go and get the code hash of the account uh that you are delegating
to okay that needs to be to be double checked but if I understand correctly this is the this is the course of action um yeah I have to check that and uh and we can uh settle this question next time hopefully but um from what I understand yes you you would just need to read the code first check that it's a delegation and then add to the witness the code the code hash Leaf of the target account to the delegate the delegate excuse me the delegated account yeah exactly for every code hash
we read the first two bytes and then we do the next thing exactly okay if there are no more questions um I I know what I have to find out uh do we want to have a couple like do people have question about the EIP draft that ignasio published knowing that he will make a presentation about it next time but uh um if there are some top level questions I'll be happy to to answer them this is the binary tree EIP yeah
I guess also just more of a meta discussion around larger question here um yeah like there's been a number of conversations on this topic over the past few months and I don't know if we maybe the idea Gom I think that you hinted at earlier was just having sort of opening it up to a little bit of a Q&A and just seeing if anyone has thoughts that I've that they've been marinating on since um since the new year or yeah since the holidays but maybe we save it for the for the next call and we can get more into the meat of it all right no takers I guess
yeah I guess we can wrap up and have the presentation next time yeah yeah I mean clearly it's um it's one of the more important topics for us to get internal Clarity on um binary trees path to statelessness all of that good stuff um yeah I think we all um sort of understand and want want Clarity on that and figure out the best path forward for us internally as we continue to uh discuss organize calls and and work together on this so maybe it's what we actually use most of the next call for Guam what do you think yeah I think that's uh what we should do indeed okay cool well thanks everybody for joining can end it there and uh talk
to you soon oh actually uh Joshua sorry uh since we have some time uh could I ask something as well uh um uh yeah so that's for gilam um I wanted to ask what's the situation for the call codes that question that I asked last time so I think we landed on not removing the costs for call code when there's a value transfer but I think last time you said you were going to check with uh with someone if why was that removed um yeah no I think we okay I I'm run into that code uh two days ago um yeah I don't remember the answer but let
me uh I'll check it up and uh and sync with you offline if you don't mind ah sure no problem my understanding is that yes we are not charging uh if I remember correctly what I read two days ago uh we are not charging uh we like because the call code has zero value we're not doing this charge anymore we're not doing this okay makes sense makesense sense okay yeah it makes sense either way because you also don't want to make the call code more uh cheaper or if you remove it be you can also remove it because we're not transferring anything we're not updating anything on the on the the storage uh but yeah so I just want some clarity on
that whether yeah which one to go should we stay here or should we leave it like this or should we modify it okay we'll we'll think offline anyway thanks well all right see yall later yep take care bye