Stateless Implementers Call #37

Transcript

Hey everyone, welcome to the stateless implementers call number 37. I will share the agenda in the chat as a brief summary of the agenda. Uh we have the usual team updates and then we'll have two presentations. uh one of them is uh an impact analysis of VIP7736 by Han and then Carlos will do a presentation of the new bloet uh website and uh related metrics. So yeah, let's start with team updates. Uh I can start uh I've been mainly working on more CGVM um tests

coverage. Um, I'm starting to think about them more related to tools that will help us figure out potential gas repricings rather than fully like worst case scenarios. So, it's a kind of a bit of a mix between the two. Um but yeah because like we are already starting to cover a lot of not uh like a lot of up codes that clearly won't be like worst cases but I think there they will be still really useful to understand relative costs between up codes and see if the current gas codes makes make

sense. So yeah, I mean focus mostly on that. Um yeah, I guess I'll go. Uh not much to announce on my side. Just work on uh doing the binary tree. Um well, the implementation is uh done and matches what Ignasio has done. Uh but now I'm trying to fill the test so that other people uh can see if we agree uh so that we can you know hone in on an implementation. I know Karim wants to do the next uh shadow fork with uh with

binary trees. So it would make sense to to agree on that. Um I was al also doing a bit of work on the uh pythonification of um of EIP 4762. So yeah, Yam uh Gabrielle and uh and Louis gave me some feedback. Uh so thank you guys for that. Um it's a bit slow in uh the integration because there's always plenty of consequences. Um but yeah, it's it was very useful. I'm glad I'm glad I asked for feedback because uh it was needed.

Um and um yeah, I think that's pretty much it for this time. Um I'll go next. So from my side I've been basically coding the spammer uh use cases or scenarios for bloating in particular EOA to EOA transfer uh funding with minimal weight plus then delegate author authorizations uh on a batch uh format and then also uh contract maximum code size contract deployment. Uh finally I've added also next code size base attack to force the

node to read as many bytes as possible paying as less as possible. The rest of the attacks will likely require um manipulation of the note or the database directly. So um waiting on those and on the other side I've been also working on the bloat net which I'll showcase later. Um not much to say aside from the fact that it's mostly ready uh pending to integrate graphana uh interfaces from most of the teams. Uh if the thing is easy if there's too too many issues with privacy and permissions and all that stuff I guess we we will just post a link and that's it.

On business side I was working on the transition. Um so I'm trying to set up a real shadow for with package uh not just following hoodie but really creating block etc for for the moment without proof but just create block like that. So the wall stack is ready but I had some performance issue with verel during block creation. So it was it was a little bit difficult to do the shadow work with verel. So I decided to not really waste time uh optimizing vehicles since we want to switch to binary tree and uh I want to directly um use binary tree for the next shadow fork. Uh so I'm

trying to see with Tomar uh we are trying to to propose the first implementation of the banner maybe this week or next week and uh when it will be ready we'll try to pass the test uh that Gum will create and when it will be okay I will continue to work on the shadow fork uh directly with binary tree I will start with hoodie and when hoodie will work smoothly I will be able to do the same test for mainet. So why I'm trying to do this kind of real shadow fork like that other client I think it will be more easy for other client to join to test uh to verify the state root etc. Um so yeah still still working on

that. Anyone else wants to give an update? Okay. So, next we have um a presentation from Han regarding EIP7 senses 36. So, Han, whenever you are ready. All right. I'll share my screen. All right. Cool. Yeah. So, um, today I'll like to quickly share about um, one of the analysis that I've been doing for

EIP7736. Basically answering some of the questions in regards to how effective this um, proposal is and also to answer some of the key questions that we have for CSR in general. So uh as a recap or or for those who are not too familiar with 7736, it is um relatively simple proposal that works pretty well with work and perhaps also in the future with binary um um as a state aspir um proposal. So uh how it works is that at the leaf level we basically add an additional metadata.

Here I called it um period or you can call it um expiry epoch or um it's basically like a time stamp to denote um if um like the last access for a given state. So this period this metadata is will be used to determine if a given stem is expired or not. So that's pretty much all you need to know about this proposal for now. So um since we have this proposal I would like to know if uh the the effectiveness of this um CSR solution. So I did a bunch of experiment. So for the experiment setup I use GF. I basically do a full sync from about block 17 million to 21 million. So this is about one one year and five months worth of full syncing.

Um so during this um period I basically record the last access block number for each key value pair. every time a read or a write event occurs. So basically for every state access operation. So now the first question that um that I would like to answer is how many accounts and slot were accessed. So from my analysis during the one year and 5 months only 29% of the total accounts were accessed and only 23.5% of the total storage slots were accessed. So from this graph or from these two graphs you can already see that um that um a significant um chunk of the state is um like is still it hasn't they haven't it hasn't been

accessed for a long time so that's one and the second question is um how many stems were expired so expired here means that um it I mean we can define the expiry how long we want to consider for the expiry period but in my case um I consider a year. So experiment means that if it hasn't been accessed for at least one year, then it's expired. So um for this question um the answer is 83.5% of the total stems were expired. So this um matches the answer that we have for the first question. Um since we have a huge um chunk of the state that is considered that hasn't been accessed for a long time. So it makes sense for

for us to have like um huge significant proportion of the stems um that are expired. Yep. And the third question is um in GF uh how much storage space can we save? So ideally we want to get like the before and after um um applying state expiry on vocal directly but um due to time constraints um I I only compare it on the flat key value storage on inf. So in a normal circumstances um we have about 17 I'm sorry 107.3 GB um worth of flat key value storage in G. Let's say we do the expiry and then we prune away all the expired

state then the final result is about 26.4 GB. So effectively reduce the flat key value storage by about 81 GB. So that's still quite a lot. Um, so again in regards to the burl that that will be like a todo in the future and the last question that I like to answer is how much storage space can we save with this proposal. So the good thing about this proposal is that it's simple. However, the downside is also that um it only expire the leaf nodes. So that means when we when it comes to comparing the storage space, we can only compare the um um story space of um in regards to the leaf values. So um in for this we um the result is basically we

reduce the value storage size in vocal uh from about 45 GB to 5.7 GB. Um I see a hand raise. Um yes can I ask question or if it's fine? Uh uh yeah since you already raised then please go ahead. Okay. Okay. I have one question like uh in the previous slide that you saw the space about after the state. Yeah. Yeah. Like this one with the normal and the state experiment means like stagelessness. I have one suggestion is that like I am actually introduce myself. I'm Chandra summer currently visiting researcher at Kishon group in security privacy domain.

So we are achieving the privacy on GK rollup. Soon our paper is came out. But uh uh in the my literature review I find one thing is that like in the like stateless expiry even we use uh uh like I have the one paper to show that like if we use the DST means like we will uh we will actually transmit the data through the DST uh I am not exactly remembering that term. So even we got more lesser space to save. So means like we are we are getting also less than 26 with the state expiry model. So I will share the literature with you guys. So like we can think about also for the space storage space if we like distribute the incient data through the

distributed hash table. So I will share that paper. Okay. Yeah. Um that's that's cool. I mean um thanks for working on the same topic as well and please do share the um the literature or the paper that you have with everyone here and we can take a read. Yeah. But um but yeah um would love to learn more about your results um once I read the literature. But yeah um yeah could you share the like emails like where where I can show the paper. Um you can just share the meeting.

uh because I am the first time in the meet so that's why I'm asking but I have loved to ethereum ecosystem last two years working on rollups rather than layer one but now I'm transitioning to work on both like rollups and layer one my mission is like achieving privacy with scale so but I have like contributing as much as I can contribute to different space so love to connect you thank you for giving me chance right yeah just share your link in the chat and let's continue with the presentation Okay, thank you. Yeah, uh thanks for sharing. Um so let me just continue quickly. Um yeah, so that's pretty much it on the result result. So I would love

to get into discussion. So um as shown just now um it's pretty obvious that a significant proportion of the state is stale and um so that's good news. Um the bad news is that um 7736 um doesn't save much storage space in terms of um the vocal tree architecture because we are only targeting the leaf values. Um but the leaf values are relatively smaller than the other parts of the component in in the state. Um so namely the especially the intermediate nodes. So one of the more important performance bottleneck that we have for E clients is um the this for intermediate nodes. So for MPT I think it will be the same for

MPT for vocal and also for binary. Um so it's not addressing that part. So the benefit that we can get for this proposal is only I I would say primarily on the storage space. Um but if we can extend this um proposal to also prune away the intermediate nodes that will um I think significantly improve the performance for E clients. So, so that's another thing to look at and um also another crucial thing that to look at is also um in I would say all of the state aspar solutions the storage reduction highly depends on the client storage architecture. So in g we have the try but we also have the flat key value

storage. So the fact key storage we can definitely reduce like a huge chunk of it as shown in the example just now but in other client um like storage architecture we may not have that. So in either mind I'm not 100% sure in basel or in breath or aragon not sure how um like pruning this expired state would result in how much benefit. So that's also another thing to look at. So some of the open questions that I would like to uh answer in the future. So the first question is what is the percentage of expired intermediate um vocal nodes or binary tri nodes? Um because if we get a high percentage that means we can extend this proposal to also prune away this um intermediate nodes which in turn

theoretically should also improve the performance. Um and the second question is what is the actual storage improvement if we prune the vocal vocal tree vocal tree and third question is how much performance gain do we um get from pruning as state. So comparing this um comparing the before and after pruning expired state in all of the um E clients and see um what's the result that we can get and um last question is how would raising gas limit affect the percentage of expired state. So theoretically raising gas limit should decrease the percentage of uh expired state because we are allowing um more state access but um uh it would be interesting to get a number for this but yeah and also open to suggestions to see

if anyone has any other questions that um you like to answer or or you think is crucial to answer and I'll I'll be happy to work on them as well. But yeah, that's all from my presentation and yeah, Q&A open to questions. Yes, you it's a troll. But when testn net when testn net for which one for 7736 uh well I'll have to convince everyone that this is a valid proposal and hopefully everyone agrees with me and we

can do it on test net. Yeah. Yeah. Okay. Uh thanks. Sorry that was that wasn't full. Uh but uh I was also wondering um yeah um do you think that uh we could um get some uh some improve like if we raise the gas limit right we're going to get u we're going to get a lot of charms. So uh is there like a theoretical upper bound like have you thought about this a theoretical upper bound of how much a percentage of the state would be uh I know this is like departure from what you've done uh but I was just wondering if there's in your

mind a way to determine that we know for sure that even if we raise the gas limit to one 1 million per block sorry 1 billion per block uh we know we would not ex expire more than so much uh I would have to do the math just wondering if you have done them. Um I give I've given some thoughts about this. I think it's most of the the result that we can get is from like a theoretical result like because it based on it's based on different scenarios. So one scenario could be like a worst case scenario where um so let's say we define a period of um like six months for example for a given period and every single block in during this six month touches different state and then um in the when we transition to the next period then we we

repeat the state we repeat the state same state assess again so that will mean that so this is like a worst case that means that um all the state wouldn't be um considered expired so because it will be forever like um refresh refresh refresh. So um so so that's one part that I thought about um but on the realistic side um I'm not sure how how we can get get this number or I'm not sure if it's even possible to get this number because it is based on real world usage. Um yeah some like um the data access patterns for different contracts for example ERC20 are definitely very different from um from another from another type. So um I think understanding the data access patterns

will be crucial to to answering this question but um we'll see about that. Yeah. Mhm. Um yeah one thing I just realized is like you said uh we we could just if it gets out of hands we could also reduce the period. Yeah. Okay. Yeah. Thank you. Um Cars. Yes. Yeah. My question is um can you distinguish if you are expiring uh an account or a random storage slot of a contract like do you have this this kind of information when you're expiring?

No. Okay. is could because the other day we were discussing with Ignasio and like one of for dust accounts and all that stuff I don't know but one of the nice things is that you don't need to worry about like your account is always there right you don't need to do anything you don't touch it you leave it there you come back in 10 years and and and your account is still there um is it possible to introduce something in the tree some marker or whatever such that we could distinguish between accounts in in in contract uh storage slots or or would that be extremely complex?

Um let me think about this. I think I think it's possible uh because like when I was doing the one of the tasks I also face one of the issue that I face is um let's say you you submit a transaction you want to revive a state but you are submitting a transaction that needs to revive a state for example the state is contains the account balance but um in the e clients they have to verify um using the state right so that means it's like a chicken and egg problem like um do you trust the the the balance in the revive transaction or or or what like um or do you get the the the balance from somewhere else first? So um so I I I think it makes sense to maintain some of

the information that we have for now. For example, one of the most important thing will be nons and balance. Uh so um you'll be interesting to like extend this proposal or to consider if you want if you only want to consider um expiring the story slots because um the accounts I would I think if if I recall correctly the accounts doesn't really take that much of a space compared to the story slots. So if we manage to add some markers to the accounts like we don't prune away the accounts but we only put away the story source I think that would makes make more sense when it comes to user experience. Uh uh on my mind I think it's possible but maybe there are some other caveats that um we have to

think about but yeah I think I'll add this to one of the um open questions that um that we have to tackle in the future. Yeah thank you and I guess I have one more question. Um, do you expect like where do you expect like we will have much much much more expired stuff meaning I mean pretty obviously should be in in contract storage slots right that that are expired um but do you think it would go like much faster that we could uh even anticipate meaning a lot of I don't know USDT or USDC balances that are used in the mappings and and stuff like that like how do you

have any sort of idea of what we could just remove uh entirely on the first run? Um yeah uh I think I are you referring to like a very specific state that we want to remove like for example um unis swap v1 contract that hasn't been used um or um uh uh is that what you mean like I mean anything anything that that hasn't that hasn't been used for I don't know whatever amount of time like what do you expect to be the the the amount of data removed when a state expire is first uh let's say triggered because it's not like it's not obvious

right for some contracts you might just remove I don't know some positions in the mappings but the contract itself remains there for others that have been completely unused you might remove the bite code also and stuff like that so I'm like I'm just trying to see if if you have some idea of what would be the the complete removal I think um for at least for now we we do know that we can somewhat completely remove like um this um uh 29 so it's like 71% of the accounts um in in in vocal or in binary will be more complicated because um the it's all of the the the values are interleaf but let's say we use this um

use this figure um so about um only 39% of the total accounts will be will remain in uh in the data structure. So we get to put away 71% of the um for on the of the accounts at least. So I I I I'll say this is a number that we can have in mind. But in actual in reality like whether we can remove all of this um account I think that that will also depends um yeah oh no sorry actually no um every every account every address should have its own um um unique stem.

So I I think in in vocal or in binary it it is guaranteed that um we remove the 71% um uh um expired accounts at least. Yeah. So I I think this number is guaranteed. Yeah. Okay. That's interesting. Thank you. Yeah. Inasha. Yeah. I have a like open question to get your thoughts. So one of the things that uh it's pretty challenging for state expiry in a stembased tree is how to deal with the hashmaps using solidity, right? Because they basically spread data all over the address space. Yeah.

And we have like a lot of stems with only one value stored there. And I don't know, I kind of was left with the feeling that this kind of pattern for hashmaps really kind of creates a lot of noise in the tree for state expiry intentions. And it would be nice if maybe I don't know uh maybe there's another kind of implementation of hashmaps that is more friendly with state expiry. Um but as far as today we don't have any kind of incentive for developers using um kind of uh the the state tree more effectively. I don't know if you have

any thoughts on that. Yeah, I was looking at the tree analysis that you have done. Um I I think I had a similar question as well. Um so the worst case is that the one one value leaf node would remain like they they are not expired um in in the the vocal in the vocal tree or in the binary try. Um but at the same time at least from my result um it's shown that um the bunch of stems are that are expired. So that means those there there are a bunch of this um one value leaf nodes are uh should can also be pruned away. So we are left with like um

16.5% of the leaf notes that are they are not expired. So I guess um I should also find out how many of this how what's the percentage of this unexpired stems um there are one leaf um that that only contains one value. So yeah that I think that's another question that I should answer. Yeah. Thanks. Um yeah. Um any more questions? Seems like no more, but um yeah, feel free to reach out to me if you have um more ideas on this and or you want to collaborate on answering some of the open questions. And yeah,

I'll pass it back to you in cool. Uh yeah, thanks a lot for all this work and the presentation was was really nice. Let's move to the next um agenda item uh which is Carlos presenting blog net website and metrics gathering summary. Uh so Carlos whenever you're ready. Yes, let me share my screen. I'm sharing a locally built version but should be the same in like minutes. So yeah. So basically uh just created some some site for uh the whole bloatnet initiative. You have some notes

about what the goals are and and all of this kind of stuff in the page. So you can you can read more but as we said it's mainly the idea of testing how much we can increase gas limits without crashing the chain. uh also having uh some some chain with a massive state so that we can run research ideas or prototypes there and see if they actually are good or not or useful and also try to identify any issues uh when state grows and basically see how we can fix them in advance so that we don't hit that uh in production. Uh we will basically be adding all of the findings that we have.

Uh this is just an example. It's not a real use case, but the idea is that you will be able to see like at which size uh which client specifically had an issue and basically the the analysis of the of the whole issue itself and if it's fixed, you will also get a link to the PR that does it. So then we have a metric site. On the metric side, I basically have included uh all of the metrics that the teams have shared with us. Uh this is just a short description of the metric that they want. Um ideally um being pursuing I don't know how to say

it, but I'm like behind the teams constantly trying to get uh more metrics because at the end they are the ones that build the client. So they have much more insight on what is interesting to collect and what not. My intuition is that any data that it's uh non-reproducible so basically ephemereral uh it's important to be collected if it's related of course uh so that that was my my educated guess but uh so far we've had uh input from GE ourselves in status consensus bessu and some small stuff from uh and of course nethermind uh I will be

adding those uh shortly here. Uh the idea later will basically be to make sure that as many teams as possible have uh the capability of collecting such metrics and not only that but also try to expose them in some uh graphana so that basically anyone can see how the network is behaving under under stress. Uh there's also forms in basically all of the three pages. Uh so basically for anyone to actually submit new metrics that they want to collect uh or to submit attack vectors or bloating uh vectors. Um just ignore the text. This is just some uh stuff added for now to

to have some columns to be used. But basically the same idea on the attack uh vectors and scenarios. uh just trying to guess what things we can run in a transaction that can maybe stress uh nodes when we are in let's say a 100 million gas uh chain that has one terabyte of state uh and also some like more miscellaneous attacks which will likely require either uh row database manipulation or some more complex structure to be to be set up. And finally we did some research on how to bloat the state at the maximum rate possible. Uh some of this stuff

needs to be recomputed. Uh let's say uh but we have actually built the scenarios for case one two three and uh and that should be it right? Yeah one, two and three which are the the the biggest ones and they are the ones that contribute to everything. So accounts um bite code uh and also storage slots uh both in the EO smart account uh world and also on the smart contract world. So this is so far what we will be using uh together with spammer to actually spam the network as much as possible and try to see uh if we can break some clients or not. Um same

form as always and that should be mostly it. Uh I want to first uh say thank you to Nethermine because they are also uh helping a lot and moving a lot of stuff uh to basically make this initiative work. They are setting up the network. They are they are running a bunch of stuff uh to do that. So so shout to them and and also I would appreciate if Kharim has been already uh helping on that. Uh but if there are teams uh that want to contribute to any of these three things, we will highly appreciate it especially on metrics and attack vectors. Uh because running this these experiments will be will be expensive

and it's not immediate. It requires a lot of time and and time time investment from people and time in itself to to run those things. Uh so the more we can capture uh with every run uh the better and yep that should be it. Thank you very much and if you have any questions happy to answer. I have shared the paper uh if any one want to like give a look on it. So like we can discuss or we can discuss in next meet like for the agenda.

Does anybody have a question for Carlos? Okay, so that's the last item in our agenda. I don't know if anyone else has some kind of last minute uh thing to discuss. If not, we can wrap it up. Okay, so I think that's it for today.

Uh, thanks everyone and see you next time. Thanks. Here's