EOF Implementers Call #12

Transcript

recording in progress hey guys welcome to the eof implementers call number 12. uh before we get started with the client updates I wanted to just reiterate really quickly what we talked about on call 11 and maybe in the updates convention uh how teams have thought about the stuff that we talked about last call or we can talk about it in the spec updates but the points that I put on the agenda as a summary for the last call was that we were okay with adding swap in and dupin if something were to be cut this is sort of the first thing we would look at but we generally like accepted this as something that we're happy to put into eof

um also wanted to reorder the data section to be at the end of the container versus where it is today and then we also kind of love to note about talking about gas observability with respect to erc4337 since it seems like 437 is very much the approach that people are looking forward to for account obstruction and if eof makes that impossible um yeah it's important things to think about so with that said we could go ahead and get started with some client updates and maybe mention how you have thought about those things in the past two weeks otherwise we can chat a little bit more about it in the spec updates if

we need to anyone want to volunteer to get started okay I'm in okay can you hear me yep okay cool from nethermind side uh we've been doing mostly cleanup of our PRS we implemented Japan Swap and and we've been trying to continue our drafts for Mega euf end game spec and we are waiting for the for the eips to at least emerge so we can see them clearly and

update our code accordingly and yeah that's mostly yes thanks for that update uh we want to go next I'll go next um I did some performance payments on basically but I haven't done much on eof most of my time has been occupied writing slides for a conference next week cool um evm1 folks oh I'll explain anything to say from

evium ones I don't think anything changed significantly lost time okay um Alex you said that your pressure was not to make eaps yet but keep using the metaspec are you just referring to what I said about the Swap and dupin thing I probably just misspoke no I I can respond to you to Ayman because you you said you were um waiting for the eips before considering an implementation right yeah we are making uh draft implementation but we prefer

the the ARP is to be there yeah but for crafts and testing it's it's fine this way right we don't expect it to be final before their eaps of course okay I guess okay uh any other client related updates that's probably that's probably all any compiler updates

doesn't look like anything um I mean it's not like an official update but I did have a discussion with Daniel and I mean I mentioned this maybe not the last school but the the call before that the put prioritization within solidity the want to get a bit more confidence before they allocate more resources but we did agree um that they will try to merge the uf1 implementation from December which

is likely implementation but it changes a number of different subsystems of the compiler and to the university to try to get emerged and then also third parties getting much more easily work on the diff between you know eof1 from December versus what we have today um I mean right now it would be challenging because they have this massive PR for it yeah they have this mess if we are for it right now and it's it's really hard to to have any third party to make any any changes on top so the goal is to get that merged into Mainline solidity and then um others um even from this group can potentially

work on making the changes since December disability but if there is more confidence coming from all core devs than um solidity is is happy to allocate resources okay awesome that's great thanks a lot for that update I think we can move on to spec updates now does anyone have anything to talk about here Hyman uh well I think I mentioned this in the Discord I would like to suggest that we

update our traces to include extra data like the immediates and yeah well at least the images and the current code section for eof so we can so what at least what basically did is we added the section when it's not zero um that for the initial large eof and I'm you know open to Always setting the code section when it's eof code and that said I would see we have code is a nice indication but adding a media to I didn't think of that and I think that's valuable and useful yeah well we've been trying to build the byte code from traces and it was pretty much impossible

with the new up codes the new the new multiple codes for push weekend it uses from the stack of the next Trace but from for for the other ones it's required a lot of painful calculations so yeah it would make sense to have them in the traces as hexer or decimals uh whatever works for us I guess both work right well I mean most of the traceback is in decimal instead of hex when it comes to the text strings so if you like doing a hard jump you

would want it in decimal because the PC is a decimal okay then when we do them decimal like a format doesn't matter to us that much as much as they exist so we can deduce them or have them there to see them and yeah the other thing is about Japan and swapping I think the validation should be moved to the eof validation context instead of just throwing exceptions in the VM one is represent so and yeah that's it

you're saying that the part of the UF validation that happens on deployer executing and that code should also check the capability of the swap into pin yeah the current spec I guess uh suggests that if the stack doesn't have enough elements for dependent Swap and according to their immediate we throw either stuck underflow or overflow and the stack validation in our eof in the eof context takes care of that so we can just move those checks to the stack validation part and proceed normally

um yeah because on the Epsilon teams there a reason why you guys wrote it in this way where it was a runtime exception versus a validation exception yeah it was written before stack validation was ah introduced but you know as we read last week to integrate this into the mega spec it has been integrated yesterday um including this accommendation okay great but EIP hasn't been updated that's um right okay awesome um does that resolve your question I'm yeah perfect nice thanks excellent

um okay any other spec updates spec concerns so actually on the spec update Andre I'm not sure if you mic works but if it does you work the the most in respect you want to give a uh an update on it yeah we made several additions as already mentioned uh there are no and then we added non-returning functions definition and its implication for jump F I think jumpath was already there but

now yeah now it's also mentions non-reterm functions and how they have validated it turned out a bit tricky so validating whether the function is really non-returning actually depends on jump F's and whether they jump F into non-read other emotion no return functions only or not but yeah it's better to check it out on this spec also this is not a new thing but we just kind of reorganized thing we've added this Tech validation section in the dock and this is just for completeness I

guess we moved some items from code validation into this so they are now separate and more complete and easy to read hopefully and also I think since last time we changed the uh order of the sections now data oh it's not everywhere that's fixed but uh so section kinds are now four for data and three for containers and containers go before the data section yeah so I think that's that's all I

remember awesome sounds like a lot was added to the spec it's great any comments on those updates uh okay Zayn do you want to bring up this discussion again about xcode copy data contracts yeah so thanks my name is Zayn uh I'm just a Community member um that's like working in the ecosystem um so there's sort of a largest group of

us that have been using uh data contracts um and I was listening to the call from two weeks ago and it sounded like there was some sort of confusion left so whether or not uh like what level of support there would be if your data um so just as like contacts uh some of the larger people that use these data contracts would be nouns down so something like I don't know like 45 million worth of whatever in their Dow treasury uh and then art blocks uses it and then there's sort of a larger subgroup that you can access and I posted this here from the DVM Discord called math castles and like extreme Tom from cool cats

and a lot of people on the nft space and there's a couple of people elsewhere that are using data contracts um and so I think there is some confusion because within the EIP uh it seems like there's a pathway to keep using xcode copy uh to retrieve data and then uh when I brought this up in the Discord it seemed like maybe that's no longer like on the docket to be supported um where the xcode copy op code would fail on a data contract is that uh correct or yeah am I missing things and then finally a lot of us want to start

migrating the code uh over to start supporting sstor so uh uh here is basically the sequence that a lot of projects use and some sort of derivative of this which is of course using xcode copy to reduce gas and storing data within the code segment and so from the consumption side what this looks like as a problem is that as more gas is used by the RPC providers then the data doesn't actually get relate back

um so as store helps reduce that for on chain like storage so if you're just like using inferior for instance you may not get back off the data so from like multiple angles it becomes tricky when um you can't have sort of cheap immutable storage or cheapish to return back all right so that's kind of like the Spiel on I was curious like does that make sense and what the general like sort of thinking is can we move forward with implementing uh changes to say like this s store lib to reflect the current EIP or is that

off the table and I think there was some confusion about uh X data copy as well thanks for approaching the subject Zane um I think my understanding was that we were I don't know I haven't looked the mega spec in a while but I think the one idea was to have new OP codes like data copy and that would allow us to copy the data from the data section of a different contract and that would provide like this summer function now that functionality of having data contracts but I don't know

what the latest on that is Alex yeah I I guess there's a distinction between um you know using data within a contract versus um you know cross contracts um so what we have in the in the spec is data copy which is local to the current account so that you know that is similar to what we have with code um code copy before um that is um going to be supported um reading from other accounts which was

accomplished with xcode copy for that we don't have an X data copy counterpart um I see a number of different solutions if we decide to support this pattern um there could be an X data copy instruction and the xcode copy instruction could be repurposed if the target is an eof account or what I like the most now is um this idea mentioned I think by Daniel on the channel that there is nothing stopping data contracts from actually having just regular API function which Returns the data uh the caller is

asking for um I think the only argument to be discussed here is what are the overheads the the cost overheads right because uh the the main reason there's a preference for export copy as opposed to anything else because that is the cheapest I want you to close this out with uh some random feedback I've been working on pricing in vocal trees I was my hunch was that you know maybe this did a contract question will be changing in vocal trees um my current empirical findings don't

support it yet data contracts will be um more expensive than they are today because of the um because of the the code chunking employed in workout trees but I was I was wondering you know what is actually a a correct pricing about any of these um so I'm not fully sure at this point that data contracts you know in a vocal tree paradigm should be cheaper than storage because in the Rocco tree they kind of cost the same so I think that's something else to to

keep in mind that you know maybe data they're currently cheaper but maybe they won't be cheaper in the future and then I guess my sort of follow-up question would be what would be the reasoning behind them not being cheaper um given that my let's say our code copy oh oh two points actually um two things to just bring into the awareness so a lot of let's say like D5 and different projects are starting to lean more into uh Diamond contracts and proxies um and essentially chunking uh kind of a mega contract under one umbrella so

um local data copy is probably going to be not as useful as external data cotton um just because like a lot of contracts are like starting to brush up against those limits and then the sort of everything would be uh from just like uh bytes or bytes in bits or bits perspective uh it seems like if you were storing data in the code segment and the cost is that like it's not immutable storage but immutable storage that like it would seem that the cost of storing anything in those segments would be like the same

um now when it comes to reads I could see that as being a thing but I wouldn't say that choreograph is particularly optimized for uh the reading use case and I think a lot of infrastructure uses uh like indexing anyways from external systems um like uh for instance like falcon okay that's my like my long and short of yeah I think saying these are like really awesome questions the the first point you made that there you know contract size limits um I think those again originate from

you know fixing the US vectors and with eof I think we're actually getting a different fix to many of those those uh the US vectors like you know one of the the early issue uh why code size limits for injuries were the jump test analysis uh to put a Bound in it now with the UF you remove the need for that I could see a potential that actually UF contracts wouldn't be subject to the same code size limits so maybe you know um you could actually have much larger um now there's one limitation there that the data section currently is limited to

16k and so that would be the limit you know that's the limitation of the header um and then just one more response and I won't be able to answer all of your questions and want others to also speak um but the generic response to why things are Priceless they are you know essentially the pricing of both like handing contract code and handling should somewhat reflect the the underlying cost of the client and today these costs hopefully reflect what the client has to do but with Oracle trees the the work needed to be done by the

client will be different than it is today and maybe that will mean that you know the cost of like data contracts will be closer to storage than it is today and I will pause here yeah awesome responses I think uh like you know I think that makes sense in the sense that like uh essentially you're trying to like price the storage and then maybe the price goes up or down and prices are always supposed to be dynamic uh so like I think that makes sense I think probably from like the outside perspective from let's say the DAP side

of things it seems as though a lot of there's been a lot of momentum towards splitting contracts just because like at some point you'll hit some limit and the jump test Uh current limitation makes sense um and I guess the question I would have is from the eof perspective there's like the code section and then there's the data section and I think like people just looking at like storing data in the code section is kind of the angle versus like uh in the data section itself are you thinking

that the eof format will no longer like sort of allow that and you want to have like a clear borderline so um yeah we do very much want the clear borderline um to make sure that code never hits memory never hits um anything that could be evaluated in the evm one of the reasons has to do with zero knowledge proof translations to be able to take the evm and easily translate it into a zero proof system is your knowledge proof system and haven't have access to the byte code um kind of makes it more difficult but also locks uh constrains the kind of Transformations

we can do on the code in the future if we need to upgrade into a new version of eof or if we need to go to a slightly different system for ZK proofs that has the same effect of the code but doesn't have the exact same code so that's one of the reasons why we want to make the code unobservable and why we separate the data from the code actually with the eof the data section 64k because it's it's two bytes so that's more than we can get in in the contract today if we were to lift limits um one thing that would be helpful for us to evaluate the pricing and the impact is to know whether these contracts how frequently do they call the XT code copy within a transaction and how much data do they copy from EXT code copy

um because the idea that I had of if you have a contracted serving up data you put a function in front of it that says you know give me your data and then it can copy it there and then you can get it back because even the data itself in some of these translation scenarios if you can prove that the data doesn't quote unquote escape the contract there's more optimizations you can do and more stuff that you don't need to bring along with as you do the transformation to make it more efficient so if the contract explicitly says hey I'm exporting data by having a contract method that actually you know does the copy itself and then returns it in the return buffer um those are those sorts of things that you know these systems going future looking systems know that this data is

data that's meant to be shared and it can keep it appropriately versus if it's not meant to be shared they can you know copy it as a consonance of the code what they see it's copied in and just do all sorts of interesting optimizations to speed things up a lot so when metallic concerns I was I was you know a little annoyed at the timing of it but I think ultimately he's right because if we want to make sure that these evm contracts are very future proof we need to put limitations on what can be shared outside of it and what can't so if if we knew how many times these contracts called the XT code copy and how big they were per transaction we could gauge if the impact is going to be crippling to these contracts or if it's just going to be a slight gas problem

um I I think the truth is somewhere in the middle I think it's going to be a bit of a gas pump but I don't think it's going to um make it impossible to call these in the eth call type system with the gas limits will still be under 15 million cats easy with these which I think would be the gas limit for most of these systems I think some of them actually have 50 million gas so so that the costs imposed by having to read through a contract method I don't think it's going to be bad but until we get actual numbers as to what these these would look like we really can't you know get a firm estimate on it but as far as if we're wrong we can always add EXT data copy in and future revisions of eof in a compatible fashion but if we put it in

today we basically can never take it out so that's you know one of the reasons why I'm biased towards not putting it on first pass to see if we can make it work out without it foreign yeah it's uh interesting I would say that like uh for the most part uh a lot of like contracts will like launch data contracts today so they'll use like a store to launch a contract that is like writing into the code segment a large chunk up to like pretty much of the contract limit uh and then from there uh what will happen is a lot of these projects are

like say playing around with nfts and things like that so the read method will stitch together multiple of these data contracts to then return back a result so it would be something like a token URI call and then you would see like okay uh essentially a series of xcode copies uh to like other contracts um that would be off the top of my head and then I think maybe a Next Step would be to try and figure out like what kind of analytics we can get on this Behavior maybe there's a way to look at the generated by code to just see

who's calling xcode copy but from the top of my head it would be like generally used for marketplaces um and exchanges like uh along those those terms so you can imagine like open C probably will have a read call to token your eye like ever so often or wherever like wallets want to sort of resolve this directly Etc so if you could get a copy of the ecall RPC against test net or like satolia Gourley I think that would be the best thing you know if one of the larger contracts one of the more bigger ones but as far as you know

launching these data contracts create three and create four have support for that built in because you say I'm gonna deploy this contract and it's gonna be a little stub that says here's the read method and then he provide auxiliary data at the time you called create three so you don't know your auxiliary data at the time you create the subcontractor when you actually invoke create three you will notice auxiliary data and that's where they can load in their data into these data contracts up to the limit so I think the current definition still supports this use case where you create a large you know data known only at transaction time and deploy that contract it's just that what data would go into the auxiliary data part of the create three and create four calls so it will be appended to

um the code that would do the EXT get and stuff and then we would read from there so we could we can do arbitrary transaction time data contract Contents I I'm not concerned really much about that but I would like to see um if you could send a couple of calls of the contracts or the some of the larger ones doing these I think that would answer a lot of the questions about the actual overhead of charging another 100 gas per EXT cold call is really what it would come down to okay yeah I think that that makes sense as long as there's like some sort of provision is there like any sort of docs on create three create four uh so like I can like Shuffle that back

to the various groups and stakeholders that are interested in these data contracts and we can kind of stay I guess so on top of it for lack of a better word um or like uh start to build the test harnesses because as like uh platforms are like sort of using this to launch like future contracts um it's kind of important for all of us to be able to like change with the times um or at least take the tires grade three create four are in the mega eof spec um not every client's implemented it yet so it's gonna be hard to get test harnesses out that's the step we're at right now is getting the clients to

implement these Specific Instructions um I hope to have I thought I'd have basically done it by now but I got too many interruptions um I think evm1 has it so you could probably test against them um I don't know if there's gethcode yet or another mine code yet okay cool uh does anyone have a link for evm1 and then I think that would pretty much answer it and just the takeaway so that way I make sure that like I've got everything covered um we'd be looking for uh to make Eve call rpcs with a larger

contracts that are stitching together uh data uh and then I guess what would you what pet appointment would you want would you want like a markdown of like the results and like how you could call it so you could observe it or markdown would be fine and probably all I really need is just to know which contract it is I don't want some of the interesting inputs are for some of the nfts that they're looking at I could probably um tease some of the nft data out of openc if I just know which one of these contracts it is okay yeah I can do that I can like I'll ping out to math castles and like um try and coordinate with art blocks I think

per Pat may have some connection there um and then see what's up yeah that sounds awesome could I ask just one quick clarifying question here that's related to this that's been a little bit unclear to me from the specs that I've seen so far and maybe it's in this Mega spec and I just I'm too dense this morning and quickly trying to read it um yeah go ahead is in the long run I think like our Outlook at our blocks is like you know we're gonna have to update our storage contracts to you know be conformant with

UF spec Etc I think the part that's been unclear to me is the behavior for like it's it sounds Legacy contracts being able to use Legacy operations to interact with other Legacy contracts will still exist foreign Legacy contracts can't create new contracts new contracts can't create Legacy contracts that makes sense will new contracts be able to read Legacy information or is that part still kind of unclear I don't know if I misheard you but Legacy contracts will continue to be able to create Legacy contracts sorry

is that I don't think new contracts will be able to EXT code copy out of Legacy contracts I think that's one op code we're also removing at the initial launch wait are you saying that Legacy contracts deployed by Legacy contracts will no longer be able to xcode copy no new contracts um EOS eof contracts won't be able to read Legacy contract uh byte streams correct okay is there any like pattern there that is suggested as to like how to make that possible um or is that just like expected like a necessary kind of hard-breaking case

so that's kind of a necessary hard breaking case but um there's there's Escape hatches you could do you could write a helper um that you would pass in you know the arguments for any XT code copy and all this helper contract would do it would call from eof and would call into a legacy contract that Legacy contract would have EXT code copy and you would tell it you know which to copy from and bring it back so you can kind of do an in-direction to get there from the Legacy contracts if you really need an escape hatch and it's it's this pattern is why we're Banning delegate calls from eof calls into um into Legacy calls because if you delegate call into this Escape utility um you could have this Escape utility

then call self-destruct which is something we're trying to totally keep out of EOS consideration right now um so the direct call and you can get the external observable effects and not affect your own storage that escape hatch is fine but Escape calls that will change your storage based on Legacy rules is what we're trying to avoid so I guess the pattern is to like you know maybe we could standardize a specific escape hatch contract in one location on the chain that you could call these if this becomes critical but I think you know with forward planning um a better practice might be when you do these data contracts always put in a little stub that will serve up its data

so you can just call the data contract call the input method and the data says Hey serve me up this block of data and it'll return it to you in the return data oh I see so that will be okay so like uh eof contract calling a legacy contract that then internally calls uh uh EXT copy from a different Legacy contract that will be right as long as the contract code executing is Legacy you have full access all the legacy codes assuming you're targeting another Legacy contract okay yeah I think then in I would yeah I maybe it depends on how people are using things like ssdr2 but

I would imagine like the common SSR 2 cases covered for most folks who are deploying that as a yeah who are using that because you have the read methods there that you're interfacing with you're not interfacing with like doing code copies directly so cool that that makes sense uh and is reassuring to hear I think that part has been a little bit unclear to me so thank you okay Zane yeah so for that pattern your suggestion is that we launch a legacy uh uh contract proxy I could probably take in any of our Legacy contract addresses and let's say a range and then that will

then call out any other xcode copy data that we need so that way we can then access that data via a method called to that Legacy contract otherwise you would be stuck in the water without let's say a proxy to call from an erf contract right the whole two systems at once is is a pain point and I think that's that's the solution as you would call into the Legacy that is designed to help you with the pain point which in this case is the XT code copy it's just there are certain ones that we

can't do like we can't let yourself destruct your eof code so we won't let you delegate call into these that are standard call or a static call that's that should be fun awesome thanks yeah thanks a lot Jane and perpet for being here and asking some questions appreciate you guys keeping up with what's going on on eof I do want to try and move to some testing stuff is there any last comments uh related to spec spec updates okay let's move on to testing

any testing updates questions since we last spoke yeah from testing there are um who requests to pending um they have been with the work in order to use the new year validation format and this way you start using the the amount of that file and making making it clear the return of your validation failure so yeah I think they need to be reviewed but yeah it is now let's let's review

hope it is okay cool sounds good um if you get anyone had trouble hearing him I could go you're a little echoey sounds like there's two PRS that have been reworked a bit into the testing repo and that's been finished over the last two weeks and now it looks like those things are just waiting for review to finally go in any other testing updates from the python python test uh sadly there's an audience we've been focusing on 4844 at the moment but uh we will uh spend some time uh in the next couple

weeks to finally get into updating the year of this for the buying tests okay great yeah I hear that's a pretty big EAP so makes sense other testing updates okay that's pretty much everything we have on agenda are there any other things that we didn't cover that people feel like we should chat about one more quick question is a 3540 still

being targeted for the next hard Fork uh what is the official status I think right now it's considered for inclusion but they've created another level of acceptance and uh 4844 for instance is like accepted to Cancun whereas eof is only considered for inclusion so it's still something that people are trying to make happen but uh I think personally I think it's more likely for the following Fork but yeah I don't know people are still we're still working on it and trying to have it ready you never know what can

happen it might make sense to put it in this Fork is this smarter correct thing for client applications to do to be like you know working on implementing eof compatible Solutions Etc but like to wait to deploy those until after the hard Fork is that that seems right to me but I yeah oh definitely um say that's the right path I think the right path also is like being here and engaging at this time because we want to build these changes so they are supportive uh you know as supportive as we can of developers who are building things and it's useful to have this kind of input so I appreciate you guys

providing some of that but yeah I wouldn't deploy anything until um it's accepted into a hard fork and the spec is like it's pretty clear this is what is going to change cool okay that's what I figured but I appreciate the confirmation there and um yeah we'll just say like from our plots perspective definitely want to make sure we're managing this transition correctly but also like having a spec for how to correctly use Unchained storage contracts is very exciting so I'm really happy this works happening great uh okay we got 12 minutes left let's talk a little bit about 4337 and the um Banning of code introspection or sorry of gas um observability

have you thought more about this at all Alex yeah unfortunately identify time um in the past two weeks the no no real progress I'm not sure if anybody else had any time to think about it so I did have some thoughts about it so there's two worlds we need to worry about one is the um mixed Legacy eof world and the other is the eof only world um in the mix eof Legacy world if if eof doesn't have gas observability that's not a problem because you will write all

of your um bundlers to run in Legacy and the first thing they'll do is they'll call eof code um we intend to have Legacy to be able to call anything directly in the eof code we don't anticipate any bumps we'll probably smooth down any bumps if we find them so so today on mainnet the bundler should just continue to work as is um where things get trickier is in Chains layer twos where it's eof2 only um and I think that's a bit further down the road my thought is the future I'm hoping for is the account abstraction will be a thing that will be built in locally to the chain rather than what is basically

you know a second class hack contract to to emulate a feature that belongs in the protocol now the upside of this approach is we're socializing in standardizing the whole user operation binaries and we're proving Market acceptance and Market usage of this so when account abstraction is brought in at the protocol level there will be existing demand and usage and it will work work much smoother and I think it addresses the whole chicken and egg problem um the way it's working right now so so my thought is you know if it's going to be a protocol level acceptance um that that will be the long-term eof only chain rule is that it has to be done in a protocol level and I don't

know if that's um acceptable to the 30 to the 4337 crowd or not um if that's part of the vision but I honestly don't see how we can enforce gas limits um with with sub calls and gain the advantages that we want to gain out of banning gas observability I I think it's a hard a really hard problem to solve that I don't know there's a good answer without protocol integration thanks for that Dano um Alex yeah I just wanted some clarification then when you said that they can just use the Legacy stuff did you mean that uh the Legacy code gonna create the UF code

that is the trick yeah Legacy code would need to be able to deploy an eof contract um via a user operation so that's one of the reasons creation right what if you want an uf2 wallet uh can't you just have another eof contract um maybe is like permission it can only be called by the entry point contract and the entry point contract would call that I guess it would be slightly different because your contract creation would rely on that address versus the entry point contract but I think it could be like a small addition to the current uh contract architecture and I think that's also why I wanted to

move to referring to um create four contracts by hash instead of by index so it's been a little easier to bundle so if you need to combine the contracts and move them around or let's say you're bundling up a bunch of contracts they're all creating the same contract you could refer to it by hatch rather than by um by index it costs you know more bytes than a byte code to do it but it provides the ultimate flexibility but I mean I don't think this fixes anything because see the either you have the user having the ability to submit random code right and then

either you go the Legacy route where you can limit gas but the code is going to be observable or even if you have like an eof proxy which creates it ultimately I think you lose yeah I guess so I guess the point is that you can limit the gas from Legacy when you call the US proxy right that that's the trick yep yeah I guess it works like 457 will continue to work in these

chains that have both the Legacy context and you have context modulo some maybe minor changes and additions the big concern is these worlds where you have no Legacy context there is no gas observability and all the entire execution layer and I guess right now the only real the only real proposal for dealing with this is saying just that this should exist at the protocol layer right and this all I think is also another reason why I think we should have different op codes for Call delegate call and static we're going to take the gas out because if we get it wrong and we decide the solution is we need to

return gas observability um we can't just change the cost semantics of those three operations um so making like you know a call to a delegate call to or status call to or the call x with the immediate that sets the modes if we put that a different place and we figure out things don't work and we need to return the observability we could just return the existing op codes I guess it's something to just continue

keeping in the back of our minds as we go forward because I know that that's going to be a question that comes up as we move closer to become accepted for a fork but we've still got some time so let's just let that simmer a little bit five minutes left any final comments topics to chat about okay guys let's call it um thanks for coming we'll talk again in

two weeks I'll set up the agenda issue yeah talk and evm channel in the meantime have a good rest of your day thanks thank you thank you