EOF Breakout Room #2

uh I'll share my screen and we can see how that works so this is the checklist right now these are the EOS yips that we've been working on and the open issues so the first one is just renaming all the UF Eeps to have this prefix a little choppy can anyone hear Pavel or is it everyone I think issues on my side okay yeah I'll be I'll be like in some better Sports in 10 minutes okay sounds good um yeah so I mean in the meantime uh we can go ahead and start going through some of these things the first one is more of just uh operational thing having this eof prefix for all of the UF Eeps I think this makes sense there's a question does this make sense for static relative jumps I feel like it does for now because we're sort of considering all of these for Shanghai together as an atomic package so we might as well just do this and if later on for some reason this falls through we can just remove it uh I don't know if anyone thinks differently about that she's gonna have the the reason this came up because uh there was no nice document like this listing out what is considered and you know like a entry point people could find all the editing information and so what people did they were rather grapping for UF on eip3 on the torque and which is currently not possible um right makes sense I've been trying to push people to this page when I can as well just because I think that this is a good overview place but yeah I would be good just so they can grab through it so yeah if you guys want to accept this PR to make the modification that would be great uh first Eve to talk about is 35 40 the object format V1 first question Moon generic contract creation rules from 3670 foreign so this is basically adding this logic about how to deal with transaction creation so the the request only actually like copies it from the other one but I think we can move most of this like generic logic like how how contract creation fails like when it fails like what is the gas cost of that because they're kind of general rules about dof yeah for some reason like I don't even remember like they end up in the second the second AP but I think that was already seen as a confusion so that's later so um yeah I'm for like moving what's possible to the to the main one and I think the the code validation will be just uh smaller because of that so yeah yeah um yeah makes sense I'm in favor of that foreign okay next we have a question about whether we should forbid eof deploying Legacy contracts I think yes but I'm also like very far on the spectrum of generally restricting what you know people can do with respect to Legacy so does anyone have an argument for allowing you up to deploy Legacy contracts I think the main main question there is should rather be is there a use case where this is desired I think we asked this question a bunch of times and maybe there was some discussion around it at devconnect but unless unless there is a use case found which this would prevent and the use case would be important I think it would likely simplify everything if this wouldn't be allowed right and I think it's true to say that if we disallow it and later on want to uh you know allow Legacy contract creation we don't have to bump the version whereas if we do allow Legacy contract creation we want to remove it yeah we might end up breaking things if we remove it later so it seems better to restrict as much as we can in the beginning and see if people request the functionality does eof break Legacy eof does not break Legacy contracts okay so I would say go forward let's go forward with this and if any thing comes up where people are saying they had a use case for it we can discuss more but I'd say let's just be restrictive in the default case okay clarify overall code size limit still applies I haven't looked at this but I assume this is meaning overall as in like the whole UF container not the sum of the UF code sections yeah I don't think he modified the meaning of code size limit because yeah that is done one step outside of this yeah so my at least my assumption was that the overall I mean what is called today code size limit but we try to reframe it to container size limit but basically the current limit would apply to everything um but we did had a discussion and both of the context of 30 3860 and eof what if the limit would be changed so what the 3860 says it's the creation code limit is twice of the deployed code limit um and you were thinking what if we would actually modify both of these to be slightly bigger than it is today um that is like another discussion to be hit at some point right yeah that makes sense it was confusion was about like what yeah what does this mean um I think we we always intended to be like that whole thing yeah but maybe that's I guess we might need to read the specs to make sure it's clear yeah I mean for that I believe you need to investigate the origins of the limit why the limit was introduced and what it's supposed to cover and restrict um and I think it was more about straight State growth and not about like drug test analysis but if it would be only for covering like the jump test analysis then of course it would make sense to say that it only covers the code section because that's the only one which would be affected yeah um but the main question in this is are we even open to complicate this limit uh so like Erp 170 are we hoping to complicated such that it wouldn't cover everything but sections and I think the likely answer is no because that seems like seems like a quite a complex rule set but maybe that that's something we have to answer I would also agree that it would be better to avoid complicating this 170 rule set at least for now but yeah I guess I also was thinking that the code size limit was originally in place with the assumption that jump dust analysis was not linear in cost so in that sense it would make sense to just do it over the code sections but yeah I think for now my preference would be to just stick with what exists there and run the limit across the whole container okay I think it was not only for that but also the state growth because um I think it was stage growth in the sense that some codes were not well priced and the bigger it animated containers you could craft much bigger code abusing those OP codes so I don't think it was related to jump test but it would be yeah we should really ask you know maybe Martin you definitely should know the answer um to get an understanding you know why why was the limit added and that should answer this question too okay um anything else on 3540 that we should discuss okay 3670 UF code validation we didn't mention this but I assume that this uh points will also involve removing the contract creation rules from the code validation so the main thing to update with 3670 now is to reject the deprecated op codes call code we you know mostly already accepted that's going to be deprecated has been deprecated for a long time self-destruct I guess is the more questionable thing should this be deprecated should it not be deprecated uh what do people think about that so I guess I internally expressed my opinion um it's a call code I'm definitely in favor of because who needs call code um self-destruct my opinion was that because it's still floating in the air um I think a final decision of about that can only really be made once there's more clarity what the future of self-destruct gonna be um but I'm leaning more towards you know just just restricting it because it can be added later yeah I was also leaning pretty hard in restricting it but now I'm like questioning slightly more with these people wanting to use this as like uh um uh like a pay-all type of op code and so even if we do get rid of the self-destruct functionality of the op code and it's just send all I wonder if that's going to be a frustration I do still think the evm is better overall without it even if it's just pay all but I'm not sure if that will upset developers but you know I think again like if we're coming from the mentality of more restriction in the beginning this is something that can be added back if people say you know on Legacy we have self-destructive percent all we should have it on uf1 that can be added in a future hard work um isn't the only reason why I self-destruct these on the on the Legacy contracts currently is because it is probably going to break some contracts in the minute yeah another reason we are not basically removing it is because we are afraid to break some things but with this format we are breaking a lot of things I think should be okay just to remove it all together yeah and yes and then yeah yeah I agree sometimes you just gotta like rip the Band-Aid off yeah this spawn was like should we should have done that a long time ago right but yeah I guess the argument is that if a bit is still a likelihood there's still stuff this truck can be modified in Shanghai so the same Hartford and if that happens then the decision here likely has to be changed in light of that you know whatever the decision going to be but if self-destruct is left as it is in Shanghai then I think restricting it is the best way forward sorry if so if no no change is made to self-destruct if no changes are made in the rest of the evm for self-destruct then eof shouldn't allow it yeah but I think there's there's a hope that self-destruct change is going to happen anyway yeah and if it does then uh yeah I mean just really just a note you know we have to keep in mind to review this yeah in both cases we are removing self-destruct but if self-destruct is basically rename to mobile it's like different top coat in it in another in any case but yeah I totally agree with that sounds good okay uh anything else on 3670 code validation hi Dana hi sorry I'm late uh calendar posted over an hour later so yeah I think yeah I think Tim accidentally put it on at yeah an hour later and then I realized this morning so I moved it to the correct time okay did I miss anything good um no I think we've just gone I've recorded a couple of the things related to 3540 on this document but generally this has all been accepted so uh yeah we just we're finishing up 36.70 if anyone has anything else otherwise we can go to 4200 okay 4200 static relative jumps one point here there's a question should we calculate the offset of the relative jump from the current instruction position or should we calculate it from the next instruction position which is plus three bytes taking account for jumping over the op and its operand Alex is in favor of the plus three that's because it's more favoring of jumping forward than backwards is that right yeah and the calculation is also yeah I mean in my mind it seems clearer um yeah and also like jump zero becomes a no op in this case uh jump minus three becomes an infinite Loop jump what jump minus three becomes an infinite Loop yep I don't have a preference does anybody have a preference for changing the semantics to offset from current instruction foreign [Music] but it's it's tiny tiny difference so I don't really care so much but I kind of this plus three shows up in some implementations for sure what do other app club sets do for this it's nothing really like similar to this one think there's no relative jumps yeah yeah well I think jvm has had it also from the like it calculates from the instruction I believe but I'm not entire issue but I did some research on jvm uh when I was comparing the verification Daniel do you want to maybe speak from solidity's perspective like in a similar two points yeah I mean yeah I mean the offset doesn't make much of a difference for us we can generate code either way so I don't mind that at all General we have been discussing for uh or starting to discuss whether we want to have the Erp extended by some jump table jump I'm not sure whether we want to go into that we're not entirely clear about that yet uh but yeah regarding the offset first not to just distract uh yeah it doesn't matter to us okay um I don't know how to make a decision on this right now we're still at the plus three bytes I think you know we should either keep it at that or if somebody is able to point to a few other instruction sets that are doing it from the instruction itself or you know some other reasoning that we should seriously change it I think we should just stick with what we have I think there are two data points which can help make this decision so one is looking at the once this is implemented in all of DVM clients um look at you know which way has more overhead from the evm perspective I mean Pavo said that in evm1 the current one has a slight overhead right um but would be nice to see it across all the different tvms so that's one data point um and I suppose slightly we have to prefer um The evm Interpreter perspective but the other data point could be some statistics from solidity once this is implemented in solidity which is which is planned um you know in this year so what's it it's implemented in solidity we can collect some statistics of frequency between backward and forward jumps um and that's like another data point you know which could help this decision okay um but yeah I think the evm implementation has precedence because you know we want to make the evm implementation is simpler yeah uh makes sense there I think is definitely going to be an overhead for the plus three semantic but it's you know just one addition so you just have to decide um yeah is that worth it uh okay I wrote that note on there anything else on 4200 that people would like to discuss um Java jsr does it from the instruction not from the next instruction so that's one point okay does anybody want to just go ahead and say we should change it right now given that information or we should just wait until we have the feedback that Alex pointed out um let's just go ahead and change it unless we find a counter example because the overhead's in favor of changing it jsr and Java is in favor of changing it um that's two that's pretty strong foreign I'm happy either way so are there like any other languages or like via I think like um web assembly is kind of irrelevant because they they have much more sophisticated jump instructions based on labels so I think it doesn't show up like you just what's the name of the Microsoft's bike code they are something like that it's CLR CLR Cil that's what I'm looking for 10 minutes but the byte code's called Cil ant okay let's salute back to this after we look at a couple other uh some assembly I think there's one more data point so what Daniel mentioned we have been discussing the jump table or like this yeah jump V instruction and there are many different questions around that um namely whether it should be dense or sparse whether it should have the data as an immediate or in a section um this depends on on many questions we've been discussing but in it would be nice to get more clarity on that and I think we want to discuss that on Monday with solidity and that may also have like an influence of this because ideally if you do end up having such an instruction it should be following the same semantics as air jump um so that may be another data points on it sounds good let's just loop back to this next week okay okay we will also yeah just I'd also try to join next week to discuss what we ended up with the solidity usage of from table instructions and stuff like that okay yeah okay uh all right 4200 uh a 7 47.50 you'll have functions first thing is we've set the call F and red f op code numbers to b0 B1 I believe that's what this change was for yep b0 B1 that's okay with everyone any one against that okay set gas costs for Cola front F I don't know if there was a PR for this but it's listed down here red f would be three gas call off would be five gas I haven't looked at the instructions enough lately to know yeah these numbers feel but I assumed that they're okay so so the numbers like the the last section is kind of I think they are a bit lower that we originally proposed uh but I did try to kind of analyze what's like micro micro I don't know micro instructions they actually then the implementation should do and yeah based that on the so they click Master you like to give give some consistency but they also like sophisticated I mean they have I think lower that some people might expect so I'm not sure this is not controversial but uh yeah I mean one thing they are from my side from solidity core generation is one of the issues to the eof functions is that it will make it hard for us to do bytecode level code deduplication because we can't jump across different functions if the app codes are as cheap as they are right here then a conditional jump and they call together are still cheaper than a conditional term a jump I which will mean that even if we don't find a nice solution for the problem I'm thinking about next week which we will try even then it will not be harmful in that it will be more costly than what we had before so that's an argument for these low values to be nice but yes yeah that's one piece of feedback I've gotten and yeah you know we'll talk about it or you guys will talk about it more with this jump table instruction but um some people were a little upset that the relative jumps because we can't jump to the dynamic location anymore was more expensive for their optimized by code so keeping it cheap makes that a little bit better yeah we're actually talking about um three features in total over the past like two weeks so the jump table is one a conditional call is another one and tail call is the last are these things that you want to try and also put in the suite I think we want to do a bit more analysis From soluti's perspective to find out which is the the best of these um ideally we don't want to put all of them because we still want to keep the surface relatively small um but I could see um you know the tail call or the the conditional call one of those two to become part of it I'm leaning towards the tail call um and the jump table obviously would be rather useful for many different cases but that requires more analysis um From solidity's perspective yeah I think we could live if we had to without either but I think both would be very good to have so but yeah we will get back to you once we I played around with it a bit more next week okay sounds good I think like just generally the sooner we can have like some sort of spec or you know something introduced teleport devs the less that people will shout about more evm changes going in so just to like keep that in mind yeah my plan was to draft up um maybe not an AIP but at least a spec for these instructions and uh we want to have some preliminary idea before next all could have next week um yeah whatever you want to propose these or not that would be great okay that was a gas costs the next one redefine code section header to be an array of code section sizes this I think I opened this PR um yeah I think I don't know you guys can weigh in but it felt like the way that the eof header was uh evolving was partially due to the way that they were written and the anticipation that some things would go on before others but if we think about them all as the atomic unit now it feels like it makes more sense to have the code section size just be an array but and there's like different two two is a repeated field though for functions two is a repeated field um the code Type yeah code's repeated isn't it I don't know if I follow there are there currently it's allowed to have multiple code sections and it will still be allowed to have multiple code sections but in the header of the eof container each section is like an individual thing and so you have the section prefix one code and then you have the size of the code and I'm proposing that you have instead of multiple one prefixes code size you have a single one prefix for code and then you have a list of code sizes each two bytes and there's two ways you can know the end of that list it can either be that we enforce there always be a type section header and so then the size of the type section you would just divide that by two and that would be the number of code sections you read or you could have like a no Buy Terminator I mean aren't synthesize build itself fixed length anyway so you can just divide the size of the okay Etc yeah you want to mix the type in the code and what's the discussed um I mean do you have it in a single header yeah I I kind of proposed that but I didn't actually dig into like uh I think this kind of a big like technically makes sense uh but like we lose but just like this like one level of abstraction that the way the uh the eof headers are defined like it's very simple that it does the kind and the size of the content um so the type sections have actually the types in the content and or code we can't do it so yeah but because like we always require the the type and the codes going on and we kind of matched so we can actually combine these two uh like this I think number of options you can do it you can even put the type in the content like prefixing the code that may be also annoying because I have to remember that the first two bytes means something different than the code um yeah I don't know I think yeah it might be better yeah keep them separate yeah I think there's like multiple options I didn't actually put a lot of time in Korean yet uh so yeah okay uh I don't know if we can make a decision on that here but yeah there's lots of different ways we can do this I think we should definitely consider yeah different different ways and I think the important indicator of which ways are better would be like the parsing complexity of it so it would be great to keep the parsing complexity low and also keep the total size and like you know redundant information low but I would rather have a bit of redundant information if it pertains like Simplicity of parsing okay uh clarify if the data stack has less than color stack Heights plus the code sections outputs then execution results in exceptional halt what happens if the stack height is larger than the number I don't really understand this one honestly I if the stack height is larger does it not just return yeah um that's complicated one okay yeah so uh it's mostly about the read uh red f instruction that ends the the function execution that's related to like the validation as well um but uh yeah for this like eof functions EAP we don't have the strict validation yet so yeah mostly you need to have uh uh in the type you have the number of outputs specified for a function and so you need at least this number of outputs on the stack when the return f is executed um and and the spec says that it has to be at least this number but if you think about it you kind of want to keep keep the top up stuck items as the output right so it seems like return F would need to kind of modify the stack so only kind of keep the top on and remove the some additional at the bottom or something like that and unless we keep it like this and like somehow it goes uh but I'm not sure maybe you can discuss it later offline uh or okay we kind of will go back to this when if we have time to go to the to the stack validation because it's kind of repeated there as well and I think on this strict validation what we end up ended up with is that we want exactly this number of elements on the stack so far um so you can kind of make it the same restriction here as well so not like it has been above or equal but it has to be precisely equal and then the implementation is kind of trivial yeah that of course shifts the complexity to us but it's fine we've been that are doing that always anyways so yeah that's that's correct we kind of aware of that uh but I think the kind of the resolution was to like see how the code generation would handle that like how bad it will be and then we can always be fine I mean all the functions we generate so far already have exactly the amount of uh additional uh outputs on stacked so it won't make things easier for us but it will not make it harder than they are before so okay okay yeah that's what I heard and that's also like the the next item which is I think yeah yeah same so I'm sure I explained it well but I think I can handle like both these cases later with some okay proposed change okay let's let's do that and just keep going and we can revisit it a bit after you yeah do a little work all right um okay so let's skip this one too so the next is limit number of functions to 256 so that we can use a single byte immediate for call up that seems okay honestly I just I don't really have a way of making a decision on on that I don't know if anyone has thoughts on why 286 is okay so that would limit total code size to about a mega and a half I think I don't know if that's good or bad foreign oh because of the max code section size yeah I think I did the math round let me fix it well Megan a half would be in almost an order of magnitude more than we have now no no I think that's the confusion we already discussed like the the code size limit kind of wraps all of all of it like all of the eof container I think that's right what at least that well currently there's the the limit of course by the EDM but for the container the largest it's actually 16 Meg it's the largest possible container would be 16. okay okay I know what I mean okay sorry yes and um 16 Meg should be enough for anyone but it does kind of prevent the hybrid optimization of having like a lot of tiny Hardware functions I mean possibly um this is yet to be found out with the solidity implementation you know how many how efficient is it gas wise to split up because currently solidity already has an insane amount of helpers in the code generation and then those are in line and and potentially reduced and deduplicated currently um but we yet to see you know what strategy would work the best with the function sections um depending on the gas options there yeah the duplication may end up generating small functions in large quantities so if we end up having duplication by uh yeah block the duplication by generating functions and calling them even though it's just the tail of a function actually but so yeah I'm not entirely sure how many functions we will actually end up with on the average in the end that also depends on the gas price I would say if it's efficient or not yep it's 1 000 right that's I think it's somewhere there soldiers I think this somewhere I'm not sure exactly but I think Andre put a limit on this like some number of but it's 100 1024. sections yeah okay um it seems like most people are in favor of this I will say that like my uninformed take as a 256 feels like a small number we don't have gas costs specified for college for return F either which I think it's a question of cost there uh those seem low I don't know yeah that's like I think you know as low as we can but but might be controversial to do it this way although if you it shouldn't be cheaper than jump there's no way it should be cheaper than jump yeah it's it's one more jump it jump and jump higher eight and ten yeah but jump and jump I require the jump dust analysis right but you still gotta you either have to keep all the code in the same memory and change your offset which you know would be the cheaper way to do it or load in a new code section in memory I mean it's I think there's a bit more than one gas of work to do for a call because you also gotta check stack arguments do you check stack arguments is it not there's no is there checking I think you just pop it off and then jump to that section because it was validated deployed yeah you can you can pretty validate that yes yeah so yeah let's think about like the gas cost okay yeah yeah I don't know like my understanding is reverse so maybe we'll keep it as it is for now keep it as 10 24 for now no like the current one like two bytes immediate right so like we don't have to change it if we are not sure and we can look back to this okay uh all right we've got 13 minutes left as well so yeah let's just keep that in mind we have a couple more things to get to 54.

50 and I think we should definitely talk about this one since it has some of the most criticism right now okay anyways reject jump jump I jump dust I mentioned I think it might be good to expand the rationale a little bit on this just like what does this really provide why I do this Etc but it's a favorite that's the the first first moment we can actually do it yeah because we have replacement and like the benefit is right I think it'd just be good to say that like explicitly in the EAP just for people who don't have as much context I think that that's there's no even request for it at the moment yeah I guess yeah everyone is on board with that yeah okay next one replace jump desk with no op it kind of already is a no-op it just happens to be a jump destination yeah I think that's so yeah we can be removing trumpets as an invalid we can kind of reassign it like change the name uh I think we can consider it offline and the same for the the PC next one like I had it somewhere in the notes uh okay so you will you won't be able to observe like query on the code uh but we didn't do any black analysis how this is good or bad so let's keep it for now okay yeah sounds good um reassign your section IDs to be in order that makes sense to me sweet uh make type section mandatory I I think this makes a lot of sense I think the reason it wasn't mandatory was because of the potential of different things going at different times but if we are doing them all at once it seems like extremely unlikely that we'll have a single code section deployed so there's actually some arguments here um some charts from Viper left some comments on the if you're magicians and also reached out because his comments were not answered and this was from a buyback what he has was why even enforce a code section for data contracts yeah um and you know in that case I mean the type section is is again just an overhead but if you have a single code section the type section definitely is an overhead um well it depends on the validation right um depends on the next section here um but also this discussion whether we're gonna have the type information in the code section or not yeah I think there's a lot of questions we're interested in any case um yeah but the the optimizer Community definitely would ask you know why you have this if it's not used uh I think it doesn't really matter in terms of uh like validation because we just have like implicit type there like for the so it's I think it's like rather matter of encoding this information but doesn't really change how it behaves foreign [Music] no okay so there's still an argument for data contracts but is it really that big of a deal to have a single byte in the code section I mean the extra overheads like five bytes total probably so because you don't have multiple cases yeah this information is available to the contracts if they wanted to parse it because they can access the bytes with that what's the best way to make a more informed decision on this like do we really need to like sketch out the different approaches at this point and just see compare them and see if anything falls out of that or are there other things that if we answered this would become clearer and all they're fighting for is like what 28 gas or if it's zeros mostly we're fighting for let's talk about yes with respect to contract deployment right yeah oh employment's 200 to buy two so but still we're talking about small amounts of gas we're trying to optimize okay I think like I can maybe write up a couple different approaches for doing this unless somebody else would rather do that and then we can compare them okay you know I'm personally in favor of uh can we get more strict to make parsing easier so optimizing for runtime um cost yeah at the expense of the storage cost um but you know maybe this is something which can be also floated at other client devs which is more important are they do they really want to optimize for um you know storage cost instead from like a design perspective yeah I think I'm on the same page as you so I can write a couple different ways of doing that and look at the differences a bit and yeah let's talk about it again later foreign clarify the 1024 stack limit still applies I think this makes sense and yeah just a simple change to 47.50 just clarification okay six minutes 54.50 stock validation uh yeah this I've heard the most criticism about like obviously right now it's not something that people are considering as much as part of this like full eof Suite I realize that why everyone's call feels differently and like we want to do this but uh yeah it's not considered for the next devnet right now and Martin has probably been the loudest person who's had criticism of this specification and how ready it is ETC so I don't know if people have thoughts on that uh just a quick question um if we don't if we don't end up cleaning the stack on a terminating instruction where are we going to store the data that's located on the stack um actually I didn't didn't understand the question yeah I I the way I understand the question is like the stack elements just still exist from the like parents call frame and there's no need to clean them up yeah so like let me quickly explain uh when you when you call it a function then you get like the subset of the stack space available and and the idea is that when the function returns it has exactly it leaves on this this subject subsection exactly the number of items that is specified in the function type so the caller know exactly how much items will be in the stack after the call it's not a guess it's like kind of explicit and it's a matter if this is verified on deploy type or is checked at runtime but the behavior is kind of a bit more strict one point I just wanted to mention is that I think you know with respect to Martin something that would make him feel better about these things is if we had more motivation 450 450 in terms of what you can do with compilation because he generally feels that 5450 probably isn't worth it if like the only thing it's doing is reducing the number of Checks In The Interpreter Loop for underflow overflow and so if we can provide some motivation that this makes things better and you know future worlds that would probably alleviate his concerns for that so something to consider I mean the biggest sell is for future jitting but right um that's you know Greg's you know not in favor of cheating because it feels there's concern for logic bonds but I think a single linear analysis will remove a lot of the logic bombs um there's always you know multimodal interpretation too you can mix your compilation and your inter your agitated code at the same time um but I mean there's also the the some people feel like especially in the move Community the dispute of The Interpreter is secondary the data access so there's we're also fighting Upstream against that yeah is is there anything other than future jitting that we could and stack reduction that we could pitch for that foreign no I don't think there's like much more to to find here it's like it simplifies the The Interpreter at runtime but the the the whole performance gates are not really big and uh and like my kind of like different thing thinking about is that we we do need to to do uh code validation anyway and right this adds additional paths to like to to more validation and this is it's a bit like like I kind of feel like how how much we can push it and this seems to be like the final step uh I don't see anything about that uh but yeah I understand this concerns maybe it's not worth it but I I think it's like either we created here or like we will not be able to do it anyway so because if it doesn't go in the first suit like it's definitely not worth it to introduce it later like to have the contracts that has to obey it and the contracts that doesn't have to abide because they are right you have one but yeah okay and yeah I did I did put like newer version of that like it has the text back so it doesn't have to follow python code um and I like if you really do it well uh really kind of advocated for it but uh that's not my intention but you can kind of replace the the previous CIP with only this one but that's that's mostly like how to organize the specification for it yeah okay guys we're at the top of the hour any final comments questions things that we need to be thinking about before ACB this week next week can we add more restrictions to stack validation um I can draft up a doc for it but if we could require that any instruction following a terminal instruction must have been referenced by a prior jump you know we could word Smith it um we can do single pass and we can do dead code checking too and we could do all this validation in one Loop and pass through it once and get all this okay yeah I mean if you want to write something for that they think that would be great I don't yeah I don't have enough context you know how likely something like that is but it sounds useful okay thanks a lot everybody this was helpful thanks a lot it's Apollo Alex for coming up with the list of open issues um yeah just a little bit of work to do I'll oh I guess like one other thing is that Mario Vega has been working on some more cross-client tests uh I can post the link in the Discord evm Discord channel so if you are a client developer implementing this there will be some more tests coming out soon uh yeah anyways looking forward to hearing the outcome of your guys's conversation with solidity and yeah let's keep chatting in the evm channel thank you bye-bye thank you bye have a great one you do