Stateless Implementers Call #46

Transcript

Loading developers...

All right, here's Gon. Cool. So, let's get this uh started. So, welcome everyone. This is stateless implementers call number uh 46. Uh we are January 12th. Um I shared the agenda in the chat. Uh it seems we might have Vitalik today join in to present one EIP. Uh but in case he doesn't join, I think he's here. I'm here.

Stateless Implementers Call Introduction

>> Oh, there you are. All right. Good. Uh since you're here, Vitalik, I will prioritize your time and have you present the EIP uh as the first agenda item if you're fine with that. >> Perfect. Yeah. Um, did you want to like get the doc into the chair? >> Do that or at least I will attempt to. Oh no, that's not the one. That's the one. Yeah, refreshing windows. Here we go.

And uh where's the Okay, screen. Uh, there you go. >> Okay, great. Is uh is everyone seeing the uh the seeing the screen share? Okay. >> Yeah. User associated storage. >> Yep. Okay. Perfect. Uh so the uh idea behind this is B this new category of uh storage that uh I'm proposing which I call user associated storage. And the idea is basically that a contract and like the easiest example to think through here is like an ERC20 token can create storage which is associated with

User Associated Storage Proposal Overview

some user and ideally like lives with that uh user in some sense uh but it's still controlled by that contract and so like even though it lives under the user's header the user cannot choose what to what to write to it which like makes sense for balance because I don't want users to be able to just give themselves coins. Um, and so the goal of this is that it's more friendly to basically any kind of state expiry or state cooling, which is like what what I've been calling these proposals that expire state, not by like fully deleting it, but by moving it to like some place which is still accessible, but accessible with like more difficulty or

more lag. And uh the reason why it's more friendly is basically because all of these proposals benefit when like state that is beneficial to a particular user all expires together and all can be revised together. And in addition to this, it actually also allows users to save gas. Basically, it reduces the uh amount of branch queries that you have to do by one. And so it could make things like 2,000 gas cheaper. Um so the basic idea is that we create a uh a new map user associated storage and the map maps basically so creator user and index uh so that's the

key uh to 32 byt values and then um the so basically it's like a mapping except we're like basically taking the concept of a mapping and we're moving it in protocol um Um and uh the other thing about this is that this there are two places in the tree um where this storage can be saved. Uh so this is all assuming the u the the binary HP design right and so basically the one of those two places is kind of default storage and default storage is like this and it's like basically a random place in the tree very similar to how contract storage is

just stored at random places in the tree. Um but then the other option is basically that the user has the ability to promote a limited number of uh their own storage pos uh these user associated storage positions to live in their um account directly in their account header. Right? So the way that the binary tree IP works is basically that it's the bottom of the tree is these 8K pages. And uh I mean I think like by the way we should still benchmark this and like explore reducing the pages to 4K or 2K like this whole thing is uh and like originally designed to be both was both a hold over from the vertical era where

like more width is good and was designed for database friendliness but like we should make sure the width is actually database friendly. Um and so there's like a lot of slots that can be loaded with one single disc read. And in the current design with APK, you have 63 positions for the header, then you have 63 positions for the storage. And this is really nice because like for example, if you're like like I remember I was looking into Uniswap V3 and just every transaction reads like eight storage slots and so 20,000 gas will go down to like 2,000 and then also the first pile of code chunks. And so if you have small code, it loads all at once. And I'm suggesting we kind of squeeze in basically these privileged UAS positions. And the uh idea is basically

it's like a list of 16 and it's just one a key value key value key value key value. Um and uh reminder that the keys here are basically that you take um like basically the uh hash of the uh account and the and the user um and then um actually what we're going to do is basically prepend uh to that the uh in uh the index and the index just lets you have 256 of them and it just makes it easier for accounts to like for contracts to have multiple mappings like this. And so basically what you have is you have this kind of promotion

mechanism where basically as a user we have this op code and uh effectively normally your UAS slots will just live in random positions in the tree. But what you can do is um at any time hopefully even before you get those coins you can like write call this op code and the op code kind of promotes the location where it gets stored to the in the header and uh then when or and it also kind of demotes the old the old thing and and moves it down right and then you add these op codes kind of US store and US load that basically read or write the storage in the right location right so US load would basically we first check in the header and then if

there if the key isn't uh one of these privileged values then it would read in the global state but if it is then like it just reads the header and it stops there and then one thing is in this EIP I have this mechanism where basically you use like address mod 16 uh to choose which position in the header and so that means you only actually have to read one position there's like a couple of different ways of how to implement this there's like small trade-offs but basically it means like you have to do only uh only one read of one chunk. Um, and uh that's like basically the whole thing, right? And so the way that this would get used is again basically imagine that like this account is like for you know

your account and uh the contract that's creating the UAS is uh some thing could be an NFT could be an ERC20 token like let's say it's your sheibbaenu balance and then what you would do as a as a proud shebaenu holder is basically you know you would uh you would call set privileged user storage once and then that would set one of these keys to be the Shibainu address and then when you receive Shibainu coins the what the US store would do is it would first look at that position it would check for the key matches and it would just save them in the header and then when you do a get balance you would just read them from the header and so basically yeah if you're any kind of user who only touches

a few coins then like almost always you would uh like basically just be doing everything entirely from your header and then like you would you would also have to touch the code of the sheiba contract but uh like those are the uh only two things you would ever you would ever actually have to touch. Um so that's uh yeah and again like from an expiry standpoint it's basically really nice because effectively yeah at least for that like subset of users which I think is large and which I think with like proper privacy practices will only get larger like you only have a few coins and so like this entire thing could just be expired together and then revised

together. So yeah that's it. >> Um thanks. Is there any question? I have a few questions but maybe uh the audience does too. >> Uh yeah I have a question. So um let's take this like chart here with header values and storage slot. So let's say we are dealing with ERC20 like Shiba Enu. So the user would itself like the the owner of the the the token balance that I have sheiba I would myself call set privilege user storage on the sheiba enu token allowing it to write on my own local storage

effectively treating like this balance on equal grounds with a normal ether balance right so it's a way of promoting that up to my own account storage but Then this lives under I guess I'm confused is what lives on the Sheba enu contract that like purple part and what lives on the my own uh >> okay so everything in this diagram lives under your own header so if once you've promoted the address then the only thing that lives in the sheibainu contract with respects to you is basically the sheiba uh the sheiba contracts code >> we'll get Fair enough. And all storage

lives under. So anytime when I want to call my Shibu Sheiba Enu uh token balance would I call I would still call the balance of uh >> yeah. So technically uh the way I designed the uh US load op code over here is that it uh actually has a flag uh is user and so you can access you can read your local storage either from your own account or from the Sheibbao contract >> and would that require smart contract changes on behalf of the Shebao token to so that there's a like initial initially it would use store uh if available

otherwise it would fall back to its own contract storage. Right. >> Right. So this would require token contracts to change and to start using US store. Fortunately it does not require any changes to the ERC20 standard. >> Yeah. Good. Cool. That clears up my question. Thanks. >> Yeah. So technically we don't actually need to use binary try, right? We can also apply it to the current MPT. So I mean we do have to wait for binary. >> Yeah, that is uh that is true. Um though the I guess the one thing is that that would require kind of opening Pandora's box on like changing the number of objects in the header. And you know I've

I've been told that this is non-trivial. >> Yeah. And there's also the question how you handle the transition. I mean, I'm sure it's just about writing the tree, but yeah, it's it's one extra thing you need to translate. I mean, >> yeah, I mean, technically, you don't need like any kind of full sweep because it's like empty by default, but uh yeah, like you do need to suddenly give clients the capability to treat the header object as something that has like the 36 fields instead of four.

>> Yeah. Yeah. But what I was more thinking of, you know, you've got your promotions and your demotions. [clears throat] >> Uh, if one of them is in the has been converted to the new tree, but the other is still in the old tree. I mean, >> I'm sure it's doable. It's just I don't really want to be thinking about this. That's my >> Right. Right. Yeah. Yeah, that's fair. >> Um, any other question? Um uh would you say that the main benefit of this is just having an easier pathway toward state expiry or is it just gas reduction like what do you see as the main benefit?

>> Um I think for me both are interesting. I think uh like in a world where we adopt so like stronger forms of state expiry I think the state expiry friendliness becomes more meaningful. Um but uh like in in worlds where it's uh I mean even in worlds where we adopt kind of things that are closer to the leaf based state expiry ideas that you know and the others have been uh supporting then like effectively the user's header becomes one leaf and so that like it also becomes very convenient um in in worlds where we do something more non-invasive than uh or or nothing then it matters less and the gas cost reduction starts mattering Sorry.

>> Okay. Thanks. That's all for me. >> Um, okay. So, okay. Yeah, I have two questions. Uh, one of them I don't at least if you answered, I didn't see it. Why don't we put uh like, you know, compared to the regular the base design where we had 128 code chunks. Um why don't we move why don't we put this the the US the privilege US zone why don't we put that uh you know in the reserved uh position like you have zero to 60 I see you have 62 slots that are currently reserved >> um >> I think we can I think that's a totally valid choice for us to make

>> okay and the second question is uh when do you see this being shipped uh you know like we have this road map which most people in this room haven't heard of. >> Uh but where uh when would this happen like uh with the binary tree potentially before u or you know with state which >> right right I mean I think intuitively yeah like I mean with the binary tree is very uh natural. I think like the big challenge with doing it before is that you basically have to come up with write the code for both the before version and the after version and even the transition and then figure out pre-im images to the transition and like it's more code. Um doing it with uh I mean doing it after a state expiry I don't

think makes sense because like I think if you're going to make any IP that uh like makes it harder to do things with old state like like I feel it's only right to give users access to a mitigation. Um and so basically yeah like some somewhere in between uh those two. I mean for me it's like anything anything is fine. I think the nice thing about the binary tree design is that there's this kind of get tree key mechanism that actually makes it easy to just like throw in new kinds of storage to represent pretty much everything and it just all like lives in one blob, >> right? So yeah, potentially we could have it right off the bat.

Mhm. >> Yeah. The bite resization. >> Okay. >> Um, one one detail I'm not I'm a bit fuzzy on. So, there's a maximum of 256 uh UA UAS slots. >> Uh, here are 16 privilege. Yes. But >> privilege. Oh, no. In total, yeah. So, 256 per account. So, effectively, yeah. I mean theoretically like actually yeah it's probably yeah you know like this basically means that like a contract can have 256 of these user mappings >> and like it theoretically like if you had like if you want more than 256 you just work around it by making child contracts.

>> Yeah the I mean theoretically of course uh like with regular storage you can just do whatever you want with mappings. The challenge here is like the protocol needs to be aware of the fact that the storage creator is a particular contract and then the storage key is uh a user. >> Mhm. >> So when okay uh if we don't use any of those things >> uh like the default behavior is we we fill all the slots. >> Um then uh what happens like it's it's a failure. a revert like we see once it's filled. It's filled and that's it. Uh basically yeah what happens is that like well the only way these these 16 get

Token Slot Management: Discussing user choices for token slots

filled is if a user calls promote right and right and so if uh let's say for example like I get sheibba coin and then shecoin is assigned to like slot 14 because that's what the address 16 is and then let's say sheibba goes to zero and I yeah like stop [snorts] caring about it and then some other token um like I don't even know like I don't know mudencoin comes up and like it turns out that mud endpoint is also 1416. Then in this design I as a user basically have to make a choice and I have to like either privilege one or privilege the other and then the one I don't privilege is going to cost more gas and it's going to be more annoying to revive, >> right? Uh but you know if Muden you call

it? >> Yeah. >> Uh if muden and uh and she are also the same uh the same value module 256 >> right? Oh, I see. This is uh in the version where like we do like kaku hashing basically. Right. >> Right. Yeah. >> Right. Okay. Then if then again like you you would also be forced to like d-privilege one of them >> and Okay. So you d privilege one of them. >> And in that but you know it's not like one overrides the other. >> Yeah. No. Okay. Basically Yeah. Yeah. Basically when you d privilege all that means is like the the place where the storage lives just kind of goes back into its uh like regular location and then when you do a read like you would basically you know read the header and

then it would see oh this this key is not representing mudang now it's representing sheiba and then you know you would fall back. >> Okay. Yeah understood. >> Okay cool. Carlos, >> sorry I replied. So maybe maybe this was already said, but uh is this like first come first serve uh for transactions that I receive or does the user actually need to do something to actually allow these token coins to get the privileges? >> Yeah. So the user has to call this set privileged op code. And the reason why we have to do this is because otherwise like spam tokens could privilege themselves. It would be annoying. Um, and uh I'm basically arguing that like we'll have account

State Expiry: New method for state expiry without account loss

abstraction by then. Like even with 7702, it's just like it's easy to just uh throw the privilege into like whatever like call that's inside any transaction you make. >> Yeah, that makes sense. Okay. So, that might sound quite familiar to the people who are aware of oopsie. Uh but it's it's ma this I assume mainly makes significantly easier to anyone to store their account data plus their token balances on a way in which they don't constantly need to fetch contract uh updates to see if their balance changed.

Is that correct? >> Yes. >> Okay. So we finally have a way to do a state expiry but without the burden of killing accounts which are really hard to recover for balances of tokens which are not pure. Okay, that's nice. Thank you. >> All right. Any other questions? All right then. Thanks a lot, Vitalik for presenting. Is there Oh, it seems

Han and Carlos both have their hand raised. >> Okay, >> Carlos, you want to go first? >> No, no, sorry. It was a le over from previously. >> Okay. All right. Go for it. H. I think I'm just thinking all up here because this I mean this this feature is nice but um definitely has a restriction of having limited number of u like user associated storage. So this might sound like a stupid idea, but is it possible for um for like contract um like contract by code to to be redesigned in such a way that if there's a mapping between an address to some arbitrary value, we would store it in the uh in the storage space of accounts rather

than the storage space of the contract itself. So, so that means we'll be expanding on this UAS to not just 56 but more than that. >> Yeah. I mean effectively this is doing that right like this is creating like basically yeah like locations in the like locations in the tree that are uh like I guess they're not like there the binary is uniform and so like storage is not like live under a user's account but it's uh like I mean it's it's effectively yeah in an index that's that's balanced to the user.

Why not then just use the existing storage slots for the account that are unused for EOS? >> Um yeah, I mean you could I don't like existing storage slots. I mean it ends up not being different. I think uh like that would just create more like logic for like it would create more awkwardness for differently supporting EOAs and smart contract wallets and like basically yeah the the thing the thing that you would end up saying is like oh you'd have to like come up with a different hash prefix to deal main separation between this kind of user storage and the other kind of user storage and like effectively that's exactly the same as this.

>> Yeah. Yeah. That's fair. And within that clash with potential 7702 slots, >> right? Um, right. I mean, if you like directly use storage, it would if you Yeah, if you do it, it doesn't. >> All right. Any any other question or comment? >> All right. Thanks a lot for taking the time uh Vitali. So I mean you're free to to to stay here but we'll proceed with the next element on our agenda which is uh team updates.

>> So whoever wants to go first feel free to get started. >> Hi Ken. Uh so this last week and this week I've been mostly focused on two tasks. The first one is trying to unblock ACD uh by getting uh benchmarks on 7907. I've built I've built a ton of stuff uh but the issue is that I was getting cached results from G. So I spent quite some time with Gary discussing how to approach this uh and now I basically nuked uh my my mainet DB to actually use it with G in development mode and be actually to be able to take all of these benchmarks. The bloating of the setup is almost done. So I think by tomorrow I

should have all of the results and the plan is to publish it on it research and if needed present present it very shortly on ACD uh this week. The other part is I've been working uh with another guy from the uh EPFL I think it's called something like that uh on basically the the second posts on the feature of the state that I did uh specifically on a formalization on how the uh partial statefulness will work when you look at the tree. So uh we're trying to integrate it within valves uh computing the worst cases for balls which would be uh EOA transfers uh from non-MPT to non-MPT accounts where this

is the way in which you can actually get the least amount of storage written and the biggest amount of bytes um put or dumped uh into the block access list. But so far it doesn't look it doesn't look bad at all. So we are finalizing the the specs and everything and the idea is to push another post and then if I get some green light or people sees uh interest on on being able to run these partial stateful nodes the next thing should be probably coding uh something a prototype uh that actually basically is able to run provides RPC responses especially if get proof which is what I'm the most interested on and on the top of that is only storing a very

Prototype for Partial Stateful Nodes

minimal amount of storage something likely like VOPS requires. So we could kill uh two birds in one shot by actually having the VOPS functionality to maintain the meool and at the same time having the partial statefulness uh functionality also. Uh so yeah this this has been mainly my my last week and a half. >> Thanks Carus. I can give a quick update but uh just want to share um a few things on what we have done with the if team. So I'll just quickly share my screen.

Yeah. Uh okay. So basically I would like to introduce this page in u if pendops um the lab page. So basically you can um everyone can see the state growth um visual visualization here. So um I mean this this data is recorded from a gaff node. So definitely if you compare it with your um E not node is definitely uh different but at least they can sort of see like the trend of state growth over time. So yeah that's that's one page on state growth and then there's also another page on stay expiry where uh we are exploring like what happens if we do different expiry policy. For example, this one is at one year like we only keep um state active state for one year and this is two years. then how many uh

how many storage slots will be deleted or reduced and same goes to like contracts and later on we also have accounts. So yeah, there's a few things that you can explore and also there's also the top 100 contracts by storage size which the first one is definitely Zen that's that's pretty obvious but yeah um so yeah just want to quickly share on this and um we still validating the um accuracy of the data I think for state growth is it should be fine uh contract codes is slightly inaccurate by very little like uh this should be like 208 eight something something but um but yeah for Squar I think we are we are trying to valid validate the data and

same goes with the contract but you guys can take a look and give us some feedback on what you would like to see next. So that's all. Yeah, >> great. Thanks. Uh Han, I noticed at the end of the graph there's a small spike. Uh is that intentional? I'm just looking it up locally and I see that the data stops at like September 22nd and then it jumps in in January. Like >> uh yeah. Um yeah, that's that's the back end refactoring part because we were we there there was some uh issues with the back codes data. So uh the ependox in trying to um rerun the the back end thing and um I think by the end of this week we should have the accurate data

but yeah it's mostly >> okay. So it's just a data issue. Cool. >> Thanks. Thanks H. Anyone else or team updates? >> Um I guess I can talk uh yeah about what I did since uh the last call which was a long time ago. Uh there's been 2926 right which was the FI. Um but nonetheless uh I've been talking to a few teams about this and uh yeah the next challenge is to address 20 sorry seven is it 797 uh and try to not get not getting scheduled uh and instead just replace it

with a with a proper um just just a code size increase. Um so yeah to be continued during an XACD. Uh otherwise there were some roadmap discussions that still are road map discussions in Berlin. So I'll have a quick update about this. Uh and uh yeah basically binary trees are back in full force. I was discussing um the topic with Karim who's not here today because he's on holiday. Um but we're going to to make a push for that.

Uh and it will become more apparwide. Um but yeah, that's the general that's the update. Yeah, Carlos, I just wanted to point out that independently of whether 7907 happens. Uh notice that there's going to need to be some EIP if we decide to go with the code size limit increase. uh because with the Fusaka transaction gas limit uh it's actually impossible to deploy any contract that is bigger than I think it's 80 kilobytes. So 128 and 256 are completely out of the page. In fact, I wasn't even able to benchmark them. I've been only being able to benchmark up until 64. Um I could hack even more, but at this point it's getting uh tricky. So

yeah, just point it out. Um okay I'm not sure I understood actually. So you're you're saying okay I understand you can actually deploy 80 kilob 79 >> even even if 7907 doesn't make it >> if we want the code size limit increase we will need to have an EIP no matter what because we need to actually allow contracts bigger than 80 kilobytes to be deployed and the only way to do that is if we add something into the protocol that says we can jump over the transaction gas limit >> only if we are deploying I mean something along ong these lines.

>> And and this this logic needs an EIP. So, >> but >> even if it's not 7907, we will need to do another EIP that basically says that. >> But if we bump the size to 64 kilobytes, we will not have this problem. >> Oh, yeah. But I mean I I was assuming that people is pushing to 256 for for some reason, not just choosing a random number, but >> there's like a two a two-dimensional chart here, right? Because I think uh there's also the goal in glam of bumping up the gas cost of creating new state and so effectively like the idea this year would be that like we'd increase the amount of execution gas by 10x but we would increase the amount of the state creation rate by like only 3x um

hopefully I mean or maybe if people end up being conservative even a bit less and uh the math was basically like if you uh increase the new creation cost by 3x That means 600 gas per bite. And uh at 600 gas per bite, every 10,000 bytes is 6 million. And so with the current stats, you'd only be able to get up to like basically about about 27,000 gas. So effectively no increase at all. And so the uh the realistic options on the table are like some combination of um you know one accept that and give up on doing contract code increases in glam but you know maybe do them in H star.

Two is uh temporarily bump up the per transaction gas cap. So like for example if you do a bump up to 32 then you would be able to bump up the like you would need to bump up the per transaction gas cap to 20 million and so it's like a modest on both sides you know and then uh and then the third option is like yeah basically yeah figure out some kind of multi-dimensional limiting and that's like hard because it's sort of invasive in the EVM. It's not like a clean thing like call data because uh even for creation transactions the code that gets created is ultimately generated inside the EVM like it's not just like a a raw

field of of call data and so like that stuff is doable and like there's a lot of mood to go toward multi-dimensional gas but like intuitively to me it doesn't feel like a glam thing. >> Okay, that's fair. Yeah, that's fair point. >> [clears throat] >> You want to continue with your update or are you done? >> Um, yeah, I'm done. >> All right. [clears throat] Thanks. Anyone else? Maybe someone for from testing.

Benchmark Test Approaches: Discussing pre-compute vs. introspection

I think uh Carlos already reviewed uh that one but I think another look would not hurt. I think the main discussion point let me share first link just quickly. Um um this one [clears throat] just one second. This one uh I I got a review from Carlos. So this is basically based on a PR that he prepared already. I think the main question here is um how do we approach benchmark tests. Um there are two approaches at the moment.

Basically the uh gas introspection one where you decide when to stop benchmarking this the state codes or whether we premp compute how many iterations the um the test uh does in in in one transaction. Um I really like to uh preomp compute everything so we have like a more certain approach and if anything changes in the future for example if we repric something uh that would will definitely not break tests whereas if we change the prices and for some reason something doesn't work anymore we will not catch this if we are relying on on the transaction uh to do all the work by itself and stop

wherever whenever it wants. Um but yeah, I think um um I don't I don't think I'm missing anything from you, Carlos. Uh do you have any comments on on this um on this PR? >> Uh not on the PR in particular, but on the gas introspection. Uh Yim gave the idea which is actually do uh e estimate gas calls and maybe with that we can kind of sort it out one way or another. The only problem is that these don't take into account previous transactions within the same block. So if I do something in transaction one and then in transaction B I touch state that was touched in transaction one the gas uh

estimation of the second one will actually not work. So we will need something like if uh I don't know estimate block gas or know something like that so that we can send an entire block and see how much gas the entire block takes um to be to be processed basically if we can have that then I'm positive we can fix this uh quite easily. So my my thoughts on this is that uh this already computes the gas. Um so we already put the effort on trying to premp compute the gas uh which which we want to use for this transaction. So I'm hesitant to roll that back because we already did the work. And also I have another PR uh that is very recent and

the idea of this other PR is that we automate the gas uh calculations for all the tests basically. Um and this will make it extremely easy for us to premp compute the gas during the test test execution. Um I would like to show that tomorrow on the on the gas uh benchmarking call and if if there's no hurry to to mesh this today I would wait for tomorrow to for me to present that PR and I think I can uh [laughter] get you guys on board with this change. Um but yeah I think the the only question I have is is this important to to get it merged today or can we wait until tomorrow? I think that's my last question.

>> At least for the depth and Xcode size benchmarks, this is not an issue at all. Uh they are already working and in fact I have been using them locally uh to get the 7 uh 907 uh benchmark results. So I'm I'm fine on my side. >> All right. Thanks. So yeah, let's wait until tomorrow. I'll share a little bit on the other PR and I and we can discuss that there. Yep, that's it. Thank you. >> Perfect. >> Thank you. Just one question for one question for Mario. Uh, regarding the binary tree, uh, could we I mean, what would be the best way to at least start figuring out how to integrate and move everything that we have in our execution spec tests

Binary Tree Integration: Planning and prioritization steps

branch to the execution specs uh, normal one? um should we have a call or like what's the best way to to do this because we discussed about that but nothing was done and if a lot of things depend on binary tree maybe we should start prioritizing that a bit more >> I'm not sure about the status on that one um I mean we we can set up a call if that's that's what you guys need that that's fine yeah >> okay I'll I'll DM then send you >> um if there's a call I'd like to be part a bit and also uh we should wait for Karim to be back because he's going to be interested in that. He's also working

on the topic. >> Yeah, if we can delay because this week I'm going to prioritize Amsterdam EIP if we can delay and it makes it better for attendance. I think that's what we should do. Yeah. >> Okay, perfect. Thanks. >> Thank you. I think someone else had their uh hand raised. Maybe Damian, I can recall who that was. >> Yes, that was me. Hello everyone. Um, I just uh had an organizational update. So, as you know, Danish left nether mind. So, I'm kind of stepping up and I'll try to keep my keep my hands on the on the updates and um and bring ourselves up to speed with the with the

binary design. Uh yeah, that's just it. That's all I wanted to say. Thank you. Right. Welcome along Damian and thanks for taking over the tenish work. Um, anyone else for team updates? Good. Uh, the agenda is quite packed. We won't have time to go through all of it, but I'll just go u sequentially. if most of them are from Yugium. So if you feel like some of them could be postponed to in two weeks, you can just say so and we can skip it and move along.

>> So the >> Yeah, you want >> Okay. I just wanted to say I was going to make a quick TLDDR on the road map, but the road map is still being worked on. Uh so I would rather like to skip this one. >> Sure. Um then there was another one uh basically okay I would like to prioritize the one about using a uh a smart contract to to perform the transition the system contract and time permitting do a bit more uh but yeah I would say that's the most interesting one for for the time being

>> sure so let's start with the proposal to use a system contract to store conversion pointers that's the one Yeah, >> you want to take it along? >> Okay. I I called the I changed the I changed the name while uh while I was making the presentation, but yeah, the idea is that uh currently um we have to keep uh when we do the the tree transition, right? We go over every single account in the tree. For each account, we uh enumerate the the storage. In fact, we enumerate the storage before we even take care of the account. So, we need three things. Uh we need the the last account hash, the last storage hash that was processed and just

a flag to say uh that was the end of the of the storage processing. uh and the reason for this is because if the the cut off uh happens between the storage h the the storage enumeration and the account we need to differentiate the fact that we haven't started uh enumerating the storage from the from the situation where we uh we have enumerated the storage but it got interrupted and the next thing we need to do when resuming for the process for the next block is to just process the account. So you need three things.

Um and excuse me. Um this approach has a few advantages. It also has some uh some drawbacks. [clears throat] Namely that currently those uh sorry it's not the approach itself but currently we store that uh that in the DB like in everything I implemented and presumably tenish and uh and Karim implemented as well. it's stored as uh something that's not in consensus. Um and uh and so it needs to be loaded from the DB. It needs to be stored uh stored at the end of the block processing. The advantage of of this is that uh you can first compute the root hash and then um store the store the the

transition pointers. you can start doing the the transition uh for the next block before. Um basically because it's non consensus you can do that whenever you want and however you want. Um the problem is that you need to write some custom reorg logic if something happens and uh this was notoriously difficult that broke many shadow forks. Um so we were not uh like I wasn't very happy with this but there was uh no better proposal until this one which is uh what wean proposed for 2926 um it's to save the pointers in a smart contract and initially I thought that's a good idea for 2926 for AT32

um but you can't really do this uh because uh you can't really do this for a binary tree transition uh because you need to know the root beforehand. Um and uh yeah, at least the those pointers were until now in the database were indexed by the root. Uh so this is still true but I don't think it's as much as a problem as I used to think uh in the sense that uh it just enforces that the transition for one block is really performed before uh the state root calculation is uh but once you have this uh this context that that means it forces you to

do the transition before processing the rest of the block. Uh but that can be done. You don't you can't really do do it after. Um but that's uh honestly that's not changing much. Like the more I think about it, the more I realize it's not changing anything. Uh the the biggest advantage is that because it's stored in the state, it's visible in consensus. And so the real logic is that of you know just rolling back the block, rolling back the state. And this is uh this is quite easy to do. Um it's also the question of snaps sync uh because before how would you download the the pointers during a snap you know if your step sync happens during the

conversion uh it's not really clear how you how you would do this here it's just about sharing the state so that that solves that problem too um and I think for eels it's go also going to to solve the problem uh because until now well we never really completed the the transition test in Eel, but they would have they would have had to be passed out of band like we you need to create some spec some custom logic to to handle that. Uh with this approach not anymore just do the the hold state state export state import um and you get the you get the pointers as is um yeah I think that's pretty much everything. So one

thing that's not in the slide but uh you know the people who attend this uh this call often know is know it's one of my pet peeves. Um we would have to go read the state um the state uh directly from the contract. So no do not do any EVM execution. But anyway, I don't really know what an EVM contract would look like. Uh, I mean, I guess you could just call a contract uh, sorry, EVM contract every time you you update the the like you you process a block, but that would be extremely inefficient.

So, I think it forces that model where uh, you just go and directly read the state the contract state, excuse me, without having to uh to update to to call any contract that to call the EVM. Um, I don't think that's a problem. I mean, never was a problem for me. I don't know if there are any is if there's any decent uh for for this uh for this fact. Uh but uh but I think yeah, it's um it's an acceptable uh requirement.

Um, so yeah, all I need really is to collect feedback from from the teams, uh, namely Nethermind and BU. Um, we could do a quick implementation. I did code something for AT32 over the over the holidays. Excuse me. Um, I guess I could extract this and and finish the the prototype and then we would want to do a shadow fork. But yeah, once again, Karim is not here. this today. So, we'll have to see with him. Um, that's pretty much it. Is there any feedback?

>> Anyone? Yeah, has a comment from Y. Thanks for presenting. Do you have a link to that uh presentation or that that write up somewhere? >> Oh, I'm sure. We could uh I could share that here. >> Okay. Anyone uh would like to comment? I saw a mic uh unmute. Maybe someone wanted to to to share something.

All right. Fair. Fair enough. Let's continue then and give feedback to Guiam. I think the Giam did you want to proceed with the next element on the agenda that you had otherwise we can also give the mic to I think Han that wanted to discuss a drafty IP called temporaries contract storage. >> Yeah let's let's uh let's give the mic to to Han. >> All right. Thanks. >> Thank you. I'll be quick. So let me just share screen.

Temporary Contract Storage Proposal

All right. So, uh I just want to quickly discuss on uh draft EIP right I mean very early stage EIP called uh temporary contracts launch. So um the primary motivation is to disincentivize state blue and also it's also inspired by some of our previous aspir and um I guess this ideas uh was also discussed um many months be uh ago when we first did this the analysis. So yeah I just want to briefly go through this uh the general overview of this idea and also get some early feedbacks. So um a quick recap of on the type of storage um so you have the memory um that is scope uh per core frame and then you have the transient

storage which is scope per transaction uh and then you have um the contract storage which is what we are very familiar with which persists forever or at least until a state scheme is live uh in protocol. Then you you also have blobs which uh uh persist up to around 18 days. Uh but the thing about blocks is that EBM cannot uh access it or it cannot read or write to it. So it's not very useful from the EBM perspective. Um so the general um well um idea is to is to ask this question that says that whether we can have a storage that lasts for end blocks. Right? Then uh we move on to the analysis that we did few

months ago. So um few months back uh we found out that actually most of the contract storage u more than 60% of the uh total contract storage um were used only in the single block. So that means they um I mean can spend um um many transactions but they were only used in a single block and never access it at least onchain ever again. So well uh since we have this data point then the question comes like since most storage slots are ephemeral what if we provide a temporary storage space. So that's the motivation. Um the general idea of how it works is that um again there are many variants but this is just one of the

variant. So this variant um uses a system contract where which basically we will be storing um every contracts temporary storage in the system contracts storage right so that sounds uh like a mouthful and then we will also be introducing two new op codes um so it's it's similar the general semantic is similar to um as SS store and also uh s load uh so here I call it tmp store temporary store or temporary load um so the difference is that you are not storing in uh you are basically storing this this key value pairs in the system contract the specified system contract storage and and because we are storing for all of the contract um address so

Temporary Storage and Protocol Clearing

that means that there needs to be a um key derivation uh formula uh here I just it's just a simple address and appended with the slot key and then hash it um so when you insert into the storage try you will rehash it again like uh every other storage tries So yeah that's the that's basically g of it and the general guest semantics are uh at least for now is similar to slo and sto. So the most important part is the clearing. So um on a protocol level uh we we will say that for example every 6 months worth of blocks we will be resetting the storage try of the system contract. So originally we will have this uh storage tries full of um contract storage or

temporary contract storage then we will reset to empty hash and begin from there again. So every n blocks um so uh but um that's that's on a protocol level. On the Y clients level most likely Y clients will have to persist the this temporary storage for longer than this uh protocol parameter because they have to deal with YS and um maybe also have to deal with like RPC queries and so on. So yeah that's the implementation implementation detail. on a protocol level when you are trying to for example read a value from this temporary storage if it resets then it starts from zero.

So yeah that's basically the gist of it. So uh in regards to the pros and cons so the pros is that first of all is it wants to decentivize state blo um it tries to reduce the size of permanent contract storage. It does not solve the state bloat that I mean state growth. I mean it does not reduce the state size that we have but um it attempts to modify the user behavior such that uh if most contracts use this um feature then we effectively uh um slows down state bloat and then um definitely the incentive to use this over the permanent storage is that this um storage will have um a cheaper gas model because if

it's the same then nobody wants to use it and um in general it's pretty clear and predictable because uh we are um expiring or deleting the temporary storage um for all of the contracts uh every n blocks and not just per and it's not per uh address basis. Um I think on the implementation level uh I think it's quite pruning friendly because only have to target one specific account so not all of the accounts. So um in regards to the disadvantages um so the prioritization is quite tricky because uh how should we decide the uh how long should we keep this temporary storage is

it one day is it 10 days 6 months one year right we um we have to uh find find out what this number should be and we will also be adding complexity to your clients because you have to handle this new class of state differently and efficiently because potentially you will have to um create a new database or uh I mean separate files to store this so that you can delete them in one go but um there are also other details like you have to store in the history and so on and so forth. So I think this part would be most of the work and um again you have to deal with Vox and RPCs um this is also E um complexity and in regards

to unified tree or binary binary track uh I think this idea at least given uh given this variant is quite tricky because we are storing the storage in in uh in in the same tree. So that means um pruning becomes very tricky. So we have to handle it differently or it may not work at all. So it's something that we have to explore uh in the unified tree format. Um so next steps just a quick one uh want to validate um if this feature is actually useful for applications because if we thought then there's no point moving forward with this and also to figure out a suitable time window to store the library storage and uh also to figure out the right gas model. So yeah [snorts] it's still at

very early stage. So yeah, uh happy to have any feedbacks. >> Cool. Thanks a lot, Han, for presenting. Uh I have a few questions on that, but since we're out of time, I'll just leave them for I think. Is there a document where we can uh share feedback or questions that you could share? >> Uh I have the slide for now, so I'll just share it in the chat. Yeah, >> sure. Guom, you raise your hand. Yeah. Um I had a couple of questions. I mean I guess so I mean I guess first like a comment right which is like for binary tree like if it's like the the fallback option you always have is to

Feedback and Future Steps

just like have multiple trees, right? >> Um I guess the the other thing is uh I I think for any design like this you probably want to have two trees, right? And like basically like uh clear them at alternating intervals, right? So that that way you can guarantee that even if you make us the storage like five blocks before a transition, it'll still live for 10 days or whatever, >> right? and then uh for um and then in terms of duration like one natural kind of showing point is like the seven day level or like a bit longer than that basically because uh that's the duration that like things like optimistic rollups

are like like basically that's the duration that the ecosystem already has some norms around assuming that people are able to go on chain at least once that often. So that's like one place to start. Um I guess my question is like when you looked at these uh situations where 60% of uh like user storage slots or whatever the number was were accessed in the same block like do you have any idea like what kinds of applications that came from and like to what extent that's like predictably storage that lives for one slot versus like you don't know if it lives for one slot or two years. Yeah, actually that's a question that uh we have to figure out. Um because um presumably most of the contract storage is like a mapping of

like the balances. So if this are all the balances then uh not sure if the temporary storage will work but if it's something else then this feature will be quite interesting. So yeah we have to figure it out. [clears throat] >> Yeah, makes sense. Um I think with well with balances there's always the idea that people will will use it and then if some of your coins expire you bring them back with with a stark. the yeah like the intuitively right the use case of this sort of thing is that like you use it to store information about events. So like Dow votes or like fraud proof instances or um auctions or

like anything that happens but like it will be yeah like I would be really interested to know like what the actual percent of storage is that is those kinds of things. >> Okay. Yeah that will be next. Yeah. >> Good. Thanks. The we'll wrap it up. We're slightly over time, but thanks everyone for joining. This was tapeless implementers call numbers number 46. Uh I'll be sharing a summary of this call and we'll be tweeting uh a Twitter thread about the the the lines of the the call. So,

thanks again for joining and see you in two weeks for number 47. Thank you. Thanks.