 Well, 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 the basis has been on is unmuting so. Okay. So basically we have the five VIPs in a functional first pass implemented. I haven't heard any update on changing the EOF container. So I went with the EOF container specified in the unified spec. I don't know, you know, there's a lot of PR is flying around as to what the final state of the EOF container is. But the relative jumps in the function calls would be relatively unaffected if the container format was changed again. So I've been trying to copy over test vectors from other clients trying to get unified test vector again. You know that I'm making them in such a way that they didn't rely on the container. As far as you know being able to test what's going on with stuff like return F. It's a tricky one because you got to do the code sections how that logic built in, but relative jumps is all within one code run. So that's fairly isolated. So so that's our status we're ready to start interrupting and see what's going on with it. See what the more interesting contracts are defined where the real interesting breaks are. Okay, awesome. Great. Ergon. Is anyone here. Another mind. Okay, I can go, I guess for guests. I've rewritten our implementation of EOF. 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 from scratch in guess, and yeah I've replaced my PR so if you've been looking at the EOF bundled PR in guess that now has that code instead of the older code. The tests are still sparse. 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 give an update. I could just speak quickly for the work that we've done on Ergon. It's essentially been tracking your guess changes and maintaining those. That's the general status. Okay, great. 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. What is the timeline or plans do you think completely to be we've just started so. Okay, but it looks like the volume, you know, the volume of changes be fairly small to it. The real problem is testing. Because that depends on high EVM who are nowhere. I see. Okay. I might mention this to the high EVM team. Alex. I can give an update from Solidity. Solidity has a while ago merged, at least like the base scaffolding to support 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. There is a PR for the container format, which is tested against EVM one. There is another one for static jumps. And as of yesterday, there's also a working implementation of function sections. Without using jump F only just call F and red F and they are seeing. I mean, they, in the first version, they had to disable the optimization stages because those need to be updated. But with the optimization stages disabled. They are, which also means there's no duplication of code. They're seeing a slight code increase which is expected without the duplication. But at the same time, they're seeing measurable gas savings already. And keep in mind, this is without having any kind of optimizations. Yeah, I think that's it. Great. Thanks for that update. I guess that's probably our two compilers here. Okay, so spec updates. Does anybody from the epsilon team want to give an update about where you guys are at. I listed a couple of 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. So this week I did merge some of the changes that were kind of under review for longer. So I think that the significant, like functional change is that 3046 70 doesn't require terminating distraction. As the last instruction in the code because that is supposed to be delivered by 4550 for 50. So it's been conflict and doesn't have like redundant checks. And yeah, I think that's that's mostly it and the other one mostly editorial. What is missing is this the main container format, obviously, I think we'll spend some time today on it. I planned to reach like the last one, which is the stack validation. But I kind of stopped on the jump F and read F, which has changed the semantics. Okay, maybe I should mention that's the additional functional change, but this happened when I was actually offline, let's say. So I'm sure how much this will discuss previously. Yeah, but like both of them jump F or read F are specified in the way that they require automatic stack cleanup to be performed as a part of the instruction. 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 that's mostly stopped me from reaching the last EP actually. Okay. I'm just browsing that the issue is so I think like that's mostly reflects the current stages so mostly the container format is not, it's not finalized. And this stack validation doesn't expect to be like chain functional functionally, but yeah, the IP needs bigger update in terms of just the text. Sounds good. Thanks for that update. So do we want to start talking about the header format or do we want to jump and talk about the stack clearing for jump F and read F first, I guess we can talk about the header format first that that's okay. Honestly, I'm not sure what has really transpired since we last talked about it two weeks ago on this call. Like, you know, basis implemented this unified spec version of the header format I've implemented the unified spec version of the format 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 forward. So how, how do I think about it is that like, think, like the basic option is do we want to strict format that's kind of predefined where the values are in the different offsets in the container. So that this like, I think it should be simple to to pass and like, yeah, like efficient in terms of how many buys it uses. But like the tradeoff is you use all the flexibility to be like new stuff added later without breaking the compatibility with with current format. Like, I think one of the options we have and the other one is just to improve what we currently have. So we keep the difference is mostly do we want to have something like section kind as a bite 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 of bite. I think we're going to improve what we currently have by introducing arrays instead of individual sections. I think this change is 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. So the two through almost an identical variance of that I don't remember exactly and I'm not familiar with the unified spec but yeah, I guess like, but mostly like you have a section kind which says the code section but like instead of have individual sizes you just have array of sizes and most of this. It's not like single code section but it's, it's separated by the by the size values. 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 sections or 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, in general view. It's nice so that mostly it saves you the this like linear redundancy that you repeat the same bite all the time, but you have some this this additional bytes that kind of. I think we could live without it. If we really want to. But yeah, 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 you have was designed but. 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. So it's like two buys other 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 they have originally proposed it's kind of improved version of it. Right. I guess like one like thread of conversation that has transpired in the last week or two is this post by Vitalik. I think that, you know, one takeaway from this post is that it's like, you know, seems like a very important thing to not have many versions, like we're talking like maximum two, but most likely like one version. And so what we do, we should really consider about like the forward compatibility. 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 format. So that makes me lean like a bit in that direction. Moody asked has proto buff been considered for the container format. Do you guys have a comment on that. I think like what we currently trying to do is like to be like really that simple. That's why we just like have sizes of two bites and that's like fix this not really. Maybe that's, I don't know maybe some people think it's like, like, but but direction but So I guess what should we do to make a decision on this where I kind of gain 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 5th deadline. 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. So I'm also kind of in the favor of having this more flexible one like more generic format that leave some space for extensions. So, if I think nobody protests in the sense that we want to kind of save every last bite of the format so that the storage on the codes on chain is like minimal. So I think I would also go with a bit more flexible and if that decision I think we can sort it with with much offline. I think even today. Okay, then because I don't think there's like much friction points in the exact design. So yeah if that's we go if we go with this decision then we can kind of propose like present. Kind of like single variant of that for review. Probably today or tomorrow. That's kind of my understanding. Okay, that sounds good. Same question same question as moody but for SSZ. I think the same answer probably simplicity. But I certainly prefer a more flexible format. So far as the forward compatibility issue. We really shouldn't need very many future version bumps if we do this right. Because adding an opcode doesn't change the version that opcode 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 Baron stronger guarantees which would break would break previous code that couldn't be those guarantees. Yep. I posted the anchor to the container format in the unified spec. We can take this offline and you know maybe change like a slight thing there but if anybody on the call has a comment on this format. Right now, it would be good to say something otherwise we'll post a, you know, finalized version to review later today or tomorrow. Yeah, answering like the question about wrote above SSZ quickly. I didn't fully explore that for sure. So, but what can I say, I think. So it's, it's, it's like great time to kind of explore it but yeah thinking someone can kind of present example how that would look like. Well, but I can't tell you if that helps or not for what we considered is something else. Like having variadic number and coding so it's kind of maybe like SSC I don't know SSC actually I know the RLP more. You have a size somewhere in the code or I guess mostly for the sizes and indexes of that like we have fixed number of bytes that can be replaced with the like variadic number of coding, which are relatively simple but sometimes it can save you one byte, sometimes you can add you one byte depends 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 kind of this this question showed up some like some number of times, especially when you consider we have because with the fixed sizes. Yeah, we fix sizes of numbers you can you kind of have to pick the right size. At the very first moment right. So for example if you want what we discussed, for example that the call f is it supposed to have like one byte index or two byte index. With this like variadic encoding you can kind of shuffle it because it will handle like small numbers as a one by byte encoding and like bigger numbers one as a two byte encoding. Yeah, but I mostly kind of were skeptical we want to introduce complexity. So that's why that wasn't officially anywhere. Yeah, that makes sense. Any other comments on this header format discussion. So maybe because this is recorded but all the chat text isn't a lot of conversation aside from there. So we're getting the proposal of one and choosing protocol for SSD. And I wanted to add that initially we did instead of like a fixed length filled we did consider using lead 128. But then rejected the idea because we felt like even that would be too much complexity. And clients would argue against that for not much savings. If that argument is correct and doing protocol for SSD seems like, you know, even way more complexity. I mean that's why we haven't really gone to that direction. Yeah, that makes sense. I think from like the guest perspective we would probably be against integrating like a parser like protocol or level 128 into consensus. Okay, moving on. Let's chat about, let's chat about this stack cleanup question for red F and jump F. Maybe Paul or Alice you can give a overview of this. Like to my understanding, I kind of that's like my last days to to digging into the specification of this specific aspect is that both the distractions 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 call it reserve do it and the client. But they, they kind of have specified the exact stack height is expected in the call on the end of the call and they need to move some top stock 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 cooperation, because you can have functions that's 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. 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 gas cost actually properly reflect that. And I think what this what this even worse for it is that it depends on the 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. 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 to users, but it means like for compilers mostly. And to me like it kind of bundles it with on the way that maybe it reduces issues in some other place. This is related to the fact that 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 in this way you have like pathological option to create multiple instructions that having exactly the same code. But formally they may be defined like returning different number of outputs and sometimes that might be needed to actually be more useful on the color side. Okay, that's that's all from my side. Dano then 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 rights if you want to be safe and allow the stack. And 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 courted coded poorly. Daniel. I think it was actually added to the spec after discussions with us and the reason for us getting in that direction was fear of code deduplication becoming harder with you have in general because we don't have cross function jumps and then in some corner cases these specification of not having to clean up the stack helps there. So given that we now have an initial implementation of the 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 if you would still be fine without it. Okay. That's a good perspective. 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 F that doesn't have quite how the exact characteristic do we want that we want. I have never liked the automatic cleanup feature for the reasons Pavel gave us and some others. If it's explicit. It's much easier to know that it's correct. Both for the author of the code and the validator and for just specifying what we mean by correct. We can always we can always add a cleanup up code later that does what we realize that it really needs to do. Right. Yeah, I mean, like from from Evm point of view, that's like, like that would be definitely nicer approach but I think it, I try to understand and like think partially understand like what is the usability case here and why this is like. It's like, important. So kind of my problem is that I think would be nice to spend like a bit more time on it to, and especially now like so it is starting to actually having like partial implementation and they can deliver a lot of useful data for experiments and like. Yeah, just like, like, evaluating design decisions about I feel like we don't have free time to do it so I guess we need to make a decision like one or two days about what exactly do with it. So I'd like to my understanding we kind of going. We doing a step back and try to like fix it somehow. But what exactly it means I think we try to figure out. Hopefully this week. Sorry for not raising my hand this interface I've never found a way to do it. 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, one of the cases we wanted to get with this originally would be to be able to outline reverting helpers but that the current spec even doesn't allow for 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 does something wrong but it goes to like, like a piece of code that actually can panic with some additional stuff. And that's, that's, that's usually not executed but it's there. And how they won't tell how they can't be doing that to my understanding is just like a single piece of code doing it, and you jump there and it does the handling of the panic, maybe some logs, then exits. Kind of, it seems like simple use case but it doesn't fit you have very well if you have really strict function handling. For different reasons, but we kind of wanted to maybe improve the design in the way that it's, it fits better this use case. That's one thing and the second was, there's something that I started thinking about just by renaming the tail call F to jump F that you can actually have some different form of control flow using only jump F which because it allows you to jump around as a kind of fancy jump but I think even the rename of that which I think was a really good one. Kind of allowed me to think differently how can we use this instruction so yeah that's more, more as 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 code when we have blocks that are identical and jump to from different locations and before you have we can just have several places and jump to the same code and you have doesn't allow that anymore. So, that's why we were worried that without that kind of duplication code size was blow up too much, but the first experimental results indicate that it's not as bad as feared. I was told during the discussions of 2315 that allowing such optimizations wasn't worth it because you people just in line things like that. Apparently not. Why wouldn't jump F 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 your application is absolutely free. So, depending on how jump if it's specified, for example for the word helpers, we would need to first clean up the 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 reasoning but yeah as I said it's the code size increase doesn't turn out to be as bad as I feared so maybe this we could live without optimizing for these cases at least in the first version. Okay. Yeah, so the reason is that you could have different functions that want to have additional helper like shared helper which is like third function. 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 turns. 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 that 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. If it's 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. 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 Rhett F won't have the stack cleanup and we need to have this future compatible so we won't be able to modify Rhett F in the future to have stack cleanup. So is there a way of doing jump F or tail call F in combination with some of them move opcode that people feel would 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 then it'd be nice to get it in now because Cancun is being promised for the summer but we know what our track record is for delivering upgrades on any schedule. So 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 do without it now and just use function calls, those are the two sides to it. But I would be happy if we really have a solid spec to go with it. Sure. I'm just like worried we're getting to the place where we need to settle the spec down and if we don't then there's like a possibility that EOF doesn't happen at all. That's right. And so I would rather be forward compatible with a future jump F and since solidity doesn't seem to be pushing that 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? Yeah, I'm not really a good fast thinker but I think that that's kind of the restricted version of jump F which is kind of the diffused call and read F like if you put these two instructions next to each other in the code that's kind of I think it works except that it cannot overflow the call stack but that's, so I think that's not really problematic to be included this way. I'm not sure how much this is useful though. If we can do it better later, I think we can but I'm also guessing here because we can always introduce the instructions. So I guess we can. We can then specify it as we want. I think it doesn't really matter so much. I mean obviously imagine how it would work in the future that's always better but I think the number of options are not really limited so. I think we should have read to F and jump F. They have there's no stack cleanup on it and we can introduce a stack cleanup opcode if needed because you're going to per stack validation you're going to know what your stack looks like at that point anyway. And with a stack cleanup opcode it's easier to price because you have the extent and how many are keeping as part of the call in it so we can scale the cost appropriately. Just by looking at the operation and not looking at the stack. So that's you know if an implementer's opinion matters I think that's what I would prefer seeing to solve some of the security concerns. What are your thoughts on that, Paul Alex. I mean, I don't have any problem with jump F and treat F without stack 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. I want to have three of these instructions for function manipulation. And yeah, they can be either enriched with stack cleanup later. Because I think we can, yeah, we can we can like kind of break it with backwards compatibility this way. In the previous context will be, we require no stock stack cleanup because that will be guaranteed by the validation but we can lose that. I mean lose the other requirement later. And I see. So that's that's the option, obviously. And yeah, what Donald suggested also sounds nice to have like dedicated instruction actually for that case not to bundle that with the control floor instructions. That's also sounds nice. Yeah, Daniel, do you have any comment on how useful this would be if the jump F and red F don't do the stack cleanup but we have a separate opcode 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. If we could mark functions as never returning in the future then those could be jumped F from any stock hide. That would be a path when you don't have to decide anything now 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 in this way, if that turns out to be it is that a path. 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 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. Is there any other like, should we reserve three places there at the end. Is there another. Paul says max it at 200. Are there other since your values we might want wouldn't 128 be cleaner than we could use the sign bit is 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. I mean, so far, we're basically in the amount of 16 because of the stack height stack as 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 to if we build the. Yep. Sentinels from 255 down. Okay, that seems like a pretty good idea to me. Yeah, I think we can oppose that. I've, I've lost track of which, which proposal, we're at now. So, right now we're talking about reserving the upper bite of. Sorry, which upcode are we talking here. I'm sorry. I'm still much in favor of keeping return F as simple as possible. Having any cleanup go to a separate opcode that we can design more carefully. Yep, so I think the proposal right now is to reserve the upper bite in a type section of outputs. And 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 men move type of opcode. I think Dan will post 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. And we will not have automatic stack cleaning by those ops. Sounds good to me. Okay, great. Any final comments on red F jump F D pop, et cetera. Okay. We have nine minutes left. There's a few more things to talk about. I mentioned this one little thing that kind of came up when I was reviewing some of the proposed test vectors for EOF. There was 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. So the benefit is like it doesn't have garbage code. That's one thing, but you also that allows you to do validation in single pass over all the all the instructions but not in the, in the order. And that's all only allowed when you have this requirement. Okay. That seems pretty convincing. I'll put into the EPS and unified spec, because it's not there yet, but we can get those updated. It makes code much easier to read and other ways to just scanning it from one end to the other, you can tell for sure. You can tell the certain certain bite codes actually don't ever get executed. 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. I have a question because I'm lost in specs. I think some of which are up to date yet. We have the max height field now, which I don't see in the call f spec yet. And I'm not clear on whether the author of the routine fills that in or it's getting filled in by the validator. I'm not sure the routine would fill it in and it would be verified by the validator, but the EAP still needs to be updated. Okay. Dan O 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 F in section zero. 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 kind of specified. Just stop it. Terminator execution. I think there was some concerns that it should be exception. I don't, I don't have so much opinion about that. But I like the point where it's a stop because I could see you wanting to in esoteric cases recurs into section zero. So I'll treat it as a stop. Cool. 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 in the spec. So I'll put a comment there. Okay, thanks. Five minutes left. Two more things to discuss. 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 are kind of aware that we're sort of sprinting towards this January 5th all core devs date. That's the first one of 2023. And they've requested that we have you have implemented in clients. And that's kind of like the first gate of that we need to pass to make sure that you have 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. Yeah, I would 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. 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. 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 day that, you know, we'll 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. So I'll try and we'll be working on tests hopefully by the next EOF call, which I think we scheduled for the 29th of December. I'll have to show up double check at 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 the sum of those things. And then we'll probably come into that for January 5th. That's a good place to come into the last thing to just mention is 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, Vitalik 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 wouldn't be possible with the currently specified EOF version due to the fact that we can introspect code. 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. 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 in 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 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 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 in that contract it might change. That's like one possibility. Another possibility is just being extremely ruthless with banning all of those op codes and maybe adding things back in as we find a solution. But yeah, that's sort of the status with that. Again, I think maybe we should focus on the big EOF implementations before we spend too much time thinking about how to resolve those concerns. Alex. I just wanted to give like a brief background info on that. When we initially proposed EOF back like almost two years ago, we actually wanted to have a data copy of code. Some of the early documents have tests explained. A data copy would be used for the data section obviously. If this introspection stuff is removed, you would need to have something like that. Ideally, because a lot of contracts depend on so called immutable variables which are included in such a way and loaded with code copy currently. So for that you would need data copy. But I guess this is more like a usability question. The second point is, even if you disable introspection from within EOF, EOF code outside from legacy code can still be inspected. And you cannot, I mean, you can only give like verbal commitments there that you shouldn't do that. But if people start to do that and rely on that, will that mean that all of this was for nothing because you still cannot update it. So I think that's like a bigger matter question. But personally, I'm interested in restricting stuff and we actually had these to some extent discussed last year. So way before, you know, it came up last week. But it felt like it would be like an immense amount of changes. And hence we didn't fully explore it at the time. Yeah, just to ask about testnet, just thinking it would be very useful to have a full EOF testnet sooner rather than later. Obviously, you know, suspects 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 testnets. It would resolve like, I think there's a less interoperability things to concern with because it's not changing like any of the networking blockchain structure more or less. It's something we want to do ASAP, but in my mind, like order of operation right now is finalized spec work on cross client tests and testnet. I think cross client test and testnet can be done mostly in parallel, but like personally, I will be working more on testing specifically. If we can get this back finalized to the next day or two, and you know, people want to help run the testnet in the next week, like let's do it. But that's where my mind is. We're three minutes over time. Any last comments? Yeah, I mean, that makes sense. I'm just thinking we don't want to like wait too long. Agreed. We definitely want to be doing a testnet by the next EOF call, which I believe is January 29th. I'm really sorry or sorry, December 29th. I'm really sorry that we're doing breakout rooms this time of year, but I'll be there. There'll be time to discuss any questions or comments that have come up and hopefully we'll have the testnet by then. Anything else? Great. Thanks a lot, everybody. Please 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 roughly made. We'll send an update with that stuff being resolved here soon. Thank you. Thanks. Bye-bye. Bye. Fairly well.