 Okay, so we're recording, we'll upload this to YouTube after for people, it's not live streamed out. I guess, yeah, the main purpose of this call just based on the conversation in the last All Core Dev I think is to try and figure out what's the best path forward for EOF and how do we kind of get started working on that. I think there was a lot of discussion on All Core Devs about whether we want to do kind of one big EOF release or split it up. It seems like people would rather have one, but the risk there is that if it's too big it might not make it into Shanghai, although some people were optimistic that maybe we can make one big EOF version and get it into Shanghai. I think the biggest probably objection by my clientease is the idea of changing the version too often, so maybe if there's a way where we can minimize the sort of long-term maintenance costs, even by doing not everything in Shanghai, that would be another option. But yeah, I guess, I'm curious, maybe from Alex, I don't know if Powell's on the call as well, the two of you or the authors of this after the last All Core Devs, what do you feel is potentially the best path forward here? Yeah, I can see a few words. We had a bunch of internal discussions as well as discussions with Solidity. More specifically, but the DevNet, we actually figured that the DevNet would be a really good place to test out some of the questions which have been discussed. For example, but of course, this really depends on the resources on which everybody is low on, but a hypothetical example of what could happen on a DevNet is launching only the first two EIPs and then rolling out the static jumps and just seeing if that needs a version bump or not, and then rolling out the function feature, which definitely needs a version bump and just build up more confidence in regards to these changes because we, in terms of rolling out them in step by step, which I do believe we don't want to actually do on mainnet, but it would be interesting to actually test this on a DevNet itself. Yeah, I think nothing has changed since all Core Devs in regards to what would be the optimal case in our opinion, which is rolling out everything at the same time. But we also discussed some potential improvements to the functions feature with Solidity, which we want to prototype. I'm going to stop here now. Thanks. Andreas, do you have your hand up? Yeah, I'd like to elaborate on my understanding what the problem is, kind of what Marius said, and if Marius is here, he can also talk about it. But how I see the problem with our initial desire to have EOIF in Shanghai is that the two initial EAPs, they don't deliver much, and we would like to have a complete package with some benefits. And to my mind, we also need to add one extra EAP to completely disable dynamic jumps and to verify that we can compile Solidity contracts without dynamic jumps. And that would be a certain feature of EOIF, because without it, without disabling dynamic jumps, then it's not clear what is the win of EOIF. So I kind of how I understood it and I concur, Marius' point is that it doesn't make sense to have somewhat intermediate version of EOIF-1 that doesn't give any benefits, just introduces a new format, but then we'll have EOIF-2, which we will presumably deliver benefits, but then there is no urgent need, no urgent pressure to have some kind of intermediate version without any benefits. That's my take. Thanks, Marek. Yeah, I'm wondering if for Solidity team or for smart contract developers, it will be useful to have two EIPs. If yes, we can use Shandong and Shandong contains main EIP and code validation, and we can add more EIPs later. But as I understood, Andrew, this testnet could be useful when we add static relative jumps. And yeah, that is what I want to say. Got it. Anyone else have thoughts just following from the last quarter's calls? And I would like to add at least how I see it, maybe because I don't know anything about Solidity, but to my mind, the trickiest bit is actually implementing it in Solidity. And if we have verified that it works fine in Solidity, then on the client side, and we have like a complete spec, then maybe it's not that difficult to add it into EO clients. But perhaps I'm wrong. Perhaps it's not that difficult on the Solidity side. Thanks. Anyone else have thoughts just following from the quarter's call? Yeah, I'm a bit more optimistic right now. So I kind of expected that we actually decide that we don't any of that in Shanghai because there's no space for it. And there's like two major features that people want to be in the next half. So yeah, at least I'm glad there are some people interested still in this and we can work it on the side kind of. And one comment about Solidity from some discussions we had, I think they're kind of neutral in the sense that there's not really like killer feature in the EOF they desperately need and that would like make their life much better. Other like code generator because they can target existing QVM more or less with that kind of similar efficiency. So it's I think actually in this like Solidity case it's not like game changer. But I guess if you don't have dynamic jumps for EOF it may be if it's still possible, if Solidity is still fine with it, then the benefit of EOF would be easier verification and probably some speed gains because there won't be any dump check, dump desk check analysis and stuff like that. So there will be a small gain. Yeah, well it's not directly for them because it doesn't really matter like technically if they like use the existing jumps on the new jumps. Like how they generate codes like they will like do the same kind of thing but not really something that's changed the code generation, right? So maybe it will be a bit cheaper but this is not like exactly like answered how much cheaper that will be the dump type feature. Yeah, let's kind of try to express what was my understanding of kind of the position. Alex? Yeah, I would say their position is a bit more subtle than that. Just to answer like Andrew's question whether the first just like the format change would give any benefit to Solidity. It doesn't but it also doesn't require any major changes. In fact that EIP was already implemented last year in Solidity and it's fairly small. The main benefit it brings is rather from trying to verify EVM code. So it could be useful for L2s and since it doesn't really introduce any like gas reductions to the user side, any speed benefits it gives to the client comes as a benefit because there's no reduced gas so it technically could speed up clients in a minuscule percentage. Now regarding the full set of features that I think does bring benefits to Solidity on two sides what we discussed. It can reduce some of the pressure on the code layer generator because right now they have to move around like the return address on the stack and it can also depending on what gas prices we end up deciding on because the gas prices for the function section isn't actually decided yet. It could bring I mean first of all it should be at least the same cost as it is today in the worst case but likely it could bring some or more benefits on the gas side and it could also bring some slight code size reduction and implementing all this in Solidity it's not inherently complex but it will take a tiny bit of time because of course the team is kind of overloaded without a work. There was one feature they're planning to add which is algebraic data types in which some of these features would actually be useful so that's what we have been discussing but there's no resolution on that yet. Thanks. My point of view a couple things if the gas prices for your jump or anything close to my estimates in 2315 which they should be they'll actually be substantial reductions in the cost of making function calls and more important or at least as important so long as we have dynamic jumps we cannot generate machine code from byte code in linear time and space and that's very important for getting performance. Okay any other kind of high-level comments about this? If not then so we have Shing. Oh yeah Drogan. Sorry I think there is two things here one is introducing new workloads basically static jumps and call of the function and second thing is object format basically enforcing those things to basically using only those things and removing all the jumps so first step would be introducing all those op codes so the slate the compiler everybody working already can use it and then the second step is introducing format that's going to disable all the jumps so maybe for the first version we should just introduce those op codes and for the second version it may be the not the the next hard work but the one after it because it deduces object format that basically disables old op codes that's for my sense. That can't possibly work you can't you have to get rid of dynamic jumps even to be able to validate the safe use of the new constructs. Yeah but you need to introduce new constructs before you can disable old ones. Yes but at all it's one piece you can't validate the safe use of the new jump constructs and the function call until you have disabled the dynamic jumps you can't validate their safe use. Yeah yeah no that's that's what I'm saying there are two steps one is introducing them being basically in the wild and second step is introducing format and validation of the bytecode that's going to remove the old jump codes but use only the new ones. So you're going to make me wait two more years before I can generate machine code. Think about that in this way if we are going to deduce new op codes it's basically we are restraining ourselves saying we are going to use them. How I see it in terms of the implementation it's absolutely fine to move step by step so yeah the first natural step is to introduce the new op codes and the the new call F, write F whatever instructions but to my mind it should be a kind of a parallel stream of work so the dedicated stream of work to EOF and we do not release it into into a main at hard fork until we have the last bit namely disabling dynamic jumps that will be then we can say oh okay so we will implement it to the new instructions and with the new instructions we can disable dynamic jumps and it's all in the new EOF format and that's EOF format is version one and because Mario's concern was which I share is that there is if we introduce some EOF format version one which has dynamic jumps then we'll have to support that forever and I would rather avoid doing that so in terms of yeah in terms of implementation absolutely move step by step but in terms of adopting it as a main net main net update then I would go for one for the whole package that's the main basically I totally agree with that there is no sense introducing the format that's going to be temporary and basically stuck inside the EVM for the eternity and probably not going to abuse but we want to bundle two maybe separate things maybe we should first step introduce new outputs leave it for the for the while and then introduce object format after that that's that's the point so if we have time to bundle them all together great it makes a lot of sense format is basically how it makes a lot of sense yeah but that's just one of the possible parts not more Alex you cannot introduce any of these opcodes without the format because they rely on immediate and if you don't use immediate for them then you go back to the original problem of having them efficiently so they definitely depend on the format you cannot go the other way around and and what Greg was explaining that the validation algorithms we have it depends on not having dynamic jumps in order for you know the function sections to properly operate hey I was just wondering is anybody not in favor of the end goal of of achieving all of these separate parts because I mean what I'm hearing all of this both in the all core devs call and in this call as well is really saying well hey can we divide this thing into parts do we want to do a step on the way or do we want the whole thing something to my mind that's really like a a risk management thing where you know you've really got good work that you can be scheduling and and all of that stuff is going along but I mean if we if we if we come to a conclusion that a partial thing is not of value are we then all you know in consensus that we would move forward with the combined package and then that would ship as a single set of changes when when ready that we could aim to do that for Shanghai depending on how things go but if it doesn't the work continues and does that sound wrong is anybody not in agreement on wanting that end goal so I think the question is though assume assuming we all want that that end goal how strongly do we feel about trying to get something in Shanghai basically and this is probably where like there's differences in opinion like yeah you see the chat is there so I don't know maybe a way that that the kind of phrase this is like what's you know what's the minimal set that that that people would want to see in Shanghai what's like maybe a stretch goal in a way um yeah because and and is we already have basically a minimal set in Shanghai um which is uh just 35 40 and 36 as 70 I think the the the code validation but um yeah is there more like I guess is there more we would want beyond that even as a minimal set and then what's the if we could get you know the whole thing in what does that entail uh yeah can I ask like who is advocating to bring something immediate in in Shanghai what what will be the benefit of having some thumbs in partial in Shanghai like clients you want to give us your take here sorry can you repeat the question I was still typing the chat why so so what what's the the benefit of having something in in partial in Shanghai I think you know I would rather just have the full like a minimal set of uf that allows us to deprecate dynamic jumps but if we're just looking at like what's kind of considered cfri right now I still think it's like a strong commitment that we're improving EVM and it like gets us on the pathway to doing these other things yeah I think it's been a while since we've really made like substantial changes to the EVM and Shanghai is in my opinion the right time to do it we don't have like huge changes going into right now maybe four four four um but I'm guessing that four four four is going to not be ready until later next year and so if we do Shanghai early in the year then it's basically just withdrawals so that's the right like we have availability to ship this and most of it's already done in terms of like specifications and it we just need some implementation to test in so I would rather have the full set to deprecate the dynamic jumps um I mean is anybody against the full set to do this or are we still debating whether to do that versus the current cfi slated I think it sounds like everybody agrees that we should do the full thing the question is the thing that's unclear to I think a lot of us is why would we do some subsets in Shanghai if it doesn't bring any value to users until the full set's in complete I mean I don't do even need to debate this like I think that we're just we should just ship the full set like they're specified they're implemented in some EVM implementations we have some tests like we just need to finish implementing and testing it uh Andrew yeah like my preference would be that my kind of personal preference how I see it is that we can keep Shanghai small and deliver withdrawals there and also solve the issue of synchronizing EL and CL updates and then have two parallel streams occur on top of Shanghai EOF and 4844 block transactions so how I see it we could create two maybe two provisional updates like two provisional hard for EOF and block transactions and because EOF what we want to do we want to deliver a set a number of EAPS so we want to synchronize which EAPS go in and so on so it's it's it's it can be a dedicated hard fork or it can be end up merging with the work on block transactions but what I would do I would separate the two and have two two parallel streams of work because they are independent of each other they might progress with different speed but when we realize that okay we are done with the EOF and block transactions are not done then okay just have a hard fork releasing EOF stuff so I would decouple the progress of the two what do you sorry what did you mean at the beginning when you said that we need to have something in Shanghai to synchronize EL and CL because previously our hard for folks were based on the block number but now we want hard forks to be based on the timestamp and that will also feed into the fork ID and things like that it's mostly technicalities but still something that we should sort out okay I mean I I just think that if the only thing we have going into Shanghai is withdrawals and you know changing the way that we do the fork to timestamp based it's going to be a very small fork and I think it's extremely unlikely that we're ever going to have an ELF only fork there's a lot of things because there's so many things being slated right now to go into future forks like we have four eight four four we have verco trees we have data availability sampling we have all these things that people are wanting to do and EOF is not going to like overtake something like a verco and so I think the best that we can do is ship it in with another fork well the thing is that if we kind of if the the the the this work is quite independent one is heavily on the EVM site and the other is touches the different layers mostly so if it can be even a smaller group of people working on the EOF but I would like to verify that okay we have a working solidity compilation into the full EOF format that works we can compile smart contracts into EOF fine then we can say oh okay it's ready so let's merge it with another hard fork that's no problem because the bulk of the work is is is done already so it doesn't have to be a dedicated it does the timing the time my point is that we need to decouple the timing but then we can we when we are ready we can couple it with something else I just don't understand like how what you're describing is different than what's been happening for the last three years because I think that there has been a parallel track of people working on these things and they have been developing this and specifying it like exactly like you're saying and now we're coming to that point where we want to couple it with a fork and I think Shanghai is like the perfect fork to couple it with right but I guess maybe like the just like zoom out a little bit I think you know the 4844 people would say the same thing where it's like I think similarly there's this other effort that's trying to get this in Shanghai so I don't know if the and then what we've landed on basically on the CL side is that we have this this this withdrawal fork and then on top of it we're prototyping 4844 and we might choose to release them at the same time is there a way where we can do the same thing here where like it's basically saying like look we're gonna assume we're going for the full EOF we're gonna get it prototyped and like you know just from a like a code-based perspective you build it on top of the withdrawals fork but separately so that you know you can pull it out worst case at the last minute and best case you just activated on the same block or the block after whatever but that gives you sort of time-wise a way to like have them be coupled but code-wise be separated and in terms of just implementations I guess what I mean is I don't think the full EOF is implemented in any client right so we probably have the minimal EOF in most clients but if we're going for the full and the sort of consensus is we'd like to see the full EOF go live at the same time then maybe just separating that kind of like we're doing with 4844 is the way to go yeah Lucas you have your hand up yes so two things from from the mind perspective we already implemented the the EAPs for let's say simple EOF or at least are partially implemented like being tested and we have capacity to potentially even implement the whole thing for Shanghai whenever that would be in the end but there's a question of testing it because we are touching more and more things so complexity of testing rises and that's the main concern of mine can we like guarantee it stay being stable and secure on the release yeah that being said this has full support of never mind and we want to we want to prototype it we want to be included and we want to see it through whether earlier or later one more thing Greg directly can we can you reach out to me or I can reach out to you about code generation we have actually one very interesting proof of concept in never mind of generating a native code from bytecode like dynamically and I would maybe this would interest you and yeah that's that's it for me yeah one suggestion from me is that how about if some client teams like as Lucas said never mind is all for full EOF obviously but if some client teams are feeling hesitant about implementing the full EOF for Shanghai what if we can like okay put in the plan that before Shanghai in the dev nets we will test EOF a couple of the IPs that are in the EOF spec and these are a must even if they are not included in Shanghai but they're a must for dev nets and in dev nets we will include them but for Shanghai we won't and that will push the clients to implement these ones and then once the spec is finalized for the other ones the clients can work on them and the full EOF can be included in the next fork not in Shanghai just just an idea I think the thing we I would try and avoid is being a spot where the code is just very coupled and then we need to remove it from Shanghai basically so like if because in the past we've seen consensus issues on main net caused by removing EIPs that are activated together so that would be my only my only like concern there is like if we're unsure about the scope then maybe just separating it like you could imagine a basic dev net just has the withdrawal stuff and like you know the three other tiny EIPs and then you just have another dev net on top of that that activates like all of the EOF EIPs separately and this way we can kind of keep iterating on the set of EOF EIPs and the implementations but we're not in a spot where like if we need to if we decide that like this can't go in Shanghai for whatever reason that we need to like pull out two EIPs of like the the the yeah the Shanghai spec um yeah so that'd be my but I think generally though it's like I guess in terms of next steps we already have Shangdong which has two EOF EIPs that's running um what would be like the way to just row that um what's like the next one or two EIPs we would want to see implemented in clients that gives us what we think is you know a a good feature set uh to push for just have the full EOF in the next test net yeah what so and but just to make sure we're all on the same page of the full EOF is 35 40 3670 4200 and 4750 is that it oh and 54 50 which okay yeah I mean how well you have comments on this um yeah kind of like would like to know what is in this current test net like I don't remember the name even but I know like two two EOF EIPs out there but like what else so uh and Shangdong yeah please I can answer so uh EVM object format uh 3540 and EOF code validation and there was there are some transactions uh on EOF already so two EIPs okay that's like two I think so I think we can go with this like as a like like first sets of features because it's already there and like people can join if they are late and we already start like doing something with this um but I like for the like first feature set I was actually considering also adding pro zero because that's EVM related and there's one that uh has additional cost for it's proportional to the unit code size this is right so those those are already in as well right yes yes they are because okay they are so there's anything that's it's not not considered from Shanghai that is not in the test net I don't think withdrawals are part of Shangdong I think that's the only one that's included but not in Shangdong okay but that's please specify it yet isn't isn't self-destruct also the activating self-destruct uh in Shanghai no we we haven't made a decision on it yeah so some people would like it to be but it's not not here yeah um Daniel as you had your hand up the wall so 5450 uh that's the code validation I still feel it's a little bit under specified all it consists is one phrase is make sure you count the stack heights um as far as what the specification means um we can get the benefit of it without having to require the validation um you know you're valid or you're not and that could be something that a implementation detail so I don't know why that needs to be you know a grounds for dismissing a contract but it's not as well specified as it should be uh I can answer this um yeah I think like your feelings are right and I agree with this so we mostly don't dump it as a like prototype so like people like to be noticed that we kind of also working on this that's why it's like this is like in the prototype state and that's not even the first prototype it's like the second iteration that we internally were working on that's why it's like python code describing we're less what we know and there's definitely some work needed on this so I think I would say it's like kind of research phase at this point um so should we should we remove that if we're doing the next dev net do we want to have that it or do we want this um so like much more um special yeah I think it's it's not something you can easily implement and you can try and then you can give some feedback but it's like risky to like whatever the outcome will be I think I think yeah I think if it's not fully specified like and given time teams have pretty small resources like we can always do multiple dev nets right like we don't have to do everything at once my gut feeling would be trying to add 4247 50 first and that gives the epsilon team some time to specify 54 50 and parallel um and also like a easier target for for fine teams to reach that might be a better way I don't know how fine teams feel about that um so like finish this one uh I think like we kind of invite people to like take a look on this and maybe try to understand what we mean by it and we also we try to like explain what we mean by by this like what the benefits are like maybe like next week or two uh but I wouldn't schedule it for any dev net at this point and uh it's also not required to get rid of dynamic jumps so it's kind of not like needed for that so it's addition that make EVM more efficient and we can save some like gain some efficiency in the EVM implementation and yeah I think I wouldn't uh spend a lot of time right now on this okay so if we have this then as like a sort of spec for the dev net which is 35 40 36 70 40 200 47 50 what's the best way to implement it do we just want to extend shangdong and add to EIPs I know teams are starting to work on withdrawals as well um so like is it better to just have a dev net that's built on top of withdrawals um yeah I just recline things like what's the best way to do it if you know we want to be able to bring this into shanghai potentially and um but at the same time it's not 100% sure that we can would we need to do a reset of shangdong because I know there's chat around the discord of doing it this weekend um do we set a date where we're going to turn on the two new eats I mean I think shangdong is a good solution to get this you get something running where people can work together and validate code together on a test network yeah and I mean we can just call it shangdong too or whatever like I it's probably easier to do that than to try and like actually a hard fork the dev net right so like this this like assuming it will continue running for some time this one one nice feature one nice thing we can do about it is to to deploy static jumps and the thing is they are backwards compatible with the current EOF that is deployed so we can test it that works nicely uh I'm not sure if we even need hard work or maybe even coordination would be enough like we say like from this date clients actually have it implemented I don't know what is static jumps what's EIP is that they did just add two more instructions to the the EVM and it's but it's 4200 right that's the I think no that's the function so I don't remember the number 47 then 47 so 4200 and 4750 static relative jumps and functions I view those as forward compatible we don't have to reset the system if we suddenly start accepting it at one date because everything that is valid before it is also valid under the future so it's it's just increasing the scope and clients that aren't up to date will just fall behind until they implement it yeah exactly that's only for the for 4750 which are static static relative jumps they are they're backwards compatible because whatever you add to the instruction that's fine so we can actually take out relative we take out dynamic jumps though that would be a no they will coexist they will coexist so we don't have to take away dynamic jumps we can deploy static and they will coexist it will be fine so like this is like like yeah the current version plus addition which we don't have to like reset the test net or like schedule a hard fork I mean it's not something you can do on my net because yeah but we can like agree like okay we'll just deploy it right now and either you don't send transaction containing it or you just like implement it and then join later on something I don't know exactly I'm not really good at like organizing test it but that's will be like the second thing we can add do it and then we can do the the last one which is 4200 that's that's your functions and that will require the version bump so there are two two ways we can do it we can do with the EOF version bump so we can test it out or we can just reset the test net with the new EOF1 that have more features but I think that will be we will need to like start from from scratch so I don't know like you actually have a lot of questions how does that test not operate and there's like monitoring how to join all of that but that can be offline so yeah like how to spam it with transactions how to actually get the EOF code yeah we we've yeah we can I think we can resolve that once we have it implemented in kinds like we've done this for a bunch of other definites in the past it shouldn't be like a massive blocker um Andrew I think you were Andrew and Madden and Lucas yeah my kind of in Erdogan we don't have any implementation of EOF so from our point of view we definitely would like to separate test test nets for Shanghai core like withdrawals and whatever goes into Shanghai and EOF because if we do them in a single test net that that that would slow down withdrawals for Erdogan from from my point of view if maybe we don't join the EOF test net until relatively late but you don't need all four clients to prototype this in Solidity and so on once it's all ironed out then or when once it's all settled then we'll join of course thanks Alain yeah just to to to clarify the two EIPs that you would like to include in top of Shandong that are not already in Shandong which ones are there and have that Ethereum.js team already implemented them or not yet the two are 4200 4750 I'm not sure if Ethereum.js has implemented them um yeah Lucas I have a question about state of testing apart from DevNet I see DevNet as a good very good integration testing and very good practical testing but from implementing point of view the very useful tests are a high test Ethereum tests and are there any test vectors being prepared there for any of those EIPs or maybe we have it already in some PRs so I can ask where are you so for two first EIPs we have uh tests but but I'm not sure about others and I'm not sure about the also status of this test if they are cover all scenarios but I think they should okay what's the status of the other EIPs then um yeah so like for that first do we have state tests um there's kind of like I don't know almost ready so we can you can use it down the pre-quest for tests test repo uh we like Ethereum.js actually found and back in the test so we have to fix uh but so far it looks okay and and the next one is actually uh to get test for uh the EOF functions but the blocker is that we have to implement it in the gap first because that's the way to generate tests and this is work in progress so that's more as a status I don't know how to I mean they kind of also generate you can convert state tests to blockchain test and I think the blockchain test work on Hive so so I guess we have some pieces but that's probably not fully integrated so maybe we need some help okay I mean so so the kind of like one of the issues that we're not allowed to merge these to the main tests because they are not like decided if they're going to Shanghai so they are living somewhere else and I don't know how to make somewhere else to be brought to the Hive testing so like all of this like moving past that's that's kind of the problem I think so if you know how to find good enough for us yeah that's good enough for us we can execute them from from brand from PRs no problem okay I guess yeah the two questions like I think are really important to answer before we wrap up is one I think sorry I think we we have agreement like 4200 4750 is is what we should go for how do we implement it like do we have this just in Shangdong is that the simplest for if it's simplest for get based on another mind and not arrogant it probably makes sense to do this as like a v1 but then if we do that are we just like painting yourselves in a corner where if EOF is not in Shanghai then it's a ton of work for client teams to to decouple withdrawals and the three other small EIPs from EOF yeah I'm curious like what's that how the client teams feel about just what's the most efficient way to implement this and does this lock us in a specific direction so just so sorry can could you repeat the question yeah so for yeah for another mind is it easier to just extend Shangdong with those two EIPs or should we create a new test net and kind of have a separate fork where like fork one is basically the Shanghai core stuff so withdrawals and like the other small EIPs and then fork two would be EOF basically so my opinion is if we want to create a hard fork on Shangdong we should decide how we want to fork it by timestamp or by block number and maybe it will be easier just to restart Shangdong on this stage it's not like big damage because we did it a few times so I think maybe the better will be start restart the Shangdong when we implement these features okay and if if we restart Shangdong I agree like not having to deal with the timestamp stuff it's probably good if we restart Shangdong do we want to have one or two different hard forks on it like do we want EOF to be part of the same hard fork as all of the rest of Shanghai or do we want to separate it in the code so that it's easier to not turn EOF on in the case where it wasn't part of Shanghai I think the other EIPs that are included in Shangdong already are fine and are already implemented from our side so we don't have a problem with them being included with whatever EOF EIPs we want to add into Shangdong so that I believe it's fine to just stick with Shangdong for any EOF testing and just include the same EIPs okay and that means and and then that won't cause a problem say we do have Shanghai and EOF is not in it then you need to have basically Shanghai without EOF and you kind of need to rework that for us it's not a problem because we can specify what EIP we want to include in configuration so it's not a big deal okay Andrew well from for Ergon the strong preference is to have to restart Shangdong without any EOF EPS concentrate on but but have withdrawals and it's like concentrate on withdrawals testing and make sure that withdrawals and Shanghai core work fine and have a fork later maybe a parallel test net so I yeah our preference is definitely to decouple with Shanghai core and EOF I have basu guess any thoughts on that can you repeat it I was in chat lamp yeah so basically is it better for basu to just have the Shanghai core stuff separate from EOF and then have kind of another fork activate what is on Shangdong or somewhere else that just includes the four EOF EIPs it can be written to support both because we could just underneath the covers to Shanghai and then Shangdong on top of it yes that's what I'm asking yeah push zero is is the only thing that goes in the EVM core the rest are around it warming the core base limiting the init code my concern though is what's going to come from the EIP bonanza on Thursday during the next all core devs call stuff like transient store unlimited block size off the zero I mean some of those are going to get shot down but I don't think all of them will get shot down so I think my preference would be for us to have dev nets that are building towards what's actually included and then separate dev nets that build for stuff that's like CFI or on on defense and that's kind of why I think it would make sense to like refactor Shangdong because then you can have regardless you know if we decide to include something next week say we decided 1153 was included or BLS was included that becomes part of Shanghai core we like change that set of EIPs there and then if you know we have something like EOF we just build it on top with the 4844 stuff we also build it on top and then at the point where where these get included we decide to like yeah we decide to merge them together but that would mean it's a bit more work now for trying teams but I think it might put us in a spot where it's easier to like add and remove stuff all a carding dev nets is expensive dev time it's expensive to maintain the code paths it's bug prone it's how bugs get introduced so I'm not a fan of all a carding specific test nets turning features on or off I would prefer to see it be a small number like to Shangdong is Shanghai I would also yeah I would also prefer to try and minimize the number of configs we define so okay like maybe one extra one is okay but like generally I think you know I would also just be happy to have like a core Shanghai and continue building on this and whenever if and whenever we happen to remove things that we can cross that bridge and remove them I don't think that that's going to be like you know a huge amount of work okay so I guess that means we would add the EOF stuff to Shangdong because that's the closest we have I don't know what that means for withdrawals though because they're not activated in Shangdong so there's no chance we'll activate withdrawals for the next Shangdong or the next test at whatever it is well I think from all corridors it's like we're going to want some withdrawals definitely as soon as possible and then the question is like what else should be part of that so that's kind of where I want to make sure we don't like diverge too much here because it's like if on one hand we have people implementing withdrawals that's actually the main thing we want to like prioritize how do we make it so that like I don't know we the EOF stuff doesn't make that harder um yeah and you're saying it's bundling all that in a single config Matt? I mean from my perspective on guess that's pretty straightforward for us but I think that we have maybe a bit more of EOF implemented than Spinner clients so it's a little lost work on that front um but like if I was the only one making a decision I would just say to have the next test that have everything slated for Shanghai including the full EOF including withdrawals right but we haven't decided that full EOF is slated for Shanghai that's the thing and I think this is why it's like kind of tricky same and it's like the same issue with 4844 is like you have these two big things that are sort of on the fence and how do we test them without having committed uh Alex yeah uh yeah I was gonna say why don't we just target a test net that's for the CFI EIPs and then if EOF stuff is ready we can add it uh I guess the concern is it's going to be complicated to like have that optionality in the clients but I don't think we should like block it just for uh this other work stream I mean that kind of was what Shindong was though just without withdrawals right so to me it's like we've had Shindong running for a couple weeks with all the CFI things minus withdrawals people have been working out with the draws some people are interrupting and so the next one can just have withdrawals since we're already about there and then we can try and target the other EOF EPs who's there robbing uh Marius said that Gath and Prism have been robbed we're already a bit sorry why can't we just uh leave Shandong as the as it is right now and add EOF to it and if we want to test with withdrawals we we spend uh DevNet uh Shanghai DevNet uh that has that Shanghai core uh quote on quote thingies the IPs then we've like implemented all of EOF for Shandong and we've implemented withdrawals for Shanghai so it seems like we could just have that together but we can have it together once it's done and we decide like and I guess the thing I really want to avoid is say it takes us an extra week to implement like I don't know some EOF EIP you don't want that to delay the withdrawals work right like or whatever's already included so that's the risk I see which is bundling them is um right so exactly how coupled are they because like if it's easy just like basically you know flip a switch and we don't worry about it yeah yeah and I guess that's my question is like is it what's the thing to optimize for in clients is it just like the number of actual DevNet configs or how coupled the activation is basically if it's fine to like have if we want to minimize the number of DevNets then sure let's just put everything in Shandong but then that means that we might want we might be in a spot where like we have seven things in Shandong and we're removing four of them and is that like a worse place than if we just built them separate and have not coupled them because we didn't have this thing go in it depends on which four features get removed the EOF I view is fairly integrated but the other random instructions I view is fairly severable um so as far as officially pulling things out of Shandong into Shanghai when they're proven I think that shouldn't be too terribly hard especially if it's if it's all of Shandong on top of all of Shanghai it'll be really easy so we pick and choose out of Shandong depending upon the features that might get harder but Shandong does not include anything uh that is not in Shanghai yet unless it's EOF and as agreed we will only include EOF as one package so it's it is exactly as you said that if we want to have EOF and we decide that we have we will have EOF in Shanghai we can just put all of Shandong in top of Shanghai test I'm concerned if other things like unbounding code size or off or a T store and T read come in and I think he's yeah right now we yeah Shandong basically has all of the included stuff not withdrawals two EOF EIPs but not four so it's kind of a weird Frankenstein mix of like but I view what I listed as fairly severable EOF is one group T store T load is one group um unbounding cone size is one group and often off load is one group although they might get pretty pretty hairy to put it in and I'm not even sure that those will pass muster next week so I guess yeah just we're already we're already kind of over time um it seems like maybe the lowest friction thing to do in the next couple weeks is to try and just add 4,200 and 4,750 to Shandong whether we restart it or hard fork it or not you know that doesn't really matter and then maybe just get into that spot where we have that implemented in clients interoperating on Shandong um what we do about withdrawals on Shandong I think is maybe another question like we can have the withdrawals discussion on our cordial sugar out the best way to test that um if it's Shandong great if it's not we just do something else um but yeah does that make sense to people just so like we have a clear next step and how long I guess yeah last thing's like how long do we think we need to get that done in clients and should we have another one of these calls after that to figure out the right thing or can we wait until the next awkward dance and discuss things there um yeah well for Erdogan it's like it's the it's a bad option because we uh we would like I mean I think the general understandings that withdrawals take priority over uh EOF so if we have to first implement EOF to join Shandong then that will delay the the work on withdrawals right well withdrawals is not in Shandong yet right so like it's possible to implement and I believe test withdrawals without Shandong I know Marius was working on some stuff there um because I I agree I agree like this like basically withdrawals should take priority over like all the other sort of prototypes stuff um maybe I don't know yeah I'm not sure what the best top is here yeah to my mind we just need two two test nets one for withdrawal and one for EOF and whether which one of them Shandong will be it's another question but as I see it we need we need two test nets so probably one three four one for EE four eight four four another one and then but yeah Matt you were saying that's actually the most complicated thing to forget is to have multiple test net configs uh why is that I don't know oh and Matt has left um um but I don't know yeah that would be my preference as well but I think Matt seemed to say that like having more test net configs was more complicated but I think if we could have one we could have one test net for Shandong than one for EOF and one for four that would be sort of my my preferred option but I don't know it seemed complicated to forget to do that I don't know for other trying teams is that is that doable no no it's not complicated for us so it is fine to have three test nets so one Shandong so EOF and EIP for eight four four that is how I see things okay but that means we should reset Shandong because it means um they actually write this down super quick and I can be uh so you have Shanghai core which would have these EIPs sorry I'll share my screen in like one second but just to make sure we're all on the same page about this and then Shandong and Shandong and four eight four four both activate after uh Shanghai core so four four and then Shandong activates these four okay sorry I know this is kind of weird okay let me share this so I guess at a high level yeah um that means we would have to kind of rework Shandong because there's these two EIPs already but you basically yes exactly yeah and then these two yeah sort of are in parallel uh four four four and Shandong basically and we'll call this Shandong B2 does this I don't know does anyone have a strong disagreement on this so so you want to fork test net so you want to have one test net but fork it no no I just no but I mean that like in the Genesis file you sort of have you know the like Shanghai core activation at like block zero and then maybe you have Shandong activate at like block one or whatever or I don't know if sometimes can put them at the same block but and then the four eight four four test net is just like this right so but this is like Shandong I see so it will be easier it will be easier for gifting to activate it in this way and I think Aragon Andrew that's what you were saying that would be easier for you right um yeah so we would like to concentrate well first to concentrate on Shanghai core and with those because we might join the EOF test net quite late yeah so my point is if we are forced to join it earlier then it will probably delay our work on with those and I think if we do it this way it's a bit more work for the people who are already in like working in Shandong and on EOF but I think it might be fine because it means they can sort of set things up for others to catch up on and then that means it's like yeah teams that are not as far can just focus on this and we make sure that this bit goes out and say we add you know say we added an E included to Shanghai you know like on the next time for Devs then it just goes here and so and similarly say we decide to move all of EOF then this just becomes Shanghai core or you know if we decide to add for it for four then we just add this here but we keep basically we keep these blocks separate so that it's easy to like merge them as needed but you never have to like take only a subset of a block but I would have like do you mean that we need two test nets because to my mind we need three three because we need a test net just for Shanghai core yes correct so we have three test nets yeah you have Shanghai core, Shandong and 444 Shanghai core just activates this stuff and then but then the two other test nets they activate it but they're almost like two different forks they just activate one after the other or if it's easier to bundle it all together in one fork that's fine as well but the CL clients are like doing 444 this way basically where they activate Shanghai core and then the oh does anyone like do people generally see my screen or is it just Dano? yes yes yes okay okay I was like that if I could this is harder to follow if there's no text just to be clear Shandong will still include 3651 and 3855 and 3860 well yes but the question is I think it's probably worth it treat that as a separate fork in Shandong from EOF right you just have like two different hard fork configs one on block zero that activates Shanghai core one on block one that activates EOF basically why what is the reasoning behind this I'm sorry I don't know is this oh I guess for CL clients this is easier to do but if for EL for EL it's easier are you saying it's easier to activate all of this yes and like to just bundle it in one fork and then remove this part if you don't need it basically no because it will be a totally different definite so you don't need to remove anything there will be different config files for each definite that's it so you won't need to fork or do anything you will have one one config file for Shanghai including includes the first four and another config file that includes the first three plus the four from Shandong that you are listing and for 4844 you would have the first three plus 4844 and that's it right so I don't think the 4844 like this would work with how CL clients are doing it basically so CL clients treat them as like CL clients treat them as just different forks that get applied one after the other rather than like a different fork config because this means from Shandong experience because we had to run a CL client for Shandong as well we had also a like a separate config file for the CL client that has that configurations so it's it's it's not that for each test net you need to fork no it's it's not like that for one test net you have one config file period so then okay so then that means say you have something like this Shanghai core is this Shandong you you don't think we should have withdrawals basically um in it so this would be Shandong the two and then these three already in there yep exactly and I don't know if if people want to include anything more in 4844 it's up to you guys well we should I think this is probably what it looks like like or I don't know if it's do we need withdrawals basically like do we just do something like this what's the issue it's like lighthouse where you're gonna want to have to pillow and then for for after right that's yeah that's what I was saying but then it seems like Shandong doesn't work that way but that was sort of my original proposal of like we split them so that they happen sequentially I'll post this underneath but like so if you do this basically you have like sequential activation whereas if you do this this all activates at the same time and that's maybe worth discussing just on our core devs next week to see what's the best option for people I don't know do we expect do we expect to have this running by an excel core dev if not I think that's probably just worth having as a broader conversation of like how we activate this stuff um yeah because I do think like yes some client teams might some cl client teams might not be compatible with this um yeah I think we can wait for our core devs okay but I guess in terms of next steps then we agree that implementing 4247 50 in clients for EOF is the right next step okay no objection so oh yeah Alex like yeah the limit in it code would always be there by default in all of the EOF like no matter which config we take we'll have limit in it code by default um okay I think yeah I think we're good then um so in terms of next steps client teams can start looking at 4247 50 and then on all core devs we can figure out the right the right devnet config and I'll write something up and share it in the agenda so that yeah it's teams have the chance to review um anything else I'd like to suggest that that somebody creates an eep for EOF to actually disable dynamic jumps because prohibiting it in EOF version one Alex is that something the epsilon team can do oh okay it should be already okay it's disabled for 47 50 yeah I mean yeah that was the plan to be disabled in it um maybe we missed adding it but yeah yeah we can debate whether it should be like another EOF or not because we have already so many EOFs okay thanks everyone uh yeah and talk to you all thank you thank you thank you bye bye