Stateless Implementers Call #43

Transcript

Team Updates: Discussing execution spec tests and gas accounting

All right, let's uh let's get this going. So, welcome everyone to stateless implementers call. This is number 43. Um our agenda is quite packed today. So, that that's good to see some people doing some good work. Uh we'll start with the number one on the agenda, team updates. Maybe G, you'd like to go first or whoever. Uh, >> yeah. No, I'll start. Uh, just FYI, I'm at an airport, so if you with a very

loud speaker, so I apologize in advance for for the noise that is guaranteed to occur. Um, yeah, I've been mostly working on two things. Uh the first one was assisting Carlos with the the preparation like we're trying to reactivate the the execution spec test for for veral to make make them binary tree compatible. Uh so working on the PR and then uh also worked on proposing a new PR that has to do with gas uh gas accounting. So it's not statelessness really. It's more like a stemming state growth. Uh but uh yeah, it's so the EIP

is 8032. If you if you are curious, have a look. Um so from my side, I've been working on what Giam just said. Uh we fixed so far almost every single uh test case. Uh the only things that are left or are an address so far is state divs in one side. Uh and I'm not sure if state transition is there entirely at least. But everything else should be working out of the box.

We detected uh some bugs uh in the implementation of the binary tree which we were able to fix to uh and we did some some refactoring also. Maybe not crazy but slightly decent I would say. Aside from that, I've been also working on blognet and I've been also working on pushing uh benchmarks to east in order to be able to run them uh within the within the software that Camille from Nethermine is creating and on top of that uh we have mainly been discussing uh some topics that will be touched uh later in in this call.

Cool. Thanks. Anyone else? >> Um, I'll go for Bizour. Uh, so Karim is not is not here today because he's um he's he's off um and um so he he he told me that he was still uh working on transition uh and that he's been waiting for some returns on tests for binary trees. Um and I was uh mostly working last on the the past month on on on gas optimization. So another subject but I I'll be back on on stateless um now. Uh so I'll be taking uh probably the subject on on transition as well from

from Karim. Um but yeah so we're waiting for uh for for test cases. Um is it test cases or is it like u being able to build a test net? U perhaps the test net that works on binary tree. >> So regarding this um I talked to I forgot to mention I talked to Perry and they have zero bandwidth for us right now. Uh so they said just build your own uh curtosis config and try to make it work. Uh, so I hope we're going to be able to tackle that this week with a BU image. Do do you know when Kim is coming back?

>> Tomorrow. >> Okay. So, me too. That's great. So, we can uh we can do that. >> All right. Great. >> Do we have a rough timeline for when a test net could be online? >> Uh, last uh last uh Jude So yeah, no uh I mean it could be Kim is uh from from what I understand talking to him uh Kim is more or less ready to go but uh yeah we we have to write a curttosis config and there's very few people in the world that know how to write your own package.

So we're going to have to figure this one out. So uh even if ideally we if we had had the memo that we were supposed to work on curtosis ourselves we would probably have started some time ago but currently uh it could be a five minute job it could be a three months job we it's is pretty hard to say. >> Okay good. Yeah I'll I'll I'll join in with an Ethereum JS update. So we were able to get a grant to get EthereumJS going. So we're mostly in maintenance and like security mode as it's an underlying depth for many things but we still would like to help out with testing efforts in in some capacity. Uh

the main thing that we see ourselves being able to do is just you know joining test net but in a stateless fashion. So at least we would have a minimal like stateless client that can join at some point. Uh we're not going to put as much effort. I mean, it's a small like team that just does maintenance, but we we still would like to help doing that >> whenever that's available. >> That's going to be quite difficult to do because uh binary trees don't package any proofs with them. Uh it's supposed to be a stepping stone for uh for ZK proofs. So as long as we don't have uh working ZK proof execution, I mean we we could build this, but I think it's a bit too much of a step for a for a first

test net with with binary trees. Uh I don't think this is going to be possible to uh to do this unless we find a way to generate proofs and uh and forward them to you so that you can like I mean miracle proof so that you can uh you can execute them. But I would say uh that's probably a distraction at the moment. >> Okay. Yeah. Yeah. Yeah. We definitely don't mean to distract. So what we could do is what we have done in the past is uh just stateless execution without proof verification. So at least we could you know validate state changes and things like that without obviously it wouldn't be a secured client. But uh in the past there were you know we were able to help the efforts by just executing the blocks without verifying them.

>> So if that's helpful we can do it but if it's not we're not going to bother. Yeah, that's I don't think that's going to be possible because we also don't have any witness. Uh so if we're rebate on top of BALS, we could do this, but that's yet another rebase that on on a piece of uh of code that is still in active development, at least in G. The BAL is still being reviewed. And as far as I know, I could be wrong, but my my understanding of the situation as of last Tuesday, uh, is that guest is really the only EL to have an implementation of of block access list.

>> Uh, could be wrong, but that's my understanding. >> Uh, so as long as we don't have that, we can't even do stateless execution without um without uh yeah, like without checking for the proof. So >> yeah, I think that's not going to fly. I mean, like I said, we can think of something either do ZTA proof execution or or rebase on top of the ALS later, but I would say for this test net, uh uh yeah, uh I would focus on writing the the curtosis package, get BU to work, see if we can get guests to work on that as well. Uh and if we get all that, that would be pretty pretty good already.

>> Yeah. So that that's good to know. So then the the upcoming test net is not going to have execution witnesses and is not going to have like any kind of proofs but it's going to have binary tree structure. That's all. Right. >> Exa Exactly. >> Good. Yeah, that's relevant. I wasn't aware of that. So perfect. Uh any other team uh or client updates? Right. Looks like we're good on that front. I'll proceed with uh number two of the agenda. I linked the agenda by the way on the in call messages if you guys want to consult it. But number two is updates on binary tree uh t cell fixtures consumption progress. This is

Agenda Item 2: Updates on binary tree fixtures consumption progress

from Carlos. >> Yeah, thank you. So uh at the point we are at um most of the things that are not passing are just related to state defs uh which we currently don't support. So I'm not sure what's the best way to proceed now uh and what we want or what we don't want. One of the clearest things that we need from um the testing perspective is we need to heavily uh rebase or I mean start a new branch basically the main vertical uh branch from east uh which is currently stuck at I don't remember what fork well

the fork name is vertical but I mean I'm not sure which one it is in reality behind the scenes uh but it's certainly not even close to to Prague. Uh >> it's it's promising like it's only two forks down but yeah significant changes happen. >> Yeah. So uh this is one of the things that we need to do but I know east is migrating to uh eels I think I mean sorry there's just too much names but uh I mean they are migrating the their codebase so I'm not sure how this will end up and I think Mario is here so maybe we can briefly discuss this because I'm not sure if the code base will change significantly but if it does

we have a problem because all of the vertical stuff is fairly fragile. And if we move it, we we risk like a much much deeper refactor than we anticipated. >> I I honestly have no idea how much how much work is in the vertical uh branch to be honest. Uh but I I assume it's like way out of date to be reusable even maybe it's better to start from scratch. I I think we need an input from someone from the team that has worked on this branch and I think that Spencer >> is not in this call um today but I'm I'm not sure do you guys have any idea of how what what were the changes in this this branch? Um

>> yeah I mean I can't give you the exact uh code changes that this corresponds to but I can roughly explain what uh what this did. Uh, and yeah, uh, the the one that worked, uh, so Spencer was the main guy on this, but Dan also also worked a bit on that. Uh, sorry for the noise. I hope it's not too loud. Um, the so the things that did change is uh we changed the way we input data. So normally when you when you have the the block transition uh test, you get an alloc, right? like like we do for genesis alloc uh which is a bunch of account storage code etc etc and you

output also an alloc uh so you get sorry you get an alloc as input which is the pre-state and also the block or at least some description of what transactions need to go inside the block uh and then the output you get uh another alloc which is the post state this can no longer work in in vertical or binary tree because the tree is unified and uh there's a consistent hashing uh technique. Uh but because they're not in the same tree, sorry, because everything is is in the same tree, you you have no app priori knowledge of what is an account and what is a storage slot. Uh you can guess most of the time, but you you can't go around the fact that there

could be an account that looks like uh sorry, a storage um some storage area that looks a lot like an account. So yeah ultimately you can't do this. So what they did was to create a new an extra an extra field in the pre uh structure uh where you you have the alloc but you also have the list of key value stores um that uh that you would be using to reconstruct the the vertical tree or today the binary tree and then you would output two things. you would output the the alloc again but it's empty because we we know nothing of the uh of the MPT and then uh we you would also output the

the vertical tree or the binary tree now uh which is just a list of key values um because vertical had a very weird uh way of computing its keys that was really heavily that was mass heavy um you needed to uh to call back into guest uh to ask guest to to do the computation like the tree computation sorry the key computation for you. Uh that is no longer necessary because uh if I remember correctly we use SHA 256 now.

So the key computation could be implemented in ES or in or in uh steel. Um so so there would be a great deal of simplification the but you still need to have this uh dual input dual output system and from what I understand this is the only thing that really needs to be uh brought over and then of course there's all the test definitions that Ignasio did but I assume this would be uh this would be automatic like you define a new fork you say those tests are active at this fork and Uh, and yeah. Uh, yeah, that's pretty much what I remember.

>> That that that is okay. Um, thanks. Uh, so I think it sounds like the changes are localized. I I got a I got a feeling I know where they might be. So I think my recommendation would be that we wait until the weld is finished. We're pushing for it to be finished uh this month. Um so one of the advantages is that we can create a berkel branch over there and then we can do all the changes in eels and then we can bring east into there and just automatically create the tests and from I think it will be a lot of work to pick apart the changes from the branch in burl but I think it's still doable but I think we should only do it once and only do it once we have

Future Steps and Python Implementation

uh welded into eels Um, >> yeah. So, just to ask it. >> Yeah. >> Sorry. Go ahead. >> I was just going to say I I completely agree with Mario. The only question that I um that I had uh at at this point is uh mostly related um with all of the feature system and not only that but uh mainly also focused on I'm not sure if your new uh code base has its own uh like virtual machine uh written in Python or something like that. At least that that's what I understood. Maybe I

I'm completely wrong, but if that is the case, >> uh does this mean that we will need to implement the EIP in Python in your codebase such that then we can do all of the backporting because now G is responsible right for creating the fixtures and then consuming them and we can share across clients. Uh but we only take care of the implementation in G. But if I understand correctly now, we will need to implement it both in well in G it already is but we will need to port it to Python, right? Yeah, that's that's that's entire point of the world. So the the thing is that uh this thing is so yeah that you you would need to do that even if you are if even if even before the world you still need to do

this because we rely on eels as the canonical implementation. So for the EIP to progress you still need to do this Python implementation anyway. So um I think it shouldn't be that hard. Um, and what's going to allow us is to just create fixtures more easily and be like uh be able to fix the spec if there's any like issues in the spec and go back and forth in rapidly iteration of tests more efficiently. So I think in in general that's a good thing but just to come back to the first point I think yeah that's the case you need to implement this in Python ins um but we can assist you on that if that's if if that's the the main issue.

Uh so some information uh back in the day Ignasio did do an implementation uh a Python implementation of uh his his IP in uh not in EELS but in Python. So uh we already have something and back in the day uh G and like there was a bunch of test vectors that were not uh made with eels uh but GU uh the sorry the Go implementation outside of GU would find exactly the same outputs as uh as Python. So as far as I know they are fairly compatible. Now like Carlos said we did fix a few things. So maybe we we broke compatibility at this point, but

uh overall uh it's just a matter of finding where that library was and bring it into into ES uh which um yeah might uh might not be that hard. We shall see. Um the only thing that we need to handle in Eels is how to be able to have a different kind of tree. Uh maybe a different kind of account model. So it might be involved. Yes, if you uh if you can help that would be great. Uh I have another thing. Oh yeah, so one one piece of detail I did uh forget to mention before is that even uh when we created that branch the the incentive was strong or the suggestion was strong to start

using eels but we didn't do this once again because of the of the all the cryptography that was that was difficult to to implement in Python. Um so we were doing guess we were using guess as a filler. Uh if we can uh delete some of that code inside guess that guess is no longer expected to be a filler. That would simplify uh I'm not sure actually how much code is uh specific to the filling. Uh probably none actually. Uh but if we could find some more code to delete that would be that would be very nice.

EELS Branch Development Challenges

So yeah, thanks. I I think given the well situation, I think what we can start working on um is the eels branch for this. I but the main problem I think is that no one in team at the moment is like super familiar with binary trees. So it would require input from you guys to help us out with implementation. um is as I I did I understand correctly that this does not require any new cryptography primitives because that simplifies the >> uh indeed >> I mean it requires new cryptography primitives in the sense that we use chat 56 instead of ketch but uh it's not new in the sense that it's not something

impossible to find uh as a python Okay. All right. Um, let me bring this back to the team. I think the main focus that we have right now on eels is block level access list. Um but if we can coordinate starting a fork sorry a branch in in eels um we can we can work on that and then once the world is done we can just bring the tests in and then it become it it will become a little bit simpler to work on the specs and tests. So I think it's the the main um thing to do is the is

the branch at this point >> um tests. >> Yeah. Uh I just realized all of a sudden because uh I happen to be the first external contributor to EELS and back in the day uh when you wanted to implement a fork you just copied everything and you just made your changes in the in the copy which makes sense for uh you know what Eels is is designed for. But uh the problem is if you start doing this as a uh fork that is going to move cuz it's not going to be scheduled you know next or even two uh two forks down. Uh how do we how do we maintain it long term?

>> So the team is like very aware of this like process. So this this has been like I think it has been routine. So basically they take the changes the commits in cherry pick and move them over to the new fork. But this is something that I I don't think you should like worry about just now. You should just start working on top of Osaka which is like fairly stable and or were you guys planning on starting on top of Amster because that's a moving target. So I would recommend just we just start in Osaka and then when the time comes and balis list becomes more more stable we can move over and cherry pick the commits on top of on top of Amsterdam. Uh the demo already knows how to do this. It's not a

problem but yeah just to get things moving I think we should implement this on top of Amsterdam in my opinion. Yeah. >> Um wait uh because you say you're going to cherry pick the comments but they're going to be against the wrong type of files right? >> Yeah. Yeah. Yeah. Yeah. That's right. I mean it's not as simple as like uh copy pasting but it's like this has been done before so I don't think it's it's going to be it's going to be an issue. Yeah. >> Okay. Well I guess we we'll find out uh when we start implementing heels. So uh I guess uh to close that topic I mean at least as far as I'm concerned uh is where uh where do we start? We start uh no you you guys are going to start working on eels and we help you. Is that

is that the the plan? >> So I think we're like packed right now uh with uh issues to resolve on the weld and also on access list. So it's going to be very very hard for us to start this week or even the next one. >> Uh if you if you if you can start I mean that would be ideal. Um I think the only thing that you have to do is just create a new branch forks maybe. Uh let me see what what do the name um it doesn't matter the name right we we can we can basically start a branch in any of your forks of your forks of the repo and I think that would be a a very nice start yeah >> okay and uh when this happens uh right sorry the the question is what about

weld is that going to impact uh eels like if we if we start working on eels uh is that going to is is weld going to introduce just a ton of changes. >> Yes. So basically what's going to happen is that every branch on eels is now going to have the the entire set of tests. So basically the the goal of this thing is that we um we have a single model repo that contains both the specs and the tests. And the key part of improvement is that when you're working on the specs, you now can immediately run the tests without like having to go into another repository, reference your branch or reference your fork or whatever. You can simply just run the

the tests as if they were unit tests and then you can get all the coverage that you need. So this will help you in guys in the end. when the time comes that we do the weld uh the branch that you guys are working on will be out of sync with the without with all the tests but we can do that work for you. So we can once once you guys have the the branch the the binary tries branch we can come in just plug plug the world changes and it should be like seamless for you. Um so that's why I'm I'm suggesting that we start with the uh with the spec implementation in Python in yields so we can let later just come and plug in the world changes into that branch and we can continue the work and now you will also have the tests in there. Um does

that make sense? >> Yep. Absolutely. Thank you. >> Nice. I think that closes the topic. Thanks everyone. Um that's for point number two. Uh next in line on the agenda is uh number three. So discussion on basic data included in the tree by Carlos. >> Yeah, I added that uh as a reminder uh which gam asked for. we were uh I mean I don't recall the exact details but we were discussing about uh the basic data and the structure that uh basically an account had when it was laying down uh

Discussion on Basic Data in Tree Structure

sorry a contract had when it was laying down within the tree. uh and Guiam basically noticed that uh now it maybe doesn't make sense to have uh like let's say quick access between quotes to the to the first uh to the first let's say leaves uh of the contract storage uh in an upper layer uh and it will have it will simplify let's say decently the spec uh and the understanding of the binary tree structure Uh and basically there was this uh I wanted to basically discuss whether we remove this or not. Uh may I mean since

Kharim is not here uh maybe uh maybe this is not the best day but I don't know maybe Thomas has uh some insights or whatever. Um, so yeah, if Thomas is not asking questions immediately, I I do have one. I don't remember the context. Could you could you uh reexlain like we want to get rid of basic data? That kind of rings a bell, but at the same time, I don't remember the rational. The rationale is uh we had uh we had all of these uh set of leaves uh that lay together in the

same level uh such that you can access the first uh bites uh of the of the contract storage. uh and I'm not sure which was the exact uh discussion we were having but we we we basically said that it would be better to just get rid of this thing uh because it was providing no no upside uh and it was bringing complexity uh from the other side. I can revisit that and we can discuss it on the next meeting if it's better uh because I I don't remember to be honest. Yeah, I'm not sure I get it either because basic data is just a we've compressed like four fields into a a single field like uh I can't recall

exactly which one like version code size nons and balance I think and then there's the are you referring to like the 64 or 128 initial storage slots that we put into that first sleeve? So that's a different thing than basic data. >> Yep. Yep. Yep. You're you're right. But it's this one. Okay. So, you're referring to store the the first 128 storage slots that are stored into the initial leave. You would push them to another leave completely, right?

>> Yeah. I think the goal was just to not have like to not duplicate them or not have them uh treated let's say specially or whatever. >> Yeah. Exactly. Now I now I remember but indeed like communication got garbbled a bit which is why I was confused for a sec. Uh there there's the code right. Uh we we have the concept of uh uh right now the code is dduplicated in um in uh like you create a contract that already exists. Uh it's stored at a single location in the database. So you don't have to uh you don't have to store it twice. But if uh in the current model proposed for vertical trees and that binary trees inherit uh because you have this account uh like this header group

where you you do have the basic data you have the first 64 slot and you have the first 128 chunks. Uh if you've write the same control multi uh the same code multiple times you are going to duplicate at least the first 128 uh uh 28 leaves. And because the the code uh you use some offset but you also use the address actually you will duplicate all of the code. So what we wanted to do actually is to say but there was already something suggested by Ignasio a few months back. What we would do is only like forget the address part and only hash the code hash or or something similar. uh so that the code is again

dduplicated because uh for vertical trees like vertical was saving a lot of space but because of the code duplication a lot of the space it could have saved on top of that was actually uh wasted and you know it would be a good idea in spite of the potential savings because you only have to load one uh one header group to to execute the first 128 uh leaves Um it would be a good idea to actually put the code separately so that it's dduplicated if you need uh if you need it uh like if you deploy it twice.

Okay, that's fair enough. So we're to be clear we're talking about the code chunks strictly. No no no storage and no basic data just the code chunks. It would be entirely independent of the basic account leaf and therefore they could be pointed to by multiple accounts. >> Exactly. And potentially we could also move more storage inside the header account but yeah um I am I guess we need to think that a bit more thoroughly first. >> Yeah. Yeah. Fair enough. Okay, cool. That makes sense. Uh, are we moving that discussion to maybe people can do a bit more research or thinking about this because it seems like more of a new proposal that we've just clarified

>> unless someone wants to chime in >> or you going to say something Guiam or Thomas? I think it was a Yam that was going to say something, but you got muted. >> Uh yeah, no, but I was just uh I mean, yeah, I I agree. We should maybe give more uh more time to people to consider it. Uh but yeah, that that's all I was going to say.

>> Okay, good. So, that's going to bookmark that for the next discussion or further discussion. Um I'll move on to step four of the agenda. Uh then uh Carlos again it's uh bloatnet >> Yeah. Uh so on that side of things uh things are going pretty nice. Uh we finally got unblocked uh on merging PRs to east. Uh thank you Mario and Louis uh for that. Uh we also submitted some fixes uh especially on the stop contract uh side of things and on the benchmarking one. Uh the situation now is we have uh pretty

Bloatnet Updates and Benchmarking Challenges

much all of the multiop code tests we are interested on. Uh we have implemented at least the most serious or directly related single up code tests uh related to scaling L1. So basically uh s store uh onto the biggest uh ERC20 contracts uh and s load uh into empty or most likely empty uh storage slots also in the biggest contracts. Uh so now the the goal is to see those PRs merged and see how do we integrate that together with Camille's uh tool from Nethermine.

I don't want to bring a lot of discussion here because tomorrow we will have a call about that between all of the parties that are uh related to this uh but it's basically just say that uh there's a lot of work done but might have to be completely refactored depending on on what happens here because we have east then we have the benchmark from Camille uh the benchmarking tool from Camille and then we have all of the stuff that we are putting on the top of east and So those three pieces need to like puzzle up correctly together and it's not clear at all that this is going to be the case or not because no one has seen uh much of Camille's tool yet. So for instance stop

contracts cannot be specified u between different tests which is a major issue in my opinion because it defeats the purpose of having a stop contracts as a feature basically. Um but yeah that's sort to say that uh this is this is where we are at uh benchmarking wise and so on the other side which is syncing tests uh we've had uh great great help from uh party and uh we have actually seen ref uh and start interacting with us a lot more. uh it seems they are working on debugging uh their main issues that they have in this case ref uh with syncing their client uh and all

of the pinninging issues related uh to that. So so far we have run like five or six uh benchmark runs and they haven't been able to log into a single pin at any point. Uh so they are trying to debug what is going on and hopefully we will get uh we will get them on board. uh yet to see yet to be seen what happens with uh Argon although they seem to have someone that it's fulltime now working on this or at least that's his main goal uh so yeah I will update as soon as we have some progress and hopefully we will have the five clients soon so that we can benchmark uh or run all of the benchmarks uh for all of them because otherwise I will need to get back whenever a client is ready and I

rerun the benchmarks again uh and considering how heavy the the snapshots are and everything I I prefer to just not need to do that, let's say. So, so yeah, that's the the deal for glob. >> Cool. Nice. Uh any comments or uh additional thoughts on that before we move to the next point? Sounds like we're good. All right. The next one is uh from Han. Uh findings on post EIP6780 self-destructs.

Findings on Post EIP6780 Self-Destructs

>> Yeah. Um just let me share screen quickly. Right. So um it's going to be a quick one. So as part of um the initiatives on continuing the state analysis so um I I guess on the side of the expire as well um so we wanted to find find whether there's a group of state that we can like remove or expire without much consequences or like people just don't care and one of them could be self-destructs. So um that's why we wanted to um like analyze um like um the self-destructed contracts. So um the findings are pretty interesting. I mean

not very interesting but um it's pretty straightforward. So this um this is the self-destruct count based on the network upgrade from Genesis to um some blocks um up until I think block 23 million. So um yeah we we I guess we only care about uh Denkun like post tankun but just just as a quick revisit on what has happened in the history. So um so the first one I mean you can see that there's like um a huge increase in during the dow fork which is block 1.9 million to 2.46 millionish. So this is the uh infamous do attack. basically people at at that time like there's a US

attack on empty accounts and I guess it it um like gaff nodes at that time sort of got um uh like like out of out of memory if I'm mistaken. So yeah, that's that's uh one attack um done using And then moving forward, we have the I guess this period is the gas token arbitrage period where people um like when the gas price is low, then they would um store stuff and when the gas price is high, then they would self-destruct and get the refunds. So um yeah this should be the period and then uh once the some of the EIPs got um got included in London fork then we don't

really see those stuff happening anymore and then finally um I guess what we are looking at right now is the um post EIP 6780 which is activated in Tangquin. So um as a quick uh right reminder so after this EIP got activated if uh an account is self-destructed and created within the same transaction then it won't appear like it it won't be added to the state try um but if it's if it's not the case then the account won't get self-destructed like it it will still remain in the account try. So um those are I guess my intuition is that they are mostly garbage but it I could be

wrong. There could be some users that are um calling self-destruct but then still using the contracts. But uh anyhow so if you look at post that self-destructs um they are up until right now there are about 2.7 million of them. They are um self-destructed they are not deleted from the state tribe and in total um in terms of storage slots is about 380,000. So all in all it's 1% of the total accounts and 0.03% of the total storage slots. So if we can find a proposal or find a solution that removes the self-destructed accounts um given that like users are okay with it or the

communities are okay with it. Um it doesn't yield that much of a outcome in terms of like stay aspiring. So yeah, there could be other things that we can find out, but um here's just a finding that we get for now. So yeah, so that's pretty much it for the quick sharing. Uh I have a quick question regarding this last slide. Uh okay, so that's 2.7 million which indeed is nothing compared to the if I remember correctly about 200 million accounts. Uh but um this being said, what is the rate at which those contracts self-destruct uh you know get created and then someone tries to self-destruct them? Is there um

is there a waning in in the frequency like you know is is the bulk of those 2.77 million uh just like in the first month after then or is it kind of constant and we can expect more contracts to get created with the expectation they would be self-destructed but uh do not >> okay >> um I don't have the data on top of my mind right now but when I was collecting I do recall that due I think the first few hundred,000 blocks which is I guess six few few monthsish after Bangkok was activated there were a lot of self-destructed accounts like self self-destructing unique accounts and then um towards like I guess spectra the uh the number of accounts that got

self-destructed was like slowly decreasing uh but yeah that that's just what what I noticed but I should get the accurate data and I guess in regards to frequency um again I don't have the data right now but um from what I like again from when I was gathering data I so I don't notice a lot of um like self-destruct um counts right because this one is based on wait sorry this one is based on self-destruct counts but um in terms of unique uh in terms of unique accounts is about 2.7 million so maybe there are some overlapping self-destructs that that's calling the same account again and again

but I would say that the frequency is very low like maybe less than five times per account on average let's say but again this is just uh uh an intuition there but yeah >> yeah I mean I I understand and you're you're probably correct not to not to really care about uh what you say we we shouldn't care uh I'm just saying you know what what triggers my question is because we also have this idea that in veral that we would not delete uh zero zero storage slots. And if we do this, uh it doesn't look like much every time at every block, but it accumulates. And Gary did uh did did some prediction and says, well, after a while, uh it's going

to be uh it's going to be pretty bad. Uh so u so yeah, maybe maybe you know, if that thing keeps coming at a at a high enough rate, we it might still be worth uh deleting those accounts. Uh but yeah um no nothing seems to indicate this uh so far uh it's just it might be worth to see to plot the the rate to see that it's indeed tending towards zero. Okay, I'll take note of that. Right. Okay. I think that's it from my side.

I'll pass it back to Gabri. >> Perfect. Thanks a lot. Um, all right. We're at the last point of our agenda. We're right on time. Uh, the last one is from Guiam. Uh, it's about, uh, modernizing east fixtures for Virgo that currently sit on their separate run, >> right? So, so what I meant is pretty much redundant with the agenda item we already got by Carlos. So, miscommunication again. Uh this being said uh I think there's a need to revisit the fixture themselves and the test Ignasio wrote to uh to see if we uh if we want to keep everything like for example do we want to keep 4762? Yes. Uh

Modernizing Ethereum Fixtures for Verkle

do we want to keep the test for uh for the state diffs? Probably not. Uh yeah. So I'm just uh I'm just sharing that that thought. Maybe someone has a comment on this. I mean if if we don't keep uh at least all of the state div staff uh we can already share with Kharim uh all of the fixtures that we are generating and we can start comparing the implementations. If we if we want to aim for state divs then this will take this will take quite some time.

>> Okay. Okay. So just to be clear the state diffs are the only thing that do not uh that that are preventing us from shipping that PR on for guest right. So state divs is now from the 500 and something tests uh we are passing more than half then almost half of it is state divs and then we have like let's say five to 10 remaining that I need to that I need to look at but we we should be like almost almost ready if we exclude uh state tests state tests sorry >> right and and presumably If we do that rebaseline. Oh yeah, but we need So yeah, okay. We still need to be able to

Testing Challenges and Solutions

provide Karen with some uh some test feelings uh >> because that's independent, right? Like at least they can they can check uh what it's failing with our pictures and what not and we can put the two implementations in common and make sure that there are no failures on any of them or spot box or whatever it is. >> Right. Yeah. Okay. So I think that's prime candidates. Uh and do you remember the other test like what the the other test that we're feeling were about? >> Uh I think there was something related to persistence. Uh so like uh if we when we were doing tests that were lasting for

more than one block then we were having issues like nonsense or stuff like that. Uh this one I think it's uh related to some bug that I I was trying to like catch. I I I mean I can fix it but I don't want to fix it on the way I did because I just as I show you I think I reimplemented most of the most of the machinery let's say that was already in place to do that. So I just need to take the time to to debug that but yeah I haven't had it. Yes. Yeah.

Okay. That that's fine. Thank you for doing that. It's it's really not a fun funny IP. Uh sorry, a fun PR. Um yeah. Okay. No, I think uh most of it should remain, but uh at least we can delete those state diffs and that's already one thing that's going to simplify the rebates anyway. Uh so might as well delete it now. Uh, another thing that I was thinking, I mean, okay, no, we're close enough to generating the fixtures and consuming them that uh that I guess that's the the best course of action.

Um, okay, cool. Well, that's pretty much uh it for the topic, I think. >> Uh, I had one quick question for Mario. Uh Mario, does it make sense uh in the new uh repo to start working on the binary tree porting? Uh like it's a it's a re really self-contained uh thing. Uh so I'm not sure if this is work that we can like advance already uh or you prefer to put it on hold uh until No, I think I think this is a good idea. we can proceed with that with the binary tree implementation and then we can uh implement it in a in a branch in eels.

Discussion on Binary Tree Implementation

So were you were you thinking of doing it directly in eels or were you thinking of doing it in another repository and then bringing it to eels or >> I mean you haven't decided >> I I don't have any opinion I would say whatever you guys tell me I will I will do like you are the ones that that guide this thing so I will adapt to whatever works best. So yeah, yeah, feel free to create a a branch in eels directly if that's easier for you. Uh if you if you can do that, that's even better because we can just rebase and then bring the the weld into into that branch. So yeah.

Okay. Uh I mean I will contact you offline probably because it would be helpful to know like where should I start uh looking to implement that like codebase wise because I haven't even looked at it. Uh so yeah if if someone from your team or you whoever can like dedicate me 15 minutes that would be that would be really nice. >> Absolutely. All right. >> Thank you. >> Good. So I think that settles it for this call unless someone has another comment or question. Uh otherwise we we're good. I'll I'll write a summary of this call and we'll do a tweet tweet thread later this week.

Uh any closing remarks? Otherwise, I'll just uh end this slightly early. All right, looks like we're good. Thanks everyone. We ran through that agenda pretty quickly for the hour. That's uh it's good. Good job everyone. And uh yeah, talk to you all in uh two weeks. Bye. Bye. >> Cheers. Thanks. Bye. Right.