Stateless Implementers Call #42

Transcript

Loading developers...

All right. Um, yeah, I was hoping for people from testing to to join because we we have a few things on the agenda, but yeah, we'll see. We'll see if they show up uh later on. Um, so this is uh stateless implementers call number 42 and I am copying the agenda right there in the chat. Um, and uh, yeah, I guess we can start with status updates. Um, does anybody want to start? >> I can stop.

Stateless Implementers Call Intro

>> You hear me? >> Yeah. Yeah. Please go ahead. >> Yeah. Okay. So, uh, I published a docker image with a binary tree in Bezu. So, I did all of the modification normally for the next devet. So I shared the new docker image to to Yugi so we can try to start the new devet with this image as soon as we can. I was also still trying on the transition. So I I had some issues performance issues uh with my first implementation.

So because I wanted to have a proof of concept with a quick implementation, the performance was really bad. Uh because I was using an RPC call for each pre-image during the transition and it was too many uh too many RPC call uh even if I'm doing the generation of the data before the block, it was still uh too slow and I had a lot of uh thread blocked etc. So I decided to modify my implementation in order to have a first step before the transition. So downloading all of the pre-image and save and save all of this preage in the database and when this pre-shage downloading step is finished

starting the real transition. So today I'm testing this pre-shage downloading step. Uh I have a first implementation. It seems that it's work but I'm waiting for the end of the process to be completely sure. When I will be sure that this step is working correctly, I will start the transition thanks to the new uh um preage in the database and uh we will see. So yeah, still still doing some test. I think the main part of the code is here.

It's not perfect but uh I think we could have some good result with the last implementation I did. So I had to test but I will be more confident with this implementation than the one I had before. So yeah mainly mainly working on that for the moment. Okay. Uh thank you. I guess I'll go next. So um I mean we've been uh working on bloet uh on state um state like analysis of the state. So uh I mean the concerned people will will give more

details about this. Um and there's also been some ground work to get binary trees to work in G. Um yeah that's the that's the general overview. Um I haven't touched 4762. There was a a PR about updating 46762 which um I got some feed uh some feedback on but not much. Um I will uh I will need to take some time to apply the feedback. Um but honestly at this point I think it's also a good idea to rethink uh 4762. So I need to to have a conversation with that with the initial authors of 4762

and hopefully uh simplify this a lot. Um, yeah, that's pretty much it for me. Uh, from my side, uh, I've been working on, uh, blob net syncing, uh, specifically trying to fix the issues with ref for which we added the required blocks flag, but uh, still we have peering issues that we need to fix. uh as also it seems that the PR for the multi-op code uh benchmarking is finally ready and accepted. So once we merge

this one like the rest of the PRs regarding bloet benchmark should be significantly easier to bench uh sorry to to bring to to main. Uh and finally, aside from this work, I've also rescued an old uh PR from uh Guom and Ignasio. Uh which basically in which basically I replaced uh the binary tree for the ver tree. Uh now my next step is to run the field uh the filling uh within east and produce uh all of the artifacts and then run it against uh my branch itself. If

that works, that should theoretically mean that we can already uh share these tests with Karim and from there we can figure out what things work, what doesn't work and we need to to fix and and this kind of stuff. So yeah, uh I hope I have it uh this week. I mean it depends on how many errors I find but ideally I should have it this week and Karim I will bring you uh once everything is done so that uh we can start taking a look to the specific tests. Any other updates?

If not, we'll uh move on to the next uh step in the agenda, which is uh Han's presentation about uh his his article. Um so, yeah. >> Yeah, you have the floor. >> All right. Uh let me quickly share my screen. Um right. So um basically what we have been working on for the past few weeks is to we want to we wanted to um like learn more about um the state access patterns on Ethereum. So um in your mainet to be more specific. So we did a bunch of analysis and this is the first round of

results that we get and um there were a few um interesting findings that we get but I think overall it's still like we are we we're still scratching the surface and there will still be more work to be done in the um in the near future. So but yeah um I'm just going to give like an overview on on the results that we get. I think um for like for most of the client teams um uh um maybe this this wouldn't be like um uh like a huge thing for you guys but yeah there there could be some things that you you guys can utilize to perhaps like um uh improve performance or do some caching on on your site. So yeah, I think it's it's still good to know about all this

um data that we have. So all right um I'll just start right away. So um the first thing that we wanted to know is that um uh EOAS versus contracts and which which one actually lasts longer. So the main metric that we use is something called activity span or you can think of it as lifespan or is it is basically defined as the block distance from the first to last access um of a particular state which is account or storage slot. So access here means um onchain read and onchain rights. So as a store and uh as load for storage slot or for the rest accounts then that would be uh balance nons um yeah and and code.

Yeah. So um so one example is um so if the account activity span is zero it means that um a state or let's say an account was seen in seen first scene and last seen in the same block right so we actually see a lot of these accounts and storage slots um um in in the next few slides. So um looking at the first graph um we are looking at the accounts. So um the first result that we get is um I mean the conclusion is that UAS definitely lasts longer than contracts. As you can see that actually 55% of the contracts operate for only a single block. So that's interesting.

And um if you look at the overall accounts most accounts operate for only under a year. Um so about like 80% and maybe like um the rest of the 20% they operate like more than one year and with very little operate more than for example 5 years or or even six year. I mean if you look at like over eight years then that's like less than 1,000 but those are like really legacy accounts and maybe some of like um for example accounts controlled by EF. So those are um you you see some of them here and um the next thing is um the uniqueness of the contracts. So we wanted to analyze the bite code and its relationship with all of the contracts

that we have. So we basically categorize into two categories. Um one what we call as template which is basically bite code deployed by more than one contract and the second one is unique which is basically by code deployed by exactly one contract. So um majority of the bicos are unique. So that's the first thing. Um I think even in your clients I'm not sure if you have something like inspect db tool. If you do like something in uh like db inspect in g then you will see this result as well. We have about like um 1.6 million um like unique code hashes in total about about that number. And if you do the categorization then um about

Analysis of Contract Code Uniqueness

1.45 four five million is unique like truly unique and about 150k is like template all requires template bite codes. So that's the first thing and the second thing is that um um we have like most contracts are deployed using templates right so we we have about 150k um template uh bite codes but those template bite codes are actually used repeatedly by about 48 million or yeah 48.7 million contracts which is like 97% of the total contracts that we have and in terms of the unique contracts is only like 2.9%. So that's a huge deal because it means that um most contracts nowadays just basically just be used as a single

by code. Um and if you look if you compare the activity span between these two categories um the unique contracts actually operate uh like two times I mean yeah um two times longer than the the template contracts. So this um basically suggests that perhaps most of the contracts that we use by codes perhaps they are spams. for example like fishing tokens, right? So that's that could be one example in regards to why is this the case like we have to investigate more with the labels that we have in the future. So um so so that's that and um and then when we look at the concentration and also the distribution

um so on the left side you have the commitative distribution graph. So to to simplify it, so 50% of the contracts I mean sorry yeah 50% of the bite codes um are only used by two wait yeah are only used by two two contracts at most and uh 99% are used by are used by 7 728 um contracts at most. um then you have 1% of of the bike codes are used by like millions of or like basically more than this number and um we also plotted we also wanted to um know the concentration of the contract deployment and the

result that we get is basically um here like the top 100 B codes are used by 82% of the contracts. So yeah, this basically suggests that um there is a few like let's say for for the first top 100 is just getting reused and reused again and again by different contracts. So again um what are those contracts? Um we don't know yet. So um that that's like further analysis. Um then um also quickly want to go through like who deploys the contracts. Um so we also wanted to know the concentration of the deployers. So um uh I think we just focus on the the right right side graph

here. Um so um we do see like a huge concentration as expected. So basically we have a few guys or actually if you look at the top 500 the top 500 deployers account for 57% of all contracts. So there are a few guys who are just deploying contracts over and over again and um for what reason we also don't know yet. Yeah. And uh also quickly look at the uh factory distribution. Yes. Um uh I think we have a question.

>> Yeah. Just uh regarding deployers if the smart contract deploys who would be counted there. smart contract that deployed it or the one that initiated transaction or >> um is this is the I think based on the data set that we have is the is the is the EOA that that initiated the um the transaction. Yeah. >> Okay. because I I imagine that a lot of the duplicate contracts are like a dex pool or something like that that the major because we we observed a lot of the duplicate uh same bite codes being deployed and assume it's just not actually being deployed directly by um external accounts but basically by other

smart contracts just always deploying the same smart contract because of logical indexes or something like that. Yeah, I think I think that that would be something like uh the factory like the so basically smart contract um like they they execute the create create or create to up code. So um um so so that could be one but in regards to again um what are the contracts that are actually like deploying the same thing over and over again we so we we so we already get the labels um the label data set and the next part is just to figure out like what are those um categories of contracts that are just spamming or I mean I mean they might not be spamming

but like basically to understand what what they actually trying to do. Yeah. So we we will get we will know more once we once we do the analysis. Yeah. Okay. Um so um just so to continue um we also wanted to look at the factories um factory distribution and focusing on the concentration side and we found out that uh again the contra the concentration is also very skilled um like the top 100 factories account for over 89% of all contracts which uh basically supports the evidence that we have in the past um in the in the few sites before where um uh like most contracts we use the same

bite code and so on and so forth. So yeah and um next thing is um to look at story slots. So we wanted to um know on the distribution of the story slots by the activity span and the first um very important finding is that 63% of the slots only operate for a single block. So um we have about 1.3 million story slots and 8 and I guess uh 837 million of them are um I don't want to say useless but um we don't know how useful are they because they they were only read and written to in the single block right so yeah why is that the case we

Discussion on Storage Slot Usage and Ideas for Improvement

don't know um so we have to figure out and similar to the accounts most slots operate for also only under a year so this is um this aligns with the the the the result of the accounts as well. So um after getting those data I think we have a few ideas that we wanted to share. They may or may not make sense but it's just like a brainstorming thing that we wanted to share with the community and get some feedback and whether we can turn them into EIPs or whether we can get more interesting ideas based on the data that we have.

So the first idea is not really a new idea. It's basically what we have been um like researching in the past I guess decade which is state expiry. But um I think one thing one outcome that we can get um out of this data for state expiry is that is to determine the the period of expiry. So last time perhaps we we were considering like six months or one year. So based on this data it seems pretty clear that we we should only keep like best one year and that's sufficient at least based on the historical result.

Um so in the past six calls we we I also did like a simple benchmark on GF and um we managed to show that we can save like 80 more than 80% of the storage space in terms of the state size in in GF. So I assume that will be the the same case for uh Bessu and Nethermine but I'm not sure about Ref and Aragon. Yeah. So the next idea that we had is something called like a temporary storage model because so this is inspired by the fact that most of the storage they are they they only um operate in like a in in a single block.

So wanted to see if um if we can introduce a temporary storage where it's basically the same as the so-called permanent storage but um on the protocol level we state that okay for example after 6 months or after one year all of the slots return to this temporary storage for all of the contracts um um yeah all of contracts in the protocol they are automatically clear I mean clear out as in logically clear out but um I I would imagine the E clients will run like a background process is to clear out all all of this data um in the background. So yeah, so that's one idea that we have. Um the next idea is um on improving the user experience. So when

Improving User Experience: Contract Deployment Costs

you deploy a contract there's there's a bunch of calculation and one of the calculation is the code deposit cost which is 200 times the code size in bytes. So from the data we know that most contracts we use same bite uh bite codes and bite codes are the duplicated in clients meaning they don't the e clients do not store duplicate bite codes. So um we were thinking that we can actually make um like other department cheaper by removing or reducing the code deposit cost right. So um there were a few there are two variants. I mean there are three variants. The third variants is on libraries but um if you're interested you can check out the original article but um the first idea I mean the first variant is basically same what we call a

sim block duplicate discount. So it's pretty straightforward like if a bite code appears more than once in the same block then the second and subsequent deployments get a discount. So um the first immediate disadvantage that comes to mind immediately is um um it's it's unfair because um like um it becomes like a ordering game where people would try their best not to become the first one to deploy the the same by code right so so there's this issue and the second um idea which I'm more in favor of is something called like a global cos registry where you have a system contract where you all the code hashes.

So all the contract deployments first check if the code hash exists. If it exists then maybe we can wave off the code deposit cost or at least the cheaper one and if it doesn't exist then you have to pay the full one. So these are the two ideas. So I think one argument when it comes to making contract deployment cheaper is that we are incentivizing more spammy contracts if that's really the case because it's going to be cheaper to deploy the same um to to deploy a contract with the same bite code. So that's on the like a malicious party side. But on the good side uh we can make a lot of things cheaper like um if people are launching like proxy proxy contracts or perhaps for example like um AA wallets or a

smart smart accounts. So those will most likely reuse the same bite code. So um maybe this might help um with reducing the cost for those users, right? Um so the next idea that we had is um something called progressive per address storage pricing. Um I think um the the gist of it is that um because uh um so a contract can have unlimited number of slots, right? and all of the uh all of the slots have the same price uh have have the same gas cost. So um we wanted to see if we can make the the cost of storing a new slot into the contracts based on the number of slots

Progressive Per Address Storage Pricing Discussion

that the contract has. So uh for example, this is like a very simple formula. Don't don't read too much into it. It's like um so for example as a store could be repriced into 2,200 plus um 10 times number of slots that the contracts have. So so just like a so this 10 times num slots is is just uh idea to show that okay we want to price it based on the number of slots. So the the general idea is to tie the cost to the actual storage go at at an address. So, um it it kind of like disinccentivize um people from spamming like overly spamming too many story slots. But at the same time, the disadvantage or or

something that is weird is that most of the successful contracts they usually have a lot of users and which means that they would naturally have a lot of storage slots. So we are kind of like punishing those successful contracts or successful applications to have too many slots, right? So this part doesn't really make sense. But um again, it's just an idea to kick off some conversation. So yeah, I think overall um that's the gist of the data plus the ideas that we have. So in the next um few weeks, what we're going to do is that we're first um we're going to analyze with more data sets that we have. So first thing is the with the labels. Then we also want to to find some um short-term solutions that

we can have. So for example, is there like a subset of accounts or storage slots that we can delete them and nobody would complain about them? Like we can for sure 100% guarantee that if you delete them um you'll be fine, right? So yeah, so more things that that that can be analyzed to understand the state patterns. So yeah, that's pretty much it for now. Oh, I think it's a bit of a information overload, but um yeah, I'll just stop here. >> Thank you. Nice presentation. Um is there any question for Han Milo?

>> Yeah. Um one thing that would be interesting if you're since you're doing more analysis if you are accepting uh requests it would be interesting to see in the first year what would be a distribution like are most of them used only one day versus one block because one block is really short period of time but like are majority of them actually used through entire year or majority of them still fit in the category of maybe like one day or one week or one month or something relatively very short term and they also forgotten afterwards. That would be one interesting and also um if if it's possible to know the ones that are considered one block is that what is distribution versus one block versus one

transaction only um >> because there is a temporary storage that that already exists uh the bite code for temporary storage and it's just a question whether that's being utilized or not. You could just use during one transaction or something like that. this would be interesting to know but yeah if you do like a more research I think those will be interesting topics. >> Yeah. Yeah that I think that's that's a good idea. I think um we also had a similar idea on um like as part of our further analysis which is basically to understand the intensity of the activity because right now we are analyzing the activity span which um which could be inaccurate in a sense that um like we could have a contract that that have a

very short activity span but during that short activity span for example like one pun it could have like a tons of activities whereas we could have a very long activity span like those um longtime holders or whales or whatever they don't really have a lot of activities they just hold ETH uh and they perhaps they operate once in a while like perhaps throughout the eight years they only have like five transactions so the antivity is pretty like in terms of intensity they is very low so I think I think it aligns with what what you were saying just now so um that's definitely that what we we'll be looking at Yeah, >> perfect. Thanks.

Any other question? Um, if not, I do have one. And the question uh has to do with um something I should have been asking a long time ago, but uh there was this um this u article uh that was written by Gary when he discovered that uh veral and I guess by extension binary trees were planning to remove deletion uh of accounts like account uh account deletions and storage uh storage deletions in the sense that if you write to zero it's not the same thing as deleting a slot. It's not the

same thing uh as deleting an account. Well, okay, account deletion is already uh happening because of um sorry is already neutered because of 6780, but storage slot uh deletion was is removed uh and replaced with a with a zero. Um do you get a hunch? Uh and once again it's a bit of a I'm not trying to to trick you. I should have uh thought about this question some time ago and already asked it in in the past. Do you get any hunch of uh you know if if uh Gary is right to project that uh

Discussion on State Expiry and Slot Deletion Impact

account uh like removing the ability to delete slots when you write a zero to them is really going to blow up the state. Um so I think I think uh like internally matan is is is has some this data on storage growth and um I mean we do see like um I mean I didn't run the query yet um and I didn't see a result but uh I I did I did like run a small snippet of of of what what he did and we do see that there there are actually a bunch of slots that are actually return zero.

Mhm. >> And um so so that's one thing. Um and then another thing is if we do not delete them anymore then that means the we have to repric it right. So like um that that if we write it with zero then it's no longer cheap. >> So I'm not sure if this how going to if this is going to be acceptable by the community. Um but I I think there there will be a significant impact. Um I think that's that's my hunch um on the the state blo >> right. Yeah. I mean uh that's also what Gary said, but it would be interesting and maybe that's you, maybe it's Matan.

Uh we we should definitely check if um you know zero doesn't mean deletion anymore. uh we should try to see if we can confirm this because then we would have two sources to to say this is a bad idea and that's going to impact the the design of uh of binary trees and vertical trees too but that's not really an option anymore. Um so yeah that would be that would be interesting to have. Oh can you let us know why is that the case? I mean I mean why is it being considered for slots as well or to remove delions? Is it the same reason as accounts?

>> Uh no it's not the same reason as accounts. Uh it's just that okay the reason is actually state expiry if I understand correctly. Um I I do not remember uh for sure but my my uh like if memory serves which it doesn't really at the moment. Um it was because we wanted to uh enable you know like uh still expiry with several periods uh using address space extension and everything. And the idea was that if you ensure that no the no account and no storage slot gets deleted then you can prove that something was never um yeah deleted and

resurrected. So you can't try to to trick deleted. So um that was my uh that was my understanding of the reason for doing this and uh Gary's argument was precisely well until we do have state expiry um this should not happen uh because it's going to really blow up the state over time and we do that for no good reason. Um >> there's uh there's another reason uh that I'm trying to remember that might have had to do with the way vertical leaves were calculated. Um because if you delete

uh yeah no that's not going to work. So okay I I think that's uh that's the only that's the only reason I can think of. Uh maybe we should investigate that a bit deeper and see if anybody cares about this. And if no one cares anymore, well then we can just say that's it. uh we're going to remove this from the spec and uh simplify simplify our lives or well okay it's not going to be simpler because we're going to have to implement deletion inside vertical trees uh sorry vertical trees or binary trees um which never occurred so far but it's going to remove a lot of a lot of issues at least in the GU storage layer and the G um uh yeah database layer.

Okay. >> Um, okay. So, if there's no more question, uh, let's move on to the next item in the agenda, which is, uh, the test net relaunch. So, uh, yeah, Karim, uh, you're more or less ready. Um, and I think we you and I were having a discussion and it's uh rebounding on what you said earlier that you you have this new uh version for the shadow fork uh where you download the pre images um and you and I were discussing the possibility to at least for the next test net and the next shadow fork to have a new format for key computation.

Test Net Relaunch and Key Computation Format Discussion

where the key would actually be the catch shack uh sorry the well it can be the catch shack can be the shadow 56 but of the catch shack of the uh storage slot and the catchack of the address and the reason for this is u you don't need the pre-im images if you're doing this so it's a bit complicated but it would be a nice uh first step for client ience implementing shadow forks that they don't have to worry about the pre-image distribution problem and uh yeah that's definitely not the final design uh but we would like to potentially do this on

the next test net so yeah any anyone having an opinion on this >> just on this side >> not simplify I think it will be more complex >> oh yeah >> yeah maybe you misunderstood but as I said I looked at the code and uh for the moment the current implementation of the binary tree structure is using a lot the preage uh it's a refactor I did for ver and if I want to go back to the ash I think I will have to modify a lot of part of the code but >> okay so it's not >> it's possible but it's more work if it's

not the final thing we want to have at the end I think it will be more work for Bizu. If you want to go to this duration uh having that at the end of the implementation, it makes more sense maybe to do some effort on Bizu side to to implement it. But if it's just for some months or something that it will be more complex, I think >> okay uh well then yeah okay if it's not helping you then there's no point uh in doing this at all. Um I had another question for you in mind uh regarding the Oh yeah, you were asking earlier the if it was going to be SH 256 or Blake 3.

>> Um >> for me uh personally I would prefer SHA 256. Uh the spec uh I think talks about Blake 3, but um yeah, I think we should uh if if it's better for everybody, if it's simpler, uh we should do shadow 56. So unless someone opposes, we we could agree on this. >> And just one question uh for the next uh devet, do we want to just have binary tree or we want to have also the transition? Because for me the next devet would be just a binary tree starting from u from from zero or something like that or

do we want to have a transition in the next deet? >> Uh no I think uh no no we do want um no transition simply because if we want guest to to join that test net that devet this year um we will we will need uh to not have the transition. I think uh it's merging has been very slow um even slower than I anticipated. So um guest is definitely not ready to to do the transition uh at the moment. uh but joining the the DevNet that would have a vertical transition would sorry I say vertical but transition at gen Genesis

would be um would be the the right way to would be much simpler and so we it's realistic for us to to have a two a two client devet before the end of the year. >> Yeah. Yeah. because I also think for transition we need to define maybe a small specification because for the not I have the custom implementation calling another node uh thanks to RPC to generate the pre-shage before the transition but I think we need to have maybe the same way to work like that we will be sure that this pre-shape will take the same amount of time and will be ready at the same moment so if we want for the for a future dev net to have the transition I We'll have to work

Pre-image Generation and Transition Process Discussion

on this definition of how the pre-age will be downloaded etc. >> Mhm. Yeah. Okay, fair enough. Uh then uh I mean yeah no no rush in uh pushing a transition uh on the on the devet. Um you know you're working on the on it on the shadow fork which I think is the most uh the most valuable demonstration at this time. Um yeah, as long as we have both uh I think uh I think this is the the best we can hope for realistically and uh and there's no reason to make things more complicated.

>> But if you think that removing preage will help to have maybe get uh sooner. I can try to take more look at the code to see if it will simplify the things or not in bizu for for I don't think but if it's a way to have maybe more client more easily or I can try to take a look but >> uh so if I think the pre-age no uh it's not it's really that was really meant to help you uh I have no um yeah I have no problem uh you know generating those pre-im images We we have had the code to do this for a long time. Um yeah, it's not it's not a problem for us.

>> It it will be interesting maybe to have a call later to to see how you are doing that. Maybe I can try to have something similar just uh yeah >> um I mean yeah we don't really need a call in the sense that I can just tell you right now it's uh we're we're just having a a node that is synced uh that that does a full sync from Genesis and records every every pre-image ever used ever seen when we identify a block we want to do the transition at we just stop the node and we go over the snapshots or the flat database uh and we simply uh we simply check the pre-image for everything and we store it

for everything that is needed and we store it into a file and then we put that file in another node and that file that node does the transition. Um yeah that's that's a very painful slow manual process but we know how to do it. So you are reading the file every time to get the pre-age of the specific key. The key are in a specific order. So you are just reading the file in the right order or >> Exactly.

>> Okay. >> Because it's a frozen database, right? At the transition. So at the at the vertical fork, you start with an empty overlay tree. um and uh you wait for some time before you uh before you start the iterator sweep of the database. So your reference um yeah your reference uh file is always the same. Um and so you you can generate it and then you can even verify it um by going over your own frozen MPT snapshot and verifying that the pre-image that you get the next pre-image you get in the file corresponds to the next item in your in your flat database or your

snapshot. And it takes about yeah uh one hour these days to to iterate the snapshot. So we're uh yeah it's pretty it's pretty fast. yeah any anything else you wanted to talk about on this uh on this item? Like the next uh item on the list was also the shadow fork. Uh yeah, maybe you want to give us an update on on your status, but you kind of did already. So if there's nothing else to add, we can move on to the next uh to the next item.

>> No, I think it's I already showed everything. Yeah, it's okay. >> Okay, great. So next item, unfortunately, we can't discuss it really uh because none of the people that uh would be able to contribute are here. Um but yeah the so it will be pushed to the next to the next stateless implement call simply uh just to give an um an explanation uh we have even before we do the the test net uh we have these uh execution spec tests that we've been running and it was mostly uh at the end of last year at least it was it was Ignasio uh writing a lot of tests

to to do this and guess would be filling those tests and uh other clients. So in that case, BESU and Nethermine uh would be the ones um consuming those tests and verifying that everybody agreed on the state uh which is easier to debug than on the live devet. Uh so this is something we would like to do uh well we have hoped to hoped to do on the before launching the devet. Um but at this point I think it's also valuable to to launch a new binary devnet um and and still do the that thing in in the background. Um we have a branch

that's called vertical/main uh that is uh that is for vertical that we need to adapt to binary tries uh sorry to binary trees. So um so Carlos was actually looking at preparing the GPR to to do this um and supposedly it should be agnostic but the problem is that this uh branch is out of date. There's been a lot of changes in in the execution spec tests. Uh so we would like to modernize it and also bring it to after the latest fork which is currently Prague and will be uh Osaka pretty soon. Um so yeah ideally someone well both Ignasio and uh and someone

from testing would have been here so that we could discuss the feasibility of this but uh today no nobody's here. So I guess we just have to to move on to the next uh to the next uh item. which is also a pretty short item. Um we are planning to uh start a to create state anal an analyzer panel uh which might be on the eastend ops lab uh website and um we were thinking of doing some uh some metrics uh to showing some things. So uh I have a document that is not really ready to publish at

State Analyzer Panel and Dashboard Plans

this time but I can already kind of go over it and uh my question would be uh can you think of other things you you would like to do. Um so let me look for the window as I always do. Yes, here we go. So we have uh yeah I don't know if you guys can see my screen but uh we have a state dashboard. So this document is going to be published this week. uh we still need some input from from some people but we would have a homepage saying this is u you know the state size uh by categories so how much is the uh how much is the are the accounts how much is the storage etc etc this is the

equivalent of a of a DB inspect in guess if if you do that today um we want to have a sto total uh state growth over Um also rank the contracts. Um try to uh like say this is the biggest contract. So send is the biggest contract. Um we uh we also want to do something like what Paradigm did back in the day. Uh but keep it keep it up to date instead of just having a static uh rendering. Um yeah some some suggestion that was given is to display the growth with respect to gas limit. So you know

when the gas limit goes to this level how big is the is the state growth um and uh yeah um number like add some values like how much is represented by EOAS how much is contract so a lot of things that Han has exactly done for uh for the his state uh state analysis uh uh article simply uh keep it up to date instead of just being a one uh uh something that gets published once and uh and is forgotten. Uh we also want to make a a state expiry page. Um so yeah, roughly exactly what Han has done. Uh but uh up to date like kept up to date

so that we can see if there are changes in the pattern. Um there's an IP I wanted to talk about and then yeah this is how we would collect the data. So it's not really interesting to to talk about in this uh in this presentation. Um but yeah, so if someone has an idea of another metric they would like to see, uh we would like to hear this either uh right now or you know we are going to try to publish this document this week. So if you have more um information or more ideas as the week goes by, we would love to to add it to this document. Um yeah, that's pretty much it for for that topic. Uh if

Discussion on Metrics and Document Sharing

someone has uh questions, I'll be happy to take them. Um yeah, otherwise we can we can end the the call early >> if you can. Uh not yet. Uh I will sh I will share it uh this week. Yeah, because I wanted to share it to to the team like that they can propose maybe new metrics. Yeah. >> Okay. So, uh I'll tell you what, I will record the I will resolve a lot of the comments we we have. Um and then I will share it uh yeah I'll try to share it

tomorrow. >> Okay. Thanks. >> Um yeah, so that's the end of the agenda. Is there anybody else uh who wants to bring some last minute item? All right. Uh well then, thank you for attending this call and uh we'll be catching up again in two weeks. Cheers. Bye-bye. Bye.