Stateless Implementers Call #40

Transcript

Hi everyone. >> Hello. >> Hello everyone. Cool. So, it looks like we have the recording going, the note taking going as well. We're going to wait uh a minute or two to, you know, allow people to join and we'll get started in a in a minute. All

right. Hey, Karim. right, people are still

joining. So, I'll once that stabilizes, we I'll get started. Uh, yes, Karim. Cool. Let's get uh let's get this started. So, welcome everybody to stateless implementers call number 40.

So we actually skipped the last one because uh lots of people were away and then we it was overlapping with the other call but we yeah we are doing this one. So the the agenda has been shared and we are starting with team updates. So whoever would like to go first can go for it. >> Um I guess I'll start. I'll go. Uh oh, Karen wanted to go. Please, please. >> Okay. Could you hear me? Yeah.

>> Yep. Yep. >> Yeah. Okay. Um so I was working on the implementation of the binary tree with Thomas. Um so integrated this implementation on Bizu. We fixed several issues. Uh normally we have a node that can follow hoodie. Um so it's a it's a fork of the hoodie network but we are just uh creating new block um and uh trying to compute a state route with the binary tree. We are not validating the binary tree but just to to know if we can manage the roll back etc. So for the moment we it's it's working sometime we are finding some issues we are trying to fix them but in

general it's working. Um I also used some tests generated by by Gum. So it's just simple test but just to verify that uh the basic logic is working correctly to to insert some some leaf in the tree and verify if we have the same statute as get. So for the moment the uh this small number of test are working correctly and in parallel I'm also trying to do um a transition with a binary tree. So I started also a node um on the shadow fork of hoodie uh doing a transition and uh yes the same for the moment uh it's working uh

sometime I have some issues so I have to restart but uh for the moment it's working and I also had some performance issues during the transition because amount of leave was um too big so I implemented some optimization to do the all of the transition logic between two block not waiting for the block in order to do that and know it's better it's not perfect but it's clearly better uh in general the block are taking three 300 millisecond sometimes 200 millisecond but u it's better than before and uh there is still a room of optimization that we can do so yeah for the moment it's all uh all the stuff we

did um on this side Good. >> Sorry. Um, yeah. So, we uh managed to get some stuff merged into G. So, yay. Uh, there's still some uh a lot of work to do, but the transition itself is next. So hopefully uh whatever test net gets created we'll be able to to join it. Uh maybe not from the start but uh hopefully hopefully at some at some

point. Um and uh there was something else uh yeah so there's a few there's a few things that are going to be merged next uh including the binary trees. So like Karim said, uh I started creating a document that I will actually it's not on the agenda yet, but I I would like to add it at the end just to talk about it very briefly. Um it's a document explaining uh uh the like showing the tests um describing tests that you can do to to verify that you get the same route as GU and and BESU because yeah, Basu is passing them too. Um so that's the the few things otherwise uh Carlos is not

here today so um we're still just going to give a very short bloke net update um we're still uh so we we reached the size that is twice the the size of mainet uh and now we're proceeding with uh writing the the tests there's a document uh with the test that has been published. Uh if I can find it, I will share it now. Um yes. So if you if you can think of more tests, uh please add them to this document that I'm currently sharing. I hope it's the right one. It's the right one.

Um and yeah, we have uh we are going to to start writing those tests. I mean, Carlos did start writing them, but we're going to continue this week while he's while he's gone. Um, there's more stateless consensus updates uh to do with uh with code chunky analysis, but uh that's for way to uh sorry, that's for uh to uh report them. That's it. >> Uh I think I can go next. So on nethermind side we finished our work with uh transition but on work trees uh it was working properly but was like quite underperforming. So recently we did a lot of refactoring on the client

on how we handle state and now it's a much it's much easier to implement uh the transition with binary trees. So uh and we have like we have not worked on state test for a while now on mind. I'm starting to I'm off next week and after that I'll be starting to work on like the binary implementation. >> Nice. Thanks. Uh anyone else would like to give team updates? >> Yeah. Uh I can give mine as well on the set of stay expiry and uh just like Gil mentioned co-chunking as well. So I think a few weeks back um I presented the results in I think last call or the

last two calls um but there were some minor changes on the results. So basically we increase the sample size but the conclusion still remains the same. So um basically um the the proportion of bytes and chunks util utilization is is very low. So that means that if we ever do code tanking it would it will achieve the benefit that we hope to achieve. Um but if anyone wants to like read the whole thing again here's the document. Yeah. And I've also been working on analyzing the state access patterns on mainet. So an article I'll publish an article as soon as possible. But there were a few interesting discoveries. For example, um

I found out that half of the EOA and contract accounts were only accessed up to four to five days and 70% of the total storage slots were only accessed once in a single block. So um yeah so there were other discoveries which I'll publish in the article but the this data basically strongly suggest that if you ever want to do some form of CSR or even some other forms of temporary storage on on the protocol level I think it would be somewhat impactful at least on the state side of things. Um yeah and then on the state on the side of state expiry I'm currently benchmarking the knife

printing method in GF and I'll also perform the same thing in other E clients. So yeah that's all from my site. >> Great thanks for the update and thanks for sharing the link in the chat. So yeah, I think that completes the these updates unless someone else has something to to say. All right, looking good. So number two on the agenda u and y added as a fifth point the thing that you mentioned with testing documentation by the way uh the new test net is second in the agenda.

I'm not sure who is uh driving that but I I've put it on because it was requested last time. >> So on the PU side so as binary trees for for the moment is moving forward. Um I think maybe at the end at the end of the month I think it will be okay. Uh we also implemented some EIP that was missing uh not some modification regarding the gas the gas cost uh something that was implemented on get and not on biz. So we did also this modification. So I think maybe u yeah maybe in one weeks I will be able

to share a docker image of bizu working with binary tree may normally with all of the configuration. Um so like that we'll be able maybe to start a test net with Bezu and uh yeah should be maybe I think in one week it should be okay if I didn't find any more issues and if everything is working correctly. Yeah I think it should be should be good. >> Awesome. That's some uh exciting progress. Good job.

>> Yeah. >> Anything else on the test net point? >> Right. I mean just repeating so yes first of all very good job Karim on this work um I think Bas is going to be leading the the work on this one like um I did say we we have merged some uh some PRs and guest but I don't think we'll be ready in a week um so I think uh basu should take the the place of that guest has used for every virtual test net or at least everyone I can think of um and just be the the lead on that and GU will will try to catch up. Hopefully, Nethermind will will as well. Um, but yeah, like like I said, it's going to be

very hard for guest to to be uh ready this month. Uh although it's looking a bit better, but still still far. Uh, one question I had though is about uh the thing we've discussed. I think that was last call or two calls with Felix um which was about changing the behavior of uh of system contract/system addresses um I don't know if you guys remember but it was about saying as soon as you call uh system contract we we don't record anything um sorry as soon as you make a call from a system address we don't record anything Um, did you guys implement this

in Bizu? >> Yeah, you're muted in case you were speaking. >> Yes, sorry. >> Um, could you could you repeat again? Sorry. >> Sure. Uh I don't know if you remember but a few calls back maybe last one uh the Felix from GU was there and we talked about how to handle system system contracts or system uh system calls um and we agreed to change the spec.

There hasn't been an update to to the spec uh in the EIP yet because you know there's still in the background there's a 46 uh sorry 4762 revamp that is uh very complicated and taking a lot of time. Uh but um maybe I should go ahead and edit the current uh EIP with with the right wording. But the idea is that we would not be uh as soon as you're calling um a system contract. You don't worry uh I'm trying to remember the exact details but uh yeah there there's a different

handling of system contracts. Um, and if I if I remember correctly, that just means as soon as it's a system call, you don't touch uh you you don't record anything and you don't add it to the witness. >> I don't think we implemented that. No, I don't think I need to verify again, but I don't think it's implemented. >> Okay. Um, I would have to go back and remember what we agreed because there was like at least a >> Yeah, because I'm not completely sure. Yeah. Yeah. but we should uh if we do a new test net uh we should enforce this new policy and also ideally update the 4762. Uh but like I said 4762 is going to take a bit

of time to to revamp. So yeah, even though it's not in the spec, we should we should go ahead and uh and behave the way uh the way Felix would like, which is to not uh yeah. Okay. Honestly, I don't remember the exact details every time. Uh every time it it takes me a few minutes to remember what it was, but the idea is that >> Awesome. Now if we can just add that in some AMD like that we are sure that it will not be interpreted differently in some weeks.

>> Yeah that's a good idea. Let's uh let's try to write it down >> maybe maybe in yourd that you shared before but just we're in one place and we'll try like that to verify if it's like that in VU and uh we'll be able to confirm it. Yeah. >> Yeah. Um okay awesome. I think that's pretty much all we want for this new test net. Um like I mean apart from the binary tree and that uh that tweak I think that's all the changes we want for uh from the the previous test net.

>> Good. >> Perfect. Sounds good. Thanks. Thanks everyone. So fourth point on the agenda is uh I think Yugi it's about chunk based code Malization EIP 2926 uh right let me see if I can share my screen I have a tiny presentation uh Uh oh, that's the one. Yes.

Can you guys uh can you guys see it? >> Yep. >> Excellent. Um yeah. So I would like to talk about uh this AIP 2926 uh which is not completely stateless related. It's only partially stateless related. Uh the context is that it came from a conversation in Berlin between uh Tomas uh now the executive director of DF and myself about how to to get um vertical or binary trees shipped and Tomas was saying um you know what's the most important aspect that we could use right away and I said that would be good

chunking um which explains also why Han has been working on on this topic recently Um and um yeah, so we we we realized that maybe it's a good idea to try to to push in the code chunking aspect first in Glamsterdam. Um and so uh I went ahead because now it's a tradition I guess for the for the stateless effort to to go back in the history of abandoned EIPs and resurrect one that uh was kind of what we wanted.

and uh and make it our own. Um so that's the case of 2926. Uh it's code Merkelization. Initially it's been done by the former formerly the epsilon team um Cena and and Axic from from the the epsilon team at the time and uh the idea is to introduce uh well it's pretty simple. It's intro introducing codealization in MPT. this EIP was formerly abandoned and uh in the last month month and a half uh I led an effort um um that uh that tried to resurrect this EIP get the approval of the in the

people involved and see if we can uh if we can push it for for Amsterdam. uh this is this does not preclude working on uh on uh binary trees or even vero if if it ever comes back um in the future for further for further forks. But the idea is that uh we could ship it uh in Glamsterdam and at least get that uh the benefits of having CO right away and then um we can um work on a tree conversion at a later in a later fork.

Um so this should be just okay in theory at least it's just grabbing the code chunking part from from uh from ver or from binary trees and putting it in the MPT uh and u there like thereby delivering a lot of the changes that we would have uh uh delivered with with so yeah like Karen just asked and and Han answered um the idea would use would be to use an MPG and so add add a new sub tree. Um we keep the 31 byt chunk with one byte push data. We presumably although uh I would love to get people's

opinions on that we would we would keep a 4762 um at least for the chunky execution part and uh we would still require some some kind of overlay transition but because there's only about 10 gigabytes of code uh the the conversion itself could be a lot smaller which is great because um because it would be uh it would be uh demonstrating that the transition works. It would probably make the life easier uh the life of people involved uh I mean all of us uh involved in delivering stateless Ethereum a lot

simpler for for a further further tree change. Uh I see a question by Karen the key will be based on code hash not address hash. No, the key will be based I mean I'm going to show I'm going to show the structure in my next slide. So you have two t two types of uh EOAs um of sorry of accounts. You have the EOA and the conference. And the EOAs they don't really change. I mean they don't change at all. In fact you still have the nons you have the balance you have the code hash and you have the storage route. Um but for contracts uh we add uh two extra fields. we had the code size and this is so that you can directly go and get uh and get the the

code size from the from the account. Uh this is something that was already mentioned in other EIPs like 7 7907. Uh that was one of the solutions proposed for for some of the issues in 7907. Um so so yeah, I think it's a good one. It's one that we also use in binary trees and vertical trees. So, might as well use it. Uh what's what's interesting is that it's just an extension of the RLP. So, it's not uh it's not a big problem to to add this and it's only for for contracts. And then we had another uh field which is the code route.

And the keys in that MPT are uh simply the the chunk numbers uh except the last one which is the version. so it's at um yeah two 2 to the^ of 25 256 minus one. Um, one uh thing. Yes. So, uh, Karim was asking, will they uh, okay, it's not directly the question that Karim asked, but it's, uh, the the the keys are not hashed. They're just regular numbers.

Uh, and the reason for that is because we don't worry about the unbalancing of the tree because there's still the code size limit and even if we extend the limit, it's never going to be too uh too imbalanced. Uh, and you can't really attack the tree. Uh, it's just a sequence of of chunks that uh that increase. Um, of course, I assume this is the question that will come later. Uh can we uh can we somehow uh because every account that has the same code like two accounts having the same code will have the same field. Do we want them to uh to have um you know the the tree duplicated? I guess not. So

that's an implementation detail. Uh but presumably we could I mean this is already what we do with storage. We we store the the the storage tree outside of the of the account tree. So we could do the same thing with the code and not duplicate the data. Um but yeah that's the that's the general idea. Um yeah so just uh pressing on the differences it will be an MPT tree. Uh it is a new subree so not everything is uh spread over the the main tree like we do in in veral. Um and there's the question of the version which is currently in the tree. um if it's the question is whether it's RLP encoded or

not and which encoding it's going to be u if it's RLP encoded and the version is zero and it's encoded if the encoded is to just write a zero instead of a 0x80 um then effectively there would be nothing in the tree at that uh at that uh specific uh key and uh that would be uh that would be that would mean that until we start getting accounts of with version one uh the the key issively missing from the tree. So I think that would be a good compromise there. Um but yeah, I'm open for uh I mean I'm open for comments on

every aspect of the of the EIP of course. Uh but yeah, if you have an opinion about the encoding of the version, please let me know. And uh is there a new question marim? How uh how will the code be shared during sync? I mean it's exactly like we would share it for um for um what was that called? Uh for the storage trees. So we just add uh it's it's just a new tree. We have to recmp compute the root. Um, so I guess we would have to add either some kind of message but at the same time not really because we can use the same thing as the as the storage tree. It's just a different route. Um

so >> my my question is do we want to share as as today just share all of the code and by code ash and we recreate the MPT locally or do we want to share each chunk one by one and we >> yeah because if we for example if you have a flat DB just sharing all of the code it's maybe better >> I'd say as long as the code limit hasn't changed But of course this is a change uh one of the advantages of uh the sought after advantages of going for this uh for this approach is that you can remove the the maximum code size limit but as long as it remains at 24 kilobytes there's no reason to change

the way we do it. So indeed like we could just get the code rehash it it's not going to be that much um and then uh and then recomputee it. I think if we start having code sizes of several megabytes, um, we might want to and probably before that, we might want to just do it, uh, exactly like we like I described and like we do for storage trees, namely that uh, no, we're going to get uh, we're going to get the code like chunk by chunk and then rehash everything in the end. So, I guess there's going to need to be in the future some evolution of Snapsync. Um, but currently it's not really necessary.

>> Good. Are there other other questions? are you at the last slide of your presentation or >> uh yes sorry that was that was the end of it so just have a look please >> thanks so uh to kind of recap how much closer this gets us to the the the end goal uh so one of the advantages is that well we then have the the the actual code in in the state uh but the is but also about kind of showcasing that we can make a transition happen and do do you foresee the like the buyin from the community as easier or or this

smaller scope EIP rather than for a full state transition or you mentioned that this will make it much easier for us at in the end and I'm I'm wondering why. >> Uh yeah, exactly. I mean um first there there are several ways of getting buy in um or at least there are several ways that I think this will get buy in for for further updates. The first one is indeed uh there's some irrational fear that the transition is too complex. Um I think you know Karim uh I I actually not sure if uh Tanish has finished with the trans. No, yeah, you haven't. Um but uh

Karim has done it. Uh G has done it. So you know we know it's pretty safe. Um there's a lot of uh influencers that think that uh we don't that it's too too risky, too complex to etc etc. So I think uh if we can come up with a first smaller scoped transition and prove that everything uh is fine uh that should uh that should help people realize that uh how simple and really uh fairly safe that thing is. Um uh also prove that you know it's it's well

tested and uh and that we we can go with it. Um the the second reason I think it's a good um it's a good argument for for stateless is that it's um it's solving the problem of the prover the prover killers uh for which the the community okay some people in the community are extremely excited about real-time proving and even though I'm uh quite skeptical we can we can achieve it uh in the next uh years um at least uh we're removing a hurdle by doing this and uh based on this proving that we we brought uh real time proving closer we

can also make the argument that you know binary trees or even once again vero if we can find a postquantum way to to do it uh would be um would be a further advantage and get people a lot more uh um like have a lot less quanss about this about this whole transition. >> Good. Good. And if we were to answer the question of what are the tangible benefits that this provides without considering things further down the line, what would you say is the best way to like convey that, >> right? Um so yeah, I mean I'm just going to reformulate what I said. Uh but it's really that um you you have a simple and

uh a simple and well thought out way to to introduce uh code uh sorry to remove the code size limit. Um you have a way to uh um only like create some witnesses where you only load the the chunk of code that you that you need. So like I said, you can expand the code size limit maybe not indefinitely but by a lot as long as you only add what you need and what you actually need for execution in your witnesses and uh it's much smaller. The other uh reason for doing this is that it effectively solves uh like I said the prover killer. So right now you have uh

a very cheap way of killing um of killing provers by just doing Xcode size on very large contracts. And what will happen is that the ZKVM needs to load the entire contract and hash it. And that's a huge performance hit that they take when they have to do this. It's very cheap to do. It's very difficult to prove and uh it's uh in the past it has taken down the the provers um like crashes or some of them took 30 minutes to pro to prove a block some of them just uh completely died. Um so so that's not uh I would say these are the

two tangible benefits. It brings it brings zk closer uh safe zk closer and uh and yeah uh code size limits can be can be removed or signific significantly expanded. >> Great. Great. Thanks. >> Awesome. Any other comments or questions on this uh EIP 2926 or should we move on to our fourth point? All right, let's move on to the next one is uh I'll I'll lead it. It's the it's about the stateless summit. So, long story short, I I prepared a pitch

and a Google forms survey that we will be sending out to uh teams that could have an interest in a stateless summit. So the teams that are in scope would be uh a lot of tooling teams for example like our RPC providers um like wallets uh pieces of tooling like that like tenderly or you know things like that and I have a list on on the Google doc that some of you has have seen and the idea would be to gather interest in a potential stateless summit and not only interest as participants but also what the topics would be um interesting for people both on like statelessness and

and state expiry and also gather interest for people who want to present something or maybe lead discussions. So initially we were kind of scoping that as interest for a buenoseris dev connect uh stateless summit. Uh we want to make it so that it's not mapped to that specific uh event. So, we'll just send out the survey and we can ask in that survey if people are going to go to Devcon connect, but it's not going to be like mapped to that uh specifically. So, uh yeah, GM, I noticed you're still presenting in case you're not not aware.

>> Sorry, just realized, but I have something to present afterward, but sorry for Perfect. Yeah. Yeah, no worries. U so that's it. there's been some some comments on it, but it seemed like people were fine with the wording and with the with the the survey itself. So, I'll be putting that into a like clean clean form today and sending it out this week to the list of teams. So feel free if you have any contacts or people you would know would be interested uh just ping me and I'll be happy to like include them in that uh sending out the there is an open question about whether or not we want to do this at Defconnect

Buenos. From what we've heard it seems like the focus of Dev Connect is going to be more app uh focus and less core dev focus. So we uh and from judging different people in the telegram chat, it seems like there's not much interest in going there. Would you say that's accurate, GM? >> Um this is actually um yeah, it's kind of it's kind of accurate. Uh so you you people might not be aware of it yet. I mean, I'm only aware of it for sure since last Friday.

um they are going to make Dev Connect really about apps. So this is this seems to be like the final decision. They were toying with the idea for a while. Uh now they're going to really make it about apps which is okay a good thing. Uh simply um you have to recognize that Argentina for most developers Argentina is really far. Um and so the early uh interest uh like we we try to gauge for early interest and the the feedback has been that indeed uh if there's no protocol development um people are not going to to bother going to to Argentina. Like I said it's

it's really far. Um, so what we would be maybe doing uh is either if there's enough interest like since uh since Gabrielle said we're going to send send out the form and see what uh what comes back either we make it very uh app focused um or we make the stateless summit at a different time uh somewhere where there will be more protocol devs. Uh the one thing uh the one place like now is uh is CC in uh in can next year which should be in March. So it's not too far off

from now. Uh but yeah, like there's no decision as to when this would this would happen. Uh currently we would like to see if there's going to be enough people going to Buenosirus to to wear this, but from what I gather there's not that much interest. Uh so if you if you are interested, please let us know. If you're interested in going to Buenosirus and feel like you would like to go to a stateless summit, we want to we want to hear from you. >> Yep, exactly. Uh thanks for that. So yeah, I'll be sharing the final versions of all these things in the chat this

week. we can tweak the final wording and and questioning to have more or less focus on on Devcon connect. But uh yeah, please like this is the time to reach out to so that we don't crystallize a decision that you know people might be unhappy with. So this is your chance to speak up either like right now or uh this week in the chat. So yeah, I think that's all for the stateless summit unless someone has anything to mention. Cool. Sounds like that's it. Uh we're at our last point uh of the call. Uh Guiam uh at the beginning of the call you

mentioned that you had some uh documentation regarding testing to share. So the Mick is yours. >> Yeah. Um so I created this page for binary trees. So I shared it with um with Karim. Um it's pretty simple. I want to keep expanding it. Uh for example, account plus storage uh the the account plus storage section is is empty right now. Um and uh but yeah, sorry. So it's it's incomplete, but at least we uh we we have some tests that you can verify you get the same the same results. So I'm

going to uh share it just now. Uh I don't know if um I forgot which link. Uh can I just Yes. Right. Copy. That's it. Uh so I'm going to share it in the chat. Uh if you have any comments uh or if okay so if you want to implement the binary trees try to use this right. So we have the input. So you insert at that key and you and you insert that value at that key and you we we give you the root hash. Uh it's a bit incomplete but we also make a representation of uh of the final tree.

So you can compare the structure to make sure you at least conceptually you agree with what's being displayed. We only do it for some of the trees but uh yeah that needs to be completed. Um, but yeah, so for your information, there's this page that exists if you if you want to like I'm especially thinking of tennis because I don't think anybody else uh is looking at it uh is looking at the implementation right now. Um, but yeah, if you if you want to implement it uh or maybe also Gabrielle if if you want to do it in JavaScript. Um, yeah, if you want to make sure we all agree before you before joining the test net,

that's a that's a good starting point. >> Thanks for that. Any any questions? What uh what GM is showing? All right, thanks. And I just see you shared the link in the chat. Perfect. We'll make a note of that.

All right. Uh, we still have a little bit of time before the time closes, but there is nothing forcing us to go all the way to the end. So I would close this down unless someone would like to take that opportunity to discuss something relevant. All right, nice. Uh we're finishing early then it sounds like. So thanks again everyone. Uh that was uh the implementers calls number 40. I'll be sharing the summary of the call and we'll be sending out some tweets later

this week. Uh thanks for attending and nice to see some some of the work particularly like congrats on all the you know testing progressing the bloat net uh bestu being able to lead that test net. That's uh that's great. Nice uh nice job everyone. and thanks for leading the the call again. Thank you very much. >> Yeah, you are welcome. All right, thanks everyone. Bye bye. Thank you. Bye.