Stateless Implementers Call #48

Transcript

Loading developers...

All right, seems like everyone is here. All right, so welcome everyone to the stateless uh implementers call. Let me just find the agenda quickly so I can share it in the chat. This is call number 48. And there you go. The issue GitHub issue is in the chat. So, let's get started with the agenda. We're going to start with team updates.

Team Updates: Discussing transition code and test net setup

So, whoever wants to go first, go for it. I guess I'll go. Um, I was working on um merging the transition code in G. uh found a problem or not a problem but found a [clears throat] potential tweak to the to the spec that I want to discuss. Um otherwise we have been interacting with Karim trying to get the test net started. Um but before that we we just want to make sure we agree on the on the details.

So I produced some blocks um and uh yeah we agreed that this was not the right way to do this. [clears throat] Um so in fact we we will need to talk about it a bit later how we how do we sync um yeah that's pretty much it for the for the binary tree itself. Yeah, on business side. So I know that Tom is working on transition but I don't have a lot of news on this part. Uh but on binary tree so as Gum said we had some discussion. So I have a branch with binary tree in Bezu. Uh I have to update it because uh the last time I updated

this branch I think it was some months ago. So uh if you want to run a test net I would prefer to to run it with something that is up to date. So it's what I will do this week or next week. We'll see. But I think this week and after yes to see with Guom who we can have this test net running with Bezu and get and maybe other clients mainly that on my side. Um so from my side I've been mostly working on two things. The first one is to add support for binary tree bloating

uh in the state actor library from uh Tony so that we can actually start addressing uh well and understanding specifically the performance uh that binary trees bring with worst cases and what are the gas limits that we should expect uh to be able to handle and otherwise improve the implementations. And from the other side, I've uh implemented the first version of the partial stateful nodes uh which is being able to sync as of now. So I I basically snapped sync uh the account plus die and USDC and that took around 50

something gigabytes uh of database in like 30 minutes. So now that it's confirmed that we can actually snap sync uh only what we want from the state uh I'm starting to rebase well I actually rebased I finished some some minutes ago I rebased on top of balnet 2 and the idea is to now not only make sure that the snaps works within a bal enabled uh test net but also uh start uh testing all of the block processing uh for the for the val and computation of the state route check that we can actually provide uh or serve it get proof for the contracts that we

are storing and and all of this kind of stuff. So that's that's partly from my side. Good. Anyone else before we jump to the next point? Good. Well, point number two is a point from uh Gon. So, we're going to start with that. It's about well, something you just mentioned in this update, but specification tweaks regarding transition using system contract for storing pointers. So, Gon the mic is yours.

Specification Tweaks: Transition using system contract pointers

Uh thank you. Um yeah, so I would like to talk about a tweak to the to the um like you know last time I was talking about using um an overlay sorry a system contract to track all the conversion pointers or the conversion state if you want. Um namely which was what was the last account that was being um being uh converted or what is the current account being converted? What was uh the what is the the next converted and uh like a couple more um a couple more items including whether the conversion has

started because the conversion starts after a week right we need to distribute the pre-image file um and uh whether the conversion has has ended because if the conversion has ended we just go with a binary tree we don't go with this middle um like facade pattern uh that does the rights into the the overlay tree but does the reads first in the overlay tree and uh in the in the transition tree if it's uh if it can't be found in the overlay tree um so I tried to implement that in G um and I found um bit of an issue or at least it's very difficult um to

implement um and so um I wanted to talk about the possibility of delaying the the conversion by one extra block. Uh so I'm going to to explain what what's going on. Okay. Uh page not changing. Okay. Uh yeah. So at the core uh it's uh basically it's um uh it's a bootstrap problem, right? Um the conversion status if it's in a system contract uh in in the storage of a system contract that means it's in the state. Uh the state itself as you all know is represented by a tree and because of that uh it means that to read the tree we need to know what kind of state that is what kind of

tree that is sorry. So that means that uh yeah it's it's biting its tail. Um you you need to know what um what state you're you're reading. what type of tree you're reading to know what type of tree uh sorry you need to to read the tree so that you know what type of tree you open. So um yeah that's the that's the problem. Uh there's not many elegant ways to do it. So the the naive approach which is probably going to be the final one but I um I want to suggest another another approach uh before um you try to open both tricks. So you first try to open the binary tree and if

that fails well the tree you have is an NPT. Um of course we're not going to do this all the times or at least you know it's left to the client to decide if that's what they want to do. maybe uh on the test net or any any test net any shadow fork. We don't really have to to care too much about this kind of performance. But it's pretty bad to try to open a tree and if it fails, you return you try another one because there could be a genuine error in your in your uh database and then um and then yes, you just start from a fresh tree. So it's um it's not a fresh overlay tree.

So it's not very um uh well okay let's say there are errors that that would not be caught and that's not that's not ideal. Um so yeah you like the the idea is that you try to to open both and the first one that works is is the correct one. Um but that means that for us uh we wouldn't want to do this all the time. So we would have to signal that the opening only happens after the after the attempt at opening the binary tree only happens after the fork and uh if that is the case then uh you need to pass a flag in the tree management layer. something from this uh in this uh slide but is also

very important is that um if the right like the the start transition the start of the transition is not already stored in the contract which is what you do when you bootstrap uh you have an issue because uh you will not see like you will fail to create the binary tree so you still have uh an issue with the bootstrapping problem. Uh so that's a bit of um solution. That's that's a sketchy solution that probably is going to end up being the correct one, but it's very very um yeah, there's a lot of uh devil in the details.

Um and um yeah, um I haven't managed to get it to work for GU uh yet. Um the other approach is to use the one block delay. Um, so once again, sorry for my poor penmanship, but uh this is supposed to represent uh this is the fork block. So this is the the fork slot and this is the the slot just before the the fork. Uh and what we do is we start with the the MPT that we write to and then at the fork block we keep the MPT.

Fork Block Delay Strategy: Discusses delaying fork block by one block

So we don't bootstrap the vertical tree or sorry I say vertical but binary tree or whatever um at all but what we do at the end of the block is that we write uh a one into the started uh like the the leaf uh of the contract the slot of the the storage slot of the contract that corresponds to whether the transition has started or not. And so we've write a one and that's all that happens for for this block. So there's a delay uh because the first block after the fork is still 100% MPT.

Um and then um the fork sorry the block after you see that when you read the MPT so you open the MPT and then you see that um it's been um it's been set to one. So you also bootstrap the binary tree um and um then all the rights because it's been uh created you start from a fresh tree but all the rights go in there and as a result uh for subsequent blocks um the MPT is always frozen. I mean it was already frozen here. Uh and all the updates go into the the binary tree and

that means uh the all the other conversion pointers end up in the in the binary tree. Um so the idea is that we're starting one block later than um than we used to in that model. Um the yeah I just also realized doing this presentation that this is more or less the case already because we don't start the conversion right away. Um we wait for a week. So it's actually more than one block delay. Uh what I'm saying is we could extend this uh this period by one more block and then um at least it's

um it's a solution to to to this problem that I have. To be clear, this is um this is totally connected to an issue in GU or at least the way GU is written. Uh it simplifies the code a lot. Um I'm submitting the idea to see if uh you know BU I guess because no one from the other mind is here would uh would be aminable to that solution if they think it's too complicated u etc etc.

>> So so I think I had the same issue when I was working on the transition. So I found a way to manage that but uh I think I will prefer your solution because it will also simplify my code. So I had to to to use some uh work around method to fix this issue. So if we have something cleaner like that, I think I would prefer >> uh Okay. So that's um >> because on my side I had to >> Yeah, I had to look at the time stamp when we are importing the block. Yeah, I think I had the similar issue also on my side. So

>> So delaying it's better. Yeah. And to be fair, that method also requires uh looking at time stamps or at least the block time stamp at least. Um >> yeah, but I think it's the previous it's the previous time stamp. It's some it's not the time stamp of the block we are running. >> I think >> yeah, it's it's it's more matching the logic we are we have already in Bizu looking at the time stamp before and for the transition I had to look at the current time st. So it was uh it I had to add some some different code just for that. So >> Mhm.

>> Yeah. Okay. So that seems to uh to align with our our own problems. Uh but then what do you think of this method where you just try to open both right? Uh >> yeah. >> Uh regarding that, I'm not sure to understand. Uh >> well, once again, it's something I haven't managed to to make work, right? Uh so um so it's probably it's probably not not even a starter. Um but yeah the idea is that when you detect the fork um like when when the fork starts you start reading two uh two trees like you

say okay the fork has started so I'm going to assume that I'm going to read the binary tree uh and if that fails that means I'm at the first block uh and therefore I need to bootstrap so I need to go and read the the root time passed as a MPT but an MPT is not uh like the only thing it's actually an MPT uh that is the base tree and the the binary tree is empty so this is like something that's going to work for the for the for the first block really >> so I think it's more related to get implementation in vizu I was just

looking at the time stamp and depending on the time stamp I was uh starting MPT or binary tree or transition tree because I had this kind of transition world state where we have binary inside and MPT inside [snorts] uh but I was just using time stamp on my side it was working correctly so I think it's more related to your implementation maybe but >> that means like this would not be of interest to you >> no I don't think with with time zone I think we can do uh we can do Okay. Well, if you can do anything with time stamps, then uh good for you.

>> But we can maybe discuss about that maybe later, I think >> because I'm not sure to see how Pam I don't know the get implementation, but seems strong that we we cannot use time samples in get but >> well that's the thing we should be able to but uh >> yeah it's a very uh intertwined piece of code. So once again, this is a 100% guess problem. Uh at least 100% guess problem. Maybe it's also a problem for other people. Hence my uh my presenting this. Um but um yeah, if um if the the second solution works for you, then maybe we can uh yeah, we we can keep

discussing and if we if it turns out that's really the problem, then we u we change the spec. I think I can try to implement the second solution and see if it's working correctly. I think it should work correctly with Bezu, >> but I can try to look at the second fix and see. Yeah. >> Okay, perfect. Uh yeah. Uh we can do that. Um unless there's more questions. I know you've wrote something. Uh okay, you were talking about time stamp. Okay, so unless there are more questions, this is all for me.

Transition to ERC 8147: Introduces new topic on binary tree storage layout

Thank you GM for presenting this. So since there doesn't seem to be more questions, we'll move on to uh the next item on the agenda. This is a presentation of VRC 8147 local preserving storage layout for binary tree. Uh this is by Han. So yeah, the mic is yours. >> Yeah. just share screen. Um okay. So I think it's going to be the short one because um the idea is actually very very simple. Um so um the previous source I think I mentioned about like doing um something with locality as well. Uh but

that one is a similar idea where uh we want to um optimize the the locality as much as possible. But the previous one is an EIP where we are adding new new op codes. But I actually realized that that's no longer needed uh because we could just have to change uh we just have to update the compiles to to do the to update the key derivation method uh once we u migrate to binary tree. So um um so a a straightforward way to explain it. So let's say we have these three mappings uh in a contract. So the current MPT how how uh what we will do is that um we will hash it um and then those keys will be randomly distributed in the try. So locality is bad but we

Key Derivation Method Update: Discusses updating key derivation for storage

will have the same problem as well in um uh in in binary tree uh where even though we have the 256 uh values uh but they are they are stored individually. So what we need to do actually is to uh basically update the key d the key derivation method the middle part here to for now it's something like this um where uh we are hashing the address then we remove the last bite and then you uh do an or operation basically replacing with the with the base slot uh index. Um so this is this will be done by the compilers.

Yeah. So to do that um basic when we are generating the the try key um so you can um notice that it's like it's is sequential for this uh for the same address u mapping it doesn't have to be address uh it can be something else as well depending on how the contract is written but address is the most straightforward one. So uh if you do that uh that means that we um those these three mappings uh for a particular address they will share the same leaf basically the same page. So yeah so that's basically um the the thing that we have to do. So yeah that's it actually

any questions? Yeah. So this is intended mostly to to be used by uh for storage or for code or what's the the >> uh storage storage. Yeah, I I don't think um like contract developers have to care. I mean okay they'll definitely have to be aware of this new optimization because the gas cost would change but I would say the most of the work is done by the compiler side. Yeah. >> Yeah. And what happens if we go beyond 256 uh chunks of storage?

>> Uh for now I don't think we have I mean uh I don't think we have 256 mappings at least. But if let's say we do then I think it's um it will be the compound's job to actually detect that and then to adjust the the the the keys correctly. Uh I mean we can fall back to the previous one or maybe we can. I'm not sure if we can uh actually exceed it. Yeah. Uh but yeah, that's that's a good question that we should check out. But I wouldn't say it's a big problem based on at least based on our uh uh our current patterns on uh contract codes right now.

Yeah. >> Yeah. The reason why I ask is uh a a lot of storage like proxy patterns are going to specify an explicit like storage location which likely wouldn't map to the first like whatever number of storage slots indexes there are >> and it would fall like somewhere >> probably beyond that because it's it's effectively just a random number in the storage tree. >> Uh yeah >> and a lot of modern proxy patterns use that. I'd have to to look it up, but I I know I've seen it used quite a bit. So, yeah. Uh I don't know.

>> Okay. Yeah, I think that's a that's a good point. Yeah. >> All right. Uh >> yeah, I like the idea. It's quite it's really simple. So, I I like the design. >> Nice. Okay. Uh stop sharing. Yeah. >> Uh sorry, just a question. So the structure you would be targeting are mappings, right? Not uh because like in the case of an array, >> yes, >> you would have Yeah, I guess you could use this for an array as well. But so that means uh yeah, I guess it doesn't matter because the the Yeah, >> 31 bytes security.

>> Okay. Yeah, no question. Makes sense. >> Yeah. Okay, cool. I'll pass it back to you. Y >> nice. Thanks. So that brings us to the last point of our agenda number four. Uh it's by Carlos. So it's binary trees, redesigns, and performance considerations from themes. >> Yeah. Hello. I I don't have a like visual presentation and I mostly wanted to introduce the topic and see what other people uh think. So lately I've been working on several stuff. Uh one of

Binary Trees and Performance: Introduces binary tree redesign and feedback

them was this partial statefulness idea from for which I'm I'm working on in in G. And the realization I had is uh I mean it's fairly obvious of course but is that uh the current MPT design basically embeds within the topology u some dependencies but also some advantages. So for instance for partial statefulness uh one of the main things that we that we take profit from is that we can discern between the account tree and the storage tries uh of every single contract and that is really useful because that allows me to actually snap sync only the accounts and only the contract storage

that I want to have. Um so when going to a binary tree if we go unified basically uh that means we b we lose uh everything here like there's there's no way anymore to know what is an account and and what's not and I was basically trying to seek some feedback from people on whether we actually value more having the tree to give us meaning for what we are looking at in the storage or we actually value more the fact that we have fully unified tree. Um, does anyone have any takes on that?

Oh, I think we can still have the like topology in a unified tree, right? But maybe we have to sacrifice a bit on um not sure about security side. uh uh like uh I think it's the same idea as what you mentioned in our internal meeting last time where um like the left portion of the tree is for accounts and some portion is for storage. So the the the partitioning is very clear uh but I'm not sure if if doing that in the unified tree will still uh be suffice for uh for partial statefulness.

>> Yeah. So, so there are several things here. One is uh we could just have two trees. Uh because one of the main benefits or why we want to go towards a binary tree is first of all small proofs. Uh but no one is really using proofs anyways besides snapsync. So I mean I would love for this to actually matter but so far it doesn't look like it. uh but the second one is that the state root computation actually becomes uh let's say as optimal as possible in the sense that uh if we have a a unified tree uh the the probability of uh the storage slots that we are touching to recmp compute the state is that

basically they are distributed across uh all of the possible sub trees and therefore we should not have any hot paths whereas this is of course not the case uh in the MPD But if if we could actually get something that that also tries to avoid this these issues in the state computation like having to roots or distributing the keys by prefix. So basically accounts go to all of the zero one prefix and and storage goes to the one zero and one one or I don't know something like that. Uh would this would this actually make uh any sense?

Like is is there anyone that has actually thought about that? Uh we just consider going to binary uniformly and and no one really cares. Like I mainly wanted to get ideas and feedback from people as we are working on trying to see if it makes sense to redesign a bit the binary tree since uh we are on time. uh and yeah and basically I wanted to hear thoughts if there are any so when you say redesign the binary tree you're mostly wondering about uh so so you mentioned now like distributing uniformly like the accounts uh are there

other like there's also I think it would be helpful to break it down into different architectural sections so there's uh there's a leave design, there's the way that the you know account keys are computed, there's the fact that it's you know actually binary like two to two to two to two to two to two to two to two to two to two to two to two to always two uh what facet of those would you like to get in most input on what I want to get input on is basically whether we value more the fact that the tree is unified so we have just one tree or we value more that the tree has topology within it like the So we know when we are iterating over accounts and when we are iterating over storage and basic we have this set

Unified vs. Topological Tree Structure: Discussing trade-offs

domain separation which comes in handy for several stuff uh like the archival state expiry that Giam is working on like the partial statefulness that I'm working on all of these solutions exploit that when we look at the database we know if we are looking at accounts or looking at contract storage and what type of contract storage are we looking and So the there seems to be this trade-off between whether we have one thing or we have the other or we have a really weird thing in the middle. And I was basically asking whether anyone has hot opinions or or yeah I don't know how to say it like strong opinions sorry uh on any of both paths.

>> Cool. Yeah thanks for clarifying. Karen seems like he has something to share. Yeah, go for it. Go. >> I think you can also give before. >> No, go ahead. Go ahead. >> Um I mean just maybe it's just a opinion since you asked for it. I mean first of all I mean whether you have um basically if you sort of do this kind of domains operation then internally of course this amounts essentially to just having separate trees. I mean if you just look at everything from below the I don't know two layers below and you just look at the root the intermediate rules in a big unified tree then these are basically separate state trees for just

a portion of the state that corresponds to account storage code whatever um in so in a sense it's actually nice that they can view it in both ways um from a security point of view I mean the fact that it's no longer completely evenly distributed but rather I in inside some sub tree of maybe a bit of a smaller size. I think it does not make that much of a difference at least if you're looking at worst cases because if somebody wants to sort of make craft some block where a lot of accesses happen on the same hot path they can just do this and whether you have um sort of whether you have it spread out or not does not really affect this um at least not for adversarially created

blocks. And the third reason is more well maybe the more interesting one is that I think that in the future we might need to sort of have different tiers of state like I don't know state that is only temporary or that automatically expires or that is sort of accessed differently in a parallel fashion or whatever and sort of um making these kind of links with a prefix ling basically opens up at least future updates that make much more strong distinctions between different tiers of state. So just from a point point of view of up or future safety or upgrade safety um it's probably better to use a design where you have a bit more structure in the tree. But that's just my opinion.

Security and Efficiency in Tree Design: Addressing imbalances

So that I mean all good points. One of the things that I I was basically thinking which is in I mean kind of in line uh to what you said is if we go with the prefix idea and we and we have let's say two trees uh they are informally distributed inside uh but of course the fact that address sorry accounts or EOS are in one place and contract storage is in the other definely creates an unbalance there right so What I was mostly uh kind of trying to to to understand is if we do this like key distribution and we have only one tree

but we distribute with key prefixes. So basically everything that has 0 0 is an account uh sorry EOA and then whatever has uh one zero or one one is contract storage. Uh the problem that we have with this is that we never actually know if the ratio that we're picking is good enough. Basically now the ratio is accounts occupy 14 gigs more or less and contract storage actually takes the rest basically minus of course intermediaries uh intermediate nodes and so maybe this ratio changes in the future and therefore the imbalance is even greater.

Besides that and from a security perspective, I'm not really sure how is it worse than the MPT meaning it it is actually not yeah worse but maybe I'm missing something. So can you actually like elaborate a bit more? >> I mean on security point of view I mean okay let's assume it is imbalanced. Why is that even a problem? Um because I mean the question is of course from the database layout internally. I mean nothing stops you from basically internally having two different databases, right? I mean you would have even though sort of the tree is sort of the same from data structure. I mean you could basically store everything that sort of starts with one one in a

different access database that is maybe smaller and the other one the three keys that start with I don't know zero in another database. And I mean the only sort of the only thing where they basically interact is the final step of the of the state computation where you basically hash the root of the one and the root of the other. Sorry. I think he's unmuted. Okay. you're unmuted.

>> Yeah, I muted him. >> Okay. Yeah. I mean just I mean and also mean for the I mean Okay. So what what happens if if one state if one of these links is sort of smaller um that does not make that does not really pose a problem because essentially um the coast you have the coast you have per access basically depends on the depth of the whole thing of the tree that you get and just because one of the trees is smaller I mean if if sort of you have a lot of accesses into the small part I mean most is off by most a factor too if you have a loss of excesses into the small part and these excesses actually become cheaper. So it would only be a problem

if most of the excesses are in the big part. Um but there you only lose one layer at most. So because even if you add s of the small layer to the top layer to the the small part to the big part the only difference is basically one layer. So it's basically a plus one difference as far as tree depth is concerned. So it's not a big deal. In fact, it might be a it's potentially even an improvement. >> Sorry, I got the deceit. Um I I in line with that one thing that I'm not sure if the guys from Mega E or or who it was but if we keep this separation one of the good parts is also that we can keep

the account still separated and we could potentially put it into RAM if RAM happens to become much bigger and much cheaper in the future. So even we could still recomp compute state route faster at least in one side and we can cash also in run the first levels of the storage tree if that helps on on something. >> Yeah, >> I just think that this thing is just not really an issue. >> Okay, I see. Okay, that's nice. That's good news. Uh why why is not >> just before you were a bit offline? The reason is basically I mean if you sort of if you if you if you basically just

Binary Tree Depth and Performance Optimization

separate into two parts I mean if you have a lot of accesses either it's so say you have a very imbalancing you have a small part and a big part if most of the excesses are into the small part that's actually better than if they part because the co the thing that we that we depend on is actually not that they are spread out the the spreading out is not an end goal in itself. It's only the spreading out. It's just there in order to make sure that the depth of our tree binary now does not grow too large. But if a lot of accesses are into the small part, this will have just a lower depth.

So you have a lot of accesses with lower depth, which is good. And if you have a lot of accesses into the bigger part, then you're basically paying some extra in some sense, but the amount of extra you pay is at most one layer. So it's just a plus one in terms of depth on a binary tree that you that is basically the worst thing that can happen with this thing which basically accounts for this extra prefix. Yeah, I think for performance performance in um at le doing the domain separation doing yeah separation is going to be much easier to for example you know like there's one domain there's one region that you can

cach for sure but if you are if you are going with the um current unified tree I don't think I mean it's it's still possible but um it's not that straightforward from what I can tell so I think also on the performance optimization side I think u doing the separation be Yeah, from my side only I wanted to add uh one one thing to this which is um one of the things I want to start benchmarking as soon as possible as as soon as I can get the the the DB of GU in in binary remote bloated uh is in the MPT I've recently discovered on

the stateful benchmarks that what actually affects the performance on stateful rec computation isn't only the depth but also the size of the contract that you are um basically fetching uh nodes from. So I I want to basically run some analysis and see uh what what affects more uh in that because what could very well happen is that depth is what leads the cost and so in binary trees we usually have the worst depth always which is the average case. Um so yeah I'm sure if anyone is interested on these numbers but I can forward them as

soon as I get them. I mean just one thing to sort of add here. I mean you have to be a bit careful about sort of the worst case for sort of maliciously crafted state parts because an adversary sort of could basically create state that is unusually deep. >> Sorry, can you elaborate a bit? >> Uh I mean just just be aware mean if you're sort of looking at average sort of if you're looking at average case performance because I mean it's actually not terribly difficult. um to create a lot of state that sort of collides in the first the first bits. So you have sort of a part of the state that is

actually much deeper than has much higher depth than sort of sort of what the average case would sort of just >> by something like >> I see I see. So you mean we are safer if I understand correctly as it should be harder to craft those nodes or you mean the opposite? um harder compared to what in what case? Binary versus MPT case. >> Yeah, exactly. >> Um slightly, but it does not make much of a difference. I mean, the depth is just generally bigger because it's a binary tree, right? And it does actually get a bit harder to um make something with higher depth. I can I actually computed this once I would I would have

to look at maybe get back to you or something. It gets a bit harder but not by much. >> Okay, I see. Because I have in the execution specs, I uploaded some worst case benchmarks for depth and I mined uh combine the account and the storage tree of the contract. It was I think uh like depth 20 something uh overall. And then what I did is since the slot index is the same in all contracts, I could basically just copy paste this huge branch to a lot of different contracts who all fell uh into an account that was also really deep into the account in the

MPT. And that created a really bad uh case for the for the entire MPT uh when recmp computing the state route because you are in the deepest part of the tree for all the contracts which you have deployed. But I'm not sure I'm not sure that a I can do this in the binary tree as easily uh because the depth is much higher. So um I will probably run out of compute but maybe I'm missing something but but yeah I also am not sure that I can find these things as as easily. So maybe if you can give me some of your uh I don't know you have thought about this and maybe you

wrote some code or whatever. So if you can give me any resources that will be useful. >> Yeah I mean I wrote down something on this I don't know something like one and a half years ago. was probably not up to date, but I can I can give a link. >> Thank you. Thank you very much. >> Um, yeah. So, one uh extra comment since you were asking for for comments um is that I'm not sure I mean okay I I get a an idea why but uh I we already mentioned similar ideas um not not exactly the same idea but the uh we did mention to Vitalic the idea of not of taking the code out of the account

Discussion on Account Data and Witness Size

header um And the problem with this uh is that uh okay that's not uh what the problem is but Vitalik was not super happy with this idea simply because I think he likes the the fact that when you open an account you get all the data in one that you need uh okay that small contracts need in one swoop. Um because you get um you get the well the account descriptor, you get the first few uh slots which is what um what uh mo smaller contracts uh need. Um and uh because variables tend to be uh

stored at the beginning of the of the storage space and then if you have a hashmap or uh actually just a hashmap yes it can jump all over the place but uh but typically the compiler will store everything at the beginning of the state. Um and if you don't have much code then uh everything will be accessible in just one DB read. So uh that's the first aspect of it. Um and the second aspect of it is that uh we um you know if we separate the the code from the sorry well the code of course but the

storage from uh from the account. Uh is that you will need to prove more leaves per um per access per account access or at least contract access. And uh this is this might make the the the witness bigger. Um now these are not my um opinions. It's just me channeling some uh somebody else's opinion after a conversation from like a few months back. Um but I think that in order to decide on a model like this, we need to prove that uh we need to have numbers on

what the average uh witness size would be, which in the case of a binary tree is a bit uh annoying because it's going to be bad compared to BLS and it's going to be bad compared to to ZKVMs. Uh so maybe with ZKVMs it doesn't matter as much anymore. Um but actually yes it does because you will still need it for for syncing you will still need it for uh for uh things uh for RPCs and things like that. Um but yeah like just uh we we need to measure the the I would say the performance if it turns out that reading in one location of the tree and

then another location of the tree is not is not as bad then it doesn't make any difference and we might as well do the more rational thing especially if the average performance is much better like what goi was saying and then uh also look at the witness size uh yeah these recommendations. All right. Well, thanks again for the engaged discussion, everyone. Um, I think that uh settles the that part of the discussion, right, Carlos? Was there anything you'd like to add or closing

Discussion Conclusion and Next Steps

remark or >> No, that that's that's good enough. Uh I'll maybe write about this and publish an eth research or something uh and try to gather more more feedback. Uh and I will also get all of the performance numbers so that we can come and discuss again but but with data. >> Thank you. >> Amazing. Yeah. Thank you. Cool. So, uh, unless someone wants to take that those last 10 minutes for, uh, something relevant, we're going to close this, uh, this call a little bit early, uh, because we, we've just run through our today's agenda.

So, yeah, I'll leave like a 10 second opportunity for someone to to chime in, but otherwise, uh, we'll close this now. Oh, uh I guess most people are gone, so it doesn't really matter, but I wanted to say we're trying to uh organize a stateless summit in uh HCC next uh March. Uh actually, it's going to be April 1, so next April. Um yeah, so if anybody hasn't signed up yet for that, uh please uh please uh sign up. We're going to have some conversations. We're going to have some presentations and I'll keep showing it over the next month. Uh but yeah, wanted to to share that that info.

Announcement of Upcoming Stateless Summit

>> Great. Yeah, thanks for sharing the All right, thanks everyone. That closes this call. Uh I'll be sharing this summary shortly and we'll be tweeting about this uh this week. >> Thanks. >> Bye. >> Thank you. Bye.