Stateless Implementers Call #41

Transcript

All right. So I think we can start. Welcome everyone to status implementers call number 41. And we have a few items on our agenda today. So as per usual let's start with team updates. So anyone is if you're ready just you can just give your updates. Yeah. I can uh Yeah. Could you hear me? >> Yeah.

>> Y >> uh so on Bezu side um compared to last week not a lot of news. We just uh did some test with hoodie as I said uh last week. So my test was working. So I fixed several issues. Uh no my test can do a transition on hoodie and after it it can follow uh the head without any issue. Uh as I said for that I cannot really uh verify all of the state roots to be sure everything is correct but yeah I I didn't found any crash or memory issue or something like that. So it's it's already a good news. Um and uh

for the moment I'm waiting uh for feedback from the DevOps team GM as I said because I wanted to have more information regarding the test net before sharing a docker image because I wanted to do some test on my side before sharing something that uh maybe will not work. So when I will have some feedback uh from your devops team and I will be sure that everything will work correctly. I will share a docker image uh on the gas side. So I will let Louis talk about that. I shared your EIP for your update of the EIP gum regarding charging gas for Cisco. So I just share

the link to Luis and Luis if you want to to give more feedback on this one. >> Uh maybe we can postpone that after the updates and then we can discuss it with Gil. He has that on the agenda already. >> Okay. Okay. So yeah. So for Bizu it's uh it's everything. Yeah. Uh I think I can go next. So I don't have any major updates on other side. Uh we just will start working on the binary implementation. This um yeah so I was actually I'm currently

in the EF office in Berlin and so is Perry and and Sam from DevOps uh doxing people right now. Um I asked uh him if he could uh just drop by so we could make it uh maybe like try to solve these issues right now otherwise uh yeah I uh I will talk to him afterwards. Um yeah so update from my side. Yeah working on the update to the to the EIP 4762. uh also working on a mer uh on merging more code into g. still had some success. Uh still uh quite far off in terms of uh master being able to to

follow the chain, but my my current target is to uh just be able to feel test and replay them uh at the like without the transition just for test netis. And uh yeah, that's uh that's pretty much it. Uh yeah, I think so. All right. Um anyone else like to give any updates?

Okay, I assume that's it. >> If you could give me one second. Perry is actually joining me in the room for uh for a little bit so Karen could ask his questions directly. >> Uh >> yeah. >> Hey. Um so I'm actually on uh like speaking right now. Uh you know uh you probably missed that but Karim had some requests for DevOps to uh for espan ops. He's trying to to do the to test that shadow fork uh sorry the hoodie shadow fork with the doing the transition and uh Karim could you please share your uh your questions for for parade. Yeah, I think we can discuss about that on

discord. But just the idea is to have uh the test net configuration you are using because I want to start Bizu on my local setup to be sure that Bizu will work correctly for the test net you want to launch and when everything will be okay I will be able to share a docker image. So if you can just share me how to set up the test net the configuration etc just to be sure everything is is okay. Uh >> yeah, I can show you a config on uh ktosis. So you just have to use network colon hoodie- shadow >> and then >> we we want to start a shadow fork of hoodie for the next test net or just a

new test net uh starting from scratch. >> So this one would be a hoodie shadow fork and this is locally tested. I'm not sure about which test Gong would want. >> Yeah, there are two things. There's the test net uh which you would be starting. So that's your uh yeah that's whenever you you're ready. Uh and then there's the shadow fork which we want to keep demonstrating and and go uh you know keep uh keep showing that it works and make it more and more realistic every time. Um, so yeah, I'm not sure what you >> So for the end of the work, we want to start the shadow fork of hoodie, >> right? Yeah. I mean, I

>> Okay. Okay. Okay. No, no, for me it was more a new test net or something. Okay. For the shadow fork of hoodie, I have everything I need. It's what I'm doing currently today. So, yeah. But but so for a shadow like we we do want a main net. Sorry, we do want a binary tree test net as well. Uh but yeah, it's whenever you're ready because we like like I said like guess is not going to be ready. Uh never mind. Well, Tennis just said he was working on it, but we're uh we're not quite there yet. >> Yeah, but >> yeah, >> sorry. Yeah, just for the binary test net, who will manage that? for me I will share the docker image but who will set up this all of the infrastructure so >> yeah I can take care of that um but we

can we can text on um discord first I would need to I would need the docker image from you as well as um how to activate the binary tree genesis I think if I have those two pieces of information I should be okay >> and and for the genesis generator because we used to have that for veral we're going to have >> yeah so I would need to know How to start binary tree agendis like what is the is it binary tree timestamp zero or are you starting it at fulu or are you starting it at some >> Oh yeah no we would be starting it at uh I assume pectra >> yeah then it's fine I we already have support for that genesis generator so >> what I mean is for the for the genesis

block itself >> like you know back in the veral days we needed to modify to genesis. >> Yeah, true. We need support for a lot of things. Um, >> so okay, I guess you and I can talk. >> Yeah, I can make a list of things places that need support for this year. I would need to add support there. Yeah. >> Okay. But we should be able to use the go code by proto lambda which I need to change. >> But by now we we're not using that tool anymore. We have another tool that we use ourselves.

>> Okay. Okay. So, you need to make a PR to attestance types as well as um PKA maintains the genesis tool now. But we can I can make a list of this. >> Okay, cool. Yeah, please share it and uh and then we we can get started on that. Yeah. >> Okay. >> Yeah, you can share everything on this complex that we can start. >> Okay. Thank you. >> Nice. Um so that's it for the team updates. So we can move on to I think this I'll pass it to Gum on the update on EIP 4762.

>> Uh yeah, thank you. Um so give me another five minutes while I fumble with my uh with my Windows to try to share the right screen. Um where is that uh Firefox? Yeah, I think no. Um, yeah, it's a classic. It's uh uh wait. Okay.

Right. That's the one. Um, right. So, that should be this one. Can you guys see my screen? >> Yeah. Yes. >> Right. So, uh, a couple like a couple calls back, uh, Felix was here and we, uh, were discussing, uh, a change that he wanted. Uh, so to give some context, they didn't like the way it was specified.

And I understand why. Um because the the target was to be as uh conservative as possible and put zero uh zero like system contract code or data inside the inside the witness to try to save some space. Um but the problem was that there were some corner cases where some contract would uh actually uh call like could copy the system contract or something like this. uh and there was a case that did not exist but could exist in the future where someone would call the system contract that would call some code uh that was not part of the system

contract. So for example typical case uh a factory contract. Imagine a system contract that would be the one creating other contracts. So once again something that does not exist today but it's not impossible that this will happen in the future. Um, so we wanted to try to cover all these uh use cases. The problem with doing this is that uh there's no way around keeping a list of system contracts and going over it every time uh you call, every time you do an Xcode copy and things like this. So, uh, Felix in particular, also Gary, really didn't like this and they wanted

to, uh, change the behavior by saying if this is a system call, uh, don't record anything into the witness. But if it's not a system call, uh, record, uh, record as you would do. Um, so that has the advantage that it's simple. Uh it does break the case that I just described of a potential future uh factory contract, but that's okay. They don't exist. So um we can we can cross this bridge when we get there. Um and so uh yeah, so I this PR is about like uh we did agree back then that this is what we would do. Uh

this PR just changes the wording to to reflect this reality. So uh I mean I'm not going to go over every single word uh every single sentence that got uh modified but you can see uh if you have a value bearing uh targeting a pre-ompile we remove all system contract uh we just don't add data. So we basically the the the behavior is that if you're in a system call no matter what you touch you don't record anything and that should work until system contracts start accessing other pieces of code. Um so yeah please uh have a look I mean especially uh yeah uh other

core devs from other teams. So Danish Karim Lewis um I think I didn't forget anyone in that call. Please have a look. It should be a fairly simple one but as everything in in that EIP for 4762 the devil is really in the details. Um and when we have that uh I guess we will have to uh to implement it which should be pretty easy and uh then we will have to uh regenerate the refill the tests but uh I don't think we need to to bother uh refilling the tests uh at that moment. We should just implement it and consider that's going to be the

behavior on the on the binary tree test net. So we just implement this and uh we uh whenever someone is ready to fill the tests which I hope could be G in like uh two weeks time uh we will refill the test. I will probably ask Ignasio for help at this point. Um and uh and then yeah when this is done uh uh we just uh make sure we all agree on the interpretation. we fix the tests that need to be fixed and uh we will be able to to relaunch the the test net I think.

Um yeah, so that's really all there is to it. Just have a look. It's just a few a few lines that have changed. Uh and if you see any issue, uh just tell me. And if you don't, just tell me as well that you that you're okay with this interpretation because we I would like to merge it and uh and proceed with uh yeah with making it official and and actually run it on the next test net. Yeah, I was uh looking at it today just quickly and uh now that you're scrolling up and down um I I understood that start the start start understood it in the different way uh where the system contract who whoever calls the system contract would not be charged would not

be added to the witness but I see that you remove that part actually so it makes more sense that whoever calls or does a the code hash or code size to a system targeting a system contract is charged or is added to the witness uh and the system call itself what happens inside is not added um uh to the witness >> exactly yeah >> so that's what it's supposed to mean if if it's really not obvious to you or if you think it's actually clashing with this with with what I just said please let me know Um >> what what's happen what's the difference

like like a system call initiated by um a user or um the difference between initiated by a wallet or initiated by the EVM itself? Shouldn't we make this distinction? >> So if it's initiated by a user, it's not a system call. A system call okay not quite true. Um if depends how you implement the the block hash instruction. Uh but as far as I understand the block hash instruction has to be implemented by a direct read.

Um so if you implement your block hash instruction as a call to the system I don't even know if the system contract can get you that. Yeah, right now the client at least peso is doing it does not have a u I mean you cannot do a call to a system contract because essentially we are just reading directly from the state >> but some EIP mention that at some point we might even we might even have a proper contract uh living in the in the blockchain.

>> Right. >> That there's that option in that case some user could call into it. H um yeah but that's the thing I I don't I don't remember if there's a get function in the in that system contract for block hash for example. So >> if it happens um then we have something missing from this description because actually I we don't because it does say that if it's through the execution of a of a uh instruction somewhere it mentions the instruction uh right to resolve a pre-ompile up code it's here u so if it's also in that case then uh the system contracts code chunks

and account header access should not appear here in the witness, right? Uh so um so yeah, normally the only two uh okay, assuming uh your instruction of for example block hash your implementation of for example block hash calls the system contract which I don't think will work in the in the current setting but I I could be wrong. Um then in that case it's considered a system call and you don't uh like starting from the moment you trigger the system call until your that system call returns nothing gets added to the witness.

>> Mhm. Um, actually that's uh I just realized there's a problem with that wording. Uh because you would still need to add the storage. Uh so so storage needs to be and is that still compatible? Um still right. It says code chunks and access headers should not appear in the witness. So actually storage would but that's normal. Okay. So no, that's that still works. Uh but it's a bit of a finicky thing that we have to be aware of. So it's just code chunks and account headers that don't make it to the witness, but storage slots would have to be added.

>> Mhm. Yeah. Yeah. My point was just distinguish Yeah. between users calling which doesn't exist today. You're right. Um uh but I do remember in those EIPs that it was strongly encouraged uh to move towards that solution of uh deploying system contracts on chain on chain um at some point and that this direct access was a hack for the time being. Uh it is more efficient. I I like it more more than um than having the contracts deployed to be honest. Um but uh >> I mean some said that that's true. Uh

you know I disagree with this EIP. I've been uh you know it's my opinion. Uh I I think with the whole uh Sepia hack I've been vindicated but of course it's my opinion. So I wasn't uh I was going to feel vindicated anyway. Um yeah, right now uh I'd say most people like the idea of uh system contracts like uh delegating a lot of stuff to system contracts. I think it's misguided and uh the more we wait the more people will run into problems and uh and in the future it might change but my my advice is to not implement stuff as system contracts if uh if we can avoid it.

>> Yeah. Okay. Makes sense. since it doesn't exist. I'm uh I'm I'm I'm behind you. Good. >> Well, cool. That's two of us. Um yeah, that's pretty much it. Unless anyone else has a comment. >> Yes. Not. Thank you. >> All right. Um thanks. And um next item on the on the agenda is um broad net update. So maybe Gilmore or Carlos, you want to give a quick update on Broadnet?

>> Um yeah, I can give a deal. Yeah. Uh I was out of office the last two weeks. So um the thing I'm not sure how to say it, but yeah, there were a bit less updates, let's say. Uh so far uh the implementation of the single up codes for the east benchmarks uh to be run on blet has been started by gu uh as stores done and slow is uh work in progress pending uh to fix some some nitpicks. uh also Han has been working on uh some use cases that uh will be implemented with spammer and has started already with the first one which if I

recall correctly was the combination of warm xcode hash plus balance. Um then we have run the first round uh and shout out to party for that. uh the first round of syncing tests at 2x maintenance size um for state of course uh the results have been mainly influenced by peering issues which uh are being worked on at this point but uh to give a tlddr and bessu have been uh able to sync although really slowly it took two days to them to to do so uh mostly again due to pinging issues

uh Dre, Nethermine and uh Edgon were not able to complete the syncing but again uh this will need to be rerun once we have sorted out the the pering issues which we are at uh we're working on at the moment. Uh aside from that uh Camille from uh Nethermine uh continues to work on the integration of the of their tooling to run all of the east benchmarks uh sequentially in different uh chains. In this case we need to run it in uh perfet so net and what we will be starting to run is all of the computebased benchmarks. So all of the ones that have been used uh in perfet so

mod x and all of this kind of stuff that what we have been hearing a lot about uh we will run all of this against bloet not much expectations to get anything uh as it's basically compute and it should not be affected by the size of the state but uh worth giving it a try and see if we can spot something uh that we were not accounting for. Aside from that, uh the goals for uh the next for this week uh are try to get uh syncor so this tool to test syncing built by if panda ops um to include all of the metrics that I left uh in one of the endless hack and this I have uh let

me share it here just in case. Uh this contains all of the metrics that are already in uh the graphanas exported by all of the EL teams. And so the idea is to gather all of these data points when the syncing is running so that we can do a much better analysis of the syncing uh that we can do at this point. And aside from that, we will also be syncing with Camille tomorrow to see uh when can we start launching uh all of the tests. uh east is also including uh stopped contracts I think we were calling them or something like that which basically will allow uh all of the east benchmarks to use state that already exist in the

underlying chain which is something that we are not capable to do at the moment and among a lot of stuff this will allow us to execute all of the Zen uh test cases and benchmarks which are one of if not the worst first with respect to smart contract size and state access. Um I would say that's mostly it. The rest is to continue to implement uh test cases for east and for spam and continue to run uh as much as we can on on blet and get results.

So that should be it. >> Nice. Um thanks for the update on net. Um yeah, if anyone has any questions, we just wait for five seconds. Okay. No. Right. Let's move on to the next item. Um so I think this is also by GM. So um mention you want to talk about um Blake 3 versus SH 256 in GE. >> Yeah. Um this is something that came up uh this morning during some uh PR merge review in the guest team.

Um we uh okay Gary to be to name him uh was pushing against Blake 3 asking for why we we picked this. So I I gave some uh a bit of feedback but I just said well so far there hasn't been any uh official decision on uh on the hash function. We're still waiting for Poseidon and and like the Poseidon uh uh effort um the security there's an effort to currently try to break Prooseidon we're waiting for the results of this which will continue until the end. I'm trying to remember is it next year or this year? uh we talk about 2027 so I guess it's sometime next year anyway

um so yeah uh I think the main reason for pushing back for push back is that to merge things into G we would have to import an external module uh that is not validated like go the Golang standard library has support for Blake 2 but not Blake 3 um and while We all like Blake 3. I think it's much faster and uh more efficient and and parallelizable and things like this. Um it's there's no there's no denying that this is not an official release. We would have to merge something into guest master that is not really validated or not validated enough for our liking. Um

so yeah, Gary was pushing back and said we should use Chat 256 instead. So as far as I'm concerned there are two ways we can do this. Either I just use chat 256 in master and then whenever we need to build a test net I replace that module with uh with blake 3 to be compatible with the with the test net or uh we just uh decide that it doesn't matter which function we we choose right now and everybody moves to shadow 56. So honestly I would say for me it makes very little difference. Uh but uh as long as we all agree on what we do uh which which is why I would like to ask

you guys what you think. >> I think for Bezu it will not uh be a huge modification. So I think we can switch to SH 256. of code element as well. We haven't started the implementation yet. So any Okay, I think that's pretty uh every client represented here. Um Ignasio hasn't said anything, so I assume uh there's no hard uh push back

against it. Um yeah. Yeah, I would say that I think it doesn't matter much because uh ideally the end result would be that we will be using posit I guess. So even if we try to use flex three now we will probably have to change it anyway. So I think the the thing is that the each client just call a hash method um and pipe all hashing through that and eventually we will simply switch whatever this method is doing um

so yeah I won't care much about that today so just do whatever is the easiest Okay. Well, I guess that settles it. Thank you. We'll uh we'll use SH 56 on the first test nets until a decision a formal decision is made at the EIP level. >> Right. Cool. Um right. So the final item on the agenda will be by me. So I would like to give a short presentation on on the latest effort. So let me just share screen quickly.

All right. Um so I'd like to share a little bit on um what I've done on benchmarking for say expiry. So um here I call it naive pruning which I'll explain more about what what is knif later on. Um but the whole goal of doing this benchmarking on state aspire is that um it's basically to find out how effective state is right now um with various methods. So um like um I'm expecting the the most optimistic case here where basically we just prune everything and we don't have additional metadata. But in actual scenario where we actually implement some sort of state expiry EIP whether it's um S736 or the previous o older um EIP or state expiry

or even state rent is going to introduce additional um metadata into the like in protocol. So it's definitely going to be um I mean it's going to affect the the performance but here I'm just want to do a optimistic case so that in the future we want to decide um whether we want to do ST or not this this should give tell us like um like this should give us the numbers to to to make that decision. So yeah um I started off this benchmarking with something called naive pruning um which is basically I I do it in GF. So um like in GF state we basically have two layers. So one is the snapshot flat key value store and another part is the

cry part. So um yeah so this knife pruning thing is basically we only focus on the snapshot layer the flat key value store layer where we only prune the expired accounts and the storage of the snapshot layer and for the try it still remains the same. So theoretically this should work because um for the accounts or for the storage slots that aren't touched then um when we delete them it should um the execution should proceed safely. So yeah, so this is the naive pruning part. And in regards to the benchmark setup, um I only test it on GF for now. And I I I was using um Rox 5B.

And then um I'm only comparing between the full state versus um holding only one year active state. And um in the experiment, I sync it for I sync the note for 20,000 blocks and then repeat for five times to get the average um result. and I started the experiment in uh quite a recent blog about three months ago. Yeah. So let's dive um straight into the result. So in terms of the snapshot size um so we actually see a huge improve I mean a huge improvement as expected u because a lot of state um is expired. So in terms of the account size we see a 72.5% reduction from 13.5

gig to 3.77 gig and in terms of the storage slots we see a 82.6% reduction from 94.1 gig to 16.4 gig and we look at the total size um overall it's um 107.6 gig to 20.1 gig. So about 81.3 storage size reduction which is um in this aspect is a lot. Uh but I guess if you look at the whole um EL client um like storage DB size then maybe it's not too much but in this particular um layer it's quite a lot and um then we look at the execution performance particularly on the time

taken for state read. So we only compare two things. One is account read and another one is um state uh storage read. So for account read we do see a decent performance gain um from um 8.1 millisecond to four 6.4 millconds. And for storage slot read it's um 20.6 millcond to 17.3 millisecond. So yeah so when I compare the sync time um the sync time also improves by a little. So the account read um the performance gains from account read and storage read would probably uh contribute to that as well.

And finally um on the DB side so since um GAF is using a LSM3 based um database so we also want to compare the compaction time. So in terms of the compression time, we actually see a um I guess a small gain in in um per performance in terms of DB compression from u 152 millisecond to 139 millisecond. Yeah. So these are all the um benchmark results that I have for now. So um to answer the first um the the question um how effective is the knife pruning um I mean um uh within expectation is the reduction of um storage size and we also do see um um

some performance gains in terms of the account read and storage read and also the DB compression time. Um but um if you were to ask me like is this enough to justify if we want to do stay expiry um I guess not entirely. Um I would say these numbers are still quite um naive or still still like preliminary. Um there are more things that we can um explore and um definitely if um like if you want to compare this performance gains or storage um size reduction trade off versus the um like the the trade-off they have with state expiry which is like um um users having to revise state and so on and so forth. Then um we might

have to debate debate over it but again these are just numbers for now. Um yeah so in terms of the future work um I also like to do benchmark with um expired um MPT nodes prune. So that will uh give us even more um um DB size reduction for E clients and definitely also on in terms of performance and um I will still proceed with GF um for now. Um I was planning to do it in other E clients but I guess um time is ticking on my side but if anyone wants to collaborate on this part um let me know and um yeah I'll be happy to work together on this.

So yeah um that's it for the result for now just a quick sharing and um yeah any questions >> um you >> I do have a question um yeah so I think uh when you say the compaction is um I I have a question okay I have two question the first one I will uh ask but I'm going to go to the second one immediately afterwards uh how do you Exactly. How do you gather DB compaction time? And I'm setting this question aside to add a comment. Uh I think when you say it doesn't show much performance, uh I think it doesn't show

much performance today, right? On today's on today's DB, um it doesn't have much impact on compaction. I think we should do the same thing on bloatnet to see if it you know doesn't improve greatly over there because yeah I'd say we don't need state expiry today right okay we don't we don't need it very much but state expiry is what we need uh 10 years from now 50 years from now and uh I you know like just because you don't get great results on the compaction time um today doesn't matter doesn't mean much in my view. What I'm really curious

is what happens when you you know when you do this on the bloat net and uh what what we're afraid of in terms of compaction is that compaction uh becomes you know um start crashing and keeps happening again and again and never stops and basically uh yeah it's uh it starts and never ends and so performance is degraded over time and when this happens uh you reduction reduction in compaction time is going to matter a lot so that we don't get into this uh infinite cycle of uh of writing data while compacting so that you never finish compacting um so in my view um I wouldn't be you know underwhelmed I mean

like even though those results are underwhelming I would not uh I would not uh reduce the significance of of your results to to this specific uh to this specific uh you know block height basically. >> Yeah. Um yeah perhaps I forgot to mention as well I think um this result I mean based on our current gas limit and based on the current block height this result is kind of expected but um in the future when we are scaling um even with higher gas limit then um I I I mean all in all it's just that as the state grows as um as the time pass like five years from now or 10 years from now um the

result is just going to get better and better uh even with knife pruning like without considering the apt. So um but yeah u this this the current numbers that I have right now just shows what we have with CS currently the the yeah but in like 10 years from now is the result is going to look quite different. So yeah and you mentioned you have another question. Yeah. So the the the I mean this that was the second question which was uh yeah which was basically could you try doing this on on bloet that was the second question and the first question is how did you measure this time like what did you do to to get those measurements >> oh okay um so for for this measurements so it's we basically I basically just

take it from graphana so g exposes all these um metrics for DB block processing and um sync time and whatnot. So yeah, everything is taken from there. So I didn't build like any any additional metrics. So that's one. And um on the bonet side um that will be very interesting to explore um because um here I'm using actual mainet data um says very threshold um but on the botn net side because we are um building the state artificially. So that means when we want to prune the state and also try to sync the sync the notes, we also have to do it somewhat artificially. So yeah,

it's definitely possible. We just have to explore. >> Yeah. Exactly. >> Um one um Yeah. One one thing I was thinking because you know if you just take it on Graphana that's uh that's great because that's where it's reported. So that's unfortunately the only source we have. Um but you see like if I look at my own validator uh the uh the uh was um the compaction really happens like large compactions only happen once a day, right? So if you don't hit exactly the moment where the big compaction happens, uh the risk is that

yeah compaction time is going to be fairly small anyway. Um so maybe and that's yeah go for it uh Carlos. No, no. I just raised the hand to ask something later. You can go. >> Okay. Sure. >> Um, so yeah, unfortunately maybe to get more uh more relevant uh compaction time uh info, you need to let it run for more than 20,000 blocks. Uh actually 20,000 blocks. Yes, it's more than a day, of course. Uh okay. No, don't forget what I said. It's um yeah, it's probably the best we're going to get. Okay. Thank you.

Yep. All right. Um CS, >> yeah, I was going to say that um uh aside from what I mentioned on the chat, which is that I think it's interesting to the only issue I foresee is that state since it was created artificially, it was introduced all within a margin of two or three days. So it will expire all at the same time. So I'm not sure I mean we can expire like older state and we will still have a really big state which for compaction definitely matters. Uh but yeah I'm not sure if is exactly what you want. So just for you to be aware uh but the thing that I really wanted to mention is um I know we are testing this

with G but certainly for other clients and and especially for other types of um of like database uh architectures. uh so for instance MDBX uh I think it's really interesting to also take into account things like uh state rule calculation time um so once you are able to perform uh the expiration uh contracts like Zen for instance will not be an issue anymore for breath and which is uh which was the case uh now or at least until ModX uh got uh nerfed let's say um So may maybe if we also take a look to other clients, I

think we can definitely find uh more justifications and and more uh like let's say nice cases or or nice additions that uh state expiry brings uh for scalability that maybe are not uh entirely visible right now but that would certainly have a a big effect uh on things that are being worked on. >> Yeah. Oh, got it. Yeah, definitely. It's definitely um good to the other E clients. It's just um uh whether I have time to do it. Yeah. Um yeah. Uh Tanish >> uh I had that question in the similar lines uh that was asked uh that so if I understand correctly the new state expiry proposal will not uh have any

difference in like state root calculation time, right? Because we are only expiring leaves and not uh the internal nodes. Uh yes that's the I mean that's the latest um uh sales right EIP that we have 7736 but we were also considering to also I mean given that is in vocal tree/ um vocal like binary tree um situation then we may also want to consider expiring the um inner branch nodes the extension nodes um but I'm still considering whether it's feasible or whether it's effective or Not but definitely if if we can make it such that um we can also prune away the um

inner nodes then definitely that will be the best case but um as of right now for that particular EIP um is only pruning the leaves in which the this current benchmark will show us like um how good that I mean even though this is yeah I mean yeah it will show us how somewhat how good um that EIP will be but I wouldn't say that that EIP is the final form of state expiry that we have um in the future. Yeah. Okay, that makes sense because I'm very I will be very interested in knowing like if we expire the internal nodes as well, what kind of a performance improvement will we get uh in state root calculation because again like the biggest

uh time consumption or the the thing that takes most time is state root calculation like the reads and writes also takes up some time but if you like check the percentage of time that's used uh related to state I think the state calculation is takes up the majority time. So if some way we can optimize for that, that'll be pretty good, I think. >> Yeah. Uh it'll be a challenge. Um but um we'll just get the numbers for now and um when we have better solutions, then we can see how we want to move on with that. But yeah, right. Thanks for the questions and comments and um anything else?

Just stop sharing screen. Okay, I think that's all for today. Um, that's the final item on the agenda. Um, Tanish, you have your hand raised. Okay. No. Right. Yeah, that's I think that's all for today's call. Um, if anyone else have anything else to say, Gil? >> Yeah, just thank you for uh taking over Gabriel while he's gone uh on holiday.

So, yeah, very good job. for leading that call. Thank you very much and talk to you guys in two weeks. >> All right. Thank you. See you guys. >> Cheers. Have a good day. Bye.