EOF Breakout Room #3

sweet uh let's go ahead and get started then um the agenda is here I've got some notes on my end of some things I want to go over maybe the best place to start would be to just get some updates from client teams who are implementing eof does anybody want to get started I guess I could go ahead for um guests really fast uh 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 the spec most of the Eeps are implemented already and the questions that we still have are more regarding like the format of the container and so it's yeah I 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 um Basu anybody who wants to give an update yeah we forgot all the small eof changes integrated as long as along with all the the Shanghai stuff um I haven't done too much on the big eof ones yet uh partly because they're still kind of flux with some of the requirements um Diego's got started on relative jumps I've got started on some of the container stuff um and uh the um stack validation messages and updates to the validator so that's not really going to have any far-reaching effects so that's where we're at mostly the container needs to settle down and um get a committed version before we can go too much further yep that makes sense um another mind any updates uh yeah I'm uh actually not uh involved in it directly yet I'm just going and working on the OS and apes are in 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 eof and and don't have the exact knowledge to share okay cool thanks for the information uh Aragon uh hello I'm Chris from EDC uh we are trying to help with making things uh happen for UF and for that reason we tried to Port uh go with you get Implement full uof Suite APR to Argon and this has happened and probably tomorrow or Monday we will open a PR lab stream this has been already discussed with ergon team and today we started trying to make ergon think with a sangong and currently we got stuck at the 3 000 block uh and we are trying to deal with it and make it a and make it sink up the let's block got it okay great thanks for that update um any testing updates oh Danna forgot to mention the faces um yeah the rest of that done last week excellent um awesome so any testing updates either past nudge and long related stuff or cross-client test updates I think uh 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 uh call off and red f um yeah it's difficult to get everything targeted on the exact same thing so yeah I think by all core devs next week we'll have those tests fields for people to start running um Alex or anyone from Epsilon do you wanna share some updates about the spec what you guys have been up to the last week or so sure um I mean a lot has been happening um so first of all there is the checklist which has been updated to contain um 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 um to explain the application layer effects better as well and then we spent quite a bit of time with uh with it team as well as with the like client to go through the checklist items as well as brainstorm on the header format regarding the the header the I mean a lot of this discussion took place like a year ago but um the difference is back then we had these different ufeips in succession and uh you know we weren't back like a year year and a half ago we aren't hoping that all of them could go live at the same time we we wanted them to go live at the same time but um you know given the the velocity of of all cores it didn't seem to be possible at the time and so a lot of things were designed to be built on top of each other and that may not be you know the the best um 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 had to improve the header with that in mind um and Matt shared like a document on on where we established the goals calls and metrics how what kind of uh properties are are valuable in the header and that's like the the next big thing we want to finalize during next week and I think this this will be done before all devs and the goal would be that um you know there wouldn't be really any changes coming from ourselves after next all core Dev it would be only just um you know minor changes as discovered through implementation and testing um so that would be the goal um yeah I think one more update is that we have been working on a unified UF spec um I 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 um and in that document the the changes look way 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 um and so this spec would would um it doesn't look as scary as the five eips um and maybe a final update on from the solidity side uh we had a lengthy discussion at this point almost two weeks ago um 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 IPS and the features and the effects on solidity and that there was also something which um made an effect on on some of the changes we submitted during the week um and they also solidly put all of the changes onto the roadmap and they they are implementing everything during uh this year I mean practically within the next three weeks um and they want to have a full support um before Christmas I think that's the long update that's great that's great news um 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 maybe May realize this or some people who may not but to say explicitly this is the last all chord 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 um 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 in like early next week on some of the like last small things that need to be decided uh 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 we're trying to think about how to be like the most future compatible with other changes that my um people might want to do um so I think Holger I'm not sure if I missed you in 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 um yeah sure um yeah so so yeah crmjs is um um we don't really have kind of like um concrete progress updates so we have got um so this base um based your faips we've got ready for quite some time and um kind of like for a couple of months already and and now we are looking at at the moment we're looking in the industry other erps and um from our team we want to do the implementations on that um and I guess we will so he he's planning to to take in like four weeks for that so we would like to be ready early January with a UF implementation as they are now in in the current EIP Forum so that would be kind of like the the implementation update from from our side okay great thanks for that update um I think the next best 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 um 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 depths 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 a as much of a technical question like I think that that 663 AP is a 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 elf environment to have an immediate um I think most people in this call are like more amendable to changing the evm so we're kind of preaching to the choir but if anybody has a thought please share this is uh this is the six six with 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 ELO okay and 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 in eof it's 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 twosy uh well they still would be a hard Fork it's just that we wouldn't need to change anything about the eof we would need to bump elf in any way it would just be soft worse maybe soft works the wrong word it's a compatible upgrade that doesn't it's a compatible upgrade that's correct yeah all right yeah so basically My worry is I'm afraid to go to all cordoves the last awkward of 2022 and asked to against extend 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 um yeah so I I feel like we should focus on on at least just getting eofm but yeah I understand that but I mean yeah it's a bit frustrating to us because this changes 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 you have any kind of write-up about like motivation from the celebrity team or is it more just like the spread post on youth magicians I could write something more up if it I mean I think they're 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 that would go a long ways okay feel free to post any updates or um 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 an Excel courtes and you think this is really important I would post something on the alcordev's 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 um there's probably no way it happens in Shanghai but um maybe if like people have like the weak the kind of debate it then kind of think through it um then I 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 will just say like we should push this to the next four because there's already so much stuff we're like debating for Shanghai okay sure okay cool great amazing um let's start looking at this checklist I'm gonna share my screen and we can just start going through some of these things so um maybe you want to refresh it because I was making something okay so I'm not sure right 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 the General open question we're considering using a different set of op codes because we can have all the op codes for UF be consecutive rather than right now they're split across b0 B1 and I think like five 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 of codes are grouped by the function so look to follow that I would just put relative jumps close to all jumps Etc yeah is that how it's currently laid out the current species yeah that's kind of how I was I felt as well I think we ran out of room in one of the sequences and how to put some stuff in b so B is the new section for that so I guess are we happy with the current um position of the op codes we've got our jump and our jump I at 5C and 5D and we've got call F and red f at b0 B1 do people feel strongly about changing this or are we okay with this where would pop and Duke go uh pop in and dupin yeah those continue to go and be I mean right now it is proposed Ruby um but it turned out two stories also also proposed for for the same slot Tea Store is yeah t-store tilo there's B3 B4 and swapped it was also on that um but yeah I mean any of these can be changed yeah just move around do we want to make any decision now or do we want to leave it with the status quo yeah I think that the motivation with this e range uh what's that there's already like this special EF and there were I mean I I guess the the idea would be then that all of the eof-dependent op codes would go into that range so it would be maybe easy to be 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 decide we decided it is important and all the rest of the Apes for Shanghai ShakeOut um okay I just said emerging 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 just yeah leave leave a little room to expand things as we go um sounds good uh okay maybe actually one one comment um the probably the call F and red f um 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 prosecant calls they're within the same account so I think at the very least we should probably move Cole F and redf next to the to jump so into the B range or if you decide to move all of them to the E range okay well isn't call off and redf already bob1 yes they didn't fit already into yeah because push zero was five up okay let's keep going um consider merging 36.70 and 5450 into a single spec condition on 54 50 being accepted I think 5450 has been accepted and I think that this is something that we're going to do right yeah one comment on that is uh 3670 has some some rules which are then and then implemented in a much nicer way and sometimes implicitly with 5540 and and and now we are removing some things from the motivation in 36 17 to make 54.50 easier the net outcome is that whatever is in the motivation is still applicable um 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 okay 3540 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 the invalid eof init code invalid we discuss a little 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 okay 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 we're at because this is an operation that the user knows beforehand before signing a transaction that it's going to be invalid so if they sign into valid eof and it code that's totally on them and there should be liable for the charge of the create foreign 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 36.70 we've got UF code validation um we yeah this was done last call I think and now we're discussing knots terminating in 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 um all right where did we okay 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 the decision to pick one yeah uh I see I think Alex probably marked this out did you want to have a comment on this I think it was pebble Pablo okay uh yep so we're just gonna stick with the currently specified offset from plus three forward this is merge this morning um specifying our jump V I think this was another strong request from the solidity team but also generally it's very small addition to 47.50 uh or sorry uh 4200 and it it substantially improves the um 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 4200 there is that edition of our jump V uh 47.

50 we've got elf functions and this is where we start really getting into the questions about the UF header I'm trying to see if there's anything it's not related to the eof header that we should discuss so wait wait our job V adds Dynamic jumps back in it adds the jump start is 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 a stack okay so it's it's a jump table it's a jump table Yeah and the table is fixed in the code it's 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 uh there's been some debate for Rhett 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 were people were leaning towards cleaning the stock I thought we were leading 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 have that not for Ratchet but for terminating constructions the requirement is very bad because it blows up code says unnecessarily for letter if we can work with both yeah terminating instructions is a different thing you're you're done Alex Andre any comments foreign way to determine would be once we have hopefully in the next one or two weeks in implementation in solidity then we can measure the impact of this on some code bases um and that could be a data point to to make a final decision on it um and yeah I would probably if there's like a measurable difference between the two uh and no major downside to have it done by the evm then we should go with that um but yeah it will depend on the the numbers okay so we will see from this lady implementation how that is going to evolve foreign a few more things on the header and then some questions on 54.50 uh we've got one left the requirement to clean the stock for terminating instructions this is similar I think yeah we'll probably just wait to see what the data points that's definitely something we want to avoid oh this is okay this was agreed I think it was implemented by panel as well in in that new algorithm so the terminating instructions they don't care if the stack is is clean yes yep okay we'll check that off then um 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 mean Pablo would be able to explain because he made that uh um the pr called new algorithm standard yeah um 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 um 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 before we look at the container format stuff instead of the container do you want to quickly show the unified spec because okay it's an idea of the scope yeah so this is the unified spec that we've been working on uh hopefully I think like we're trying to break into three main categories one like the container definition and the validation that can be done related to The Container and so that's sort of just checking that everything is well formed um 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 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 evm so we're kind of imagining that from an implementer's point of view you're going to start implementing this and you have this evm um uh construct that can execute code and so this is going to outline the things that need to be modified about that construct when executing an eof context and so you know there's the basic stuff like um execution starts at the First Flight of the code section not the first bite of the container the instruction jump dust is a no op now you can't use um call code self-destruct Jump Jump by like all 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 CR jumps from 4200 and we've got the call F and red f subroutine things from 47.50 and this just defines like very simply 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 I think 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 things about what needs to be implemented and then if they have questions about the rationale or they need like very explicit definitions they can look at the eaps themselves any questions or comments okay um let just yes just one thing uh is there like a specific time that we're planning to finalize all these eips because like right now all these eips 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 aips uh 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 uh we're gonna have it 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 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 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 is specified now this is the oh this is the unified spec the way we have this specified now this is the status quo we have the kind uh 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 client code and this just ends up adding you know a lot of extra bites 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 eaps were written in a way that they could be included uh notatomically on their own we have these quirks like kind might the 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 search and you have to define the type signature for that uh section that almost means like certainly every single eof container is going to have this as a um 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 um 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 the parser would interpret this is it just knows that it has a fixed um location in the header at by four this is where the section size is bytes four and five and then similar the code section size is uh begins to be a list here they're just like concatened uh u16s 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 implying the parser for this like you already know exactly where the type section size is you know exactly how many code sections there's going to be and then you can just check are 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 be in their own section we actually sort of combine the code sections with the uh the the code sections with the type section so here we Define like okay this is the number of code sections uh 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 you know a a contiguous array of bytes it's first you have to type information that's the first um 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 combines with arrays I think Alex added this uh this one and I feel like this is probably the one that I I'm feeling like most strongly about in a positive way it's very similar to the original like eof um uh definition basically the there's a few like Alternatives that he proposes but the main thing here is that we continued having these kind these like kind prefixes so you have that for the type section in 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 client the number of code sections to read and then you have the list of all 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 um 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 um 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 client types the statically Define things given Terminator and then you have the code section sizes and so this is kind of nice because it has like really simple property in the eof 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 if your comments about it but I think like generally the section comes with arrays um is probably the best approach and I realized like maybe we should have gone over like some of the goals before I like started diving into all of these um 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 um I've been talking for a long time does anybody have any uh comments did I miss anything Alex or Andre that you wanted to go over foreign that proposal was by by Pavel but based on the 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 eof 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 ufrs and evaluating them against a few different um 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 an average contract was 64 or one with tons of helpers like more than 256. um 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 so 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 parsley Library other than it changing um 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 and codes uh their header sections I don't know if you want to expand on that Alex and I think the motivation if you scroll up would would explain that um but I can pick out you know the goals um the extensibility describes some of it um but yeah I can highlight a few of these pfts which is um even webassembly has a version field um 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 diversion field of eof um and therefore we want to to make the header um design in a way that it is extensible without bumping the version field um and then the other like strong motivation is uh is I think size based um because we are rather short on size in um and and the evm itself um in the accounts and now with adding like a lot of small helper functions um I think it's important that the the header defining those functions will not be too significant and the observation we had that a lot of um they're like two kinds of functions um at least two different kinds of functions which would uh exist in a 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 and we want to to make sure that we don't base too much space um for the metadata the type information uh for all of these functions because that would that could defeat the purpose of um using small helpers so that that's like um I think the two two important codes um regarding the header um from my point of view uh I like uh that one that led client was leaning towards which is having uh the number of code section and then an array of code section sizes this one yep yep uh do you know Alex if these are in a fixed order or could the types actually come after the code section in this proposal I think the main I mean this one um I have no idea okay um but yeah I mean we want the fixed order in a 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 of number of code sections foreign yeah I mean just to um just to comment regarding you know the the District ordering I mean there was there was a 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 um you know a few bytes it's not not the loop honest it always it was always an idea we wanted to um 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 uh what what decision are you referring to uh 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 um 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 won't 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 who 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 they're super important I think that what's specified is pretty good um but yeah let's discuss this a little more offline and we'll make a decision in the next couple days do you want um to talk briefly about the evaluation criteria um you know which you showed there for the wrap if there's anything missing any yeah are there any comments to this um we already have the data set generated for these three and it doesn't take too much to generate them yeah I will say like one last thing on this and then we'll talk about timing and testness and stuff I thought this was an interesting win for eof um if you're not familiar with how vertical trees are going to work um 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 byte chunk and right now the way that it's specified is that the first byte of each code chunk actually points to the index in which code begins because what you can have is you could have um 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 far farther future things that's a a nice win for vertical trees okay two minutes left let's talk about hasnats let's talk about timing I think we mentioned the beginning of the call next Thursday is a pretty hard deadline for at 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 the UF does 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 it seems like most clients are in progress with the UF 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 um get to like uh spec parity in their implementations I'm just like coming from my perspective with the Geth 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 Eeps more or less implemented modulo 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 expect to be able to participate in uh I believe that's reasonable for from another man's perspective great depends on what else we got on our stack for basic but two weeks where we're at um it's worth shooting for okay okay that sounds good uh we're at time but yeah let's keep chatting in the evm channel we're gonna be working to get the specs finalized and as soon as they're in that place we'll be sure to let the client teams know so that you can start um finishing those last couple 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 that you know all the implementations are are kind of in the places that we expect them to be okay two minutes over lost comments or questions before we close sweet thanks a lot everybody have a good rest of your day and weekend thank you all thanks a lot bye-bye thank you bye have a great weekend bye