EOF Implementers Call #70

Transcript

I'd like to welcome everyone to call number 70 and I won't be doing notes on ETH magicians because it's got problems. So this is EOF uh implementers call number 70. Um I think it's number 70. Today is the 2nd of April 2025. And here's the agenda. Um we're going to be focusing on DevNets mostly today and talk testing DevNet 01 and coverage reports. go through the client compiler updates and then dig into specific details about DevNet one, DevNet 2, and postdevet 2. Um, including potential new EIPs uh post DevNet 2. Um, and this is probably actually

um in Glance Amsterdam or later. Any other requests for um any other requests for agenda items before we start? All right, hearing none. Um, let's go into testing. Mario, you want to kick us off? Um, so yeah, um, I've been reviewing a couple of PRs and, uh, most of them either have comments or are merged. Um, and yeah, some interesting PRs with new uh, interesting test scenarios. I think uh I think we should include them in

Deadness Zero definitely. Um so should we make a new release um I think soon uh only for for for DevNet Zero. Um yeah I think I think we should make a release uh in in in the following days. We're planning a product release. So maybe if we release at the same time uh we can save us ourselves up of making an exclusive EF uh release. So maybe that's that's an option too. Um but yeah and other than that I don't I don't think there's other other updates. Okay.

Um and u DevNet one tests. Anyone from Sloan want to take that or should I lead with it? I have tx create test in progress. Slow but steady. There's a lot of U of create test which I'm converting to tx create and we have been quite creative about the scenarios and some transform by a common pattern but some are quite uh quirky especially the cast ones because of 7623 uh which is a pain. Uh yeah that's it I think on this.

Okay and CX is the only real new feature. Everything else is porting existing tests with the new container format changes, right? Yeah, I would for example taking data 0x FFF as an example, the tests were transformed, you know, by just swapping FF and 04 in the bite codes and in the framework. However, maybe and I have that on somewhere on a to-do list too.

It would be good to make some I don't know how to call them like impure tests which test that we have correctly transitioned from one to the other. So just think about scenarios. What would break differently if someone had this uh I don't know mixed up or something. I didn't I didn't catch that. So do you want some parameterization or or what did you have in mind for for these new scenarios?

Maybe not I I don't there scenarios just a moment of hesitation to think about you know what would break if [Music] um well like specifically that what some what used to be a data section still was done with the zero for uh in in kind by right so I just make sure that we have tests that actually make sure that 04 is not a data section anymore probably there are tests like that but I I haven't really spent time

on looking for these there are some tests that test for like section 5 67 etc exactly so we probably just need to make sure that those also include four in their list yes yes along the along those lines and also in conversely we have had FFBD, you know, kind of weird section kind placeholdery thingy and it is a data section now. So, we need to probably be also careful that we have all the relevant cases uh still um covered. You know, I think I think uh there in this PR I think it's a draft now, but I

already gave it a review. I left some comments specifically on those those those tests. I saw that we were testing for CX05 and CX046. I think I commented uh that we should use CX4 and CX5 for those and also Yeah, sorry. I was a I saw those comments. I think I I I covered them. Yes. Thank you. All right. All right. All right. Good. Thanks. Good. Ben, you had your hand up brief briefly. Um I mean this this comes from trying to implement TX create but it may affect some of the tests. Um so we don't have uh the contract address by code

um in the EIP. So I I don't know if that affects the um some of the tests you can make. That's the uh delegate checker contract address the the the contract that's being called or the creator contract. Yeah. Yeah. Yeah. Yeah. We need we we need to somehow compile it, put it in the spec and uh I recommend having also dedicated tests for this behavior in east.

Yeah, I think the address is going to be OXB. It's going to be the next one in the pre-ompile list. Is it a pre-ompile or is it bite code? That's uh something we need to discuss in ACD. So, the plan would be to have it a pre-ompile a predefined set of bite code that we would put at a specific address as part of the transition. Um that's a pre-eploy. That's not something we've done before, but that's something that's being discussed um for um uh for like the uh EVmifying the ident identity compile is it takes the existing pre-ompile and replace with EVM code. So there is precedent for other things doing this rather than eof. So we

would just also do that. Another alternative is just say it's a pre-ompile and it acts as though we would use this bite code and the gas charging is as though we have this bite code. So it doesn't go in the state tree. So that's some of the details that we should probably work through when we get down to that section. So there's still a bit of design need to finalize because I don't think ACD quite understands what we're proposing with predeploy. Yeah, it's it's a little bit different. It's it's a different mechanism, right? So normally with system contracts, we predeploy them before the fork, but now we need the client to put something in this state at the fork block. So we never tested that.

So it's it's we have to pay pay careful attention if we are going that route and it's a chicken and egg because we need to deploy an eof container which is currently banned. So to deploy other eof containers we first need the eof container which is where it gets tricky. Yeah. Absolutely. I I I understand the need for it. Uh I'm just I just wanted to pinpoint that we have to be careful about testing. Yep. Yeah. Okay. Um, we'll probably come back to that in deeper when we get to the TX grade section. All right. Um, one client request that I have for all the clients,

um, if there's a way to generate a coverage report when you run the, uh, EOF reference tests, there's a way to generate that and share that, that would be good. Um, we had a meeting with most of the other internal EF people a few weeks ago. Um, one of the meetings we had was about testing and one of the things that uh the testing group really wants to get towards is to use coverage um to help help us decide how good the tests are. And it's um you know there's there's there's steps in this. There's you know line coverage and then there's branch coverage and then there's path coverage. Um you know they're they're not going to stop testing until they get 100% on all of them. But I think we get the biggest returns on line coverage if if a key branch is not taken in any way,

shape, or form. I almost guarantee you there's a bug. Um or maybe there's something with the uniqueness of your client that you may need to figure out how to get unit tests to trip that because I know in basically there's a lot of uh defense and depth things to trap out underflows and overflows which are probably unnecessary with eof uh but we have them in there anyway because we share a lot of code um with the non-containerized execution. So that execution still needs those. Um, but if we could, you know, get a a coverage report on these, I think that would also um calm a lot of people's fears um that it's, you know, too complex. Um, the complexity is something we can't handle. If we can show that we've been able to exhaustively test all the code paths, I think that would

really calm a lot of people um who can be calmed. Okay. If you want has coverage calculated on the CI and I have uh I have shared that but maybe not with everybody here. It is it is close to 100 for the relevant relevant lines. There's some um there's some pieces missing.

Um, they don't have a shuffle, do they? I'll shuffle this next time. Today, we'll do this in alphabetical order for client updates. But first, any other tests before we go into client updates. Cool. So, client updates. Let's do uh alphabetical order. Uh, Basu. Uh, yes. So I think DevNet one is implemented. Um and we have also implemented the payup codes for DevNet 2. I think that's pretty much it.

Okay, cool. anyone from Aragon started fuzzing a um they almost instantly found a uh the fuzzer instantly found a bug with the swap and the exchange. Um so I wrote a new test with that. We weren't um all our tests were symmetric. So if you were doing it from the bottom instead of the top, it looked like it passed. So I added some asymmetric tests. filter some of the things we're going to get into. DevNet zero. Um, if you fuzzed, you're probably fine. Um, EthereumJS, anything?

Anyone? Okay. EVM1. I think we've got all the DevNet one changes except the creator contract. Someone correct me if if I'm wrong. Um and uh pay code is still u not started I think. Okay. Have anyone from GU?

Not seeing anyone. Never mind. um implemented the pay up code uh for DevNet 2. Um and yeah, not um finished the DevNet one. Uh still waiting on the create contracts as that's one of the major ones. Um, what I was thinking is would it make sense to do this as uh a new branch rather than working on the existing label for DevNet 3?

I think a DevNet one branch would make sense. Yeah. Um, why wait on the create contract status? if you can implement the net one still without it or just you you just want to wait it's more final. Oh no I was just clarifying in this meeting what um what the details of it were there's a lot of there's a lot of docs with e to go through. Gotcha. All right. Uh rep uh no updates. Uh, I still didn't start work on devet

one. Oh, I missed the testing. Um, my goal is to try and get some level of, um, contract, uh, some level of, um, UF, DevNet one by next week. Um, so we can, if not the full transaction tests, at least we can get most of the container changes so we can validate those. Um uh would would that mean we should leave um the current creating in there or yes should we have transaction

create? I I think we can't remove the current create mechanism until we have um the cont the eof creation contract in place. So to answer some questions, that's why I still have it listed in the mega EOF. Um once we have it working in the DevNet, then I think it's fine to pull it out of SFI. Okay. Um anyone from Solidity? Not seeing Camille. Anyone from Viper?

All right. Any other compiler or client team updates that I missed? Eels. Eels. Yes. Yes. Eel. Let me add to the list. Yes. So, uh for us we are implementing the DX create right now and pay codes would be the next uh thing. So, DX Create is work in progress. And what's the name of the branch that you're working off of? Uh, it's EIP Osaka EIP7692.

Uh, EIP uh- 7692. Okay. And has that had a recent rebase onto EES? Okay. Yes. Yes. That's what I've been waiting on. Great. I'll I'll play with my uh buzzer and see how it works with the new stuff. That's good news. All right, I will I'll work off this lift next time so we can get everyone without me having to ask again. Okay, is there anyone else that I've missed? Cool.

Um so I guess the rest of the call go ahead. Have a question. Um so I see that many different clients are implementing uh DevNet one and DevNet 2 variants and different branches. So the question is should we have in the test release should we make a distinction between uh DevNet tests uh so for example have a flavor of devet one tests and another one for devet two tests or is it too complex for clients to consume these tests these different tests. um it's possible in in the in east to to do this. Um it's is is is not free. So we have to uh do some work to make this possible. Maybe I think create a

different fork of uh but but yeah is is there appetite for for for clients to consume different variants of the tests or is it like just not worth it? clients opinions. I'd risk to say that it's not worth it. I don't think it's worth this either as as well. Um so they are kind of versioning version. So one after the other I don't see why we it's we would be running definite one or definite zero tests after it's finished.

Right. makes yeah makes makes complete sense. Um so yeah I think um we should at least in the release we should make it clear that this is targeting that zero and in the follow-up releases uh just make it very clear that it's targeting de one and so on and so forth. Yeah. Thank you. Okay. Um here's a wild card question though. What are the odds that pay is going to be available to uncontainerized code? I know it's essential for EOF, but I'm wondering how much pressure we're going to get to make it available outside of a container.

Is that a question for for testing or just in general? Testing in everyone. I mean, that could impact testing because then we could test the payoff code outside of the EOF testing code so clients could still validate it without having to run it inside a container and wait for DevNet, too. Um from from testing perspective I think uh we can we can plan ahead and just try to put effort into looking of ways we how we can parameterize efficiently uh inside and outside of the of the container if container. So I think it's it's a nice thing to have in mind uh just to make sure that if the decision is made we can just flip a switch in the

test and then just uh test both inside and out of the container. Okay. Yeah. So that's just something to keep in mind. I don't think there's action on it yet until I think next week's not next Yeah. Not not tomorrow but next week's ACDE call I think is where the call for that might be made. though I uh I'm not sure if it's a good argument but including it in legacy sort of increases the scope for this change because it needs to be analyzed you know with backwards compatibilities whatn not maybe and also it needs to be tested with interactions with ex uh sorry the

old legacy calls probably maybe creation as Oh, okay. And it's not really I don't know what's the gain of having payup code in legacy. Uh because some people really really want it is the short answer. Like does it really really apply to legacy as well? Because for applies for eof. I'm not sure. I I think EMF it was more than really I think it addressed a security concern. I don't think it addresses the same security concern outside of Are we continuing to add new features on

the legacy VM once the OF is shipped? That's a discussion to be had. Um my thought is to limit it to only container codes, but honestly that's going to be a function of how well community uptake is. Um, if community uptake is amazing, that's going to be an easy sell. Uh, but I think there are some features on tap that I think people are going to want to use. Um, outside of container, the uh, create delegate op code basically the 7702, but for contracts I think is one that there's going to be a lot of pressure to not have container only. So it it's going to be to the call, but I think going to the future I think that's going to be the default. So we can let um code outside a container oify and code inside a

container is where the evolution would happen. Um yeah and we could use that as kind of a carrot to encourage people to use eof. Uh but there's going to be some features that will require EOF like the current formulation of EVMX um needs for efficiency sake and needs immediate op codes. um doing all those with pushes, we immediately lose all of our uh gas efficiency. Uh so that's that's going to be one of the reasons for EVM max to to be container only. And as far as EVMX, um the current limitations we have in

EOF for backwards compatibility, I don't think will matter because almost all EVMX contracts I see is doing one cryptographic function very well and not doing any fancy DEX type stuff. So it it lines up pretty well with that feature. It's I don't I honestly don't see anything that uses EVMX really calling outside of it for the first few uh major contracts that come out of it. Okay. So let's move on to DevNet one. Um I think based on the client implementations um implementation is

mixed blocking somewhat on. Is that a fair accur fair fair characterization of what was state stated? Um so the I think the two big features are txreate and the nit code transaction and the creator contract. Um we had a little bit of discussion earlier. Um like I said we need to I need to get on on the list.

Um my plan is the first advocate. Actually I tried this six weeks ago. Um and what we got was um round two of should we do eof or not. But I wanted to raise the question of um 7877 I think it is EVMI the identity pre-ompile um and get get the opinion of everyone in in the uh alcore devs if pre-eploys are a thing we want to do and I think that that the pre-ompiles are a different kind of pre-eploy um that I think may be more palatable rather than arbitrarily deploying contracts um and arbitrary addresses uh because then we might get asked like well can you deploy my stable coin can you deploy

my matecoin and I think the answers to that is going to be a resounding no but I think what the difference that um the eof has uh the eof creator contract and the pre-ompiles is that those exist as pre-ompiles already and have a limited EIP driven use. Um so whenever we discuss this we're probably going to need to get you know list of standards of what's acceptable to pre-eploy and what's not. Um, EIP99 is of course going to be a third rail. That's going to be an absolutely not. We don't change contracts as part of a pre-eploy. Um, but I think we need a this is an exercise that we're going to have to do on all core devs. Um, and I'd like to have the discussion without it turning into round three of we should do eof.

So, I'll see how we can approach that. Any uh ideas, comments on the pre-eploy, how we might want to do that? is a pretty ploy from our perspective the recommended um option. Yes, like excluding all all the ACD considerations and politics. Uh what was the question again? I missed it. Do we prefer the predeploy over pre-ompile technically speaking?

So, it makes gas better. Um, it makes it obvious how much to charge for gas because it's the op codes and we exercise the op codes in place. So, if we go pre-eploy, we're going to have to figure out a gas schedule too. We need to code and spec out the I mean the code the bite code would be the spec for the pre-ompile but it I think it makes the task uh to do this correctly harder for the clients and we want to avoid pre-ompiles and we would not be able to

ex delegate call it Right. Yeah, you're right. If it's a pre-eploy, exec delegate call will fail. So, we prefer the pre-eploy, I guess. And delegate call I think is something that's a subtlety. um but it changes the source address for where you're going to get all of your uh contracts off of it and has a different distribution of the addresses that in effect only your contract can reliably use. So that is a valuable security feature.

Yeah, we had a discussion that we and we ended up softly preferring to not block x uh ext delegate call for creation purposes. Um so pre-eploy is better. So how about we just um code it and write test for it and then propose it and and trying to make a case for it that it's the cleaner solution and also okay you can make a point about gas because that's a very good point and burden for the for the clients. I think it's it's worthwhile to so here's the question. And do any of the clients have existing code to deploy contracts as part of a fork transition to add to the state? What what's the

fork transition code look like in the compliance? Dragon. Um yeah, I think that's the biggest difference. Uh if we add it as the contract that means that we need to update the state. I think everybody that sync from genesis with D hack fix has some part of code that updates the state. uh if we add it as pre-ompile that means there is no bite code and there is no like state change but for implementation standpoint uh it may because the I'm assuming here but that pre pre-ompile needs to have

sub calls for example in revm uh uh there is no support for that then it be a little bit bigger trade So there is like pros and and cons around that. Uh it seems the easier solution is to add the code to state. Um but I'm not sure if we are getting if we are going to get the push back of I'm not sure uh push back on changing the state with the hard work.

What else? I would prefer the the the by code to be included in the state seems cleaner to be honest even with the push back right. Sorry despite the difficulties that you have mentioned. Yeah. Uh difficulty is mostly like push back from community or persons or people. Okay. And how about the would it be possible if that um introduction of the creator contract be handled by running by code on the fork maybe that's a bit early to does it

doesn't matter it will be yeah if this special a section or special bite code that is run or something else. Uh there is some logic that needs to be run be that uh in the end it needs to include the the bite code. So the end those like examples are just implementation detail. Gotcha. Thank you. I mean that's another way we could do it is we could put in a special transaction um and we could have a list where the clients have these list of special transactions um if they match this hash um don't check the signature the signature is

presumed well it would also need to work around if it does a transaction I mean it depends on how special you you want it to Because we also had the 35 EIP 3541 be it feels the special transaction will just complicate it because you need to define what special transaction is. You need to add somehow preserve that special instruction. Uh BDN just saying at that block uh you need to insert this bite code at this address. It's

basically what we need to do. Well, we run system contracts on before and after block, right? True. So, we can have a system contract that or something resembling a system contract that is run just before or after a specific block. Would that be a good obstruction to introduce it? Uh I think this case is very specific and that we don't need um additional abstraction. Just saying that this block

you need to insert this bite code is good enough to insert it state. I mean, if if you do it as a system contract, you're going to be checking every single block. Whereas, if you say, is this bite code active? Then you're only going to be doing it on transaction create calls. So, there there's less weight from from doing it on, you know, checking whether it's active um when you call transaction create rather than checking every block. Should I insert the system transaction?

Gotcha. Okay. Any more that needs to be said on the creation transaction for now? I don't think we'll get much resolution today. So on the net code transaction, one thing I do think we need to look into, this is probably more for if um and whoever's working on the fuzzer is we need to have the TX create transactions in the TX fuzzer um to make sure that we can generate valid ones.

So it's to pass the transaction or pass the instruction. Pass the transaction. So there's we need to make sure that the transaction format is stable and reliable. Um, Marius had a uh Marius and Martin have a a set of transaction fuzzers that they run. Um, they've been running against the blob transaction, the 7702 transactions. So, we just need to get a generator um that will try and do bad things to the unit code transaction. Starts with valid transactions, then it goes to invalid transactions. That's just that's

probably something um that we can start looking into after uh after we get the east tests out. Any other questions about the create operation itself or the unit code transaction? Okay. Anything else about DevNet one? Any questions about the container

spec changes that we're going to be rolling out? Um, so said this before, but I want to reiterate it. Um, if there's any breaking change at all that needs to be done to the container, we probably need to do it now. The goal is that no more breaking changes after the container.

So, what that means is after this is we can do additive changes to the container, which would be things like adding new sections. Uh, the metadata section being an example of how that might happen. Uh but in the future things like EVMX may benefit from an extra section. Um there may be I I have no idea what other magic uh code section types people might want to have. I know 7701 um account abstraction want to add a section header that says here's the list of um entry points that we're going to use for count abstraction and which section to go into. So that's uh having account abstraction to peno app is really helping um facilitate a lot of things to be honest.

So the idea is that they can start working from devet one without needing to wait for devet 2 features. And then we need to get the tooling outreach done. Um I've asked a couple of times on Foundry. I need to get a contact. I've been trying to get a hold of Foundry via our epsilon ref chat um to get their feedback on the current GX uh create design. Um but other than that, it's it's once we get DevNet one, I think it's going to be stable for them

to build their changes and we'll need to get in contact with Hard Hat and make sure they have the ability to do what we have there. All right. Devet 2 payout code only has one question. okay any other

I I have a question about the static should we allow that in static envir u context um and and in what cases so if uh there is no value being sent um or it's being sending to the same uh recipient as the sender. Um I think yeah um since logs this is not explicit in the EIP. What are people's opinions on this?

um fail would be easiest. Yeah, I think I agree. Uh I think on that note I I think um because we are doing logging right on the pay up codes. Um well um I don't think we are but we may in the future. Yeah. So static calls don't do to logging. So that would be a case for failing. Yeah. Okay. That's not my keyboard. Yeah.

Because of um an EIP for logging on ETH transfers, which we don't do at the moment, but it would cause problem. So aren't calls with zero value also going to generate logs or those explicitly removed from logging? That's true. They're probably allowed. I don't know. But I mean, that's sort of call call with zero value cuz the the the way to transfer is a call. Um, and you couldn't really ban it a zero value because um, then you

wouldn't be able to call them. Mhm. But pay up code is intentional. So I think it makes it's fair. You know, why are you calling pay if you're not cuz you're not actually executing anything on the in there's a another issue that needs clarification which is um what happens in failed case. So if the sender doesn't have enough balance um so is that an assert fail where it

consumes all gas or is it uh like a call op code where it returns 01. How does uh call not ext. How does call work? It returns um a code. Yeah, I would keep it consistent. But consistent means the different thing in EF with ext and legacy with call for the error code at

least. Should it behave? I mean, assuming that it will be rolled out in legacy, would it behave differently into context? That sort of might be even a an argument against doing it in legacy. Yeah, that's a good

point. So, I think those things need to be updated to the uh Hey, what is paid number? 59 something. 5920. 590. Yeah. And there's some discussion on the magicians. So, we should probably get I'm changing this because I think we also need to change. What's I think the op code also needs to change. What op code did we use?

Uh, I think it would pull one just for the M. Um, yeah, you mean the the hex FC? OxFC. Yeah. And that doesn't conflict with anything we have right now, right? No. Okay. This seems to not have a return code. Yeah, that's that's what I was saying.

It needed clarification. There's there's some discussion about it on the ETH edition. Ah, okay. Okay. Right. So, these these these points have been mentioned. No conclusion. I mean, it's probably up to the authors of of the CIP to figure it out, right? I think we need to get someone on here as an author on it. I don't think uh any of Gavin uh Zen or Sam Wilson are regulars on this call. So, since we're uh it's already

got some changes in there, I think we should get someone in here because we're going to start making functional spec changes. So whoever edits this next should add themselves as an author. Yeah. Do you want the official champion of this EIP? Do you want to check the That's one of the issues we have that someone is putting EIP for consideration, but there's no official group that actually is championing it. Is this not working? This is why I'm using hackmd.

It had it had a rough weekend. I think it's under provision right now. Yeah. Okay. Um the the these points have run up in there and there there's a little bit of discussion. I think it's like Charles and Yeah. Here we go. Yeah, I think William should add himself

as the um is the committer. He's the one driving a lot of it this year. Okay. He's usually pretty responsive. Uh if we ping him in the forums, he doesn't always make calls, but I think we can get these added. All right. And nobody's worked on symbolic introspection or metadata sections yet. Okay. So let's post EF devet 2.

Let's start with this one because there was a request from dragon that discussed this proposal. Yeah, in general I think we already talked about this maybe months ago but while discussing UF I had uh I was referenced this how to split of how to fraction sub calls sub call gas. So I made the IP so I can reference that uh main idea or maybe difference is um set um have a field inside interpreter that's going to be set when the op code is called. Op code represents a fraction of current gas when that op code is

called and that fraction or gas that gets split is um is used as the gas limit inside sub codes. That basically yeah solves the problem where the all the gas can be transferred to the sub calls and sub call cant spend all basically spend all the gas. Okay. And no returns one input. Okay. There's some details there but that's like the general idea.

Alternative to that was to have split saved and the gas limit for the sub call getting calculated when the sub call happens. But that would mean that first sub call would take an amount of gas. Second sub call would take a different amount of gas and it will depend on how much gas got um previously spent. So this feels a little bit uh nicer because you have one value that that you can get at one point of time.

And this would be just in the call frame. Subframes would not inherit this. Yeah, exactly. Okay. And you call just one up code. It's uh it doesn't disrupt anything with UF. It's one up code and everything else is done in the background. Yeah, I need to say have something because it this kind of problem where when you proxy something when you're bridging something and when you want to limit the amount of gas that subco can spend um it popped out in discuss a few times. Yeah. Ben. Yeah.

So, um I don't I don't think this is ideal, but I do think it's better than guest introspection, and it obviously solves um a problem because you could there's like the the risk of bricking uh a contract that this would would solve if you you know, if you're always calling something that reverts, you can't get past it. Yeah. Exactly. So yeah, I I think this solves the problem. I think it's better than, you know, full gas numeric because that's especially if we're considering repricing all the op codes. Um a numeric lulls you into a false sense of uh what

it's going to do. you know, if you if you say you can only have 21,000 gas and then we repric everything to to one gas, um that protection goes away, whereas this doesn't imply that protection. That's more like you can continue up to. So I think I think it's it's good from that. I don't um so yeah. So I think I think it's both better than eof as it is. I think it's better than death introspection as it is. But you know it's it it does with acknowledgement. Yeah. It feels a bit a bit clunky. Yeah.

Especially where you Yeah. Go ahead. Especially where you are like taking the current gas when the that top code is called. That's strange. Uh at the beginning and even now it's strange to take that because it's arbitrary. uh but seems slightly better than than taking it at at time of when the call is basically cold but I don't have anything better than this to be honest um yeah I got minutes okay I I I would add um I would add a max that it can maximally be 63 uh 64 would

be my only uh change from that. Okay, that makes sense. What if there was magic values like something greater than 65k? That means use the stipen value and that could change on a schedule. That would be like my suggestion. Uh what do you mean by that? Sorry. So sometimes when people do calls they there's like some some magical schedule values that must be preserved and must be added and that they've been using for things like solidity if they pass 21,000 because they can't do it store. What if we put in a few of those magic values and then we could change it with schedule. That's that's interesting

idea. Okay. basically say that this value whatever it is it will be changed with every hard fork that changes gas pricing for this up code or something like that. Yeah, that would work. Cool. Well, I've got another meeting so I'm getting kicked out of the conference room. So, um I'd like to thank everyone for calling in. I think we got some good progress. Hopefully in two weeks we'll have ETH test and some success with clients um getting much further into DevNet one. I appreciate everyone's time.