# EOF Devnets Breakout Room

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 1:18:15
- Topics: blockchain, smart contracts, distributed ledger, ethereum, Science & Technology
- Watch: https://streameth.org/watch/yt-3Nx0z0-bhsU
- YouTube: https://www.youtube.com/watch?v=3Nx0z0-bhsU

## Description

https://github.com/ethereum/pm/issues/653

## Transcript

okay so we're recording uh we'll upload this to YouTube uh after for people uh it's not live stream though um I guess yeah the the main purpose of this call just based on the conversation in the last awkward Dev I think is to try and figure out what's the best path forward for eof and um how do we kind of get started working on that um I think there was a lot of discussion on accordance about whether we want to do kind of one big eof release or you know split it up it seems like people would rather have one but the risk there is that uh 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 um I think the the biggest probably uh uh objection by uh client thieves is like the idea of like changing the version too often so maybe if there's a way where um we can minimize the sort of long-term maintenance costs uh even by doing and not everything in Shanghai that would be uh that'd be another option um but yeah I guess I don't know I'm curious uh maybe from like Alex uh I don't know if Powell yeah Powell's on the call as well like uh the two of you or like the authors of this after the last stop cordov's like what do you feel is potentially the best path forward here and um yeah yeah I can see a few words um we had a bunch of internal discussions as well as discussions with the solidity and more specifically with the devnet we actually figured that the devnet would be like a really good um place to test out some of the the questions which have been discussed um for example but of course this really depends on resources on which everybody is low on um but a high hypothetical example um of what could happen on a Tesla on a devnet is launching only the first two erps and then rolling out the static jumps and just seeing if that uh needs a version bump or not and then rolling out the the function um feature which definitely needs immersion bump and just build up more confidence um in regards these changes because we um in terms of like you know rolling out then in step by step um which I do believe we don't want to actually do on mainnet um but it would be interesting to actually test this um uh on a devnet itself um yeah I think nothing has changed since all code is in regards to what would be the optimal case in our opinion which is rolling out everything at the same time um but we also discussed um some improved potential improvements to the functions um uh feature with solidity which we want to prototype I'm not gonna stop here now it's um Andrew so you have your hand up um yeah uh I'd like to uh elaborate on my understanding what the problem is I kind of what matters uh then if myros is here he can um he can also talk about it but how I see the problem with our initial uh uh desire to have a uif in Shanghai is that it didn't like the the two initial Eaves they don't deliver much and we would like to have a complete package with uh with some benefits and to my mind uh we also need to add one extra Eep to completely disable uh Dynamic jumps and uh to verify that we can compile solidity contracts without Dynamic jumps and that would be a selling feature of uh uof because without it without disabling Dynamic jumps then it's not clear what is the win of uh eof so I kind of how I understood it and I I concur Mario's point is that it doesn't make sense to have a somewhat uh intermediate version of eof erf1 that doesn't doesn't give any benefits just introduces a new format but then we'll have uof2 which will presumably deliver benefits but then there is no no urgent need no urgent pressure to have some kind of intermediate version without any benefits that's my take thanks um Rick uh yeah I'm wondering if uh 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 letters but as I understood Andrew this testnet could be useful when we add static relative jumps uh and yeah that that is what I want to say got it anyone else have thoughts just following from the last quarter of course um and and I would like to add at least how I see it uh maybe because I don't know anything about uh solidity but to my mind the the trickiest bit is actually implementing it in solidity uh and if we have verified that we that it works fine in solidity then on the client side and we have like a a complete uh uh complete spec uh then maybe it's not that difficult to add it into uh into El the clients but perhaps I'm wrong perhaps it's not that difficult on the solidity side thanks anyone else have thoughts are just following from the court of car yeah I like I'm like a bit more optimistic right now uh 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 two major features that people want to be in the next hard work so um yeah at least I'm glad there's some people interested still in this and we can work it on on a on the side kind of um and one one comment about solidity uh from the from this some discussions we had uh I think they kind of neutral in the sense that this is not really like killer feature in the UF they desperately need and that would like make their life much better uh other like code generator because they can Target existing evm more or less with the kind of similar efficiency so it's I think actually in this like Serenity case it's not like game changer but I guess if you don't have Dynamic jumps uh for eof maybe if it's still possible if it's if solidity is still fine with it then the the the the benefit of eif would be uh easier verification and probably some speed gains because there won't be any jump check uh jump desk check analysis and stuff like that so there will be a small gain yeah well it's it's not directly for them because it doesn't really matter like technically if they like use the existing jobs on the new jumps like how they generate codes like they will like do the same kind of thing but all right not really something that's changed the code generation right so maybe it will be a bit cheaper uh but this is not like exactly like answered how much cheaper that will be if the Johnson keeper um yeah let's kind of try to Express what what was my understanding of kind of daily position um Alex yeah I would say their position is a bit more subtle than that um just to answer like Andrew's question whether the first um just like the 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 um the the main benefit it brings is rather from trying to verify uh evm code um so it could be useful for 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 um comes as a benefit because there's no reduced gas so it technically could speed up coins in a minuscule percentage now regarding the full set of features that I think does bring benefits to solidity um on two sides what we discussed it can reduce some of the pressure on the code layout generator um because right now they have to move around like the return address on the stack um 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 um it could bring uh um I mean first of all it should be at least the same cost as it is today um in the worst case um but likely it could bring some or more benefits on the gas side um and it could also bring stumps like code size reduction um and implementing all this in in solidity it's not um inherently complex but it will take a tiny bit of time because of course the team is kind of overloaded um with other work um there was one feature they're planning to add which is uh actually break data types um in which um some of these features would actually be useful um so that's what we have been discussing um but there's no resolution on that yet thanks um my point of view um a couple things um if the gas prices for your job for anything close to my estimates in 2315 which they should be um they'll actually be substantial reductions in the cost of making uh making function calls and uh more important or at least as important um so long as we have Dynamic jumps we cannot generate machine code from byte code in linear time and space and that's that's very important for getting performance thanks um okay any other kind of high level comments about this if not then um so we have Sheng oh yeah again sorry um I think there is two things here one is introducing new up codes basically static jumps and call of the function and second thing is object format basically enforcing those things to basic using only those things and removing all jobs so first step would be introducing all those OP codes so this way the compiler and everybody work karate can use it and then the second step is introducing format that's going to disable all jumps so maybe for the first version we should just introduce those sub codes and for the second version it may be the not the the next hard work but the one after it you could introduce object format that basically disables old upwards that's for my site 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 chops you can't validate their safe use yeah yeah I know but that's that's why I'm saying there are two steps one is introducing them it's being basically in the valve and second step is introducing format and validation of the byte code that's going to remove the whole jump points but use only the new ones so you're gonna make me wait two more years before I can generate machine code think think about that in this way if we are going to introduce new up codes it's basically we are restraining ourself as saying we are going to use them Andrew how I see it in 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 uh the the new uh called f redf whatever instructions but uh to my mind it should be a kind of a parallel stream of work so that they dedicated stream of work to uof and we do not release it into into a main net uh hard Fork until we we we have the the last bit uh namely disabling Dynamic jumps that will be uh then we can say oh okay so we've implemented 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 your format is version one and because Mario's concern was which I share is that there is if we introduce some uif uh 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 mainnet mainnet update then I would go for one for the whole package foreign basically I totally agree with that there is no sensitive using the format that's going to be temporary and basically stuck inside the evm for The Eternity and probably not going to be used but we are we want to bundle to maybe separate things maybe we should First Step introducing our codes 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 uh one of the possible Parts nothing more Alex you cannot increase any of these up codes without the format because they rely on immediates and if you don't use immediates for them um then you go back to the the original problem of having them efficiently so they definitely depend on the format you cannot uh go the other way around and and what Greg was uh explaining that the validation algorithms we have um it depends on not having Dynamic jumps in order for uh you know the function sections to properly operate Bob hey I was just wondering um 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 um something to my mind that's really like a a a risk management thing where you you know you you've really got work that you're going to 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 um how strongly do we feel about trying to get something in Shanghai basically um and this is probably where like there's there's differences in opinion like yeah you see the chat um is there so um I don't know maybe a way that that kind of phrase this is like what's you know what's the minimal set that uh 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 than Shanghai um which is uh just 35 40 and 36 pests 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 yeah can I ask like who who is uh advocating uh to bring something immediate in Shanghai what what will be the benefit of having some something partial in Shanghai like clients you want to give us your take care sorry can you repeat the question I was still typing the chat uh why so so what what's the the benefit of having something in a partial in Shanghai I think you know I would rather just have the full like a minimal set of eof 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 the EDM and it like gets us on the pathway to doing these other things um 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 it right now maybe 4844 um but I'm guessing that 444 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 we just need some implementation to test it 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 like are we still debating whether to do that versus the current CF isolated I think it sounds like everybody agrees that we should do the whole 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 sets incomplete I mean I don't do we 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 media implementations we have some tests like we just need to finish implementing and testing it uh Andrew uh yeah like my preference would be my kind of personal preference how I see it uh is that we can keep Shanghai a small and deliver withdrawals there and also solve the issue of synchronizing El and cl updates and then have two parallel uh streams occur on top of Shanghai eof and uh and uh 4844 block transactions so how I see it we could create two uh uh two uh maybe two provisional updates like uh to provisional hard forks uif and blob transactions and because eof what we want to do we want to deliver a a number of Eeps so we want to synchronize we chips go in and so on so it's it's uh it's it can be a dedicated hard fork or it can be end up merging with uh the 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're done with uof and block transactions are not done then okay just have a hard Fork releasing eof stuff so I would decouple the progress of the term 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 uh because uh previously uh our heart Forks were based on the block number but now we want hard folks to be based on the timestamp and that will also feed into the uh Fork ID and things like that it's mostly technicalities but still something that we should uh sort out okay I mean I 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 time stamp 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 eof 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 4844 we have vertical 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 vertical and so I think the best that we can do is ship it in with another Fork well the thing is that uh you you kind of if uh the the the the the the the this work is quite independent one is heavily on the EDM side 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 uh then you can say oh okay it's ready uh so let's merge it with another hard Fork that's no problem because the bulk of the work is is done already so it doesn't have to be a dedicated it's just 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 uh like the the just like zoom out a little bit I think you know the 4-h4 people would say the same thing um or it's like I think the similarity there's this other effort that's trying to get this in Shanghai so I don't know is the and then what we've landed on basically on the CL side is that we have this uh this this withdrawals fork and then on top of it uh 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 we're like it's basically saying like look we're gonna assume we're going for default eof we're going to get it prototyped and like you know just from like a code based perspective you build it on top of the withdrawals Fork um but separately so that you know you can pull it out worst case at the last minute and best case you just activate it on the same block or the block after or whatever um but that gives you sort of time-wise a way to to like have them be coupled but code wise be separated um 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 in most clients but um if we're going for the full and the sort of consensuses we'd like to see the folio F go live at the same time then maybe just separately separating that um kind of like we're doing with 444 is the way to go I'm yeah uh Lucas you have your hand up yes uh so uh two things from from another mind perspective uh 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 pay attention to leave and implement the whole thing uh 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 uh can we like guaranteed stay being stable and secure uh on the release um yeah that being said uh this has full support of another mind and we want to uh we want to prototype it we want to be included and we want to see it through uh whether earlier or later uh 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 uh yeah um one suggestion from from me is uh that uh how about if some client teams like as as Lucas said Netherland is all for for aof obviously but uh if if some client teams are feeling uh hesitant uh about implementing the full aof for Shanghai what if we can like okay put in the plan that before Shanghai and the devnets we will test eof uh a couple of the IPS that are in the URF spec and these are a must uh even if they are not included in Shanghai but they're a must for devnets and in devnets we will include them but for Shanghai we want and that will push the clients to implement these ones and then once the spec is finalized for the other ones uh 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 be in a spot where the code is just very coupled and then we need to remove it from Shanghai basically um so like um if because in the past we've seen consensus issues on maintenance caused by removing eips that are activated together so that would be my only [Music] um 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 definite just has the withdrawal stuff and like you know the three other tiny VIPs and then um you just have another devnet on top of that that activates like all of the eof VIPs separately um and this way we can kind of keep iterating on the set of eof eips and the implementations but uh we're not in a sponsor 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 the yeah the string High spec um yeah so that would be my but I think generally though it's like I guess in terms of next steps we already have shangdong which has two EO feips that's running um what would be like the way to just grow 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 can we just have the full eof in the next testnet yeah what so and but just to make sure we're all on the same page so the full eof is 35 40 36 70 4200 and 47.50 is that it oh and 54.50 which okay yeah I mean towel you have comments 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 year fees are there but like what else so I checked out yes please I can answer so uh evm object format uh three five four zero and eif code validation and there was there are some transactions uh on eff 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 pictures because it's already there and like people can join if they are late and we can 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 costs for proportional to the Eid code size and 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 uh considered from Shanghai that is not in the test that 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 not very specified yet isn't isn't self-destruct also the activating sort of destruct uh in Shanghai no we we haven't made a decision on it so some people would like it to be but it's not not here yeah um Dano as you heard your hand up for a while so 54.50 uh that's the code validation I still feel it's a little bit underspecified while 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 um so we mostly like 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 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 more or less what we don't 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 your next devnet do we want to have that in or do we want this um so much more kind of a bit 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 it's 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 devnets right like we don't have to do everything at once my gut feeling would be trying to add 4200 and 47.50 first and that gives the Epsilon team some time to specify 54.50 in parallel um and also like a easier Target for for find teams to reach that might be a better way I don't know how crime teams feel about that uh 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 will 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 development 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 audition that make evm more efficient and we can save some like that gain some efficiency in the AVM implementation and yeah I think I wouldn't uh forget a lot of time right now on this okay so if we have this then as like a sort of spec for the devnet which is 35 40 36 70 4200 47.50 what's the best way to implement it do we just want to extend Shang dong 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 devnet that's built on top of withdrawals um yeah I just recline teams 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 there was chatter on their Discord are 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 qingdong 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 2 or whatever like I it's probably easier to do that than to try and like actually a hard Fork the devnet 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 uh static jumps and the thing is they are backwards compatible with the current eof that is deployed so we can test if that works nicely uh I'm not sure if we even need hard work or maybe even coordination would be enough like we said like from this date clients actually have it implemented I don't know what is static jobs what's EIP is that they just adds 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 10 40. so 4200 and 47.50 static relative Junction 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 there aren't up to date will just fall behind until they implement it yeah exactly that's only for the for uh 47.50 with a static static proactive jumps they are there backwards compatible because whatever your ads been extraction that's fine so we can actually take out relative we take out Dynamic jumps though that would be no they they will co-exist they will coexist so we don't have to take away they will collect this incredibly fine so like this is like like yeah the the current version plus Edition which we don't have to like reset the test net or like schedule a hard work I mean it's not something we 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 implemented and then join later as something I don't know exactly that not really good at like organizing tested but that would be like the second thing we can add to it and then we can uh do the the last one which is uh 420 that's that's eof functions and that will require the version bump so there are two two ways we can do it we can do with the EOS version bump so we can test it out or we can just reset the test net with the new eof1 but have more features but I think that would be we'll need to like start from from scratch so I don't know like you actually have a lot of questions how this track does not operate if 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 UF code yeah we've yeah we can I think we can resolve that once we have it implemented in clients like we've done this for a bunch of other devnets in the past it shouldn't be like a massive blocker um Andrew I think you were Andrew Madden and Lucas um yeah my kind of in Aragon we don't have any implementation of EOS so from our point of view we definitely would like to separate tests test nets for Shanghai core like withdrawals and whatever goes into Shanghai and EOL because if we do them in a single test now that that that would uh slow down withdrawals for Aragon from okay from my point of view if maybe we don't join the erf test net until uh relatively late but you don't need all four clients to prototype this so in solidity and so on once it's all ironed out then once it's all settled then we'll join of course thanks uh Evan yeah just uh to to to clarify uh the two eips that you would like to include on top of Shandong that are not already in Shandong uh which ones are there and have the ethereum JS team already implemented them or not yet the tour 4200 4750 I'm not sure if ethereum.js has implemented them um yeah Lucas uh I have a question about state of testing apart from devnets um I see that as a good very good integration testing and very good practical testing but from implementing point of view the various useful tests are Hive test ethereum tests and are there any test vectors being prepared there for any of those cips or maybe we have it already in some PRS so I can ask where are you uh so for two first eips we have uh tests uh but but I'm not sure about others and I'm not sure about the also um status of this test if they are cover all scenarios but I think they should okay what's the status of the other eaps then um yeah so like for that first we have state tests um that's kind of like I don't know almost ready so we can you can use it there in the prequest for tests test repo uh we like uh ethereum JS actually found an Embark in the test so uh we have to fix uh but so far it looks okay and and the next one is actually uh to get tests for uh the eof functions um 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 status to blockchain test and I think the blockchain tests work on hive so so I guess we have some pieces but that's probably not fully integrated so maybe we need some help foreign 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 parts that's that's kind of the problem I think yeah that's good enough for us we can execute them from from a brand from PRS no problem okay I guess yeah I did 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 47.50 um is is what we should go for how do we implement it um like do we have this just in shangdong um is that the simplest for if it's simplest for get basically another mind and not Aragon it probably makes sense to do this as like a V1 um but then if we do that are we just like painting ourselves in the 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 dips from eof um yeah I I'm curious like what's that how the client teams feel about just what's the most efficient way to implement this and um does this lock us in a specific Direction sorry could you repeat the question so yeah yeah for another mind um is it easier to just extend Shang dong with those two VIPs or should we create a new test net and kind of have a separate Fork where like Fork one is basically the Shanghai course stuff so withdrawals and like the other small VIPs and then Fork two would be eof basically so my opinion is if we want to create a hard work on Shandong uh we should decide how we want to uh Fork it by timestamp or by block number and maybe it will be easier just to uh restart shutdown 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 Shandong when we Implement these features if we restart shangdong I agree like not having to deal with the timestamp stuff is probably good if we restart chengdong 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 the other eips that are included in Shandong already are fine and are already implemented from our site so we don't have a problem with them being included with whatever eof eips we want to add into Shandong uh so that I believe uh it's it's it's it's it's fine to just stick with Shandong for any eof testing and just include the same here IPS okay and that means and and then that won't cause a problem say we do have Shanghai and eof is now in it then you need to have basically Shanghai without eof and you kind of need to rework that for us not a problem because uh we can specify what EIP we want to include the configuration so it's not a big deal okay uh Andrew uh well from for Aragon uh the strong preference is to have uh to restart changdon without any uif eaps uh concentrate on but but have withdrawals and it's like concentrate on withdrawals testing and make sure that withdrawals and Shanghai go work fine and have a a fork later or maybe a parallel test net so I'm like yeah our preference is definitely to decouple uh with Shanghai KOA and eof foreign guests any thoughts on that can you repeat it I was in chat lamps yeah um so basically is it better for basically to just have the Shanghai core stuff separate from eof and then have kind of another Fork activate letters on shangdong or somewhere else that just includes the four eofvips um it could be real to support both because we could just underneath the covers do Shanghai and then qingdong 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 corn base uh limiting the init code um my concern though is what's going to come from the EIP Bonanza on Thursday during the next all Court devs call stuff like transient store um unlimited block size um off 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 devnets that are building towards what's actually included and then separate devnets 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 changed that set of VIPs there and then um if you know we have something like uh 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 um yeah we decide to merge them together um 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 according devnets is expensive Dev time um 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 um a la carting specific test Nets turning features on or off I would prefer to see it be a small number like two Shanghai but 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 I 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 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 uh 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 and shangdong so um there's no chance we'll activate withdrawals for the next shingdong or the next test or whatever it is well I think from Awkward as it's like well you're going to want some withdrawals devnet 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 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 I mean from my perspective uh on guests that's yeah pretty straightforward for us but I think that we have maybe a bit more of eof implemented in smaller clients so it's a little it's a little less work in that front um yeah but like if I was the only one making a decision I would just say to have the next test not have everything slated for Shanghai including the full Elf including the trolls 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 so 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 Alexia uh yeah I was gonna say why don't we just Target a test net that's for the CFI erps and then if the U.S 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 walk it just for uh this other work stream I mean that that kind of was what shendong was though just without withdrawals right yeah so to me it's like we've had shindong running for a couple weeks with all the CF I thinks minus withdrawals people have been working out withdrawals 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 eaps who's there up in uh Mario said that death in prison have interrupted okay sorry uh why can't we just uh leave Shankar Shandong as the as it is right now and add the uof to it and if we want to test withdrawals we we spend uh Shanghai devnet uh that has that Shanghai core uh quote unquote uh thingies the eyepiece then we've like implemented all of eof or shendong 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 EOS 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 with just bundling them is um foreign so exactly how coupled are they because like if it's easy just to like basically you know flip a switch then we don't have to worry about it yeah yeah and I guess that's my question it's like is it what's the thing to optimize foreign 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 chengdong but then that means that we might want um we we might be in a spot where like we have seven things in chengdong and we're removing four of them and is that like a worse place than if we just built them separate and had not coupled them because we didn't have this thing go in yeah it depends on which four features get removed um the eof I view is fairly integrated but the other random instructions of you is very fairly severable um so as far as officially pulling things out of shingdong into Shanghai when they're proven I think that shouldn't be too terribly hard especially if it's if it's all of shangdong on top of all of Shanghai it'll be really easy so we pick and choose out of Shing qingdong depending upon the features that it might get harder but 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 on top of Shanghai test I'm concerned with other things like unbounding code size or auth or t-store and t-read come in and the thing is that yeah right now we yeah shangdong basically has all of the included stuff not withdrawals to eof VIPs but not four so it's kind of a weird Frankenstein mix of like but I viewed what I listed as fairly separable eof is one group T stored C load is one group um unbounding cone size is one group and auth and auth mode is one group although they might get pretty pretty hairy to put it in and I'm not even sure that those will pass uh muster next week so I guess yeah just because 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 4200 and 47.50 to shangdong whether we restarted 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 shangdong um what we do about withdrawals on qingdong I think is maybe another question like we can have the withdrawals discussion on all Cordell sugar out the best way to test that um if it's changed on 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 um and how long I guess yeah last things 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 danger can we wait until the next awkward ads and discuss things there um yeah well for for Aragon it's like it's the the um it's a bad option because uh we uh we would like I mean uh I think the general understanding is that withdrawals take priority over uh eof so if we have to first Implement uof to join Shandong then that will delay the work on with drugs right well withdrawals is not in shengdong yet right so like it's possible to implement and I believe test withdrawals without qingdong I know Marius was working on some stuff there um because I agree I agree like this like basically withdrawals should take priority over like all the other sort of prototype stuff um maybe that I don't know yeah I I'm not sure what the best top is here yeah to my mind we just need to to do testnets uh one for withdrawal and one for uh uof and uh whether which one of them shank down will be it's another question but as I see it we need we need to test Nets so probably even three four one for you uh four eight four four another one and then but yeah Matthew were saying that's actually the most complicated thing forget is to have multiple test net configs uh why is that I don't know oh and math has left um um but I don't yeah that would be my preference as well but I think Matt seem to say that like having more test net configs was more complicated but I think if we could have one we could have that for Shanghai then one for Eos that would be sort of my my preferred option okay um but I don't know it seemed complicated for guests to do that I don't know for other fine teams is that is that Google no no it's not complicated for us so it is fine to have three test Nets so One Shanghai car uh Shandong so eof and EIP for eight four four that is let me see things okay but that means we should reset shangdong because it means um let me actually write this down super quick and I can be uh so you have Shanghai core which would have these VIPs uh sorry I'll share my screen in like in one second but just to make sure we're all on the same page about this and then shangdong and uh shegdong and 4844 both activate after uh Shanghai core um so for four and then Shan gong activates these four okay sorry I know this is kind of weird okay uh let me share this uh so I guess at a high level yeah um that means we would have to kind of rework shangdong because there's these two eips already but you basically yes exactly yeah and then these two yeah sort of are in parallel uh for it for foreign does this I don't know does anyone have a strong disagreement on this so so you want to Fork uh test net so you want to have one test net but uh four kids 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 shangdong activated like block one or whatever or I don't know if I some clients can put them at the same block but then and then the the 484 Ford test net is just like this right so but this is like shangdong I see so it will be easier it will be easier for gifting to activate it in this way I I think Aragon Andrew does what you were saying that would be easier for you right um yeah so uh we would like to concentrate uh well first to uh concentrate on Shanghai core and withdrawals because we might join the UF test net quite late yeah so my point is if we are forced to join it earlier then it'll probably delay our work on withdrawals 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 shengdan 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 um 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 Eep included to Shanghai you know like other Nexon core devs then it just goes here um 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 4844 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 um but but I would have like do you mean that we need two two test Nets because to my mind we three three because yes we need a test net just just for sure yeah correct so you have three test Nets yeah you have Shanghai core shangdong and 444 um Shanghai Court just activates this stuff and then but then the 200 test Nets they activate it but they're almost like two different Forks they just activate one after the other or if it's other easier to bundle it all together in one fork that's fine as well but the CL clients are like doing 4844 this way basically um where they activate Shanghai core and then the the the the the oh does anyone like do people generally see my screen or is it just that no yes yes yes okay okay I was like that if I could this is harder to follow physical text um just just to be clear Shandong will still include uh three six five one and three eight five five and three yeah eight six zero well yes but the question is I think it's probably worth it treat that as a separate fort in shangdong 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 what is the reasoning behind this uh I'm sorry I don't is this oh I guess for cl clients this is easier to do but if for El for Els it's easier are you saying it's easier to activate all of this and like to just bundle it in one fork and then remove this part if you don't need it basically um no because it will be a totally different devnet so you don't need to remove anything there will be different config files for each devnet that's it so it you won't need to fork or do anything you will have one con one config file for Shanghai including includes the first four and another config file that includes the first three plus the the four from Shandong that you are listing and okay for uh 4844 you would have the first three plus four eight four four and that's it right so I don't think the 4844 like this would work with how CL clients are doing it basically um so clients treat them as like um clients tree damage 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 like a separate config file for the CL clock 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 shangdong you you don't think we should have withdrawals basically um yeah V2 and then these three are already in there uh yup exactly and I don't mean if if people want to include anything more in four eight four four uh it's up to you guys well we should I think this is probably what it looks like oh I don't know if it's do we need withdrawals basically like do we just do something like this is the issue with like Lighthouse where you're going to want to have capella and then for it before after right that's yeah that's what I was saying but then it seems like shangdong does it work that way but that was sort of my original proposal of like we split them so that they happen sequentially um 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 all 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 devs 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 client teams might not be compatible with this um yeah I think we can wait for awkward deaths okay but I guess in terms of next steps then we agree that implementing 4200 and 47.50 in clients um for eof is is the right Next Step okay no objection and so oh and yeah Alex like yeah the limit in the code would always be there by default in all of the eofs like no matter which config we take we'll have limit init code um 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 for 200 47.50 and then on all core devs we can figure out the right uh the right uh devnet config um and I'll I'll write something up and share it in the agenda so that um yeah it's teams have have the chance to review um anything else uh I'd like to suggest that um that somebody creates an an Eep for eof to actually disable Dynamic jumps because the prohibiting it in UF version one Alex is that something the Epsilon team can do okay so it should be all right okay it's disabled in 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 VIP or not because we have already so many fees cool okay thanks everyone uh yeah and talk to you all I'll call you guys next week thank you thank you very much thank you bye