Stateless Implementers Call #34

Transcript

Okay. Uh let's start with the call. Uh this is stateless implementers call number 34. Uh I will share the agenda in the chat. So as a brief summary of today's agenda, first we have team updates as usual. Uh then we have two 7612 items regarding code conversion and 7702 implications. Uh then we have two 7748 uh discussions around empty accounts and um the position of the tree conversion

logic in the block execution. And finally uh 4762 uh point that I wanted to raise regarding field costs um constant. So yeah uh as today is a holiday so uh maybe not everyone is here let's try to simply make progress on the agenda items and if we feel we would like to rediscuss again in the next sele on some particular point we can do that so yeah let's start with team updates um I can start So I worked on publishing some um

metrics gathering that I did for mainet regarding potential new trees. This is now in the in the um stateless book. Uh in particular I will share the link to this page. Uh then I also uh started working on some kind of new witness explorer that we have in DevNet but for mainet uh this is still work in progress and while doing that I also gather some potentially interesting metrics and publish them in some other place. Uh so I will share that in the chat too if

anyone is interested. uh won't discuss much about that. Uh but yeah, I think it might be interesting for other people. Um what else? Yeah, so I'm working also on um a document that explains a bit this by code chunking problem that is kind of already proposed in 6800. Um but um yeah I want to on board more people in the discussion on different approaches to do that because there are other strategies with different

trade-offs. So this document is currently un under reviewed and probably will be published in the next days. And finally, I worked to on um another page for the book uh for the 32 byte gold chunker uh that is still under review. So yeah, hopefully will be published in the next few days. So yeah, that's everything for me. I can go next with the Ethereum JavaScript. Um, so we've made some pro progress, although not as much as we anticipated last time because we were still in the like the the the yearly

release phase where we prioritize like the the the urgent stuff rather than the research stuff. But uh I was doing some work yesterday and today on the transition state manager askked some question in and the matrix we are going to be uh we're going to start you know running these tests this week. So, I'll be able to provide some uh feedback uh this week in the matrix chat. Uh we're going to start with the unmodified accounts. Try to run run that and see if our client is able to handle that. And then we'll run the modified accounts and and see if we can help there.

I guess I'll go. Um, yeah, I was working on uh integrating the uh transition code back into G. Um, we had a review. Um, we started breaking things into smaller pieces. So, I started uh coding every one of those pieces. None of them have been merged yet, of course, but that's okay. That's part of the guest process. No, no worries there. Um and uh yeah I don't exactly recall everything I was doing but one one thing of note it's a page that has been published in the book uh that explains how to run a like get in dev mode to produce blocks. Um so if you

want to test something in particular or for example if you want to test the the conversion um that's a pretty useful tool to see because otherwise the when we want to do a shadow fork you have to run everything in curtosis and it's extremely hard to debug. So if you're ever interested in figuring out how the shadow fork happens you can use the what what we call the dev mode where blocks are produced every 5 seconds. you can spam with whatever tool you want to add transactions that would target things you you want to break. Um, but yeah, so now it's explained if you want to do this. It's still not guest master uh because yeah,

I'm still working on the on merging all that in, but um I think it's a pretty useful tool for everyone. Um Oh, right. And I was also started on the 7702 and I was hoping we would talk about this, but if Karim doesn't show up, probably not. I mean, we we can still have the the conversation, but uh yeah, uh that's that's uh more or less what I've done so far. Uh I think I can go next. So I don't have any significant updates. uh still working on making uh like already made the changes and transition that we discussed the last thick call and after on the chat as well. Uh now all the tests are passing and apart from them

still working but still working on merging uh the workbased work branch with the petra changes. Yeah. Anyone else want to share an update? Okay.

So the first item in the agenda is a followup on this discussion we had in the previous call uh regarding if when touching an account in the overlay tree um uh if it is possible to convert the code uh which is something that today is not really defined. I mean today in the current EIP whenever um an account is touched we only convert the accounts data but not the code uh because the code is expected to be migrated um on the tree conversion EIP.

So we had some discussions uh in the previous call regarding implications of actually doing this called conversion whenever the the account is touched and we had a chat um regarding two main things. One of them was implications on the witness size uh but also implications on potential worst case scenarios regarding um this creating too many rights in the block.

So um in the previous call we decided that we have to double check some calculations uh on this and I think that Giam uh did that and we concluded that probably is too too much load. I know if you want to mention something about this. So yeah, I actually made a presentation. Uh if I can find my window as always, it's uh uh the code conversion, right? So that should be it.

Yes. Um so I don't know if you guys can see my screen. It's not it's not the most succinct uh title presentation title ever, but um yeah. So okay, Enas, you already covered that. We want to know if when you've write to uh an account before it has been covered by the iterator, it has been translated by the iterator sweep um what do you do? So if it's the account itself like the balance and the code hash they get translated um what the question is what about the code? So I was uh of the opinion that we should not convert the code but we had real um data about this. So we did the

computation um and the assumption of course is that we use a 30 36 million gas block and the current um bound of 24 kilobyte for for the code size which mind you is uh under a lot of pressure to to be increased. Um and that means that for a given uh um a given sorry oh my my calculation okay my math is correct but my formula is wrong um no actually it's correct yeah it's two two to the^ 10 um we uh we get for a 24 kilobyte uh chunk will be translated to what will correspond to uh sorry a 24 kilobyte

code will be broken into 379 93 31 byt chunks. Now per se that's already like if we have a a stride an iterator stride of 10k we're that's seven okay almost 8%. Um but in the worst case you could just send one Y one way to many accounts that already have 24 kilobytes. Um and that gives you a number of the extra number of leaves which is 1.3 million about 1.3 million.

Um, this is a lot because I mean it's many many times the any any stride we were considering like we were looking at 20K 20 20,000 leaves maybe 50,000 leaves but definitely not 1.3 million. So that would make uh the would be way too much for for the conversion. So um yeah, that's I think that's basically a showstopper. uh we could try I mean there's no way we're going to be able to convert uh uh 1.3 million leaves but even in cases where you just double the size of the conversion um it's not going to be very easy to to uh to work around it like I think later in the agenda you have the

question of whether the conversion should happen before or after executing on the leaves but if it's happening before you find yourself with already 10,000 leaves 1 1.3 million leaves And then you still have to I mean you can still do decide not to do the the iterator sweep but it's already too late basically. Uh so my view hasn't changed. We should not convert the code. Uh I did talk to Karim and Tanish uh yeah in in DMs for about this. I think everybody agrees that we should not convert the code. Um yeah the question is anybody is anybody else desenting. I guess not. Um well in that

case I I guess that's the that's the end of it. Um there's another question that's I think has been uh presented last time uh but we more or less agreed that if you only write a slot you should not translate the account and um I did uh look into it and I think it's possible so I I'm of the opinion that uh and I think I was the only one against it uh that we should not convert the account if only the storage route is translated.

Um I am yet to do um to validate it you know in a in a live test net but from what I can say uh I was the only one against it and I changed my mind or at least I agree it's doable so I will uh I think we should we should do it this way. Um yeah that's it. Cool. Uh I just have a like a brief question. Can you share again these slides because I think that the first slide actually had a formula that wasn't correct. Uh that's definitely possible because I just left it 15 minutes before this call. Um let me find it again. Uh here it is.

Um right now is that the one? Yes, that's the one you Yeah, that one. I think I think there you wanted to do 24K over 31, right? Uh oh. times 31. Of course. Yeah, that's missing. Absolutely. Okay. Yeah. I mean the result this result is correct. It's just that I uh Yes. Yeah. I I did that from memory. So it's still Yeah. Cool. Okay. Uh so as a summary of this discussion uh we won't convert the call whenever an account is touched and in the case that only a storage slot in an account is changed um we won't u migrate the accounts data.

So okay that's our good conclusions. So okay the next item in the agenda is a bit related to all this which is how 7702 uh also is related to this discussion. Uh and as a bit of context um yeah let let's imagine the following situation. there is a 7702 transaction which contains an authorization from let's say account A to set up the code uh to some other contract B right so in this situation whenever this transaction gets executed accounts A code will have a delegation

to some other contract B and technically speaking this is touching account a only for setting the call uh to have a delegation. So the question is um how to handle this correctly in the in the case that we have the overlay tree and the conversion hasn't started. Um so yeah that's kind of the the setup of the discussion. I don't know if anyone has any particular comments but from my perspective it seems like um yeah like 7702 like creates a new situation on the chain in which you can

mutate the code uh which is something that we didn't have before um for existing accounts so I think that's like an interesting case that's yeah we should clarify in the spec I mean it looks like if we don't convert anything to the new tree that means that the MPT isn't frozen because you have to write that somewhere. Uh but from our perspective we just decided that at least up to now we wouldn't like do any kind of code conversion in the overlay tree fork. So uh maybe this might be an exception. I know what other people think.

Uh so yeah, I'm I need some clarification here because I don't really see the problem in the sense that if you've write the code then um I mean that's not a code conversion per se. you're just writing the code and when you you're going to read uh and more importantly you're writing the code hash the the account itself gets updated um because yeah unlike the the root hash this will not uh okay yeah I mean uh Yam I see this but you I mean no chunkification of the code itself is uh is necessary but there will still be a chunk that only has 24 bytes um in it right uh okay depends on

the chunkification format um but okay yeah this is what I meant but you're right we don't need to break the code into more than one piece um but what I mean is that when we write that code uh we update the account so um so in effect the account is already translated now we have a problem in G that uh we when we to consume that when we get to the code the even if the code has already been uh written in the tree for whatever reason um we will just write like translate all the all the leaves and insert whatever

leave is not already present. So that gives rise to a very weird situation where the one code chunk with the conversion will sorry with the delegation will not be overwritten. Uh but actually I think what I'm describing is not even correct because in 7702 and I guess that's a question for whoever worked on that more more than I did. Um, in 7072, can you replace an existing code? I thought uh 772 was only for EOAs. So if that's the case, then you cannot replace existing code with a delegation.

Is that correct, you can't replace smart contracts, right? So then but but wait let me make a a comment here because I I think this is getting a bit in the rabbit hole before. Okay. So my my question is the following like we have a 7702 transaction which set ups a delegation for an existing EUA. Right. My question is should we write this delegation in the new tree or not? Yes. So this is like an exception to this previous discussion that we have in the previous agenda item right there's like a now there's like a case in which for an existing EOA we will do a kind of

code conversion. Oh okay I misunderstood. So you mean when we okay we have an existing delegation right and we did not uh but it hasn't been written uh like between the time the the iterators start sweeping and the moment this uh this thing gets converted uh we don't like it hasn't been written that's no right you're saying if I'm saying I'm saying I'm saying that we have the overlay tree and the conversion hasn't started Okay, we are in that case.

So we have a 72 transaction which writes uh this by code designation into an EUA. Yes. Okay. So this is like a situation in which you're writing code to an EUA that already exists. So in theory we should decide what to do about this. We should write this new designation in the new tree or or kind of what really? Yeah, I mean like the MPT is frozen and a lot of things rely on the fact it's frozen. So we need whatever we write to the tree, we need to write to the overlay tree. That's for sure. But then I don't really understand where the problem lies. No, it's not a problem.

It's just like a case in which it's the only case now that we will write code in the overlay tree situation like we just discussed that we wouldn't change we would do we wouldn't do call conversions right but I think that with 772 there's like the only case in which we will convert code in the overlay tree just like making that point more clear. Um okay I think I understand but just in okay u maybe Milos wants to speak first.

I mean if somebody just deploys a new contract we would write the contract with a new tree. How is this different than that case? Uh well that's like a new contract like it's like a new account. For that case it's fine but before 7702 for existing accounts uh we we didn't have any case in which we will convert existing code like this is just like a new situation of sense not sure like being able to add code to an account that already existed so it's but we would not be converting existing code right we would just be overwriting

the existing ing code with a new delegation. the old the old code would not be converted until um this let's see the old code would be potentially another existing delegation right the old code would be a potential existing delegation but it would when the iterator sweep happens it needs to check the destination tree to see if something is already there uh which it does but there's no there's no iteration sweep because I'm talking only about

before the tree conversion I'm always talking before the tree conversion only when the overlay tree is active is active okay right so if that's the case uh let me just uh yeah say it out loud uh right so you have an existing delegation and then between the moment the account starts Sorry. The the fork starts and the the sweep starts, you have a week in which a new delegation happens. I get you correctly, right? Yes. Yes. Okay. So then the delegation is written in a new tree in the overlay tree and then

u but the account itself um would be converted. That's true because I guess logically you override the code hash even though it's the same. Yeah, that's what's going to be my next question. It's like okay, seems pretty clear that the delegation should be written in new tree because the imp is frozen. Yeah, maybe we could only do that and not migrate the rest of the account data. Yeah, but I think that will be wrong, right?

Because the nons will change. So that's an indirect account data, right? So we should probably move everything. Oh, you burn the nons. Yeah. Yeah, that's fine. Yeah. So we we should probably Yeah. convert everything. End of story. Uh no, I think there's another case though. Uh it's when you replace it with a zero. Um because right you you are it's possible to delete the account. um to sorry the delete to set a code to zero by which it means uh it says you should uh then set the code hashback to empty code and then write a zero

um and I think this could be a problem because we want to make sure that if we read the delegation we stop at the zero and we don't we don't go back to the old tree to get a delegation that no longer exists. Um, I think it should work, but we have to double check that or at least I have to double check that. Uh, I think a similar thing happens. We discussed this before as well in uh s store as well because in worker like empty and zero are two different things. So I think there also

we discussed that we need a different mechanism to make sure that something is zero and something is empty are like two different cases. I mean that's the thing um that you're right that's the same conversation because if you write a zero then you are being returned a zero and that's the end of the story. uh like this is you can detect this but if we start doing like Gary wants to if we start doing deletions in vertical right okay so that's a global problem with the overlay tree we have to mark deletions like you said okay no I guess there's no problem yeah it should it should work as tested but it should

work so wait so if you try to remove an existing delegation You say that can be solved without supporting deletions in the tree. Like if you don't support deletions in the tree. Yes. Because when you look um okay, I'm going to do some guess internals and I'm sorry for that. But when you look at the transition tree, right, it first goes into the the vertical trees and sees if the return value is nil or zero. If it's nil, that means it's not there. It goes to the MPT. But if it's zero, it says it's zero. And then it returns zero which is what it should do. No, but I mean after

the conversion is done. So after the conversion is done uh you would have a zero but yeah it would be the same thing. So you will have like you you want a way to set that the bite code is not set not really that there is zero because it's not zero. It's not zero by bite codes right? It's more like there's no there's no delegation, right? There's no delegation, but the bite code uh sorry the code hash is still empty code and the code size will be zero. So you have a chunk yes which is uh filled with zeros if you will but

it's not like delegation is deactivated. So this is what you want. So it's actually setting the code size to zero basically. Oh yeah, it has to. Yeah. Um like like if I remember the spec correctly but yeah I guess Yam can uh can chime here. Um we uh when we have a delegation that is filled with zeros we've we've write that zero which in the MPT world means delete that that entry from the tree but in the vertical world or stateless world means uh we are just writing a zero in that leaf and then uh you have to set the account to back to being a regular

AOA and in the MPT world that just means set the the code hash to empty code hash like CD5 blah blah blah. Uh but in vertical world that would means um set it like set the code hash to empty code hash and set the code size to zero. Cool. Yeah, that makes sense to me. I don't know if anyone else has a comment about this topic or we should move to the next one. Okay. So before that I would say

that we should probably create a PR in the uh 7612 to clarify a bit more what's uh implications of 7702. I think that Gon was thinking about updating EIP to yeah considering general 77 or two implications. Um but yeah I think helping a bit more uh EIP readers on this case will be helpful. Um okay so the next item in the agenda uh is uh related to 7748 which is the tree conversion logic on how to handle uh

empty accounts. So a bit of context here. Um the way that 7748 works for empty accounts is just deciding that it won't convert them. Um because yeah that's these accounts uh had this rule that whenever today you touch them uh you are expected to remove them. So the tree conversion was an opportunity to just like avoid converting them because we want to remove them anyway. Uh and when I was writing the tests for uh the tree conversion some weeks ago, I realized that um yeah, I I've heard that these accounts do not exist

anymore in mainet already. Um so I started asking some people about this and yeah, I think some people were still arguing that some of these cases exists. Um but on Saturday I think I was talking uh with Hochem and he mentioned this uh EIP that I will share in the chat. Oh thank you. Um so it looks like from DCIP that all these cases were removed around block number 14 million or so.

Um so the question is if none of these cases exist in mainets can we like remove this rule from the tree conversion of not removing these cases because no cases should be found. Uh that's kind of the general question. Uh I know that um other people think that maybe this rule is better for other networks to apply this tree conversion because maybe these cases exist on other networks or maybe indefnets or something like that. But yeah, the only like my my ultimate intention is trying to see if we can simplify the tree conversion

logic a bit more by removing this rule if it's not really needed. Um, I know if anyone has a comment about this. Um, I have one. I was just hoping someone else would have one, too. Um, my uh my comment is that um I'm not sure we're talking about the same thing here. You know, Gary created that EIP uh 61 something 6110. I forgot. No, that's something else.

Um yeah, so he seems to think that those accounts still exist. Um I wonder if and at the same time the the AIP like when Peter Davies did this, oh sorry, Peter Miller now uh did this, he um created a transaction to actively delete them. But according to Gary, there's like uh 28 accounts and the conversion, sorry, the transaction that Peter Miller did uh has way many more accounts than this. Um so either Peter forgot some some of the accounts or we're not talking about the

same thing. And I think uh I've been trying to to get uh some more info from Gary, but I didn't get anything uh really conclusive. Um, so I think the the best way to do it would be to check, you know, a database of any archive node. Um, actually you don't even need an archive node. You just need a database. Um, and we could just check uh yeah, we could just check if those number sorry those accounts exist exists still. If they do, well, we keep the we keep the rule. If they don't uh we just say uh we just tell Gary that his IP is no longer useful and uh we close uh yeah

we we delete it. Is that the EIP that uh like empty account deprecation? Uh I didn't quit here. The IP that uh uh is this the EIP concerned with empty accounts deprecation? Just trying to find the EIP so I can refer it. Yeah, it's uh I can look for it. 7523, I think. 7523. No, 7610 is the one I'm talking about. 7610. Okay, thanks. This one.

Oops. Um, yeah. 7610. Honestly, uh, okay, that's weird. I can't copy the date the the link. Okay, done. Um, so it's a rever creation in case of non-MPT storage. Right. So, right. So, that's the thing. Uh, according to Gary, those accounts still exist. Yeah. Yam. Yeah. The the main topic here is also about like the empty accounts, right?

Because I think these accounts with storage in them, they also have a nons of nonzero, I think. Um, they have a nons of nonzero. Well, that would explain why they were not touched uh by Peter. So, yeah, that that would explain why that would confirm we're not talking about the same thing between Peter Miller's P EIP and uh and Gary's EIP. Um, okay. I guess We're we're a bit confused. I think we should just uh we should just uh look for those accounts and you know uh I can do it if no one else uh is passionate about this. But I guess right now we're just shooting in the dark. So let's uh

let's just look for it and and yeah come to a conclusion. Yeah. I I think also for the ecosystem itself, it would be very nice to to just know like are all these empty accounts deleted and though we have like this very weird case of um empty accounts. So that means uh zero balance, zero nons and the empty code hash but with uh storage in it. So like the non- empty uh storage hash that's that's also very interesting. So it would be very nice if we would all know that. It would be really great if that would be will be done. Yeah.

Cool. Yeah, let's confirm that and we can um try to reach some conclusion maybe in the next sele. Nice. Uh amazing. Um okay, the next item in the agenda is um the related also to the tree conversion which is the position of the tree conversion logic in the block execution. So why is this a topic of discussion? Uh so when I was creating the tests I realized that in the EIP we define that the tree conversion uh well let me double check this and I

will share the link in the chat 7748. So if I recall correctly, we defined that the state conversion happens before the transactions are executed. Um yeah, but when I was writing the tests, I saw that G implementation actually has this code this code after. But after thinking about that for a minute, I realized that the the actual position of the tree

conversion in the block execution doesn't matter because whatever right happens in this tree conversion um it has like a lower priority compared to any other right that might overlap in the transaction execution. So no matter if you do the three conversion before or after the transaction execution uh from a state root calculation than after it should be relevant. Um, so I think that we originally decided to put this before the transaction execution because we wanted to somehow hint that execution clients can actually do the

the tree conversion work before the actual block comes. Uh because this is like deterministic work that you can do even before knowing which transactions will happen. uh but this is also the case even if we decide to put this logic after the transaction execution. So I don't know if anyone has any thought about some other reason why the order or the position in the block execution matters or if you have any preference on on it.

I think you you you wanted to touch on this on some previous discussion but um does this go ahead. Yeah. So for 7748 I have not read this EIP completely but uh is there also like gas cost in them if you um write to state which is not yet converted in a transaction is it like more expensive or not or just the same same price is the same price. Okay then uh I don't have any point here. Yeah. Cool. Um yeah so I think my position has always been that you know it's practical to do the conversion after but ultimately we should move it before like in few when we get closer to to shipping

vertical on the test net oh no sorry on the mainet um and when I say vertical once again I mean stateless just have to lose the habit um but now there's the the idea of delayed root execution and I think it's actually playing or at least I get the feeling this is playing against it because uh if you do the conversion before you need to wait for someone to give you the block that you can build on top of and actually it's the same yeah it's completely yeah right because you would be uh you would have more time to do it anyway I guess yeah I I think it no

longer matters if we have delayed root execution. We can leave it after but if we don't have delayed root execution we would have to move it before. That's yeah that's my position but but but my question is like from a spec perspective the end result will be the same right? So you can like implementation level you can put it whenever you want. Yeah. Yeah. it would not make any difference uh because we when we do the conversion u if we do it before whatever is used in the block uh whatever is then written to in the block uh is uh like overrites what was uh written and if we do it after we have

this code that we go and check the tree to check that if we're converting something it hasn't already been translated and that needs to happen no matter what even if we put it before we still have to do the check. So it doesn't um Yeah, it doesn't matter really. It really makes no difference. Yeah. Okay. So there's like actually no research to move it really. I think that's the conclusion. Yeah. Okay.

Um, I know if anyone else has a comment on this. No. Okay. So, we will keep things as they are because there's like no good reason to change things and clients can put the logic in any place they prefer because it's like an implementation detail. Um, okay. So let's see then there was an extra item in the agenda. I closed it up.

Yes. Give me a second. Sorry for that. Yeah. So there's the last uh discussion is about field costs. Um we have 13 minutes. I think that's maybe a bit tight on discussing this, but yeah, I think I will do it anyway. I have some slides. Give me a second. I will share my screen.

Okay. Hopefully you can see my screen. Yes, we can see it. Yep. Okay. Um, yeah. So, I some a few slides to explain this a bit more. So, the context of the discussion is let's imagine that we have a new tree and we have a call value which will create a new account. Okay. So that's kind of the setup. So currently mainet if you do this kind of call uh you will be charged at least uh 25,000 gas um because yeah you are creating a new account and that has an extra cost. And the way that uh the current

devet uh for burl um behaves is that we still have this 25,000 gas cost uh probably because we don't yet have implemented field costs. So I think that's kind of the interpretation of today's reality of the devet uh for for the stateless uh situation. Okay. Now in an ideal devnet when field costs are implemented um okay so first of all we should remove I I would guess that we should remove this 25,000 gas costs and um we will charge two field

costs which will be the basic data of the account and the code hash of the account right so each of them is um 6,200 of gas and that means around um yeah 12,400 gas which is way less than 25,000. So this felt a bit weird to me because that means that creating new accounts via value calls will be much cheaper. So after thinking for a minute, I realized that maybe this is uh this actually indirectly happened when we decided to pack the nons balance

um and code size in the basic data field because before we had basic data we actually had five different values in the LE which were version balance call hash and call size. So those would be actually five field costs which in this case is more that's like at least uh bigger than the 25,000. So that made some more sense on why this happened. I think it wasn't intentional and it was like a side effect of this packing that we did with basic data.

But actually if you look at okay how this behaves with storage slots and whenever you create a new storage slot via nest store today mainet you would be charged for a cold access as usual you will be charged 20,000 gas for the new value which adds up to 22,100 gas but with 4762 um you will be charged yeah all this stuff which is like the the branch access the branch right and chunk right and the new value which is the field costs and if you sum up all this you will be still be paying half of the

current mainet costs which sounds a bit odd too. So it seems to be that at some point in the future we have to reconsider maybe the current field costs constant of 6,200 because yeah it's making new storage slots um have half the cost of today and yeah with the basic data packing it's also around half of the previous cost of creating in a new account. So yeah, I'm not like particularly concluding that we should double the field cost gas, but we should

actually think a bit more uh on this topic because yeah, something looks a bit odd unless we decide that we want to make these actions cheaper, right? But I I think this wasn't the intention of the uh the gas reform. Um yeah, that's mostly it. I know if anyone has a comment about this. Um I have a purely nitpick nitpicky comment. I don't think uh the understanding was that it would be cheaper. I think some of it was understood to be cheaper to compensate for the fact that code execution would

be way more expensive. Um, yeah, that's a completely irrelevant comment, but just wanted to to point that out. Um so let's just simply keep this uh problem in mind and maybe in the future whenever we polish the AP constants reconsider the current gas costs. Um one question regarding this is any every team sending someone to the interrupt? Uh we're not going to say where it is because it's a public call.

Uh but is everybody every team sending someone to the interrupt? Can we say when it is so that we know which one we're referring to? I can I can tell you privately. Um All right. It's a Northern European city. Yeah, I'm not going but I I think we have someone. I will be there. Excellent.

Yeah, cool. Yeah, maybe let's chat about this topic there if you want to think about it a bit more. Um, yeah, and that was the last um agenda item. I know we have like five minutes uh before the call ends if anyone wants to raise some other topic. I just want to say that we are trying to find a new spot for the S call because looks like the testing calls also happening on Monday will be extended by 30 minutes which means that it will have a 30 minute overlap with the current calls. Um I did try to gather um people's availability last week on trying to find a new spot and it seems

to be quite tricky. Uh I don't know maybe we will have a bit more time to find a solution to this but yeah uh we are trying to see if we can move the call or maybe instead of making it bi-weekly making it weekly and half of the duration we are we are still thinking about it. Just wanted to mention this topic. Uh would would you happen to have the lettuce meat link that we could share here? I I don't have it uh handy but yeah if you haven't filled the lettuce meat also inform us uh please of what

you want what you would prefer. Yeah I shared this in the chat. Yeah, if if you don't mind, try filling adding your availability so we can try to yeah figure out the good spot. Okay, so if there's no other comment or topic to be discussed, I think we can call it a day. Um, thanks everyone for joining and yeah, see you next time.

Thanks, Ignasio. Happy Easter. See you. Byebye. Bye-bye.