 Sweet. Let's go ahead and get started then. The agenda is here. I've got some notes on my end and some things I wanna go over. Maybe the best place to start would be to just get some updates from client teams who are implementing EOF. Does anybody wanna get started? I guess I can go ahead for get really fast. Not much has happened on the get implementation side since the last breakout room. I've mostly been trying to help iron out a couple of the last small questions with respect to spec. Most of the EAPs are implemented already and the questions that we still have are more regarding like the format of the container. And so it's, yeah, haven't really had a chance to integrate any of the other small changes that we've been making just waiting to get the container format ironed out. Basu, anybody who wants to give an update? Yeah, we've got all the small EOF changes integrated as long as all along with all the shake high stuff. Haven't done too much on the big EOF ones yet, partly because they're still kind of in flux with some of the requirements. Diego's got started on relative jumps. I've got started on some of the container stuff. And the stack value, that's just an update to the validator. So that's not really gonna have any far reaching effects. So that's where we're at mostly. The container needs to settle down and get a committed version where we can go too much further. Yep, that makes sense. Nethermine, any updates? Yeah, I'm actually not involved in it directly yet. I'm just joining, working on the EOF. Apes are in work, some are in the review phase. It's just work in progress. And I joined here more to just get more context about the EOF and don't have the exact knowledge to share. Okay, cool. Thanks for the information. Ergon? Hello, I'm Chris from ETC. We are trying to help with making things happen for EOF. And for that reason, we tried to port, go with the guest implement full EOF suite PR to Ergon. This has happened and probably tomorrow or Monday we will open a PR upstream. This has been already discussed with Ergon team. And today we started trying to make Ergon sync with Shangon. And currently we got stuck at 3000 block. And we are trying to deal with it and make it, and make it sync up to the latest block. Got it. Okay, great. Thanks for that update. Any testing updates? Oh, Dana. We forgot to mention the faces sunk Shangon. Yeah, I think I got the rest of that last week. Excellent. Awesome. So any testing updates, either test nudge and non-related stuff or cross client test updates. I think Mario's not here, but he's been working on some cross client tests. And I've been trying to get them filled. But because some things are in flux, we've changed the op code recently for call off and rat F. Yeah. It's difficult to get everything target on the exact same thing. So yeah, I think by all programs next week, we'll have those tests filled for people to start running. Alex or anyone from epsilon. Do you want to share some updates about the spec? What you guys have been up to the last week or so. Sure. I mean, a lot has been happening. So first of all, there is the checklist which has been updated to contain a matrix of the implementations and links to pretty much everything. It also has some kind of a motivation on the top, which should be extended to explain the application layer effects better as well. And then we spent quite a bit of time with wouldn't team as well as with the like client to go through the checklist items as well as brainstorm on the header format. Regarding the header. I mean, a lot of this discussion took place like a year ago, but the difference is back then we had these different US EIPs in succession. And, you know, we weren't back like a year and a half ago, we weren't hoping that all of them could go live at the same time. We wanted them to go live at the same time. But, you know, given the velocity of all Codes, it didn't seem to be the same. And so a lot of things were designed to be built on top of each other. And that may not be, you know, the best solution. And now we have the opportunity to actually have all of these at the same time. And it felt like a good timing to review how to improve the header with that in mind. And Matt shared like a document on where we established the goals and metrics, how, what kind of properties are, are valuable in the header. And that's like the next big thing we want to finalize during next week. And I think this, this will be done before all Codes in the future. The goal would be that, you know, there wouldn't be really any changes coming from ourselves after next all Codes. It would be only just, you know, minor changes as discovered through implementation and testing. So that would be the goal. Yeah. I think one more update is that we have been, you know, working on a unified UF spec. I called it spec, but it's, it's at this point, not for replacing the EIPs rather as an aid to show the extent of changes in a single document. And in that document, the changes look very smaller than if you look at the EIPs, but it's, it's, it's, it's, you know, in that document, the changes look very smaller than if you look at the EIPs, because just the format requirements of the EIPs is way more strict requires a lot more details. And so this unified spec would, it doesn't look as scary as the five EIPs. And maybe a final update on from the solidity side. We had a lengthy discussion at this point almost two weeks ago. So the Monday after the last breakout call, when we had a full day of discussions with solidity. And we went through all of the EIPs and the features and the effects on solidity and that, that was also something which made an effect on, on some of the changes we submitted during the week. And, and they also solidly put all of the changes onto the roadmap and they, they are implementing everything during this year, I mean, practically within the next three weeks. And they want to have a full support before Christmas. And that's the long update. That's great. That's great news. Yeah, I guess one thing I just wanted to extend upon that is just to emphasize that we are really trying to get all of these things in a very solidified place before all core devs next week. I'm not sure some people may be, may realize this or some people may not, but to say explicitly the, this is the last all core devs of 2022. And most likely we're going to come out of it with a very clear picture of what Shanghai will look like. And so I think it's extremely important that we come into that with a, a, you know, full and complete spec. It would be great to come in with some tests. And I'm happy to like update the implementation. If we can come to agreement on this call and like early next week on some of the last small things that need to be decided. I think it's important to just emphasize overall that the changes that we're talking about are relatively small, like all of the core pieces of EOF that dips on team has been working on for last year or two is solid. We're just bike shedding a little bit on like, what does this exact container look like? And so we're trying to think about how to be like the most future compatible with other changes that, that my people want to want to do. So I think Holger, I'm not sure if I missed you on the client updates, but if you want to just give a quick update on what Ethereum JS has been up to with respect to EOF, please go ahead. Yeah, sure. Yeah, so, so it's here. We don't really have kind of like concrete progress updates. So we have got, so this base EOF AI piece we've got ready for quite some time and kind of like for a couple of months already. And now we are looking at, at the moment we're looking in the industry other AI piece and Jochem from our team, we want to do the implementation from that. And I guess we will, so he's planning to take in like four weeks for that. So we will like to be ready early January with the EOF implementation as they are now in the current EIP form. So that would be kind of like the implementation update from our side. Okay, great. Thanks for that update. I think the next advice thing to do is to just start going through the checklist that the epsilon team has been working on. And we can see like maybe more explicitly what things have been merged and changed and what questions are still open. And then I think that's going to naturally lead us to talking about some of these last few questions about the container format. Does that sound good? Does anybody have anything else they want to talk about for that? We can try and wrap it up with a few last things like some talk about some test net goals, talk about some general other goals for ACD. But if there's anything else, please let me know right now. I mean, there's one thing we would ideally like to have in Solidity, which is additionally one EIP that is no bother for the clients probably, which is 663, which is unlimited swaps and dubs. But I'm not sure whether we have any chance to get that at this point, but then bring it up because we really would want that. But yeah. And it depends on the IP in this part of it in that sense, but. Yeah, I mean, I hear you. I don't think that it's like as much of a technical question. Like I think that that 663 EIP is like trivial to implement. I'm just like afraid that we're going to hit the breaking point of what people are willing to accept. I don't know if anybody has like an initial thought on this call about whether or not they would be open to also having 663. Like 663 does not require. Or it's not like necessarily part of big EOF, but it does require the environment to have an immediate. I think most people on this call are like more amenable to change in the EVM. So we're kind of preaching to the choir. But if anybody has a thought, please share. This is. The 666 would 663 be enabled across the entire EVM, or are you just didn't want to do. Well, it has to be enabled in EOF. I believe because it has an immediate and we only have support for that via EOF. Okay. And if you did not do it in the first version of EOF, would this require a version bump? No. Okay. Yeah, so I'm generally leaning to avoid doing this just because I think it is a relatively small change and we are probably more likely to be able to get it to happen in something like Cancun. And it's not like a requirement for EOF, like the functionality that we need an EOF is not a requirement for that. So adding operations that don't require changes to the container format or any other interactions. Those are like soft forks that can go in and later releases onesie-toosie. It will be still be a hard fork. It's just that we wouldn't need to change anything about the EOF. We wouldn't need to bump EOF in any way. It would just be. Maybe soft forks. Maybe soft forks the wrong word. It's a compatible upgrade that doesn't require. It's a compatible upgrade. That's correct. Yeah. Yeah. So basically I'm my worries. I'm afraid to go to all core devs. They'll ask all for them to 2022 and asked to go to the dev. The dev. Dispatch them to creation. And they'll need to expand the scope. Because I think that we're not coming from the strongest place with EOF right now and from EVM changes. Like, I think there's still a very real possibility that we don't get EOF in Shanghai. We don't get any EVM or we get very few EVM changes in Shanghai. Yeah, so I. I feel like we should focus on. that. But I mean, yeah, it's a bit frustrating to us because the strange is really minuscule for the clients and really easy. And it would really be a huge relief for us to have it as soon as possible. But yeah, what can we do? Do you have any kind of write up about like, motivation from the Solidity team? Or is it more just like, disparate posts on these magicians? I could write something more up. I mean, I think they like Yeah, generally, consider it. But Yeah, I think that that could go a long way. How much gas savings can you show in the meeting that might persuade some people? I mean, we will probably implement an experimental version of it in the beginning of next week and then have stats about it. But I think if you really want to see this in Shanghai, that that would be that would go a long ways. Okay, feel free to post any updates or you know, considerations in the EVM channel and discord in the meantime. And I think if you're if you do want it to be discussed on like the next outcourdes and you think this is really important, I would post something on the outcourdes discord like today or Monday to let people know, I think if like, we show up Thursday and no one's like thought about 663 in two years, there's probably no way it happens in Shanghai. But maybe if like people have like the week, the kind of debate it and kind of think through it, then I think there's just like a bigger chance. But yeah, I think if if it's the first time people hear about it on Thursday, people just say like, we should push this to the next fork because there's already so much stuff we're like debating for Shanghai. Okay, sure. Okay, cool. Great. Amazing. Let's start looking at this checklist. I'm going to share my screen and we can just start going through some of these things. So maybe you want to refresh it because I was making some okay, so I'm not sure when did you know that? Okay, cool. Okay, so this is where we've sort of been tracking the open questions. We've been checking things off. So for a general open question, we're considering using a different set of op codes, because we can have all of the op codes for EF be consecutive rather than right now, they're split across B zero B one, and I think like by the E five F or something. Does anyone have any strong feelings about making those consecutive? I think it would be a good idea. Alex Andre? Well, all the existing op codes are grouped by the function. So to follow that, I would just put relative jumps close to all jumps, etc. Yeah. Is that how it's currently laid out? Conspec, yes. Yeah. That's kind of how I was, I felt as well. I think we ran out of room to one of the sequences in how to put some stuff in B. So B is the new section for that. So I guess are we happy with the current position of the op codes? We've got our jump and our jump I at five C and five D and we've got to call F and red F at B zero B one. Do people feel strongly about changing this or are we okay with this? Where would pop and do go? Pop in and do pin. Yeah. Those those continue to go and be I mean, right now it is proposed for B, but it turned out that stores also also proposed for for the same slot. T store is? Yeah. T store T load is B three, B four and swap tip was also on that, but yeah, I mean, any of these can be changed. Yeah, just looking around. Do we want to make any decision now or do we want to leave it with the status quo? I think that the motivation with this E range was that there's already a lot of people who don't want to go into that range was that there's already like the special EF and there were, I mean, I guess the idea would be then that all of the EOF dependent op codes would go into that range and so it would be maybe easy to easy to distinguish. I mean, this doesn't really matter in any case. Yeah, let's keep the status quo for now and we can revisit in the future if we decide is important and all of the rest of the EAPS for Shanghai shake out. OK, consider merge. I think it would be good to get them together because if we get any more flow of control op codes, we just sort of run out of room in that little box over there. So yeah, leave leave a little room to expand things as we go. Yeah, sounds good. OK, maybe actually one one comment. The probably the call F and red F. They shouldn't be where they are. They shouldn't be in the F range. They should be next to the jumps because, you know, despite them called call, they're not working like they're not cross account calls. They're within the same account. So I think at the very least, we should probably move call F and red F next to the the jumps. So into the B range or if we decide to move all of them to the E range. OK, well, isn't call F and red F already B O B one? Yes, they didn't fit already into. Yeah, because push zero was five up. OK, let's keep going. Consider merging thirty six seventy and fifty four fifty into a single spec condition on fifty four fifty being accepted. I think fifty four fifty has been accepted. And I think that this is something that we're going to do. All right. Yeah, one comment on that is. Thirty six seventy has some some rules which are then and then implemented in a much nicer way and sometimes implicitly with fifty five forty and and and now we are removing some things from the motivation in thirty six seventy to make fifty four fifty easier. The net outcome is that whatever is in the motivation is still applicable just because it's split into like two EIPs. It's not clear enough. So it would make a lot of sense just to merge the two together. Yeah, that makes sense to me. So yeah, we can plan on doing that. OK, thirty five forty. I know there were a couple updates here. I know for one, this PR was merged for bid EOF to legacy contract creation. And there was some discussion about considering create transactions with invalid EOF and it code invalid. We discussed it a bit on Discord. I don't know if anybody has any last comments on it. I think where it stands now is that we're OK. Nobody feels super strongly about either direction, but generally. It doesn't feel like it's necessary to create a validity requirement of transactions based on EOF where because this is an operation that the user knows beforehand before sign the transaction that it's going to be invalid. So if they signed about EOF and it code, that's totally on them. And there should be liable for the charge of the create. OK, we will keep it as it specified. This is starting to touch on some questions that we'll get into in a moment about some simplifications for the EOF header. So I'll skip over it for now. Thirty six seventy. We've got EOF code validation. We this was done last call, I think. And now we're discussing not terminating the last instruction. I think we have discussed this a bit and it's probably going to be merged. It's pending on one last update. So we can assume that this will be merged soon. All right. Where did we OK. So did we come to a decision? I know we talked about this on the last one about whether to calculate the offset for the relative jumps from the current PC or plus three. And I see it's like crossed out now. Are we keeping it at plus three? There's a little consistency amongst other VMs as to which is which. So just make a decision and pick one. Yeah. I see. I think Alex probably marked this out. Did you want to have a comment on this? I think it was probably. Probably. Probably OK. Yeah. So we're just going to stick with the currently specified offset from plus three forward. This is merged this morning. Specifying our jump V. I think this was another strong request from the Solidity team. But also generally it's very small addition to forty seven fifty. Or sorry, forty two hundred. And it substantially improves the dealing with function tables, which basically every smart contract has to deal with. So I think that this is in a pretty good place. If you haven't taken a look at the newly updated forty two hundred, there is that addition of our jump V forty seven fifty. We've got you have functions. And this is where we start really getting into the questions about the UF header. I'm trying to see if there's any things not related to the UF header that we should discuss. So wait, wait, our jump V adds dynamic jumps back in. It adds the jumps are specified after. So you have our jump V the op, then you have the number of destinations and then you have the list of destinations. And it pops up to stack. OK, so it's a jump table. It's a jump table. And the table is fixed in the code. Cool. That's correct. I'm not sure what the question on this one is. I think we can skip it unless someone has a specific comment. There's been some debate for red F on whether it should clean the stack up for the user. I'm not sure if anybody wants to share where that discussion currently is. I think last I heard there are people were leaning towards cleaning the stack. I thought we were leaning against, but. I don't I don't like the requirement for a man move for different languages. That could be more or less difficult. And I prefer for the user to just clean up their own mess. I mean, the main point we had that not for red F but for terminating constructions. The requirement is very bad because it blows up code says unnecessarily for red F. We can work with both. Yeah. Terminating instructions is a different thing. You're you're done. Yeah. Alex Andre. Any comments? I think the final. We to determine would be once we have hopefully in the next. Next one or two weeks and implementation in solidity, then we can measure the impact of this on some code basis. And that could be a data point to to make a final decision on it. And yeah, I would probably. If there's like a measurable difference between the two. And no major downside to have it done by the EVM, then we should go with that. But yeah, it will depend on the numbers. Okay. So we will see from this little implementation how that is going to evolve. A few more things on the header and then some questions. On 5450 we've got one lift the requirement to clean the stack for terminating instructions. This is similar. I think we probably just wait to see what the data points. That's definitely something we want to avoid. Oh, this is. Yeah. Okay. So that means that you read. And it was this was agreed. I think it was implemented by power as well. And in that new algorithm. So the terminating instructions, they don't. Care if the stack is clean. Yes. Yep. Okay. We will check that often. Lift the requirement of the last instruction. This is one less check. To have an implementation. I think that this is the PR that we had. Yeah. So I think I would be able to explain because he made that. The PR called new algorithm. Yeah. So that. I think we'll ensure that there is a. There's always a terminating instruction, but it's not. In the control flow, but it's not requiring to be, you know, the last instruction in the. In the section. So I believe it. It probably allows that code in that sound. But yeah, I'm not really sure. That makes sense. Okay. I think that's all of the non container format related stuff. I think. Probably best just to look at this document. Does anyone have any other comments or questions. The container or not stuff. Instead of the container. Do you want to quickly show the unified spec? Okay. It's an idea of the scope. Yeah. So this is the unified spec that we've been working on. Hopefully. I think. Like we're trying to break into three main categories. One, like the container definition and the validation that could be done related to the container. And so that's sort of just checking that everything is well formed. And so this is still in flux a bit, but basically, like once we have this complete, you'll be able to very easily see like, this is exactly what the container looks like. It's concatenating a header and a body. The header is looks like this. The body looks like this. Some of the body elements look like that. And it should be very readable. And you can see that this is like already very simple. There's only a handful of like small validation checks that need to be done on the header. And then we've got execution semantics. And this is broken down into things that are modified about the legacy. So we're kind of imagining that from an employer's point of view, you're going to start implementing this and you have this EVM. Construct that can execute code. And so this is going to outline the things that need to be modified about that construct when executing in the EOF context. And so, you know, there's the basic stuff like. Execution starts at the first bite of the code section, not the first bite of the container. The instruction jump test is a no opt now. You can't use a call code self destruct jump, jump by like all of the things that are modified. And there's not that many. And then the new behavior, again, there's not that many. We've got the R jumps from 4,200. And we've got the call F and red sub routine things from 4750. And this just defines like very simple. Like how much gas does it cost? What does it pop from the stack? How does it manipulate the PC, these things? So this is all relatively simple. And then finally, like the code validation, once you've done your container validation, the containers will form. You have to validate the actual code sections. And this is, these are the checks that are done. So all in all, like this is, this feels much more digestible. And so, it's still work in progress. We're working to improve it and we'll like keep propagating the changes from the EAPs into this. So hopefully like early next week, people who are implementing this can just mainly refer to this for the high level of things about what needs to be implemented. And then if they have questions about the rationale or they need like very explicit definitions that can look at the EAPs themselves. Any questions or comments? Okay. Just one thing. Is there like a specific time that we're planning to finalize all these EAPs because like right now, all these EAPs are implemented in our client, but as PRs. And once we finish the implementation, we start the review process, then there is more changes that comes into the EAPs. That are happening recently. So is there like a specific date or time? Or are we leaving it floating? And we, we really have to keep track of all these changes and keep implementing them till the last moment. We're going to have a, like, I won't say finalize because there might be some small things that come out. Like maybe people decide they want to like, change the gas price slightly or something like that. There's like a small check that needs to be removed, but like generally we're looking for like a freeze early next week for the specs. So that way, like client implementations don't have anything changing from out from under them. Sounds good. Great. Okay. That's the unified spec. Let's move on. We've got about 20 minutes left. Let's try and spend at least 15 of those minutes talking about this container simplification. And then we're going to move on. We've got about 20 minutes talking about this container simplification. There's a few different proposals. Basically this came out of a couple of these questions from the checklist, mainly from this question about redefining the code section header to be an array of code sizes. The way that we have it specified now, this is the, this is the unified spec. The way that we have it specified now, this is the status quo. This is the type, the type section being an optional. And then we have code where there's at least one, like maybe many. And each time you define the size of the code segment, you have to also say kind code. And this just ends up adding, you know, a lot of extra bytes. It's kind of weird for the parser. And so we've been thinking about like how to improve these things. Again, because a lot of these APs were written in a way that included, not atomically on their own, we have these quirks like kind, the type kind might be an optional. Now that there's all going together, I think some things are becoming obvious. And for one, that's that because if you have more than one code section, you have to define the type signature for that section. That almost means like certainly every single EOF container is going to have this as a, this as a header field. And so making it a required field makes sense. It's, you know, much more likely that it will be there than not. So that's what we have for the status quo. There's a few different options that we have. The first one is array of code sections. This most, most of the first couple here. Drop this concept of kind. So you don't have any kind of identifier for this, the section information. So this immediately you have the type section size. There's nothing that's trying to define it by like a prefix byte. And the way that the parser would interpret this is it just knows that it has a fixed location in the header at byte four. This is where the section size is bytes four and five. And then similar the code section size is begins to be a list here. They're just like concatenate use 16s. And you can determine like how many of those there are based on this type section size divided by two. And then we have an optional. And this is like up for debate a little bit, but we have an optional data size section here. And so whenever you're implementing the parser for this, like you already know exactly where the type section sizes, you know exactly how many code sections there's going to be. And then you can just check, do you either at a terminating byte or are you at the kind of data and then read the data section size? That is one proposal. There was another somewhat similar proposal where, you know, instead of each of these being their own section, we actually sort of combine the code sections with the, the code sections with the type sections. So here we define like, okay, this is the number of code sections. We read all those code sections. I've omitted the data information here for simplicity, but then if you look at what the code section is, it's now not just like a list of, you know, a contiguous array of bytes. It's first you have the type information. That's the first three bytes. And then you have the code after that. And so this has some nice advantages that like, there's like really good locality of the type information, the code section, but then some disadvantages that you have to always remember that the executable code doesn't start in the code section until the third byte. And so that feels, you know, a little weird to have to remember that we've got this section kinds of the rays. I think Alex added this, this one. And I feel like this is probably the one that I am feeling like most strongly about in a positive way. It's very similar to the original like EOF definition. Basically the, there's a few like alternatives that he proposes, but the main thing here is that we continue having these kind, these like kind prefixes. So you have that for the type section and the code section. It's just that now instead of for the code section, it being code section size or sorry, code section kind code size, code section kind code size. You have after the code section kind, the number of code sections to read. And then you have the list of all of the code sections. And so this gets us that property that we're looking for of having a way of defining the code sections in an array with also retaining this property that we have this like kind type that lets us be pretty flexible and like how we change the header in the future, how we add new things to the header. And so like if in the future we want to add new fields, it's not something that we have to like really bump the version for, we just need to be able to interpret a different kind type after the data section kind. And then last has been discussed a little bit on discord and in some of these calls maybe, but a multi-level header. This is where we separate the header into static components and dynamic components showing this one. This would be type section kind type section size. And then instead of having the code section array in the static component of the header, we say this is the code section. And here's a number of code sections. And then at the end of the header after you read the other kind types, the statically defined things, you have a terminator and then you have the code section sizes. And so this kind of nice because it has like really simple property in the header where each element is of the form kind concatenated with size. And so that's like very trivial to parse. There's like questions about whether you want this two layer thing. I think, you know, I'm curious to hear comments about it, but I think like generally the section kinds of arrays is probably the best approach. And I realized like maybe we should have gone over like some of the goals where I like started diving into all of these. I can just like leave this up here. I don't have to read all of them, but these are some of the things that we discussed about goals of these headers. I've been talking for a long time. I don't have any comments. Did I miss anything Alex or Andre that you wanted to go over? Yeah, I think the proposal was by power, but based on them, you know, the long discussions we had yesterday. Okay, cool. Any of the client teams implementing this, what are your thoughts on the different proposals? How do you feel in general about these goals for the UF container thoughts on how to make a decision on the UF container? We had an idea there about implementing a couple of these in this UF RS and evaluating them against a few different types of contracts that you might see. So, you know, what would be the encoding size? If you have a simple contract with one function, average contract with 64 or one with tons of helpers, like more than 256. And then just like taking a look to see like how each of these compare with that. So I've written the parsing loop twice and I'm not going to touch it again until this is finalized. Having written the parsing loop twice, do you have any opinions on how things should change about it? Are there specific pain points that you were feeling with the parsing library other than it changing? If the sections were all required and all in a fixed order, that would really simplify things. That's probably the only goofiest part of it. Yeah. And that's kind of like how I was feeling about things. And then we had it, we were, I was talking with Alex the other day and he was explaining that some of the motivation for these sections was to be similar to, you know, learnings from how WebAssembly encodes their header sections. I don't know if you want to expand on that, Alex. Yeah. I think the motivation if you scroll up would explain that. But I can pick out the goals. The extensibility describes some of it. But yeah, I can highlight a few of these. A few of these, which is WebAssembly has a version field, but they don't expect to bump the version field. And I think the same rule and logic applies to us, you know, we don't really want to bump the version field of the UF. And therefore we want to make the header design in a way that it is extensible without bumping the version field. And then the other like strong motivation is, I think size based, because we are rather short on size in the EVM itself in their counts. And now with adding like a lot of small helper functions, I think it's important that the header defining those functions will not be too significant. And the observation we had that a lot of, they're like two kinds of functions, at least two different kinds of functions which would exist in a contract. The one kind is a lot of different helpers, which may have a similar signature. They may have a similar or exact same number of inputs and outputs. And then you would have a lot of other functions which could do anything else. And we want to make sure that we don't base too much space for the metadata, the type information for all these functions, because that could defeat the purpose of using small helpers. So that's like, I think the two important goals for getting the header. From my point of view, I like the one that client was leaning towards, which is having that number of code section and then an array of code section sizes. This one, yep. Yep. Do you know, Alex, if these are in a fixed order, or could the type section come after the code section in this proposal? I think the main, I mean, this one, I'm no idea. Okay. But yeah, I mean, we want the fixed order in any case. Okay. So, I mean, in that case, if we have the fixed order, then that would basically give the property that Dano was requesting. We have, and we have like the extensibility because we have the type kind, but we're also enforcing that, you know, first we have the type section, then the code section, then the data section. And so with this EOF version one for this Shanghai fork, you could write the parser in a fixed manner, other than like reading a dynamic amount, number of code sections. Yeah. I mean, just to, just to comment regarding, you know, the strict ordering, I mean, there was, there was an origin goal as well. And like the probably first version of the 3540 EIP even has this alternative header parser, which only looks at, you know, a few bytes. It's not the loop. It was always an idea we wanted to have. Got it. Any last comments or questions? Any thoughts on how you would like to see us move forward with making this decision? What decision are you referring to? We're, we're trying to modify the container format slightly to accept an array of code sections. And so that's kind of the root of a lot of these different attempts here. But they're all extremely similar for the most part. And it's difficult to, you know, we're trying to compare it on many different axes as well. So it's hard to say unilaterally. Like this is the best format. It seemed like in the course of discussion that only one of those met all of the goals and that we agreed with the goals. Yeah. I generally agree. I think we probably will make a decision on it on this call and we should, we can talk about it some more on discord, but yeah, it seems like most people are leaning towards this proposal. There's a few alternatives that Paul mentioned in here. We can talk about, I think we should talk about these offline. I don't think that they're super important. I think that what's specified is pretty good. But yeah, let's discuss this a little more offline and we'll make a decision in the next couple of days. Do you want to talk briefly about the evaluation criteria? You know what you showed there. If there's anything missing any. Yeah, there are any comments to this. We already have the data set generated for these three. It doesn't take too much to generate them. I will say like one last thing on this, and then we'll talk about timing and tests and stuff. I thought this was an interesting win for EOF. If you're not familiar with how vertical trees are going to work. It's sort of like chunking the accounts in 128 by chunks. And so that means that like you're not going to be able to store code as like larger than 128 by chunk. So right now the way that it's specified is that the first bite of each code chunk actually points to the index in which code begins, because what you can have is you could have a immediate from a push extend across the boundary of a chunk. And so the first like, you know, 31 up to 31 bytes or so of a chunk might be immediate push data. And you won't be able to know that without reading the previous chunk. And so what EOF allows us to do is actually remove that initial byte index because the validation itself verifies that there's no jumps into immediate data. And so I think that like if we're thinking about how does EOF like also help these like farther future things. That's a nice win for vertical trees. Okay, two minutes left. Let's talk about test nets. Let's talk about timing. I think we've mentioned at the end of the call next Thursday is a pretty hard deadline for spec completion. And we're working hard on making that happen. Hopefully maybe even like Tuesday or Wednesday. In terms of actually like starting to get interoperability. I think it's pretty important that we do this this month. And of course, like it matters a bit like what happens on the call on Thursday. If the call on Thursday, the outcome is that. You have to not go into Shanghai. Then, you know, we probably have like less pressure to make that happen, but like assuming those things like go forward, there are already withdrawal test nets. One of the big complaints about EOF is that it might slow withdrawals down and we should like be actively showing them that's not the case. But it seems like most clients are in progress with the EOF implementations and are just waiting on like a couple of things to be ironed out. And so if we have things ironed out next week, do people have an idea of like how long it would take to get to like a spec parity in their implementations. I'm just like coming from my perspective with the get the implementation. It feels like it's, you know, once the spec is there and it's solid, I think it's like less than one week amounts of work because I already have all the EAPs more or less implemented modular like these small changes. So for me, I think, yeah, in two weeks would be able to run a test none. Is that something that other clients would be expected to be able to participate in? I believe that's reasonable for, from another mind's perspective. What else we got on our stack for Basu, but two weeks we're at. It's worth shooting for. Okay. Okay, that sounds good. We're at time, but yeah, let's keep chatting in the EVM channel. We're going to be working to get the specs finalized. And as soon as they're in that place, we'll be sure to make sure that the teams know so that you can start finishing those last couple of pieces. And yeah, on Thursday, we'll figure out what the situation in Shanghai is and decide when to start opening a cross client test net. I think that, you know, the, before the end of this year is critical. We can discuss like what the exact date is. I think like, you know, maybe like two, two and a half weeks time from today would be a, you know, a reasonable optimistic goal to shoot for. So yeah, let's, I'll keep you guys posted and let's see how things shake out next week. And yeah, we'll also be working on cross client tests so that before the test net, people will be able to run a bunch of those and make sure that like generally they're, you know, all the implementations are kind of in the places that we expect them to be. Okay. Two minutes over. Last comments or questions before we close. Sweet. Thanks a lot, everybody. Have a good rest of your day and weekend. Thank you all. Thanks. Bye bye. Bye. Have a great weekend. Bye.