Stateless Implementers Call #47

Transcript

Loading developers...

Okay. All right. I think we can start. So, welcome everyone to status in front of this call number 47. So, as per usual, we'll start off with the team updates. So, anyone can just start. Okay, I'll start I guess. Um, I've been working on the uh on three things uh in the last two weeks. Uh, none of them are really ready to showcase. Uh, actually four things. The the fourth one is ready to showcase and I will uh I will talk about it later. Um, but it's been uh the

Team Updates Overview: Introduction to team updates and project progress

road map. So that's what I'll be talking about later. uh state expiry like archival state expiry. Um this idea I presented a few back um the implementation is at least of the resurrection is complete. Um currently uh debugging it. Uh then Han wrote the the expiry or at least part of the expiry part. So we're going to to merge that hopefully uh this week. Um yep. And uh otherwise we're benchmark benchmarking the binary trees. Um we're waiting for devops to to create machine for us so that we can uh bloat it and uh and perform the benchmarks but the the

code has been written. Uh right and the last thing is the test the test framework. Uh I think we're going to hit a roadblock on this one because it requires a huge uh refactor in their code base. So I've been thinking uh and it's too bad Mario's not here. Uh I've been thinking of actually making a fork of that uh of that branch but I think uh and just implementing the the binary trees directly inside inside eels. Uh but um honestly I think at this point we are just as happy uh producing like blocks in dev mode and sharing the blocks and importing them. At least that will cover the interrupt uh and give the

the re the sorry not the research team the the testing team more time to uh to think about what they want to do and uh and implement it. Um yeah that's it for me. >> All right I can go for for Bizu. Um so in Bizu we have uh currently two subjects. So, so the first one is uh is related to to getting the the pre-im images and and uh and uh starting to to read those pre-im images. So, code for has been written but not tested because we do not uh we did not acquire those those pre images. So, so now we're we're looking at um using what NASO developed

uh with the RET client to actually produce uh three images and go and test our our code to to consume them. So that's the first subject. The second subject that we have uh is um is is related to uh to verifying um the binary tree and and the hash the the root hash. So to do that um we have to to go dig out in the in the code and resurrect like the dev the dev mode option for for Bizu. So we can actually generate locally a bunch of blocks using binary trees and we'll uh we'll check those um we'll validate those root

hashes with with K geta. Yeah. So these are two subjects that are that we are working on at the at the moment and yeah we are not quite ready for for binary optimizations yet like Y said there's you know benchmarking um we have some ideas but it's we're not quite there yet so well hopefully give you get some some some info on this uh before us. All right.

All right. Any other updates from perhaps never met? I see crash ship or ref or everyone if anyone from the team is here. Right. Perhaps not. Uh, okay. Cool. Thanks for the update. Um, okay, that's all for the team up audits.

Roadmap and Status Implications: Discussion on Ethereum research updates

Then we can move on to the next item on the agenda, which is upcoming road map update and status implications. So, I'll pass it to >> right unmuted before. Uh, thank you. Yep. Okay. So um I'm going to make a very brief presentation because um well because what I'm going to talk about is still you know undergoing discussions um but uh there has been a meeting of the research the Ethereum Foundation's

research team in Berlin uh the beginning of January and uh turns out I was there so I joined um And um yeah, there's been some some interesting updates as far as uh stateless is uh is concerned. Uh so I'm going to to share some of that. Unfortunately, I cannot share the the road map on the public channel like this. Uh they asked to to keep it under wraps for now. Um I mean the main reason is that it's still evolving uh quite a lot. Um I mean the parts that we are interested in are not are not evolving that much. Uh but uh but yeah, overall there's been some some uh discussions.

Uh of course, none of that corresponds to any top-down decision. It's still up to ACD to decide what they what they want. And I'm sure there will be ongoing discussions for the for the rest of uh of the months, if not the rest of the year. Um but uh the TLDDR is that uh binary trees are finally scheduled uh by uh at least the the the research team sees binary trees as as worth scheduling. Um and in their proposal that would be for 27 uh or 20 like late 27 early 2028.

Um I explained uh them the reasons for picking uh EIP 7612 style transition. Um so I think there was a good understanding that this was the the way to go. Um once again that doesn't mean ACD agrees that doesn't mean everybody agrees but uh but at least there's there's a good understanding among researchers. Um and the other notable thing is that uh still expiry according to that road map which uh to be to be clear is a bit optimistic. Um but it's scheduled for 2029. So um binary trees would be in the Jar

Jar fork. uh state expiry is more like for uh yeah forks that um don't really have letters but uh you know K star or something like this. Um and I'm going to expand on the state expiry uh discussions a bit later. Um when it comes to protocol milestones uh well there's I mean this is already what I mentioned during my update. Um we need to do some benchmarking. Um the reason why this uh wasn't done is because there was no um interest before before this uh uh no wider ecosystem interest.

Um, and I've always been a bit skeptical of binary trees because I'm not sure how much data needs to be uh okay, I'm not sure how much IO is uh is impacted by uh by their by the amount of uh of data that needs to be written. Um so before like to confirm the presence of this binary tree on the road map u I I have to I have to do some benchmarking. Uh, and when I say I, it's uh the stateless team. Uh, Carlos is helping me with that. Um, and uh, we're going to see what the real performance is. Um, of course, performance benchmarks were

being realized before, but they were for vertical trees. Uh, vertical trees have a lot of very nice properties. One of them is that the whole tree can fit in RAM. Um, so the performance was definitely better. Um but we shall see uh if um what is what is the hit if there is a hit and if there is what is the performance hit of of running binary trees. Clearly uh just because the the research team is suddenly enthusiastic about about binary trees uh doesn't mean we should be pushing for it if uh if uh the performance is uh terrible.

Um nonetheless [clears throat] in parallel we can uh go back to test net. to uh Tuma and and Karim have been uh picking up the mantle on this um because guess was uh having a hard time merging my PRs. So I had a bit of a of a um bit rot issue. I mean more more than a bit uh the veral PR is completely bit rotted bit rotten. Um so thanks for thanks to them for that. Uh in the meantime I was able to merge more PRs. So uh I would be able to to do some uh some test net um knowing that we have decided like I

EELS Execution Spec Tests: Discussing work on execution spec tests

was saying during my uh my team update uh we will need some work done on the on the eels side um the the execution spec tests. So um to do uh to do uh this uh this work uh we were thinking of using guest's dev mode where blocks are produced every two seconds and we just uh uh send a ton of transactions at them um a bit like what we do with bloNet. So we're just going to do a binary bloet and then we're going to export the blocks and share them uh between clients. uh this is a lot nicer for debugging than than a test net. Uh but

when we get this interrupt, I think we we can seriously consider um having a test net. Now uh it's not going to be as uh complete as the previous vertical test nets simply because uh there's only a BU and a GU implementation of them. Um but at least as a motivational thing uh I think it's quite nice to to have. Um I don't know how much code needs to be rewritten in Nethermind. So uh I guess we can have discussion with Wash about this a bit later or or Damian.

Um but yeah like we will not have uh no longer have Ethereum JS will no longer have never mind for the time being. Um yeah, this being said, as a mind has a uh has a um code base that was working a year ago. Um so it needs uh it needs some refactoring. Uh but uh hopefully we can uh we can resurrect that. I just saw the screaming face of blue cache, so probably not, but we'll we'll give it a try. Um, one last thing and uh, it's not the Yeah, it's pretty important. Um, it's about the transition. So, once

again, expecting a screaming face from Wukash anytime at this point, but uh, at least um, I presented the the reasoning behind why we we wanted to do the transition the way we the way we wanted to do it. Um and the research team seems to be in agreement that this is this is a good way to proceed. Um so uh we would like to perform a transition a shadow fork for this uh BSU more or less is ready to go. Um yeah like if you if we solve the the pre-image distribution problem um but uh but yeah like I I I think it's more like a matter of getting

the data. It's a bit annoying, but it's not impossible. So, we should be able to to do that. Um, and then uh yeah, do do a shadow fork. I have just uh created yesterday a PR to activate this in uh in GU. Uh it's being reviewed. Hopefully, it will be merged soon enough. And if that's the case, then GU will also be ready to to proceed. Um I think uh we will either do something like uh some dev mode conversion first to be to agree that to make sure that uh Basu and G agree and when we do uh then we can attempt a shadow fork uh which we did

last time with Verl. So um you know Hoody uh Cipolia uh and then um and then mainnet knowing that mainet takes uh it's going to take several weeks uh probably too. So we don't want to uh to rush mainet before we we actually are confident that everything works uh in u in uh and that there's you know both clients can agree or both client two clients or more if there are more um yeah so that's uh that's basically it uh oh right so that's that's it for the protocol um now there's this thing uh I've been hoping to do for the last two to three

years but uh didn't really have time to do but now there's uh there's not really um any way to put this on the back burner. It's about bringing the whole ecosystem in u into this and uh collect feedback make sure that everybody is u is in line with this or at least understands the trades the trade-offs. Um so uh the first thing I'm going to do I mean I'm saying I but it's it's my it's the team it's stateless stateless consensus. Uh we are going to interview ecosystem players. So who do we mean like L2s first but then DAPs and also wallets um although wallets are less less

important right now uh because we did talk about some wallet people in the past and they say well as long as there's an API we'll we'll use it um but yeah L2s and DAPs are probably the the most uh important people to to bring into the conversation. Um so we're going to run a round of interviews. We're going to send people a questionnaire, uh have them fill them, fill it, and then we're going to uh to interview them and make a presentation uh about what the changes are going are going to uh entail, what uh what feedback we can collect and uh yes, so if you want to help with this uh either by by participating in

the calls or uh or just you have contacts because we're looking for contacts, Um yeah, please get in touch. We would like to uh to try to get a good coverage of of the major players of this uh of this ecosystem. Um that was it for the road map update. Uh I think I have a follow-up uh agent agent sorry agenda item on the state expiry. So I can do it now or I can maybe also open uh the floor for questions if there are any.

State Expiry Discussion: Update on state expiry discussions and models

Okay. So, I'll talk about state expiry. Um, yeah. So, when I say state expiry, I mean the also an update on the discussion that happened last week. um sorry last week two weeks ago uh in in Berlin uh with at the EF uh research and just to to give an update on what uh what was discussed there and what is the the general outlook of u of researchers and and Vitalik on on the whole state expiry u thing. So, in case you're not already aware, but you should be uh state expiry is a big uh is a bit of a scary topic. Um and um and so we uh like the reason why it's so scary is well

first we're removing data. So there's always the question of who's going to to hold that data and how do you get it back. Uh but it's also the UX which uh which is going to be a bit bit difficult to to handle. Um so there's been some uh discussions and um let's say the all the conversations uh all the proposals came into uh uh into two kind of buckets uh two models. One of them is the leafbased model. So it's the one that uh we uh let's say we the stateless consensus team but other other actors like for example Alexi back in back in 2018 have been working on uh

which is uh the expiry of of leaves. So it's uh something like 7736 oopsy or archival um doesn't really matter like there's a few design options like do you want to make it in or out of protocol? Do you want to do u um know how do how aggressively do you want to to uh to delete the leaves? Do you want to save them to this or still have them on a slower hard drive or delete them completely? Um and uh the other model is called epoch based and I'm just going to to talk about it a bit later. So leafbased just as a reminder well it's exactly what it says it you delete

leaves. So when I say you delete, you remove them from the from the tree. Um, where they're stored, this is this is a bit uh of an open question. Um, and uh, the problem of the leaf base is really the resurrection UIX uh, because you need to pass a proof to say well that data was there. Um and uh this the shape of the proof is really um is really uh depending on or dependent on the the way you expire those leaves and where you store them. Um predictably there's a lot of excitement about stark stark based proofs. Um but u yeah just passing Merkel proofs work

work as well. Um and then um yeah uh you can uh you can just uh enforce them being in an offline uh store. So they still have to be there uh but they're not considered part of the tree. So if you want to resurrect it um you have to somehow uh send a signal that they have to be resurrected and uh yeah the biggest problem is uh who is going to be holding the state. uh some conversations uh can well there were some discussions uh in Berlin and before and uh the the answer is that it's probably going to be wallets and the reason for this is because um those

Wallets and Transaction Costs: Discussion on wallets' role in transactions

wallets they are the ones making most of the money in uh in a builder in the builder centric world. This is something I learned recently and was quite shocking to me. So uh actually the block builders themselves they're they're not uh they're not having so so high a margin because most of the money they make they they send to to wallets to so that wallets send them the transactions. Um so if that is uh if that models model really uh uh holds then we could potentially uh expect from the wallets to to hold that data and to provide the proofs. Uh first because uh well they would be the ones profiting most a lot

from from this uh from from holding that data and second because uh this is where the UX problem really uh is solved. namely that uh you know the user could just say okay I want to send my uh transaction from this account I haven't touched in five years u and then the wallet will say well it's going to be a bit more expensive because uh you know it's uh that data is is cold uh so be aware like to you it's just uh still a transaction you sign that transaction and then when we know you sign that transaction we're going to well we're going to demand a higher price uh like a resurrection price from you. Um and then

when you sign a transaction, we have this transaction uh we will first send uh the the proof to resurrect the the state that you need. Uh and uh and when we resurrect like the the cost of this proof is provided by the the increase in the transaction fee, the resurrection fee. you could could call it and then as once it's resurrect resurrected uh forward the the transaction. So that would be a good uh a good model. Of course it's not perfect in the sense that um while it could also be censored um but at least in terms of general UX

if you are not being censored your uh your UIX is not is not affected. Um, okay. Now I want to talk about Apoch based and uh once again it's uh uh I apologize for uh for those horrible scribbles that I had to do but I was a bit short on time. Um so the idea of an epoch uh based state expiry is that really you don't you don't really expire anything. you just have a first tree and then in the second epoch you have a second tree and then let's say we're at the third epoch um you you have a a third tree and when you want to read something uh you just um read the data and if it's not present uh it's not

Epoch-Based State Expiry: Explanation of epoch trees and resurrection proofs

present um but so that means only this tree gets updated as the block as the chain pro progresses so the performance is kept uh at a manageable level Um now uh what they suggested is this idea where each tree on top of having uh each uh expired tree has a uh resurrection bit actually it's a bit map. Yeah. Um and uh each node in the it's each leaf has a bit map. So if for example I want to resurrect this um this bit this uh leaf here I would go to the bit map. the bit map has to be zero and then I set it

to one and then I go here I also provide a proof. So okay I had to provide a proof that it was part of this uh expired tree from epoch one. I also have to provide a proof that not only uh epoch 2 did not contain uh my um my value uh but also that if it did contain my value it was not resurrected. Um it has to be both uh otherwise you could uh you could resurrect items from uh from older times.

Um and uh and yeah so uh you uh update like you you mark it you mark this value as one and then you add it you resurrect it you bring it into the current epoch tree. Um this has some nice properties and some not some not so nice properties. The not so nice property is that those epoch trees are not really um frozen, right? They get updated. Uh it's not technically the tree that gets updated, it's the bit map, but uh yes, you need to keep a a hash of the bit map uh for every uh for every epoch. So your block is going to grow every time by you

know by one hash at every epoch. Um but uh the other interesting uh approach to this is that uh there's no uh address space extension which was uh always plaguing all the designs uh of the of multi-apo trees. Um so they found a way to to uh get rid of that. One thing I didn't write which is also quite uh interesting is that the size of your proof of your resurrection proof is effectively uh like logarithmic uh well it's k log n so k is the number

of epochs that you go back and log n is the size of the the amount of trees of leaves inside a tree. Um so it's um it's not scaling like uh you have a sublinear scaling. I mean you have linear scaling in terms of apoch but not uh but a sublinear scaling in terms of data. Um and uh as always you can start kit. So uh so that was very exciting uh to some people. Um yeah, the problem is technically you're expected to keep all the trees or uh all the trees all the time. So that's kind of manageable

because you once again you can have these reservation fees. You can uh have a UIX that says well if you're going if you haven't touched your account in five years you can uh you can afford to wait another 10 minutes for your data to be resurrected. Uh so all those schemes with wallets and uh and potentially getting data on the on the network uh with uh with uh rewards associated rewards in a rainbow staking kind of way are totally uh manageable. Um but yeah per se everybody is expecting to have everybody is expected to have every epoch. So the the saving is um is not

the best. Um one remark is that and this is an idea that initially came uh from Karim uh Basu Karim um is that uh when it's just a read [clears throat] you can you don't have to have all the trees you can just merge all the expired values into a single flat database uh because presumably you're only interested in the latest uh time your account was was touched. So um so you can do something like this um it's uh that's to to serve reads for for rights you still need to do the resurrection

um and in both case you you still need to do proving but the if you have like let's assume your your node is uh behaving well then everything that is in the expire flat database will be uh will be the the correct data So, um, so you don't really need a proof to to produce the block at least. Uh, although you might need it to to verify. Yeah, I think that was the last slide. Uh, yep. So, that's it for the that's it for the update.

Oh, okay. Lash has a question. So, he asked like why why can you aspire dash drop price? So, maybe you want to elaborate. Yeah. Is the question why can you or why can't you? And >> why can't should be why can't you I think right because sorry uh >> yeah you okay you cannot do it simply because if you do um you need to uh let me rephrase this uh it's connected to address space extension if you need to I mean okay I guess you could expire all the old trees uh simply uh the uh oh yeah sorry I'm mixing two things

um yeah so well in some models you can but then to resurrect you the proofs >> and in some models you are expected to do exactly like the overlay tree >> uh where you first hit the current tree and you can read the old tree. Okay. It's only in that model that you cannot expire the >> Yeah, my bad. My bad. >> So, if we could expire, can we like uh freeze the old trees could be frozen and like distributed somewhere like bit torrent whatever, right? Similarly to for forest uh and this could be okay. So, this sounds like a win to me to be to be honest.

Backup Plan for Data Recovery

>> Yeah. The only problem >> Okay. Well, you're not the only one. Uh the only uh the only problem with this is the I mean it's the same as the other one. If you do this then you have your uh resurrection uh UIX which is just as bad as as the other one because you need to pass proofs all over the place and uh it needs to be uh to be resolved. But it's true that um yeah you could uh Okay. Yeah. I've been mixing two things but come to think of it it's uh it's not bad at all. Yeah.

>> Yeah. So my my concern is I wouldn't rely on the third party to store the state like it could it can be the fast path right but I would love to have a way to actually you know a backup plan. Oh yeah. >> And this sounds like a backup plan to me in that way that this can be like shared and on you know few literally like few copies of that on the internet on like Bit Torrent or something and someone oh my my wallet screwed me and uh uh I'm not out of options. I can always, you know, download this huge file or

whatever or, you know, pay for some service to to do that for me and it will uh, you know, get this file, produce the produce the proof and and give it to you and now now I can now I can, you know, get my money back. >> Yeah. So uh just for in um one interesting uh well something of note at least is that they want those trees to be five terabytes on average. So if you have to download multiple times 5 terabytes that's going to be a potential problem but uh yeah I mean if that's the size of the state that's the size of the state. Um and uh the the other thing I was thinking of yeah my my only issue with

this like bit torrent in my view is not good enough uh because people will tend to drop um uh data like uh yeah there's so many trackers on the internet where you try to download a movie completely legally of course u you try to download a movie but uh most people did not did not even hold it like they had it at some point but so it's still advertised but they don't actually have the data and this is in my view a terrible uh I mean we don't want that to happen. Um so uh I think like my preference would be to have something like uh you know rainbow staking where there is actually

a role where you have to uh you have to provide the data if being asked and you get rewarded for it. Mhm. Uh quick questions. Why 5 terabytes? Why such big number? >> Um well, there are several reasons. First, because uh you know uh 8 terbte discs are still pretty new or at least 8 terabyte SSD. It's true that you can have pabyte uh HDDs, but most people don't have that. Mhm.

>> Um the other thing uh is that there are a few uh there's a lot of um ISPs that actually limit the amount of data you can download in a in a month. Uh for example um we we looked it up. Starlink I think has a limit could be wrong but has a limit of two terabytes or three terabytes. uh which means that if you want to download your data and you have like five epochs to download so that's 25 terabytes uh you can well you need you need about a year to to download all your data >> and you you would have to download all

the epochs right because you need to prove that it didn't change in the later ebooks that's >> exactly yes >> like if you have to do everything yourself of course if you can get someone to send you Merkel proof. Uh it's a lot better. >> Mhm. >> Right. And like Carlos says, for sure like the all those limits are going to to improve. Uh there will be more I'm sure we'll have 16 terabytes hard drives in in a few years. Uh but the thing is, you know, if more people use Ethereum, uh

we're just going to be chasing that that limit because as soon as the limit rises, the demand is going to rise as well. >> Well, >> okay. I have another question. >> Uh but that would have to this would have to be sponsored. So would have to be somehow I I doubt a um entity that is like commercial would ever do this. Uh but yeah, still let me ask the question.

Um could we somehow proactively generate those proofs when we expire things especially if we expire accounts that are use EOA accounts okay now with account abscription it's really comp gets complicated but >> but it's it's like accountion is not the problem the problem is that the root will change for every new block or epo and so >> you will need to constantly update date like when the epoch changes and the new tree comes up, what do you do? You provide the new proof for absolutely every uh expired leaf for everyone because it will change, right? All the

other proofs go stale. >> I mean it's doable like to provide a proof for every single value in the tree or at least a wrench proof. Uh the thing is if it's just one proof per tree, it's a lot more data. Uh and the question is who's going to hold even more of that data. I I I don't know. I'm just >> And you know, like I mean Yeah. I mean I I think it's not a it's not a you know, it's not a stupid question at all. uh is just I think it opens a lot more

questions that I don't I don't personally have an answer for. >> Yeah. Oh, K. >> Yeah. I wonder I've been thinking about this lately and I wonder if we should uh see um state expiry more from the perspective of actually getting rid of data and forgetting data than actually uh a revival mechanism that we can use sometimes and this kind of stuff. What I what I mean is we from the protocol perspective just leave the gate open for for revival

State Expiry and Data Forgetting Strategy

because we need to do that. But but in reality the way that we look at state expiry is just the more data we can just crash and forget forever the better. And if there's companies that get a profit from actually storing all of this data and providing proofs for revival, I mean, nice. But kind of looking at it more like we will crash some people and and that's true. And I think that's inevitable anyways. uh but the the the the positive between codes thing is that at some point we will get a a mind change between users where actually we all understand that they need to start storing this data or it's usually it's used constantly because Ethereum will

just be hot state and cold state will be just you are on your own basically and if you don't have anything to revive it you can say goodbye to it. um like we are super scared or at least I am about being that explicit but it might make our lives significantly easier because all of the discussion about the terrible UX for reviving and all that stuff it's like yeah sure it's really bad but the intention is not to revive it's to actually destroy as much data as possible maybe this is too radical but I want to see what are the thoughts of this perspective >> so yes and no so um I do agree agree that uh Ethereum like

probably shouldn't give guarantees as a chain but we should probably make this as easy as possible right so if I could for example at some point in time uh also say I don't I want to download uh proofs for my account let's say right and it just gives me everything I need and I can store that somewhere in my cold storage and I know I'm fine because even if I forget to you know keep this account hot for the next two years and it expires I can just bring that back and you know and that and I'm fine then then it's good but if we don't provide

Account Revival and Data Storage Challenges

this kind of um really good mechanism that for example wallets could integrate or someone could integrate easily Uh I'm I'm afraid that we will hurt people. >> I mean notice that it's significantly easier to revive accounts than it is to revive contract storage, right? Like holding the the entire account uh three subset. It's about 14 gigs as of today. So 14 gigs you can even hold it in your u zkm note in the future, right? Um, I don't think we should suffer that much about accounts because that's data that it's likely going to be significantly

replicated across the network even if we don't have full nodes anymore. I think the the bigger issue is contract related data and this is a big issue anyways because ERC20s store your balance inside of them. So if you expire that you're you're fed. Uh, >> exactly. But I think there's uh there's some proposals from Vitalik and and Han uh which actually might be trying to tackle this a bit. So maybe this circumvents a bit the problem. Uh but yeah, I agree. Uh there's no like uh silver bullet solution for that. Um so as I said maybe maybe it's time to start uh making people understand and dabs understand that that they need to

actually keep somehow a partial stateful note or something like that where they are constantly capable of producing these proofs uh for uh for people for example or stuff like this otherwise it's impossible to maintain tens or hundreds of terabytes always available for people to generate proofs at very low cost and really easy UX and all this kind of stuff. I I I don't see the way. By the way, how did we get to the number of tens of thousand terabytes when we are less than 200 gigabytes at the moment?

>> Well, if we go to if we follow the road map, the idea is to be at uh Gigas >> by MTA, I think it is. So, Gigas, a block that does 33% uh of storage. Uh we're talking about 333 million gas just on sore for example. And this is on the use cases that we have today. If people start tokenizing like maniacs, maybe we deploy a lot more. Uh so we could easily see um more than 100 200 300 gigabytes uh a year. And if Ethereum is meant to be running forever, at some point we will hit this rates. So that's why I

said on top uh people love to throw this hardware will improve fast enough. So we worry about it. >> True. >> But yeah, I mean I also think that at some point there will be limitations. So >> well, we already hit limitations of cost per gigabyte. Uh not to mention the current crisis reversing the trend. >> I I totally agree. I totally agree with you. It's it's not that I support this argument just to be clear. It's just that this this is the classical argument that people throw. Uh >> so so yeah I I go to the extreme then and I and I'm like okay sure even if even if we can handle 10 or 20 uh terabytes there will be a point where

this is completely unsustainable and there will be no way. So we we anyways need to prepare for that. That's >> okay. So let me ask one more question because currently we want to cap state growth a bit right. So where does comes this 100 few hundred gigabytes will we uncap it will we make it cheap enough that we will have so much state growth >> so uh if if 8037 uh gets I assume will get included uh at least that's my understanding um we we will probably see an increase of uh 100 gig uh 100 gig per year or at least I

think that was the target. Uh but I'm not sure we can run with 8037 forever, right? Like if if um Black Rockck or or companies like this want to start tokenizing stuff on top of Ethereum mainet, uh we cannot be like, "Hey guys, it will take you one month just to deploy the shares or I don't know whatever financial asset uh on chain." Like it's really bad. I don't think that works. So I think A37 is just a way to put a hold on state growth while we actually figure out what's the best way to move forward because I don't think we know yet. Um but I don't think 837 can be here forever. Uh at least if we want

to support some of the use cases that um I see uh mentioned in Twitter and these kinds of places. All right, nice. Um, so we have 10 minutes left and uh the last item on the agenda is uh a presentation by myself. So um I would like to present uh like a very early stage idea um which is inspired from uh Petar's idea um which he presented two weeks ago in the last sit call. So, I'm just going to do a very quick sharing. Uh, all right. So, right. Yeah. Um, so, uh,

Introduction to User-Associated Storage Idea

just just do a recap for for those who are not who didn't join the call, um, for the last two weeks. So basically Vitali presented a new idea on user associated storage where um so the TLDDI is that this is on binary try u we'll basically update the header in the binary try for each account to include 16 slots of what we call privileged user storage. So um basically this storage will most likely be like your token balance or something that you use very often as a user. Um and the whole goal is to um the first thing is to associate storage to a to a user. um and and which will make which will make the gas cost

cheaper and it is also quite friendly for um state expire or stateless um proposals because like the current problem is that we have all these balances like distributed across like different um tokens in their own storage. But if we associate it with like uh in the accounts header then that would be much nicer to expire compared to like randomly distributed. So that's the initial um idea. So I like to expand on this idea um and make it um I mean here I call it address based storage but the idea is quite similar. Um it's also here is it's also based in binary try.

So um so the status code of the contract storage using Zen as an example. So if you study Zen's uh contract, so uh for context, Zen is the hold the largest contract size in in the current EM minate. So I can actually show you what's the difference between the first place and second place. So um if you see here Zen crypto, right, and you look at the slots, so Zen currently has like this is real life um like real time data. So it currently has almost 141 million slots. And um the second place is USDT which is 21 million storage slots. So that's like seven times Zen is like seven times larger than USDT. And

um most of it is because of um what I would say badly uh designed storage layout but we can't stop them from from doing that. That's just how it is. Um but the point is that when you they have this um uh mapping of address to a strct which holds six 32 byt values. So what happens um underlying is that this um this all this um values six six values per address when we insert it um into the state cry it will basically when we generate the um or when the when the by code generates the SS keys how it works is that it will hash the address and then it mean concatenate concatenate

with the storage layout index and then it will hash it. So the result of hashing it is that when you insert it into sit try it you will be um scattered around right. So that means you wouldn't have the um you wouldn't have a good locality because um everything is hash. So the idea is that to we want to group this similar storage together because when you are reading this strct per address you are you are most likely reading everything um in in one go. Um so for us 20 that will be like your balances and allowances. Um so most of the at least based on the current pattern most of the contract storage is based on mappings of address to some value. So um also for contexts a mapping

Address-Based Storage Proposal: Discusses optimizing storage by grouping similar data, introducing a second-tier storage for address-based data, and its benefits and challenges

of ERC in in ERC20s mapping of address to balances take up about 20% of at least 20% of the current total storage size. So um um that's why um this mappings should be optimized. So um what I would like to propose is something like um um um basically what we have right now similar to what we have right now with the account try and storage tries but in binary try. So originally in binary try we don't have a separation of storage try account try everything is put into the single unified tree. Um but for address based storage I would like to change this to introduce a second tier um storage but this is not the

contract storage but more on address based storage. So meaning we will move like per user contract state from the contract storage into the users account. Um and this is name space the contract address. So um for example if you have an EOA then instead of storing so you have an EOA you have an account you have multiple you hold multiple tokens so um for example D USDT USDC or whatever so instead of those um storage being stored in their respective contract storage you store it actually in your storage so that's the general idea there'll be more details uh which I'll publish in the article soon but um so if you go back to the Zen example. So this is like bad. I

mean keys are scattered no locality and it makes try larger because everything is random or everything is distributed uh evenly and then you grow your try which is bad for IO and so and so forth. So if we um apply this um address based storage on using zent as an example then that means that um in the binary try because we are we are storing we are grouping values together we can actually store all of this in a single page or single leaf leaf node. So when you are reading this page you are reading it in one go. So um that's more efficient right at least for this um use case. So um just to go through that's that's

basically the gist of the ideas. Again there will be more technical details but um the pros of this solution is that um first you get locality which is more efficient and locality better locality will lead to lower gas because if you are reading uh multiple values per address um in in one go instead of doing for example multiple s loads you can only you you you'll be able to do just like one you you load it once and it's already warm for the rest of the other values. So it's much cheaper.

Um and um this proposal is also compatible with proxy patterns. So it won't break um the existing patterns. It's also compiler friendly because I mean contract developers don't really have to know uh um if they should use this or not because the compiler can just determine that oh if this is the mapping of address to something then use this new op code that we will have and um it's also x friendly. So assuming that every contract storage is stored in this I mean every token balance for example is stored in under your account instead of contract storage then um we we wouldn't have to deal with like the the UX issues of having to revive your balance uh in this contract storage. So

that's that's more friendly from an expiry perspective and from a stateless perspective uh it's also friendly. So if for example if you want to run a partial stateless node um so uh you you only need to know your account um account and the account storage meaning the token balances and it's much cleaner and simpler to do it compared to having to store the whole storage of the poison 20 token that you care about. So yeah and the downside of this proposal is that uh it definitely adds witness overhead for ZKVM. This would probably be my main concern uh because we are use we are introducing this second tier um storage

cry again and the second thing is also of complexity because we are introducing somewhat like a new class of state. So it's going to be a pain for um Ecoin developers to to implement at least in my view and [snorts] um it's also only applicable to new contracts. So that means that um the existing USDT USDC contracts wouldn't be able to migrate uh because if you want to migrate to if they want to migrate to this new contract, they would have to migrate all of the storage which is not feasible because they would have to have the pre-im images. So I don't really see a way of doing it. So yeah, so that's that's just an early idea on how this address base storage works. So yeah.

Okay, I think that's a hands up, Carlos. >> Yeah, thank you for the presentation. Uh are you like there's literally no way to do this migration for for everything? Like aren't there any ways to I don't know upgrade the contracts or Yeah, I don't know. It would just be really nice if we could do that because if we if we are able to transfer all of the valuable assets from users to the account then as you said expiry becomes significantly easier to do. Um so yeah have you have you thought this uh thoroughly or are there any hopes that maybe >> I think it's really difficult from a

protocol perspective um because um you even if you can you even if you have the pre-image you you need to have the pre-image of the pre-image because like when you're storing a mapping of currently when you're storing a mapping of address to some value is hash first and then we're inserting to the try you will have to cach it again. So now for binary try we have the pre-image which will give us the SS store key original SS key but the this SST key is hash with the address uh concatenated with the storage layout. I see I see >> so you have to yeah I I wouldn't say it's like not it isn't impossible. It's

just that I I think contracts that wants to do something like this, I think it'll be up to them to do it because they can just they can do a static analysis on on their storage layout and then get all the pre-agages and then maybe pause the pause their protocol for one day, I don't know, then do the migrations to the new contracts. But it's going to be very painful and doubt that um they they going to do it unless the future cost of SS store is so expensive that they have no choice but to migrate to this new storage. So yeah, that's the that's why I said this is downside. So >> yeah, thank you. Thank you. I mean

the only issue is that if this remains then the problem is we have two different places where the data can be and they they both need to match most likely. I mean I don't know but >> I have a different question because this this by design is very limited storage right only like few slots kind of storage right few >> uh we did think of bounded uh key but uh I actually just reverted to unbounded so meaning that um like every address And every contract storage would have it unlimited space of storing like you

basically you can store how many as many slots as you want in in this address base storage. >> Okay, got it. >> All right. And >> we're over time, but just a quick uh >> question. Why do you uh why do you need the sub tree? Why don't you just use another, you know, like the storage, we just add a huge number in front to to make sure there's no collision, but why don't you just leave it uh at the same uh level as the regular storage because it is storage after all. And in fact uh an account having its own storage will

Storage and Hash Collisions Discussion

not have uh well okay that's not true because of 772 but you know you won't have a collision otherwise that means you do find a hash collision. So why why do you need to go through a uh sub tree when when you could just put it at the same level. Uh from my understanding that would clash with um that would have potential collision with the main storage right? >> Um I mean yeah sure in theory but that means if you do that means you do find a collision to the hash function. So no uh I mean it's well it's plausible but it's very uh unlikely.

>> Okay. Okay. I mean well I mean that would be much nicer because we don't have to do in the sub I understand this was for preserving structure no like in binary trees we lose all kind of any kind of structure that we can possibly have so it's very hard to reason about what an account is and what is not but if we have the sub trees then it might be significantly easier to actually make these reasonings I might be wrong though I I Yeah, I don't think so, but let's take it offline. We're We're over time.

>> Yeah. Okay. Um All right. Uh so that's all for this meeting and we're over time by four minutes. Sorry about that. But yeah, thank you everyone for coming and uh I'll see you in the next sit call. Right. Thank you. Bye. Bye. Bye.