EOF Breakout Room #4

cool okay everyone welcome to the fourth breakout room of eof we've got some things on the agenda to discuss I think the main stuff is to talk about the open spec questions but I think it would be good to just start with updates from various people so let's maybe start with client team updates got a particular client team you want to start I think that Basu has been on is unmuting so okay um so basically we have the five VIPs um in a functional first pass implemented um I haven't heard any update on changing the eof container so I went with the UF container specified in the unified spec um I don't know you know there's a lot of PRS flying around as to what the final state of the eof container is but the relative jumps in the function calls would be relatively uneffective if the container format was changed again so I've been trying to copy over test vectors from other clients trying to get a unified test Vector again um you know that good I'm making them in such a way that they didn't rely on the container um as far as you know being able to test what's going on with stuff like return f um that's the tricky one because you got to do the code sections have that logic built in but relative jumps is all within one code run so that's apparently isolated so so that's our status we're ready to you know start interrupting and see what's going on with it see what the more interesting contracts are to find where the real interesting breaks are okay awesome great uh Aragon is anyone here another mind okay I can go I guess for guess um I have Rewritten our implementation of eof uh pretty much you know partially just to try and a couple of different approaches for things but also to iron out the unified spec so I've implemented the unified spec uh from scratch in guess and yeah I've replaced my PR so if you've been looking at the eof bundled PR and guess that now has that code instead of the older code the tests are still sparse um but I will be working on tests mostly for the next week I think and I will also be trying to help Mario with the tests for the cross clients tests any other clients here that didn't give an update I could just speak quickly uh for the work that we've done on Aragon uh it's essentially been tracking your guest changes and maintaining those uh that's the general status okay great uh is any compiler teams here or anyone who has updates from the compiler work we've just started work with the Viper team just yesterday okay great uh what is the timeliner plans do you think uh completely tippity we've just started so okay but it looks like the volume um you know the the volume of changes will be fairly small to it uh the real problem is testing because that depends on high evm you are nowhere I see okay uh I might mention this to the pi AVM team Alex I can't give an update from solidity um so solidity has uh a while ago merged uh at least like the base scaffolding to support um turning the eof on and off and then there are a number of PRS which haven't been merged yet but they are actively worked on um there is a PR for the container format which is tested against evm1 there is another one for static jumps and as of yesterday there is also a working implementation of function sections um without using jump if only just call it and rediff and they are seeing um I mean they in the first version they have to disable all the optimization stages because those need to be updated um but with the optimization stages disabled um they are which also means there's no deduplication of code they're seeing a slight code uh increase which is expected without the duplication but at the same time they are seeing measurable gas savings already um and keep in mind this is without having any kind of optimizations um yeah I think that's it great thanks for that update um I guess that's probably our two compilers here okay so spec updates does anybody from the Epson team want to give an update about where you guys are at I listed a couple things on the agenda of things I know that are still open that we've been discussing but would be happy to hear what you guys have been up to the last week or two um so this week I I did merge some of the changes that were kind of under review for longer um I think that the significant like functional change is that um uh 30 36 70 doesn't require terminating Construction um of the last um instruction in the code because that is supposed to be delivered by uh 45 54 50. and that's not to be in conflict and doesn't have like um redundant checks um and yeah I think that's that's mostly it and the other world mostly editorial um what is missing is this uh the the main container format obviously I think we'll spend some time today on it and uh I plan to reach like the last one which is the stack validation uh but I kind of stopped on the jump F and redef which has changed the semantics okay maybe I should mention that there's a additional functional change but this happened when I was actually um offline let's say so I'm sure how much this was discuss previously um yeah but uh like both of them jump every death are specified in the way that they require automatic stack cleanup to be performed as a part of instruction um and I think this like this small issues with this how this is done so that's mostly like I had some concerns about it and uh that mostly stopped me from reaching the last EAP actually um okay I'm just browsing the the issue list so I think um like that's mostly reflects the the current status so mostly the container format is not it's not finalized and this stack of validation doesn't expect to be like chain functional functionally but uh yeah the the IP needs bigger update in terms of just the text sounds good thanks for that update uh do we want to start talking about the header format or do we want to jump and talk about the stock clearing for jump up and right off first I guess we can talk about the header format first if that's okay um honestly I'm not sure what has really transpired since we last talked about it two weeks ago on this call it seems like you know uh bases implemented the this unified spec version of the header format I've implemented the unified spec version of the format this is you know what what are like the open questions here we have this document I can post it the container simplification document there's different proposals there's different goals I'm kind of at the place where I'm not really sure how to continue moving this forward with hip-hop um so how how do you how do I think about it is that like I think like the basic option is do we want a strict format that's kind of predefined where the values are in the on different offsets in the container so that that's like I think it should be simple to to pass and like yeah like efficient in terms of how many buys it uses but uh like the trade-off is you you you lose all the flexibility to be like new stuff about it later without breaking the the compatibility with with client formed um so that's like I think one of all the options we have and the other one is uh just to improve what we currently have so we keep the differences mostly do we want to have something like section kind as a buy that indicates what's follows so that's this kind of extension point for later but we actually can skip that as well and with with the the section kind kind by it uh I think we're going to improve what we currently have by introducing arrays instead of individual sections um I think this changes relatively simple and I think it solves most of the of the issues this change being what's listed in the unified spec with the array or something different uh I think they're the two through almost identical I'm not familiar with the unified spec but uh yes I guess like but mostly like you have a section client which says the code section but like instead of have individual sizes you just have array of sizes so most of this you have uh like single code section but it's it's separated by the by the size values into partitions however we call it but it's like it also has some additional benefits so it kind of guarantees by design that the code section so like this partitions of code will be adjusted it's not like you can split code sections with with data sections and so on like in on in general view right I think it's nice so it mostly it saves you the this like linear redundancy that you repeat the same byte all the time but you have some this this additional bytes that kind of I think we could live with without it if we really want to uh but yeah uh that's kind of the trade-off so there's like some fixed number of additional bytes in the header that will be placed so that's kind of as the original EOS was designed but [Music] um yeah so I think that's that's mostly how I understand it either we really go really fixed format as like IP I don't know something like that right so like it's like two bytes are there the offset and and that's it or we go with a bit more fancy but it's not it's not more fancy that the UF originally proposed it's kind of improved version of it right I guess like one like threat of conversation that has transpired in the last week or two is this post by vitalik and I think that um you know one takeaway from this post is that it's like you know it seems like a very important thing to not have many eof versions like we're talking like maximum two but most likely like one elf version and so what we do we should really consider about like the forward compatibility uh there are the future compatibility of things and I think that having these kind types does make us much more flexible in the future over the fixed um format so that makes me Lean Like A bit in that direction Moody ass has Proto buff been considered for the container format do you guys have a comment on that uh I don't know it's uh I think like what you're currently trying to do is like to be recruited that simple uh that's why we just click have sizes of two bytes and that's like fixed this not really uh maybe that's I don't know maybe some people think it's like like but but Direction but uh so I guess what should we do to make a decision on this we're like kind of getting to the point where it's really important to make the decision so clients can Implement and start testing and we can be ready for this like January fifth deadline um and it doesn't seem like a lot of new information has come out on this header format in the last two weeks so do we have the ability to make a decision now or do we need to acquire more information to make it in the next couple days uh um so I'm I'm also kind of in the favor of having this more flexible one like more generic format that leaves some space for extensions um so if I think nobody protests in the sense that we want to kind of save every last bite of the format so that uh the storage on the the codes on chain is like minimal so I think I would also go with a bit more flexible and if that's the decision I think we can sort it with with Matt offline uh I think even today that's okay because I don't think there's like much much friction points in the exact design so so yeah if that's we go if we go with this decision then we can kind of propose like present um kind of like single variant of that for review uh probably today or tomorrow that's kind of my understanding okay that sounds good um Dano has a question same question as Moody but for SSD I think the same answer probably simplicity well I I certainly prefer a more flexible format so far as the forward compatibility issue um we we really shouldn't need very many future version bumps if we do this right right because adding an OP code doesn't change the version that op code never would have gotten through the validator and various other changes are like that one of the few things that would require a version bump would be if we tightened up the validator to give stronger very stronger guarantees which would break would break previous code that couldn't be those guarantees yep I I posted the anchor to The Container format and unified spec we can take this offline and you know maybe change like a slight thing there but if anybody on the call has comment on this format right now it would be good to say something otherwise we'll post a um you know finalized version to review later today or tomorrow um yeah I'm starting like the the question about rotov quickly I I I didn't fully explore that for sure so uh but uh what can I say uh I think I'm not sure it's it's it's like right time to kind of explore it but uh yeah I think someone can kind of present example how that would look like I think that would be fine as well but I can't really if that helps or not for what we considered is um something else uh like having very link number encoding so it's kind of maybe like SSD I don't know SSD actually I know the ROP more um so whatever you have a size somewhere in the in the code or I guess mostly for the sizes and indexes all of that like we have fixed number of bytes that can be replaced with the like variolic number of coding which are relatively simple but uh and so sometimes it can say if you want byte sometimes you can add you one byte depends like on the context but if you have small numbers most of the time I guess it can reduce the two byte sizes to one byte with some additional complexity added so that's right kind of this this question showed up some like some number of times especially when you consider you have because with the fixed sizes uh yeah we fixed sizes of numbers you can you kind of have to pick the right size at the like very first moment right so for example if you want what we discussed for example that uh the call F is it supposed to have like one byte index or two byte index and with this like variatic encoding you can kind of Shuffle it because it will handle like small numbers as one by byte and coding and like bigger numbers one other two byton coding uh yeah but the most deck would kind of skeptical we want to introduce complexity so that's why [Music] that wasn't officially anywhere yeah that makes sense any other comments on this header format discussion so maybe because this is recorded but the all the the chat text isn't a lot of conversation has happened there um regarding the proposal of one and choosing product for SSD and I wanted to add that initially we did um instead of like a fixed length field we did consider using lab128 um but then rejected the idea because we felt like even that would be too much complexity um and clients would argue against that um for Northland savings and if that argument is correct then doing product buff or SSD seems like you know even way more complexity um I mean that's why we haven't really gone to that direction yeah it makes sense I think from like the guest perspective we would probably be against integrating like a parser like protobuf or level 128 into consensus okay uh moving on let's chat about um let's chat about this stack cleanup question for red f and jump f um maybe Paul or Alex you can give a overview of this um like to my understanding I kind of that's like my last two days to to digging um into the the specification of this specific aspect is that both the the instructions need to kind of balance the stack at some point like jump F kind of do it before the call because it's like the beginning of the color Reserve do it and the command but they they kind of have um like specified the exact stack height is expected in the call on on the end of the call and they need to move the some top stack items to this position in this way so um I kind of see like two issues with it like on technical level is it's it might be like complex in the sense like a bit time consuming operation because you can have functions that return over like 200 arguments or like receive 200 arguments that means if the stack is unbalanced at this point you need to move all of this 200 arguments to some different place so it's kind of like my move and the size of this can be like significant um so I I I don't think we kind of fully explored like what the complexity in terms of like how much expensive it is but I don't I'm not sure that the current gas costs actually properly reflect that uh and I think what is what is even worse for it is that it depends on their use case so like probably most of the use cases will not do it but you can kind of you need kind of design for the worst case anyway um and the second one I'm not sure I can like fully explain but seems to be like the reason is it's there maybe some other people can comment but I will do an introduction is that it like provides some usability um to use this but it means like for for compilers mostly uh but it feels to me like it kind of bundles it with on the way that maybe it reduces issues in some other place um this is related to the fact it depends on the like formally specified number of outputs but some of the functions doesn't really have number of outputs because they never return because they just terminate execution and so in this way you have like pathological option to create multiple instructions but having exactly the same code but formally they may might be defined like returning different number of outputs and um and sometimes that might be needed to actually be more useful on the color side uh okay that's that's all from my side Dano than Daniel so my concern with it is it's a variable execution time for such a low gas costed function if we were to allow the stacks to be cleaned up you know you have a 500 item stack and you're passing 200 items to copy that's at a minimum 200 copies and another 300 writes if you want to be safe and allow the stack and so that's highly variable for something that costs only three and four gas so that's why I would Advocate personally for for getting rid of that option from a security perspective because that's a way you could do a denial of service attack if it's especially if it's coded poorly Daniel yeah I think it was actually added to the spec after discussions with us and the reason for us uh get heading in that direction was fear of code reduplication becoming harder with eof in general because we don't have cross functional gems and then in some Corner cases these uh the specification of not having to clean up the stack helps there but given that we now have an initial implementation of the UI functions even though it's incomplete because it doesn't have the relative jumps yet and the code size increase is not as much as I would have feared we could also live without this so I mean I would be fine with dropping that it's yeah I think we originally asked for it but we would still be fine without it okay um that's good perspective um yeah I don't know what people think about that I think you know generally it's better to obviously ship a little bit less and later on add things on because we can easily do that in eof then shipping something like Jump app that doesn't have quite have the exact characteristic do we want that we want yeah I've I have never liked uh the automatic cleanup feature um for the reasons probably um gave us and some others if it's explicit it's much easier to know that it's correct um both for the author of the code and the validator and for just specifying what we mean by correct yeah we can all we can always add a cleanup op code later that does what we realize that it really needs to do right probably yeah I mean like from from evm point of view that's like like that would be definitely nicer approach but I I think it I try to understand and like I think partially understand like what is the usability case here and why this is like important um so kind of my problem is that I think would be nice to spend like a bit and especially now like solidity is starting to actually having like partial implementation and they can deliver a lot of useful data for experiments and like yeah just like yeah like even evaluating design decisions um but I feel like we don't have free time to do it so I guess we need to make a decision in like one or two days about what exactly do with it so I expect to my understanding we kind of we're going we're doing a step back and try to like fix it somehow but what exactly it means I think we'll try to figure out uh hopefully this week um is there sorry for not raising my hand this interface I've never found a way to do it um is there any real use case other than functions which have multiple returns that happen to be returning at different stack Heights is the silence mean no I mean uh one of the cases we wanted to get with this originally would be to uh to be able to outline reverting helpers but that the current spec even doesn't allow but that we also needed to be able to mark functions as never returning with for example 255 outputs meaning that it never returns as another special case which was never considered so without that that case even vanishes and then I'm not sure there is actually use cases for the cleanup yeah so like the original case was you can think about it like like a panic helper so you have like different places in the contract that can panic and means like it does something wrong but it goes to like like a piece of code that actually handles the Panic with some additional stuff and that's that's that's usually not executed but it's there and how they want like how they currently doing that and to my understanding is just like have like a single piece of code doing it and you jump there and it does the handling of the panning maybe some logs then exits and this kind of it seems like simple use case but it doesn't fit EOS very well if you have really strict function handling uh for different reasons but we kind of wanted to maybe improve the UF design in the way that it's it fits better the use case um yeah that's one thing and the second one is something I I started thinking about just by renaming the Telco app to Jump app that you can actually have some different form of control flow using only Jump apps which because it allows you to jump around as a kind of fancy jump but I think even the the rename of that which I think was a very good one uh kind of allowed me to to think differently how can we use this instructions so yeah that's more more or less my comment about it maybe a bit more specific about the duplication part I mean yeah what we do in code generation in the end is deduplicating uh code when we have blocks that are identical and jump to from different locations and before UF we can just yeah have several places and jump to the same code and UF doesn't allow that anymore so that's why we were worried that without that kind of 50 duplication code size would blow up too much but the first experimental results indicate that it's not as bad as feared so I was told during the discussions of 2315 that allowing such optimizations wasn't worth it because you people just inline things like that foreign suit that purpose what purpose the deduplication purpose I mean we asked for jump F because of the duplication it's just depending on how it's specified it works better in all cases for the duplication or in some cases the duplication is not almost free I mean before you have pre-duplication is absolutely free um so yeah depending on how jump that is specified for example for reward helpers we would need to First clean up a stack and then jump which is probably depending on the situation more code than the deduplication would actually gain us so that's that was the reasoning but yeah as I said it's uh the code size increase doesn't turn out to be as bad as I feared so uh maybe this we could live without optimizing for these cases at least in the first version okay yeah the reason is that if you have to have different functions that want to have additional helper like shared helper which is like third function um if the place you want to jump F to it have different stack Heights you can't reuse the same one although it actually would work because this helper never actually returns so it doesn't matter how much outputs it returns but the number of outputs the helper declares which can be zero and number of inputs kind of have to balance the stack maybe I'm missing something but you really need to draw it to figure out what's going on but at least there's some like additional restrictions like kind of validated that prevents you use the same helper from different places if they have something different going on does anybody feel strongly about trying to keep jump F in for big eof well if we don't have it we can't do tail call optimization it feels like the debate right now is that we're not sure exactly the best way of doing this and I don't know how long it would take to figure that out and so it seems like it would be better to remove it from the scope here and think about the best way to do this for Cancun or for a future fork and I'm trying to figure out a is that something that people are interested in doing or do we want to try and resolve this now and B is there a way that we can do this because I think now red f won't have the stack cleanup and we need to have this future compatible so we won't be able to modify redf in the future to have stack cleanup so is there a way of doing jump F or tail call F in combination with some move op code that people feel would you know solve the problems they're trying to solve if we have a spec for jump F that does solve the helper problem and I guess would need a dynamic gas cost um then it'd be nice to get it in now because Cancun's been promised for the summer but we know what our track record is for delivering upgrades uh on any schedule so um I'm sort of torn there it would be good to take more time to get it right so the other side is that if solidity can can do without it now then just use function calls um [Music] those are the the two sides to it um but I I would be happy if we really have a solid spec to go with it sure I'm I'm just like worried we're getting to the place where we need to settle this back down and if we don't then there's like a possibility that an eof doesn't happen at all that's right and so I would I would rather be forward compatible with a future jump f and since solidity doesn't seem to be pushing without hard for jump F in this first version I think it would be good to consider tabling it the question is is it possible to table this and still solve it in a good way in the future does anyone have a comment on that uh yeah I'm not really good uh fast thinker but uh I think that that's the kind of the restricted version of job F which is kind of like diffused call and read return read F like if you put this to instructions next to each other in the code that's kind of I think it works uh except that it cannot overflow the call stack but that's so I think that's uh that's not really problematic to be included this way I'm not sure how much this is useful though uh if we can do it better later um I think we can but I'm also guessing here because we can always introduce the instructions um so I guess you can you can then specify it as we want I think it doesn't really matter so much I mean obviously if you can imagine how it would work in the future that's always better but I think the number of options are are not I'm not really limited so um I think we should have red chef and jump f um they have there's no stack coming up on it and we can introduce a stack cleanup op code if needed because you're gonna per stack validation you're going to know what your stack looks like at that point anyway and with a stack cleanup op code it's easier to price because you have the extent and how many you're keeping is part of the call in it so we could scale the cost up appropriately just by looking at the operation and not looking at the stack so that's if it you know if an implementer's uh opinion matters I think that's what I would prefer seeing to solve some of the security concerns what are your thoughts on that pole Alex I mean I I don't have any problem with Jump app and treat f without stuck cleanup I think that's I mean unless I find something when I actually start writing the exact text for it but it looks it looks okay to me to have three of these instructions for function manipulation um and yeah they can be I either enriched with stack clean up later because I think we can yeah we can we can like kind of break it with backwards compatibility this way because previous contracts will be will require no stock stack cleanup because that will be guaranteed by the validation but we can lose that I mean lose that requirement later and I see so that's that's the option obviously and yeah what Donna suggested also sounds nice to have like dedicated instruction actually for that case not to bundle that with the the control flow instructions that's also sounds nice yeah uh Daniel do you have any comments on how useful this would be if the jump F in redf don't do the stack cleanup but we have a separate op code that performs the operation I think that would give the same behavior yeah I mean I'm rather wondering whether it would cause any problems to just disallow 255 return values for a function for now and then decide whether that should stand for never returning or not in the future right if we could Mark functions as never returning in the future then those could be jump F from any stack height that would be a path when you don't have to understand anything now you can reserve this one output thing we can then either just allow that if it turns out we don't need that or we can make it special uh in this way if that turns out to be necessary it is that a path I mean yeah I'm not sure how much of a trouble reserving that particular amount of output would be but that would seem to me like something that is safe to do and would allow for anything in the future yeah I think um I'm pretty positive on that okay yeah probably systems up I think we should do that I think we should Reserve that should we reserve only one like is there any other like should we reserve three places there at the end is there another um Paul says Max it at 200. are there other Central values we might want 28 be cleaner then we could use the sign bit as a flag to say this is a magical value is there a use case where we need more than 128 stack items in a call that's probably a question for Daniel [Music] I mean so far uh we're basically in the amount of 16 because of the stack height uh the accessibility anyways so if in Cancun we consider 663 then we can fix all this but it doesn't need to be fixed before and before that 128 would be enough I think we could always lift it too if we build a yeah fentanyls from 255 down okay that seems like a pretty good idea to me there's a new one opposed to that uh I've I've lost track of which which proposal we're at now so right now we're talking about reserving the upper byte of um sorry which I'll code were we talking here would this be this type I thought this was three top sections for the inputs sorry I I'm still much in favor of keeping uh return f as simple as possible and having any cleanup go to a separate op code that we can design more carefully yeah so I think the proposal right now is to reserve the upper byte in the type section of outputs um and so for now we'll require a maximum of 128 outputs for the function and at some later points maybe Cancun we can either open it up or make a decision on how to use that upper band of outputs and we will specify a deep pop memo type of op code I think Dano posted in the chat something what it would look like and that could be used in conjunction with red f or jump F to clean the stack but we will not have automatic stack cleaning by those Ops sounds good to me okay great any final comments on red f jump f depop Etc okay we have nine minutes left there's a few more things to talk about uh I mentioned this one little thing that kind of came up when I was reviewing some of the proposed test vectors for eof there is some discussion about disallowing unreachable code that's not in the spec right now it's not part of the validation spec as far as I'm aware is that something that we want to add is that important yes yes yes I want it very much that's enough okay so the the benefit is like we have garbage code that's one thing but you also that allows you to to do validation in single pass over all the all the instructions but not in the in the order and that's only allowed when you have this requirement okay uh that seems pretty convincing that's something we need to put into the Eeps and the unified spec because it's not there yet but we can get those updated um it makes code much easier to read in other ways too just scanning it from one end to the other you can tell for sure um right you can tell the certain certain byte codes actually don't ever get executed um you know how do you know that without traversing the code and if nothing there is if nothing there is not executable you don't have to you don't have to do that okay are there any other open issues that people want to discuss this is a question because I'm lost in specs I think some of which aren't up to date yet we have the max height field now uh which I don't see in the call F spec yet um and I'm not clear on whether the uh author of the routine fills that in or it's getting filled in by the validator uh the author of the routine would fill it in and it would be verified by the validator but the EAP still needs to be updated okay uh Dano says red f with an empty return stack is an exception correct I don't think it's possible to have an empty return stack red Earth in section zero um in section zero before you start the execution you actually push all zeros onto the return stack so what do you do then when you get a red f in section zero and you've done nothing else return the whole call so it's another way to return Yes I think that's that's how it's going to specified you just like to stop yeah terminate the execution I think there are some concerns that it should be exception I don't I don't have so much opinion about it but I like the point where it's a stop because I could see you wanting to in esoteric cases recurse into section zero so I'll treat it as a stop cool um if that's not clear in the spec maybe leave a comment in the evm channel and we can make it clear I think it should be spelled out of the spec so I'll put a comment there okay thanks five minutes left two more things to discuss uh I wanted to take a moment to just talk about the timeline for eof and Shanghai I think most people here were on all core devs or kind of aware that we're sort of sprinting towards this January 5th all core Dev State that's the first one in 2023 and they've requested that we have eof implemented in clients um and that's kind of like the first gate of that we need to pass to make sure that elf is like Shanghai ready I'm curious to know how people feel about that if there's any questions or concerns about that specifically I know it's not really ideal in any realm that we're having to deal with these things over the holiday period um yeah I would have much rather be doing this in the fall or the summer but we have this chance of shipping eof and I think we need to take advantage of it um and so I will be available as much as I can if anybody has questions or things that need to be done I can try and do it um yeah I think it sounds like most people have implemented eof and we're just trying to finish these last few things I think if we can have these spelled out in the spec tomorrow end of the day that you know will give people a week and a half of like you know sort of holiday working time to try and resolve a couple of those things I'll try and be working on tests hopefully by the next eof call which I think we scheduled for the 29th of December I'll have to double check the Discord we'll have cross-client tests that we can start verifying and then that will give us a couple days the beginning of 2023 for client implementers to review the status of the test and resolve to some of those things and I think if we come into that for January 5th that's a good place to come into the last thing to just mention is uh this post by vitalik I think a lot of people have seen it but just if you haven't I would take a look basically metallic is making a case that if we're going to upgrade the evm there are new possibilities that we could have if we make certain decisions and this possibility that he's interested in is forced upgrading code that hasn't been possible really that's wouldn't be possible with the currently specified eof version due to the fact that we can introspect code um and so he's proposing maybe Banning op codes that allow for code introspection unfortunately that it means a lot of op codes would be altered or banned we would have to change how Legacy contracts call these op codes into eof contracts I think it's like it's a relatively big change um and I think that that's going to get discussed on this all core devs and I'm not really sure what the outcome of that will be I don't think that there's much that we can do in the time between now and then to resolve the questions that vitalik has raised and I think the best thing that we can do is come to all core devs on January 5th with big eof and clients and cross-client tests and stuff and then see how important people feel one thing that we might be able to do that doesn't really resolve any changes or it doesn't require any changes is to sort of make this commitment to people that code introspection is actually similar to the gas schedule you shouldn't be using it in um you shouldn't be using it in contracts with the assumption that it's never going to change we can make the commitment that obviously if you call a contract it's going to return the same value forever but if you call code size on that contract it might change that's like one possibility another possibility is just being extremely ruthless with um banning all of those OP codes and maybe adding things back in as we find a solution um but yeah that's sort of the status with that again I think maybe we should focus on the big UF implementations before we spend too much time thinking about how to resolve those concerns Alex um you just wanted to give like a brief um like background info on that when we initially proposed UF um you know back like almost two years ago um we actually wanted to have a data copy of code um some of the early documents um have tests explained um and data copy would be used for the data section obviously um if any of this introspection stuff is removed you would need to have something like that um ideally because a lot of contracts depend on so-called immutable variables which are encoded in in such a way and loaded uh with the code copy currently so for that you would need data copy um but I guess this is more like a a usability question um however the the second point is even if you disable introspection from within the UF UF code outside from Legacy code can still be inspected um and you cannot I mean you can only give like verbal commitments there that you shouldn't do that um but if people start to do that and rely on that uh will that mean that all of this was for nothing because you still cannot update it um so I think that's like a bigger meta question um but personally I mean I'm interested in restricting stuff and we actually had these to some extent discussed uh last year it's a way before you know it came up um last week um but we felt like it would be like a an immense amount of changes um and hence we didn't fully explore it at the time Bob yeah just to ask about testnet just thinking it would be very useful to have a full eof test net sooner rather than later uh obviously you know if the specs are still moving a little bit maybe not so great but just the thought that we should really move on that soon I personally feel that cross-client testing is a higher priority than test Nets um it would resolve like I think there's like you know less interoperability things to concern with because it's not changing like any of the networking blockchain structure more or less uh it's something we want to do ASAP but in my mind like order our operation right now is finalized spec work on cross-client tests and test nut I think cross-client tests and testnet can be done mostly in parallel but like personally I will be working more on testing specifically if we can get this spec finalized in the next day or two and you know people want to help run this house at end of next week like let's do it but that's where my mind is or three minutes over time any last comments yeah I mean that that makes sense I'm just thinking we don't want to like wait too long agreed we definitely want to be doing a test net by the next UF call which I believe is January 29th I'm really sorry or sorry December 29th I'm really sorry that we're doing yeah breakout rooms this time of year but um I'll be there there'll be time to discuss any questions or comments that have come up and hopefully we'll have test out by then anything else great thanks a lot everybody uh please yeah share any comments or questions in the evm channel on Discord we'll work on finalizing the spec I think that there were about three or four decisions that we've like roughly made we'll send an update with um yeah that stuff being resolved here soon thank you thanks thank you bye-bye bye fairly well