Stateless Implementers Call #45

Transcript

Loading developers...

All right, let's get this uh started. So, thanks everyone for joining. This is stateless implementers call number 45. Uh we skipped the last two due to well, first death connect and then some other unavailabilities. So, it's good that we're meeting up again after I think it's been six weeks almost. Uh yeah, I linked the agenda in the chat. So we are going to start with team updates.

Team Updates: Discussion on recent work, including scaling L1 and binary trees

So whoever wants to go first, the mic is yours. Uh from my side, I've been mainly working on scaling L1 stuff. Uh trying to write more scenarios on east. Also wrote down some scenarios in spam to bloat uh ERC20s. Uh to do some tests related to contract size. um contract storage size and besides that I'm also working on a new page on the lab uh which basically will contain a a state analyzer tool um to analyze growth and some other metrics.

>> Nice. Thanks Carlos. >> Anyone else? Uh yeah, I've been working on the implementation of uh binary trees in um in G. Uh we managed to produce the executable. We had a conversation with Mario uh although it was interrupted but we had a conversation with Mario in def connect where we wanted to uh use the weld. Um but uh yeah we haven't really started working on that yet. Uh maybe we can take a few minutes to to discuss what needs to be done after that. Uh but yeah, that's that's roughly what's been going on.

Good. Thanks. Anyone else? All right, I guess uh that's it for team updates then. So this moves us directly to our second point. So the second point is something that I think Carlos has had initially uh brought up but I think Guom you wanted to take that conversation up uh and lead

Code Chunks in Binary Trees: Debate on code inclusion in tree leaves

it. It's about code chunks inclusion in the leaf of the binary tree. So to recap uh and correct me if my understanding is wrong is that currently in the the current leaf redesign what we have is the first 128 bytes of the code associated with the count that is included in the basic leaf uh the the first leaf of the tree. This means that the part of the code is there and another that the rest of the code is chunked away and left in you know separate leaves. Uh this has some advantages but also some downsides. So the advantage is that you you can access

as soon as you access the account you have those first code chunks which are maybe the most used that are available there. But the big downside is that if you want to optimize your tree and store uh contract code that is identical across different accounts then you need to store it in in all these different iterations. Whereas when you have the code fully uh modular modularized from the account then you can store it in a single place and refer to it from the account. So the suggestion here is to move the con the code completely away from the account basic data so that it can be you know uh uploaded to a separate place where it can be uh

effectively like compressed and only stored once for multiple accounts. So yeah GM do you want to take it on? >> Yes sir. Uh great intro. I also made some presentations so there's going to be a lot of repeat. Sorry about this. Um, still looking for my window as I usually do. Okay, that should be it. Um, right. So, um, you know, I just wanted to do some some recap. Um, and um, I apologize because uh, I was stuck in the meeting before. So, I I hope I I finish my slides on time. We we shall see. I'm

sorry if there are mistakes. Um so as a reminder in vertical or binary trees everything uh every item account item is at its own um its own uh offset and we have the basic data which contains the code size the balance the nons uh it's off the code hash is at offset one um and then you have the first slot which is offset at 64 and uh everything in between is reserved for now. Uh and then uh the slot number 63 that offset 127.

Uh and then for slot 64 uh and further on we move to a main storage offset which I think is 2 to the^ 31 something like this. I forgot uh exactly uh the value but it's a very large value and so any subsequent slot number will be uh an offset beyond uh beyond uh beyond this big value and then uh at offset 128 we have the first code chunk uh all the way to 255 and then when we reach this thing um you get main code offset which actually is a mistake is just overflowing the the the the

group and then main code of code could of set is effectively 128 and then it continues. And so in practice that means that if you look at what we call the header group we we have the hash of the address plus the first 31 bytes of the offset that we hash and we take the first 31 bytes that gives us the what we call the extension stem and extension node. um I forgot exactly and then from this node it has 200 uh 256 children and the first one is the basic data the second one is the code hash then there's the reserve stuff then you have the first slot all the way to slot number 63 and then you start with the first chunk

of code all the way to 127 and everything else overflows to a different like if you have more code or if you have more um more storage it will overflow to different uh different groups um which uh will keep the same address but we'll have an offset that overflows the first bite. So the the offset value here will change and so you will find yourself at a different node. Um and then uh and then you will start writing. Um what okay what are the advantages and inconvenience of this of this approach um is that um well the biggest thing the biggest advantage and the reason why it

was created um is that it's quite compact if you have a small contract uh with only a few slots that are just at the beginning and uh the beginning of the address space and not too much code uh you will find yourself that you will find everything is is in a single uh tree node. Um but uh of course if it goes beyond that uh it will expand uh to different tree nodes. Um the cons is that clearly the the code is duplicated because if you have um the same code deployed multiple times for in multiple accounts this part like from C 0 to C127 potentially this will be duplicated.

So what we wanted to propose um is that um we uh just go over um we we just uh move the code. So we try to dduplicate the code basically and uh we create this main code offset that is not no longer 128 but something a bit larger. And so all the code chunks will be um in a specific group uh and not partially merged in with the what we we call the header group um so that it can be dduplicated. So we reserve like whatever we freed from the from the code

uh we put it in uh in um in the header group like we use sorry we use storage slots to uh uh sorry the the slots sorry the offsets we freed in the header group for uh the main um for for from the code we use it for storage instead. So instead of having 64 uh the 64 first storage slot, we get the first 192 and then we continue the the thing the technique of overflowing to a different uh storage offset.

Um but uh the code yeah like I said is moved to its own thing. So if you look at what it uh looks like the you still have the the address of of the offset which for the first uh 25 uh 256 chunks will be will be zero. Uh I think I no okay um but um yeah uh you only have storage slots instead of having um code and the code itself uh oh there there's a mistake like I said there will be a mistake. So instead of being the address, you remove the address part. So sorry about that. This is wrong. You just have the trunk offset. Um and actually it could be the it should be

Code Storage and Tree Node Issues

the code hash. Um and then if you have the code hash instead of the address and the trunk offset, that gives you uh a new entry in the in the tree where you have everything uh all the code you you want. So um there's a few issues. So as I was working on this I discovered there's quite actually quite a bunch of issues with this. Um the first one is that yes the code is uh dduplicated but um that means you have to create an extra tree node in any case and as it turns out taking Han's uh measurements you can see that actually the vast

majority of contracts actually have a very small uh amount of code which means that in the vast majority um it would uh it would fit um it would fit into uh into the account header. So we would be expanding the the amount of three nodes uh at the cost of the duplication. Uh the other problem is that yes uh if you got uh like the the moment you need an extra tree node is shifted by 128. So not only do you always need an extra tree node uh but on top of that you will need a new one uh much sooner and like I

said it's the same picture we even those uh those accounts will uh will overflow to a different node. So even though there's not that many of them um this use the case will be uh will be u uh problematic. Um there's also and I think that's the last one uh 7702 that would force you to create one extra group for for a single single slot. And the reason for this is because um you would need to just uh like there's only one code chunk uh which is 23 bytes and uh you have to you would have to create an extra group. So I was thinking you could make an exception for

these but if you start making exceptions you might end up uh going back to the first uh to the first model anyway. Um the other advantage and uh yeah okay I'm sorry that doesn't the picture doesn't display entirely on the screen uh but the idea is that u the there's actually a lot of duplicated code so ultimately there might be a benefit um unfortunately because of diff connect and all those things I did not uh I did not quite uh measure it yet so uh there will be a follow-up but um Yeah. So I was actually thinking of mitigations uh if you only store the stem and the

commitment. So basically you don't store the code inside the tree uh like inside the database. Of course the code is stored in the tree but you don't store it inside the database. uh you could mitigate this but I'm not sure it's really going to be impactful because you still have to store the stem and the commitment and that's going to be uh to be quite uh quite uh I mean that's going to be taking some space um but yeah and you can even make the same uh technique uh apply the same technique to the current uh the current approach and uh if this works for the other approach this would this work for the current So we uh we should be uh um how do you call it? We we should be a I mean they

should be neutral basically. So there's no mitigation that doesn't benefit the current the status quo. Um and so my conclusion uh that unfortunately I didn't have the time uh but I need to do uh to do uh measurements and find out what is the final size. Um ultimately this could be attacked if you keep uh deploying uh more contracts with the same code. So even measurements are only going to inform us as to what the current state of uh like what what would be the benefit of the current uh approach versus the current implementation um of um the current implementation?

Sorry. The what would be the the benefit of the current uh version of the translated state versus the the proposed uh version uh proposed current version of the of the transl translated state. Uh sorry I'm I apologize it's still it's still jet lag. Uh yeah. Okay. So what I mean is uh yeah we would have to make a translation in both using both algorithm and see which one is is the best but uh it's going to only be a translation of the current state and if we don't uh like they could be attacked and we would have to think about this but ultimately

currently although I would like to know people's opinions um if there are some unfortunately Karim is not here and Tanish is no longer working another mine. Um so um I would like to know your opinion but I guess uh it's not worth it. Uh but we have to make sure um and uh like I was saying it might be interesting to explore if we don't store the node uh uh the code uh inside the the tree itself. that might save a bit of the database, but that's going to be even more productive in terms of of uh the current proposal. Um so yeah, ultimately after considering it, I don't

think it's a good it's a good approach. Uh but yeah, I'm happy to hear dissenting opinions if there are some. So what was the reason initially for the current status code in the MVP is that code is stored you know locally in know client databases it's not part of the tree but only the code hashes and code size the my understanding is the whole reason for moving to a state tree where we have the code was for statelessness so I Right.

Statelessness and Portal Network Considerations

>> Right. So there's the code itself uh putting it in the tree that's for statelessness. But the reason why everything was merged together uh that was a portal network consideration. Um, and the idea was that uh if you're going to have to download your stuff from the network, you might want to be able to download the minimal set in one go to be able to start somewhat executing um or at least do something about the the account uh with the account, sorry, be excuse me, before you um or at least while you download the rest of the of the code. Um so that was like trying to increase the locality of the contract.

Um, now unfortunately we no longer really have any effort maintaining the portal network and anyway I don't think you would be able to uh you know even even if it was there uh I don't think it's such a great improvement anyway because uh you would have to download everything because if uh and and that's typically the case if your contract is a jump table that says you know the the prologue of any of most solidity uh of solidity contracts is getting the getting the um the input data which is a function uh function uh hash use that to go through a big switch case and then jump

somewhere else. So the the benefits of having local contracts is only very limited to the to those contracts that are very very small of which there are many um but uh yeah they're probably not the most popular either uh from from Han's uh Han's analysis. So I think um yeah like I said I I changed my mind on that but I I don't think uh it was a very good uh it was an interesting I mean it was an interesting design but it also creates a lot of complexity in the code because you always have to check oh wait am I lower than 128 chunks if I am then I have this special processing step

otherwise I do the other processing step but I have to shift everything by one by by 128. Um so ultimately um there were good reasons to do it but uh but yeah it's not uh I'm not convinced. Let let me put it this way. >> Yeah. Yeah. Yeah. It's good to rethink it that that clears uh things up. like if we if we made these decisions based on assumptions that are no longer true, then it makes sense to kind of rethink rethink it a little bit. Um yeah, I think it's worth having maybe some of

the others in that discussion. by yeah it what what are we what do we want to make a decision like what additional data would help us make that decision >> um yeah so I think uh and like I said I'm sorry I should have made me measurements and I hope to have them for next time um but uh yeah like what we need to know is uh try both approaches and see what makes the bigger tree and I think if one of the tree is bigger um is significantly bigger then we just need to drop the whole thing uh like we we just need to go for this but like I

tried to say and once again u I fumbled with my explanation a bit um but I think the um yeah if um it's attackable so anyway we can't just make a decision based on what a simple translation was or is we we have to uh we have to see how much it cost to to go over the limit and uh make the the other model more interesting. >> Yeah. Yeah. Yeah. Good.

Yeah. Thanks for presenting. Maybe someone else wants to to chime in. All right, then. G Oh, G, were you going to say something? >> No, I was just going to say uh I don't know if you hear the beeps, but it's K inviting me, but he's he's he's not uh he's not working today. So um yeah, I guess we will share the this the the presentation recording and and see if we can get some uh some feedback offline but

>> I think yeah >> yeah we can keep that conversation going I think or during other calls the good so I think that's it for this step of the the agenda. Um I have a third step that I had noted. So I'll just go through it. It's a fairly simple thing. So uh def connect happened um well two weeks ago. The this was an opportunity to get in touch with more you know app layer teams tool tooling teams infrastructure teams. I wasn't there myself but I know that some some of the team has had the opportunity to to get

Devconnect and Team Communication Strategy

in touch with some of these people. Uh initially our goal was to create points of communication with as many relevant teams as possible. Uh the suggestion was to do telegram groups with all of these teams. Now I think what we're aiming to gain from these is like insights into how people use the state, how they consume it, and what compromises they'd be able to accept in terms of like state expiry what that would look like and the economics of it, the incentive mechanisms. uh I think it's going to duplicate a lot of effort if we create individual channels because we're aiming for the same feedback from all of these teams and I don't see any downsides from just creating a general like external teams uh telegram group

where our team can interface with all of these teams at once share progress that is relevant for us and get feedback there and maybe like these teams can also interact with each other I don't think that's uh that's an issue And it's going to be so much more manageable than creating like 15 different channels. Uh yeah, curious what you think or some others. I have already shared that in the chat but wanted to get people's feedback. I mean happy to to have a single channel more more channels like uh what is it?

Every time a new uh a new angel is sorry a new ch channel is created an angel dies. So >> yeah. Yeah. Worming to kill just one and not 15. Yeah, that's fair. That's fair enough. Cool. So I'll I'll try to round up a couple of the teams. I don't want to create a channel and just have like one team on it. But once I have like a threshold of maybe five to 10 different teams or with like BMs and all that, I I'll create the channel and have them join aiming for a few DAPs, a few tooling and a few like more general infrastructure or whatever.

So yeah, I'll follow up uh hoping to have that live like definitely before Christmas. Oh yeah, for the next call in two weeks. Still only 1 of December. So yep, that's it for my particular point. Uh so I might just give everyone 30 minutes of their time back unless someone would like to take this opportunity and use the call for another pending question. Oh, I see in the chat Mario had a question for Carlos just asking whether u you found any issues or blocker with

east. >> Uh none uh for now we are completely fine. So that that should be mostly it at the moment. Thank you for checking in Mario. >> Sure. Yeah, please reach out if if you find anything. Uh we are revamping the execute command at the moment. So I think there's going to be some changes. I hope we don't break any of your workflows. Uh but I'll keep you updated uh if if if there's not something from your end that needs to be done. Y >> okay I assure I mean uh from Nethermind Camille ran the state tests I think yesterday and everyone everything went well. Uh anyways, if something needs to be refactored, ping

me because I'm refactoring some benchmarks to be compliant with the transaction gas limit cap introduced in uh Fusaka. So I will be already doing this this job anyway. So um it's fine if there's something else to do. >> Yeah, if you need um some preview, I think I think this refactoring of the 16 million gas cap is going to affect a lot of the tests. So if you need I I I would like for us to have like the same uh solution for all the tests. So if you can send me the PR or maybe send it to Louis also and we can take a look just to make sure that we're basically doing >> the same approach for us. Yeah,

>> I I did some work for spammer and um I sent it to Louis. The idea is to wait for Louis to actually check it and see if we go with that or if he plans to do something else so that we don't duplicate work. All right. Yeah. For spammer in particular, I would also reach out to um PK from bandops. He's the mastermind behind. >> Yeah. Yeah. It's merged already. So with PK, everything was sorted out and we are already bloating uh ERC20s with the fusaka limit and the solution that I implemented. But I don't know if that's what we want to have uh in eels. Uh so yeah uh just waiting to hear from Louis and from there we can move forward.

>> Sounds good. Thank you. >> Perfect. Yeah. Thanks guys. Um yeah so I think that's it for this call. Uh yeah thanks everyone for joining. I'll be Gon or you gonna say something? >> Yeah sorry just a very quick thing. Uh Mario, I will be inviting you to talk about uh like try to finish our conversation from Dev Connect. See if we can uh get something started to to have binary trees with with the new uh welded uh execution spec.

Discussion on Binary Trees and Execution Spec

>> Sounds good. I think um are you in the steel uh discord server? >> The discord server? No. Uh I can be in that matter most at least >> I can send you >> please >> I can send you uh an invite. So what we can do is maybe start a channel there because all all of the eels uh team members are there. So they they can we can tag them and then we can start a discussion. Um but we do have something in matter right? Is this um >> we have something in matter most but if we do it in Discord we could actually get Karim as well which I'm sure would be interested.

>> All right. Okay. Good. I'll send you an invite. Yep. >> Good. Thanks everyone. That's it for this call. Uh we'll be posting a summary of this call in the stateless book and a tweet probably this week. So, thanks. Have a good rest of the week. >> Thank you. Take care. Bye.