Stateless Implementers Call #49

Transcript

All right. So, uh I think we can get started and if others join in the meantime, uh that's fine. So, yeah, welcome everyone to say oh here here's Karen. Hi Karen. Uh welcome everyone to stateless implementers call number 49. The agenda has been shared in the chat. We have three points today. So yeah, without further ado, let's get started. Starting with team updates, maybe Gong, you want to lead this?

>> Uh, sure. Um, yeah, so uh, personally doing a lot of work with binary trees, found a few issues, um, including an NDNS problem that's going to be discussed uh during the during this call. Um, and also performance issues. So um in the initial implementation that's currently in guest master we we were okay that wasn't in guest master until last week we were recomputing the entire tree all the time so that was a huge performance hit um so that has been corrected otherwise there's been some back and forth with the team but I guess Han will talk about this uh about uh changing the structure

of the tree um yeah um still still open but we're going to to talk about this uh or actually was it the other thing Han I forgot which one are you going to present the uh >> I'm trying to present the one but uh I guess maybe if we have time then we can go through the uh binary fe changes as well because it's quite early it's a draft but um I guess we can share it right why not yeah >> right yeah sure um yeah let's do that if there's time so yeah those were the to the the three main things. Uh I'm sure there was a billion things uh on the side as well, but that's that that was the the main focus

on Bizu side, but not a lot on our side. We had some talk with Guom uh because we tried to have the same state route um between G and Bizu, but as Guom said, he found some issue in the the implementation. So I think we'll have also to to do some fix on our side. Uh as he said also we'll talk about what he found and uh we should try to update the the binary tree implementation in Bizu uh because the main branch moved a lot.

So I have to to to book some days maybe this week to to update the implementation. And uh yeah, it was mainly that on Bizu side, not a lot. Thanks. Anyone else? Maybe Milos or Thomas or Han? All right, sounds like we're uh done for

team updates unless someone uh manifests. This uh brings us already to point number two, which was uh a point from Han. Uh it's about activeness based state access repricing. So H if you like you can take it on from here. >> Oh uh sorry can can we move on to the next uh agenda item first because uh Maria just texted me that she wanted to join the meeting. So uh let me just send her the link. Yeah >> sure. Yeah. Uh then we can uh go ahead to point number three from Guiam. Uh I know Yom you were kind of preparing the slides. Are you ready to present already? Yeah, believe it or not, I was

uh I was getting ready. Uh I just need another minute, sorry, to to set up. Uh but that will be quite uh fast, I hope. Um yeah, here we go. Um okay, so now screen sharing. Um Okay.

Yeah. So, um what I want to talk about is uh some tweak something that came up during uh the debugging session that I had in the previous weeks. uh and um and uh the reasoning is that if you look uh at the EIP uh 7864 uh which is three embedding uh you have the way you compute the key get tree key I hope people can read otherwise let me know I will increase the the font size um so you get the address and then you get the tree index which is uh specified in Python which is uh uh big int Right.

And then the sub index which is not really interesting to the current conversation. And then uh out of this comes uh the hashing right where you first hash the address which by the way is a 32-bit number. Um and then uh you also hash the tree index which is also a 32-bit number. Um and uh it's uh serialized in little Indian um and then you take the hash you take the the 31st bytes of that and you add the suffix. I mean that should be obvious to everybody who has implemented

the the the code but yeah bear with me uh I just wanted to recap because it's going to be important. So if I look at the way this works in practice um I have right um so yeah that's going to be a drawing um I have the address right I have uh what's called the offset and the offset is split into two uh this is known as the tree index and this is the suffix.

All right. And what you do um okay so one important thing uh I'm going to represent the NDMS starting from the most significant bite to the least significant bite. This is a 20 bytes uh big Indian address. This is a uh so I'm only talking about this uh this is a 32 byt big Indian. This is just one bite. So the ndns doesn't really matter. Um and then what you do is you're going to take a hash of zero to make it to make the address uh a 32 byt uh sorry a 32- byt number. So it's still big Indian. I mean it's zero.

doesn't matter but uh the address as a whole is read big Indian so it's 12 bytes and then um you have another number which is just this copied over so it's uh big Indian 20 bytes and then um this is a 32 byt number so right the offset right was a 33 byt uh big Indian number and I can explain if it's not clear why it's a big Indian uh Sorry. What's 33 bytes? It's because if you look at uh the way it's implemented uh it's specified in the in the spec offset for a storage um a storage number

um adds the value like take the storage key which is a slot number and it adds main storage offset. And if you go to the definition of main storage offset, this is uh a weird way to write uh a number which is still uh which is two to the power of uh 248. So it's actually a 32 byt number with just one one bit set in the most significant bite. Um so if you add two uh 32 byt numbers uh one of them like if the if the top uh if the the top of the so you have the slot number

um and if that value is 255 if you add another number which is effectively zero and here it's one this together could overflow into a 33 bit number. So this is 32, this is a 32 and this is 33 and then you chop off. So this is the same thing as that. And if you chop off the last bite, you get a 32-bit number again. Uh sorry, 32 byt number again. So this is copied over here.

But as I pointed out, if you look at this uh definition, it's little Indian, which means that this thing is actually a little Indian 32 byte number uh of which you take 31 and then you add that suffix. So what I would like to do because you have this conversion like this you have this number and this is a um another number sorry it's the same number in a different representation but what's a bit silly is that well okay this doesn't really matter but this is big Indian

this is little Indian and the final result is taken as a big Indian number again so what I'm suggesting is that we replace this with uh basically what what I'm suggesting is that what we do is let me just copy uh we we change the the method to um to do that instead of what I just did which is uh we remove this part and we just say it's going to be a 32-bit number but big Indian so I just want to change the the spec to use the NDMS uh the initial NDMS Why? Because then we don't have to do a uh a flip. Um in terms of performance,

it doesn't really change much because you're going to have to copy that data anyway. Um but um yeah, you need to copy that data from the the slot number into the the hash buffer. So it's not a performance issue but it's a readability issue simply because you don't have to uh do the big Indian conversion. is just a simple copy and um yeah just having two different types of NDNS inside the same uh part of the code is going to cause a lot of issues and in fact it did because what I was doing uh until now and it's also probably wrong in Bessu

but uh I I assume to or Karen can confirm uh what was being done until now in uh in the in the guest branch was still having zero here having uh 20 uh sorry not here uh 20 bytes here and then this was 31 bytes big in the end and then a zero. Um so that was a bug that was a bug that was described uh and that was fixed uh like in the that was fixed on Friday but uh yeah there was a confusion. So even if uh me who has been working on the on this

topic for a while uh got confused I think uh it's a sign that this needs to be uh to be uh rationalized. So I okay so this is definitely wrong but I suggest we currently we are doing this and I would like to do that. Um so I think Tuma had some uh opinions about this. Um, is this uh Yeah, like let them be heard >> like I'm assuming me, right?

>> Uh, yes. >> Yes. Okay. No. So actually in Bizu we we um uh from the test it seems that we have the the same uh we look into the the code to find um where we might have reversed to little Indianness to to to follow the spec and we didn't find it. So, so probably probably what you described is is right like meaning the mistake that we did uh with the Indianness we also do not have the overflow check that you mentioned anywhere. So that's also a bug that we that we shared that you you fixed but we didn't on our side. Um and

to us like the the fact that it's big Indian or little Indian is absolutely not an issue. uh it's probably better to have it begin as you mentioned because just for uh conformity with the rest and in fact we do pass it in uh uh when we pass it to to you in 256 it's indeed uh assumed to be uh big Indian representation so uh so big Indian seems good to us anyways um so uh so so yeah so we we'll have to to to check double check all this but I think we we do have the same bug, both bugs that you described.

Uh, and we're ready to to change this. >> Cool. Uh, yeah, please do that. Um, yeah. Okay. So, I don't know if anybody else has an opinion, but if it's if not, I will be creating the PR to to change that today, to change the spec today, and uh we can move on. All right, thanks Guiam for presenting. Uh Han, uh I think the person you wanted to join isn't there yet, unless I missed them, but uh yeah, the mic is yours.

>> Yeah, it's fine. I mean, she she just asked me for the link, but uh I guess she didn't see the message, but it's fine. Um yeah, I'll present. So let me share screen right cool. So um what I wanted to present is a a new form of uh pricing that is I guess you can think of it as something that's in between uh pre-pricing and um state expiry. uh so using the concepts that we have learned from state expiry but without the actual expiring part so that we don't have to deal with the user experience. So um

this is an attempt to to to do that. So um yeah uh basically the general idea is to price state uh but um specifically state rights by the renewal age which I'll explain later what is that um uh in in essence like older unmutated state would cost more to write. So that's basically the gist of how the uh proposal will work. Um as a reminder um majority of the state right now is um is can be expired or it's very very old and it's unused inactive. So u we would like to um eliminate that as much as possible or the general objective is to u

is to deal with the state growth issue that we have. Right? So that's the that's the hole that we have. So there's one point about M pricricing is that so imagine that you have unin contract which is fairly popular. So you will get um access maybe every block or every few blocks. So when you do the state uh updates or if you do state access in general you would read it from the from the memory most likely but for older state um you will read it from the database. But in terms of pricing uh for example if you do an S s the pricing will cost the same but the actual resource usage is actually different because one reads from the memory and

another one reads from the database. So um when we do the gas cost it actually I mean the real state right cost varies between these two different state and um I think we can uh utilize this information to price it accordingly. So how it works in general is um we would do an encoding change to so this is on MPT we'll do an encoding change to the account and also to the story slot. So we'll add an additional field what I call as last return period to to this uh to to the account. But there there will be no need to do a migration because if a state if you do the if you activate the fork and a state an account or storage hasn't been written to or yeah

hasn't been written to then by default it's going to be zero. So I just want to make that very clear that there will be no migrations needed. uh but we have to add this field and you would uh modify the RP uh function for these two uh objects. So uh to illustrate it so we have a global current period which is derived from the current block number. So for example if the current block number is 25 or 26 million then uh depends on where we start the start the fork you just minus it and then you divide it by by how many box period. So, so something like this. Um, so let's say you have a you deploy a contract, you write some storage slot. Uh, so by default, uh, you

start with zero at least in this example. So this state right now is considered active. But after a few period or uh after a few years for example um this plot becomes idle. So um if you can see here the last written period is zero. The current global period at this block number right now is two. Uh period H is basically current period minus the last written period. So uh meaning that it hasn't been written to for two periods.

So when you try to do an STO and a right operation you have to pay an idle cost or idle yeah idle right cost which is basically more expensive than active cost. So uh yeah once you do that you you would re you refresh the period and then it becomes active again. So that's a that's a I think pretty clear example. And then another thing is that um there will also be dormant state which is uh I'll show you the formula later I guess but um basically this has been like very very inactive and uh dominant state will also have to pay like a dominance storage right cost which is more expensive than idle uh idle storage

right. So that's basically the gist of uh how it works. So um uh basically what we are trying to do is to price uh price it in different tiers such that uh for example here uh it's just an example we have active tier of state doment is less expensive than a new stock creation I think that's a very good question uh do state u should be equal to the gas cost of do state state right should be equal to or yeah should be at least equal to the new state creation. Uh I'll explain later why we need to do that. Uh but yeah uh so so

here for example uh active state is like less than one year of of inactivity idle is one to two years to is more than three years. It's just an example again we can do like active is less than six months or less than one month or so and so forth. But the thing is the right cost the cost should reflect the tier. So active will be the cheapest and then doment will be the most expensive. So uh what updates the period? So again here we are only dealing with rights. So if you do reads um it will not update the period. So um because the initial proposal actually has um we I actually wanted to include uh reads but we figure out that there are actually a lot of

like problems with reads having to update their pure metadata. So yeah that's why uh I decided to only do rights uh because um the initial idea is to do hot coal storage separation but because of the problems that uh read spring um I I think I switched the mental model to become like optimized for rights uh heavy or write hot working set versus like read only state set. So yeah uh um yeah so that's basically the GSA reads do not risks uh do not uh change the period and the gas cost of will also not be affected only the rights are

affected. So in terms of the client level benefits um the most immediate and the most important one uh is storage ting. So you can imagine that all of your active state is stored in memory. Uh it depends on your spec but hopefully at least most of it. And then uh for the idle state you can store it in a on in your fast uh storage or fast database or SSD here. And then dormance state you can store it in a slower compressed or re optimized storage. So um so it goes back to the question on why uh dormant state has to be the gas cost of dormant state uh yeah do state has to be equal

to new state creation is because um if you uh because if you so the plan is that we want to put all of the dominant state dominant leaves and also the dominant trials into the into this uh separate storage right so that we can optimize it we can compress it uh but new state creation would would there's a chance that new state creation would access some of the intermediate triodes from the dominant state. So hence that's why the the gas cost of new state equation should be as expensive or more expensive than dominant state. Um with the upcoming changes of in I guess in glanc uh I I think it's already getting very very very extensive. So uh again

there's there are no actual values here but we should re revisit it but uh that's just the how how I think of this uh dominant state gas cost versus uh gas cost of new state creation later. Yeah. Uh another idea on like this the benefit of this uh this metadata is that you can do prefetching on restart. So you can imagine that if you restart the node uh the client clients can scan the database and check uh check for state that is uh equal to the current period and then you can rebuild the the working I mean the the active set again. So uh that's also another benefit. Yeah. Uh so yeah that's basically the gist of how it works. So

yeah, happy to take some questions or ideas. Yeah, >> cool. Uh, thanks for presenting Han. I I have a few questions that come to mind or or comments. Uh, >> first one that that comes is you you mentioned that there's no change to read operations at all. Um, >> yeah. >> Why not? uh because you have like um some corner cases where for example in static call uh static call how it works is that you shouldn't modify existing existing state it's only read only but if you allow for read updating the the period metadata

then it kind of like it's kind of like a conflicting statement so uh again uh I haven't looked into detail whether this will be a problem for some contracts but or for for client codes or whatever. But uh I think that's just not that's just one example of a corner case that we have to deal with and another I think most immediate problem about vis updating the period metadata is that there are some state uh that that is written once and it's it's active in terms of reads like it gets uh it it gets a lot of as loads but it it it has the the value doesn't change. So essentially if you do uh read updating the period and uh we are every time

every time um the period is updated due to the reads we have to charge a right cost. So in in some way we are like penalizing uh >> yeah you're turning reads into somewhat like some like half right operations or something like that by >> Yes. Exactly. So yeah. Well, could there be a an intermediate yet? Well, so my take away from what you said is like first we want like read pricing predictability and like consist consistency for you know smart contracts compatibility and the second one is we don't want to turn have the burden of updating less like accessed uh time to to read operations.

Like the second one you could have it as like whenever something has been written to in the last year the read is less expensive but you don't you know you don't update the time stamp anytime you read you just do with the last time it was written to >> but you also need to keep track of the read time stamp of a certain state right? Well, you could or you could go with the last written period and use that as your freshness time stamp. >> Ah, okay. Yes. Uh yeah but um it's I mean again it started off as like a approach from state expiry but if we were to go with this like uh only rights

then we can't really do expiry because the definition of expiry is that uh we are we are eliminating state that has uh that's inactive in terms of access. So there are like in in this example if some state is read only then the period wouldn't be updated. So but we also shouldn't expire it. So yeah, so it's in some way at least from how I see right now it's not really compatible with uh expiry but um in terms of like uh storage taring or uh storage separation uh it helps but yeah it's a separate uh benefit I guess or trade-off.

>> Okay. >> Yeah. Uh yeah, there's a bit of a like feasibility problem here because I think at least uh but prove me wrong by all means if you only want the last time it was written like the problem if you want to um like be the to detect that you're going to be the first one in the period to write a given location. um you you can't really do this because supposedly uh when you start a new period everything that is too old should already be uh deleted potentially could be um and if you if you don't know this that means that indeed you need to go uh

to the previous period and make every read or technically you just need to make the last read of the period the you know the the period marker for that specific location but you can't really detect you can't predict what is going to be the last period to write to. So that means that uh it should be the first read of every period uh of something that is already active that should be uh the right and yeah okay it feels a bit confusing I I I could be wrong or maybe I'm not making even sense but uh I I think it's really hard to do uh rights upon uh yeah like to be to be

to detect you're going to be the first person to read from the from the period and so and update it and the the only thing you could make it fair is if every read was actually a right which is a possibility but then that means massive increase uh in general in overall gas cost and I don't think this is something we should go for so in my view um I would prefer to have some mechanism where people manually keep some location active by using an outofbend mechanism like for example sending special transactions to say hey this is going to be uh this is going to expire but please reactivate its um uh its counter or

something. It's not great UIX. I don't like it but I still think it's the simpler version. I'm happy to be wrong and in fact I would love to be wrong. Um but I don't see how we can do it any other way. >> Yeah. Uh maybe I'm misunder m misunderstanding you like are you uh suggesting that reach should also update the period metadata. >> So what I'm suggesting is to no I'm not saying a reach should uh precisely not I think we should not do that uh because it's not very easy for me at least I don't understand how we could do it >> in um in an elegant or at least a practical and simple way. Um,

>> and so because of that, I think it should just we should just add a new transaction type uh yet another transaction type uh that would explicitly say look uh I am manually updating uh I mean I'm paying for it obviously uh but I'm I'm paying for the update of this location's period otherwise it's going to be more expensive or potentially expire. Okay. Uh yeah, I think I think that's that's like the initial proposal that I had when uh where where I consider REITs to update period. But here uh res don't update the period. So we we don't really care about risk but which is why I say

like uh we don't think about like from a excess point of view but only from a uh right point of view. uh because here the this proposal uh I mean this idea we are only considering rights so it's uh rights only rights will affect the period so if there's a value that is read only then the period will stay the same for example stay at period zero forever um and how will clients utilize this information is that there will be at least how I imagine that is that the the the state set that is actively mutated it. So all the trals and uh leaves whatever you it will stay here.

So uh to put it more concretely for example LSM3 database uh because it's more optimized for rightes. So uh so we and then we move the read only state set to a separate storage that for example B3 uh database because it's more balanced uh in terms of like read operations. So uh rather than like a hot core storage separation, we have uh write heavy uh write optimized storage versus uh read optimized storage. So yeah, I think that's the that's a that's a change that I that that I made.

>> Cool. Thanks. Uh some other things that that came for me and I think Lewis might echo some of this is I mean there's if there are three discrete periods like active idol and dormant then necessarily there might be incentives to just keep an account into a particular you know active state for example. Yes. So just you know the time right before the the idol tricks up like there's game theory there that maybe there could be a certain amount of like idol uh preventing transactions that are not you know it's not really efficient because it's actually wasted transactions. But like if it costs four times more to do

idle transaction then there's a nonzero chance you're going to make transactions in this future that right to state you would be incentivized to you know keep it active or something like that, right? >> Yeah, I think there there is incentive to keep it active. I think uh in the uh full the original document uh I I also explicitly say that people would do this. I think it's normal. Um but uh like whether would people do it like I mean if you treat as an incentive yes uh it it is an incentive but if you if as an attack vector then it's not really an attack vector because I mean it depends on the the parameters that we set for the periods but um if you set it at one

year then uh it wouldn't be an attack vector because it's impossible to touch all of the or write to every single account plus story slot and or or at least it's going to be very expensive and there's no point doing that but incentive yes I do acknowledge that and I think it's uh perfectly acceptable uh to for example if you want to keep your account active then you send a transaction every uh right maybe right before the uh we update we go into the next period I think that's uh yeah my opinion is acceptable yeah >> yeah have you thought about like let's say there are multiple transactions that uh write want to write to the state and it's a dormant state. Like people could

set up transactions so that they they like people want to be second in line, right? Because they wanted someone else to pay up for the like reactivation costs. I mean these might be more like general state expiry things, but >> yeah, I'm wondering about >> game theory aspects of it. Yeah, I think um well that that works but um but that there will be also another part of game where if you are the first and you pay the dominant cost maybe the reward of being the first is more than you paying the active cost. So I I think the economics is will be quite complex here but yeah it's good to explore but yeah

>> yeah more stuff for me. Yes. Yeah, exactly. Uh, cool. The last thing on on my list is like wondering about storage versus accounts. So like how does that uh I'm wondering like if this is implemented then we have like the binary trees like uh suggested a redesign uh how would the the the separation of account and storage how would it interplay let's say I'm updating uh a smart contract that lives in it as an address so I'm updating the account RLP but I'm also you know updating creating

a few storage slots with the >> yeah I think uh for binary that would be different um I'm still exploring the options on if let's say we go with this then how would uh this uh mechanism work in binary tree what I'm thinking right now is that because in binary tree we have uh the the pagebased mechanism so here the the metadata is per account and per story slot then when we do it in binary tree and we do it at a per page level. Um that's the simplest way that I can think of. Uh in terms of transition I at least for now I don't see a problem because uh when you are dealing with the page you uh for example a page could

have for example the account header page you have a story slot some code and uh story slot and also account uh level. So you basically just take the highest period and that would be the period for the for that page. Um so that's how I think of in terms of transition. Uh but we could also not do page base. We could also do uh here like account based and storage slot based. But uh at least from from how I see right now I think page base is the simplest and makes make the most sense. Uh but yeah I think uh binary tree is still we still have to explore about it. Yeah.

Good. That's that's all for me. G has his uh hands. >> Yes. >> Uh yeah. So I actually have a few questions, but uh Lewis and uh maybe Carlos asked some questions as well. So I want to to give them the opportunity to speak first. My my just my comment on the binary tree is that uh we should make sure it's forward compatible. But uh yeah, this this is designed to come before that. So yeah, it's not going to be a big uh concern. We just need to make sure it's forward compatible.

>> Yep. Or counts. Any questions? I had one um also in my um comment there. So I joined late but are you are we planning to charge this uh period lookup or this counter these counters look uh um lookups because these are also extra work for clients um to be able to figure out what pricing they're going to apply.

Uh period by what do you mean by period lookup like >> so how are we going to store these counters they probably going to the database right so we need to read them >> yes uh they are going to store in database but in terms of like the the actual storage cost of adding this metadata is going to be very little based on the current state size that we have is like 3.6 6 GB uh that's and that's the worst case where every account and storage slot would have this data added and um yes it's extra work and with any EIP is extra work but um the the goal is to decouple the uh state growth state size from uh for example

state root uh calculation or the performance in general because how I imagine is that for the actively mutated set it's going to be small and because it's more in for example in the LSM3 database uh the the the size of the database uh would affect the performance a lot. So if you only use LSM3 data DB for the active set then and the active set is small then it's going to help with the performance and then for read only state you use some read optimized uh uh database so there's like a separation between these two of course like u now most clients are using uh a single type of database for storing everything but uh the migration

uh I mean the separation will have do need some work and whether it makes sense for clients to do that work to achieve a better performance. I think that's uh I also have to ask you guys and for opinions. So yes. >> Mhm. >> Oh, Mario. Hello. >> Hi. Um can you hear me? All right. >> Yeah. Okay. So, um random question here. So there's let's assume for a minute that we just go in these strategy where we make the current state really really expensive instead of um trying to like adapt it.

We just create new types of state that are more tailored for state expiry and this like active idle dormant uh management. Would there be any gain in using this? So instead of trying to fit the current tree into a new design, just assuming like the current tree is will become very very expensive and we'll just create new structures that fit more neatly with these um state management like active idol dormant. So would we have like any benefits from doing this instead of

trying to adapt the tree we have or or or not really? Does this make sense? >> Yeah, I think I think I get uh get what you're trying to say. Um in my point of view um I think most problem that we have regarding state is back backward compatibility. Like if you do uh uh like if you create new state uh for example one thing that we have been talking about is temporary storage which is a new form of state. Yes. Uh it's going to help some contracts because some storage slots for example are just not meant to be stored forever and they keep changing and uh it can be stored in some form of temporary storage. But the problem is

the adoption of it because the contracts that means older contracts have to migrate to to this uh new storage which is for some contracts it we can't assume that everyone can do that. Um so I think that's the biggest problem that we have and hence uh I think uh yeah I think I think that's the problem uh that we are trying to solve. Yes. uh deal. >> Yeah. To add to this, um we still have the problem that the current state is is huge and even if you create new types and you get the adoption, uh you can still attack the tree by using the the MPG. So unless we actually find a way to

get data out of that uh and or that we completely like we said it completely read only uh people are going to write to it and there's a cliff that we know is coming which is about uh not even double the size a little bit under double the size. Um that's not going to be addressed by a different kind of storage but the different kind of storage for sure is a great idea. We we do have a proposal for this. Um but we yeah I don't think that's uh solving the problem that we need to solve which is the MPT is currently really bad. Uh and uh well okay it's not really bad. It's just bad and at some point it's going to become a hindrance to to performance.

>> Right? So I I I do see that point. But what I'm suggesting is is that instead of having this steering like everything is just costs as much as a dormant access or a a dormant right in the old state and then you implement the cheaper one in a completely new structure. Like if you want to use the old stuff, you can just be super expensive. And yeah, if you want to use like if you want to store things cheaply, you just use the new structures. So what I'm saying is like we don't need to make active and idle cheaper in the current tree if we just give them a cheaper

option in a better designed tree. Um but of course he's assumed that there's actually benefit in splitting the work like this that is easier to implement than just changing the tree we have. Um but yeah, I'm I'm I'm just just wondering. Um yeah I think uh at least from what I see is is the incentive is more on contract developers like if you don't do anything and we keep everything extensive then uh and then we have a new form of storage that is cheaper then it means that we are telling everyone or telling the contracts to hey you should migrate this to this uh storage because it's more

expens more it's cheaper for your users. uh I I I think the incentive may work or it may not work because uh for some contracts it's just not possible to migrate and um yeah so uh so yeah at least is that's how I see right now. So >> yeah. So I Yeah, but I think that's fair, but that's the same problem as we have here, right? Like if if people So in in a world where everything costs as much as the dormant, you don't get worse than when you do tearing, right?

in terms of state management. >> Uh what >> sorry what was what was the comment I couldn't understand? I asked why not uh why don't you get uh yeah if if okay if you made make every state right as expensive as dormant well first you got a huge UIX problem but uh let's just >> why why do you get the huge UX problem >> because every legacy pro program is going to use the the current the incumbent system and right off the bat from one day to the next the the costs are multiplied by I don't know how much

but like you know if if we make dormant very expensive then all your costs are going to to rise and then excuse me and then you need to migrate to a different system. uh but in this proposed approach at least you have uh it's like it's seamless integration whereas if you have a different type of storage you're going to be able to you're going going to have to hand to design a new system and you're going to design a new interface which all the legacy contrast will not understand so USDC USD uh USDT all of that they will become a lot more expensive and uh I failed to how this is going to be any different like you just

have a different tiers except one of the tiers uh uses a completely different storage model which is yet to be defined. Um yeah I I I don't really see how it's going to to change anything really uh except making things a lot more painful for anybody who has deployed contracts and using data as it is deployed today. >> Yeah, got it. I think that's fair. So I I I think my main question was if there was a benefit there. It's like at the end even imagining you go through the hard period of all the contracts having to adapt at the end of these hard periods you you would get to a better

state management um state because you were designing the idle and active storage. in an ideal scenario where you don't have the some like um I don't know some design choices that you you cannot take because you have to adapt to the current state. So because you have backward compatibility appro um um considerations um but if you feel like no actually the the end result would be fairly the same then I think that answers my my initial question.

>> All right. Thanks Mar for the question. Uh any other questions? Um yeah, I had a question. Uh just wanted to add one last thing. So I I agree that if we can find a benefit, um yeah, that would make sense. Uh it's just that I'm not envisioning it, but we should spend time uh thinking in a bit more about that just in case. Uh yeah, it's just that I don't see like it doesn't come to mind right right off the bat. Um yeah. Okay. My question was uh and I'm sorry because my uh my daughter barged into the room so at some point so maybe it's been asked at that moment but uh you know if the if the uh I'm going

to say cold I forgot the name uh dormant if the dormant data is moved to a an HDD recovering it is going to take a lot more time because you you know we say HDD but it could also be an HDD on a different machine. Why not? >> Yeah. Um is there like something that's missing for me uh from the picture for me is um how long you know uh if it takes one second to to resurrect that data um is there some kind of a synchronous mechanism that I missed like how do we how do you you know just the fact that we're going to pay more is not enough we also have a potentially uh we have to provide the data fast just as fast. But

like in your model, it's moved to NHDD. It's not just your model, by the way. It's many uh state expiry models. Um how do we you know justify this? How do we build something that is resilient to to this kind of use case? >> I think I think the criteria is still u for dominant state access. the the criteria is still that it it should still be fast and it shouldn't take so too long. It's just that active set for example active at idle should take uh it should be faster than do hence that's why it's cheaper but do state it will take longer and hence that's why it's more expensive but it shouldn't be so

expensive that you'll take up the whole uh like block time uh I think at least that's how I see it so if if you want to do a more extreme version of like uh accessing from from some archive storage I think that requires some other mechanism which uh that probably more complex like what you say like async like you look you try to access it but you have to wait for a few blocks before you can actually get to fully access it. So I think that's another model. >> Yeah that's the thing um because HDDs I mean I haven't I assume here no one has used an HDD in in forever. um just to make sure this can still work, we we

would have to do some performance measurements because if people do move this to an HDD, uh yeah, like it it needs to work. It needs to uh it needs to be fast enough. We can't spend one second just resurrecting one node. >> Yeah. >> Yes. uh argon I mean I haven't looked at what they did but I guess it's kind of this from my understand they are trying to use a mix of and B3 so this would be I guess perfectly suitable for what what they're trying to do because it's one is

optimizing for right another one is optimizing for reads so yeah uh I think time is almost up so I think uh if you have any questions just ping uh so this pass it back to Gabriel first. Yeah, thank you everyone for the questions. >> Yeah, thanks Han. Thanks everyone for uh chiming in with the questions. Really nice when conversations get going like this. This is how we we make progress. Uh so yeah, as Han mentioned, you can contact him directly uh with questions if you have any. And yeah, we're about uh to to end this call. So we'll be sharing a summary uh the stateless book

and a tweet probably coming out uh this week. So thanks everyone for joining and we'll see you in two weeks. >> Thank you. Bye >> bye.