Interop Testing #34

Transcript

[Music] Heat. Heat. All right, starting now.

Um, yeah. Hello everyone. Uh welcome to interrupt testing number 34. We have a very packed agenda today and um the idea is that we start with everything nonuf uh and then time box that to 50 minutes at the start and then we proceed uh to discuss EF uh team is going to help us moderate uh on the EOF uh segment. So yeah, let's just get started. Um so the first item in the agenda that is non EF is spectra testing. Um before anyone um any other points the only point from the testing team that we have today is that there has been a new release um I'm going to share it in the

chat and uh it mainly contains the main breaking point in this release is that we have introduced the deposit contract testing. So these are basically impossible test test scenarios for mainet but uh this something that we want to test. So that's what we wanted to include. Um we're going to reach out to every client team to see their status and their um their their stance on on fix and no fix for for this impossible test case. Um yeah and that's there's there's that we have run the all of the other test cases for this uh in hive and it seems like everything is looking well. Um and the other bullet point from

the EF testing is that we are going to potentially make a new release for this week. Um it's going to be uh packed with more BLS testing. Uh but we have uh run every single test case on all clients and everything is looking good. Um, and yeah, that's basically it from the EF testing. Um, I'm passing on to DevOps to see if they are having any any points they want to raise uh, regarding practical testing. Uh, let me see who's here. Hey, yes, thank you. One or two points, I think. So, we're working on the mainet shadow fork right now. We should have the network up in the next hour or two and we'll share a report about it tomorrow. um one of our nightly

tests it failed with uh with an assertto failure on consolidation. So we're just trying to reproduce it and if it's actually a non-f false positive then we'll bring it up. Um but besides that I think Barnabas had one more point he found over the last few days but that should be it from our side. Um my yeah my point is mainly focused on minimal spec test. So we can circle back later. Uh Barnavas is the same um request per payload uh for main and minimal or is something else? All right. All right.

Cool. Uh Pow. Uh will the east release contain the static test? Yes. Yes. We're looking forward into that. And uh we Yeah, we have everything ready for for static test should be included. Yep. Uh Justin, so Basu had an update over the weekend where we are actually failing fast if you have PCRA enabled at Genesis, but you do not have all the system contract addresses defined in your Genesis. Um so I think that Barnes might be aware of this. Perry wanted to bring it to your attention. You're going to want to update to the DevNet 7 Genesis file that I opened a PR for at least um

for the mainet shadow fork. The details are in that PR. Oh, we probably not going to actually do uh genesis or genesis for the shadow fork. We probably want to see a fork transition. So, I think it shouldn't be a problem. No, no, no. Not not pectra genesis. Just if it has pect enabled anywhere. Oh, anywhere. Okay. Yeah. Yeah. If you have a Pectra milestone, you need to have those contracts defined. Okay. Yeah, we will have it. Godspeed. On that topic, uh, we merged the Hive U PR yesterday, so we should be good there. Thanks, Mario.

All right. Any other Pectra testing related uh topics that we want to cover today? Anybody else? Um, Luka just posted the station packing bugs have been fixed. Um, and he posted an analysis. Uh, anything else that you want to comment on that? Oh, that's it. Just a confirmation that it's been fixed. Awesome. Thanks. Uh, Barnabas. Yes.

Yeah. I have one more point to raise. Uh Nimbus made a new release in last weekend. So if anyone has updated their Nimbus node then uh they might need to update again. So this was regarding the bug found in M workflow and from the comments prison primim is also preparing a 6.0 0.1 release as well. So, please take note of that and update notes. Um, all right. If there's nothing else, we can do a quick followup to pure dust pure dust testing.

Um, uh, does the DevOps team have any updates on pure specific testing? Um, I think the only one is that we got rid of devet 6. So pieras devet 6 has been deprecated. So all the testing that would be done on pas would now be done on the sunnyside labs network. Um and the pure uh the main reason is that we found quite a few bugs over the last week and clients needed some time to fix all of those bugs and there was no sense in the network until the bug fixes were in. So, we're hoping that some point this week we can launch uh DevNet 7 for Pas. Sounds

good. Anything else uh for peer test? Any clients? clients are ready for DE7 or anything that they should know about this uh this new TA. I don't think so. I think most of the discussions would happen on the Pasing call that'll be tomorrow. Um and there's already curtosis configs for whoever wants to try their fixes locally. Perfect. All right, we can discuss it.

uh tomorrow then um if there's uh is is there anything else for pure desk that any wants to anyone wants to bring up otherwise um before jumping into ef the point that Barnamas do you want to re uh raise it regarding minimal mainet consensus specs change? Yeah. So, we talked to Justin last week about uh possibly changing the minimal spec uh for the execution uh request. For example, the uh max deposit request per payload and max vidual request per payload. And we came to the conclusion that it's probably better to

use the mainet uh defaults instead of trying to have a custom that you set for minimal preset because then the E side of things would also need to know about uh the minimal spec and uh that's not something that uh currently any of the EL support and probably not something they want to support either. So if this uh disappear about that, let me just link it quick. Oh yeah, Mario already linked it.

It would be good if all the CS could uh take a look and maybe even squeeze this change into their next small release. Hopefully then uh we can start testing uh the minimal up two. All right. Um, yep. One quick one quick one quick thing. Clients will probably need to wait until the next consensus specs release to make this change.

Otherwise, the tests will fail like the reference tests. Yeah. The question is whether we want to push for this before uh may not turn off. I see no reason to do that. Yeah, same. I think it's mainly just a minimal test with a certain number of deposits that fail, which I think it's fine to wait for a week or two before makes sense. Okay.

So uh CL client teams please please take a look into this PR uh so we can coordinate what what the following steps are. All right. Any other nonf topics that we want to uh touch upon uh that are critical before jumping into ef discussion. Um Tim, do you want to kick us off in the topic? Sure. Um yeah, thanks Mario and uh yeah, thanks

everyone for showing up. I think this is the first time we get 100 people on the testing call. Um yeah, I guess before we we we jump in just a couple things like first of all I know that uh we'll feel very strongly about this and um I think it's worth being clear that like whether or not we move forward with EOF like clearly there's been a lot of work and effort put by client team by EIP champions testing teams and other into this. So like I I don't think we should associate decision to do eof or not based on like uh or or that should imply that we don't kind of value that work like um it's good that we try things out and if we learns that they're they're not a fit or they're not a fit for now

uh we still did learn something and yeah very differing opinions about uh what we should do here. Um my sense is I do think people generally want to improve Ethereum. So please keep this in mind as you respond to others throughout this call. Um I I don't think that anyone is acting in like bad faith or malice. Uh people may have different visions of how do you get to a good end state but um yeah we should try and assume the best. Um and then before we uh jump into the specifics like I know a bunch of people raised concerns about like the process and should we even be opening this can of worms again. Um I think my view there is that it is important that the process

gives you like some credibility and uh assurance that you know when we make a decision we don't work on it uh in vain. Um that said like we can never be sure about these things and this is partially why we changed you know the EIP status from included to scheduled for inclusion is that things come up and we have to adapt and I think until something's on the Ethereum mainet we should always be willing to reconsider and get to the best decision. Um when we ship something we cannot revert that um and so we should really really have a high bar to doing it. Um, and this means that, you know, we should be okay descoping when necessary. Um, and and having like a very high bar to then change or have

last minute additions. Um, because again, that kind of undermines this. Um, this said, I think at a high level, a good way to like proceed here is um, we can quickly recap the issue uh, that came up last week. Epsilon has done some analysis over the weekend about uh, the actual like scope and what's been affected. Um so we can can hear from them and then uh the client teams uh have shared their view around uh eof so we can hear from their updated views. Um but maybe yeah for people who who weren't on awkward devs uh last last Thursday at a high level the the kind of problem or thing that came up um is the concerns that um not only um not only does eof have some um h you know uh have

some compilation issues for existing contracts that use code introspection which people knew uh but more that many of the core dependencies that are used in these contracts um effectively use uh inline assembly or features like that that make it um uh that make it harder or impossible to import them in both eof contracts. Um this is a pretty major change in the developer experience because it's not just that you can't you know rewrite your contract but you can't use say an open zeppelin library in your contract uh if you're compiling under eof and that concern kind of triggered this entire um this entire debate. Um so yeah that's basically the thing that

changes like I think this realization that um there are many core libraries that would have to be imported in few ef contracts that uh that that would be impossible to do so in their current form. these libraries would not break on Ethereum like they would still work as is um and you know people can still use the legacy EVM forever but it's just that the migration path of most popular or like production applications requires not only the engineers from that application to write some new code but also their entire uh dependency tree um possibly. So, with that said, um yeah, I don't know who's the best person from Ipsilon, uh but they did write a great document going into more depth there.

So, um if someone can post a link and give a quick overview of the actual issue, that would be helpful. Okay. I posted a link on the summary. Um wrong link, but you can get started and I'll find the right link. Oh, yeah. That's the call link. Um I just copy paste here on my keyboard. Kind of a problem. Uh you have source lids impact. Um maybe I should share the screen on this. Yeah, sounds good.

So we looked at the top four contracts. Um well, top four, we picked four big ones we thought that would, you know, be emblematic of the types of changes that we might need to do. Um to just do a straight compile, just turn on eof lag and see what happens, see what works. Um we did unit swap um found some issues with call and gas. Um there is one issue with um with forge st with the forge standard libraries that we'll address when we get down to forge but those are mostly all of the changes to um needing the unis squad v4 core. These all revolve around the call and the gas operation. Um and these are we put a recommendation at the top of this which I'll go over in a bit. Um but these changes this remaining issue we don't

need to do that if we do the option D. Um I I took a nap because I couldn't stay up all night. I fell asleep. Um open zeppelin is a bit more interesting. Um there are a lot of instances of call and um gas being used. Uh and there's also some instances of using um extence of contracts. um the 2771 forwarder um would would need to have some adjustments um that are you know because it uses gas and it has a good valid reason to use gas which figures into our choice for option D um and that the solution there um in the in what's called option A would not be

um we couldn't do it as as coded create two um in general we're doing different things with create these are all specific create two things and basically is a library that helps you do the quote unquote the right thing with create create 2. The fix here would be to write a efre or a CX create library that does the right things that does the analogous things. Clones is a very interesting library um that depends on some very specific create to functionality um not much that can be um done there. and uh 165 checker has a hard-coded gas value. Um and that hardcoded gas value has been there for like almost a decade.

Um and that's the number that's being recommended there. So apart from these specific libraries, um you just need to update the calls on open zeppelin and those can be used normally. Um Forge is unique. Forge is the build tool of Foundry. um they uh do some very deep and and novel c uh custom VM integrations which are very clever and as as a developer I kind of enjoy what they do there. Uh most of the changes are again around static call. They only use static call. Um there is one issue with how to load um contracts in from the file system and I detail here but it's basically an onbrand solution for how they could use the new TX create option when they're loading EOF code um doing changes to the VM that

are consistent with how they do other changes to the VM when they run in their when they're um in their environment. And finally, so lady um they have uh their own eof plan. So lady really focuses on custom assembly. Um but they have their own plan. So we didn't dive too deeply in there. I'm going just refer people to theirs. Categorical sum summary of all the problems mostly resolve around EIP769 which is the EIP that implements banning gas introspection. Um if we get rid of this most of the issues above here are no longer issues. Um, hard- coding gas values is also part of EIP769 because we ban the gas op code. You can return the gas op code and add um your

hard-coded values into your call. Um, this is a I consider this a separate category from hard-coded gas values where you put a real number in your contract. But if you limit the gas available based on some other feature like a user operation or some sort of assigned call data and pass that value in that's similarly impacted. I think this is the safer way to deal with the auditing recommendation not to hardcode gas values. You fill in with the gas but you make it a function of something that comes from outside the transaction. So if gas prices change you can update it. Um and if we um remove 769 from eof this is fixed introspecting account types. Uh this is a different thing that we're recommending as part of option D. Um is we return the ext code size and uh ext

hashing txt code copy op codes restore those into eof but keep the same behavior when reading eof contracts. So when we restore that behavior, we're able to figure out if an account has a contract or not using the same techniques as before. Um direct use create and create two um those are not something that will be adjusted by option D. Um but these are t generally um either things that you're doing as a library to um help the end user do the right thing and could be replaced with a new library targeting tx create or efreate or you really really have deep and interesting things to do with create and uh we think the same um abilities exist with efx create you just need to write slightly different code to deal

with it and you would generally be a very uh entrenched very infranchised entrenched developer who would know um how you would develop these sort of um solutions. So while it would be code change, I think the developers that would need a change of code would be very aware of what would need to be done. So as I mentioned earlier, um EOF um is recommending that we go with get pre preferred solution which is the option D uh in the document we provided in March for EOF. This option as a summary would restore ext code hash and ext code size um and allow code uh we're changing nothing in legacy but this is inside of an ef container where it would then be allowed

to use those op codes. So code that expects that an assembly would compile just the same. Um the behavior when looking at eof code to preserve the key features of code introspection that we're getting from that would remain the same. If you try and introspect an eof contract, you would get a contract that looks like the device EF0000 and you would see nothing else in there. So you can figure out that there's a contract there. You can figure out it's eof contract. Um but you couldn't copy random bits of code out of it. The next thing that was important about ef option D is we remove the entire band guess introspection theme from eof. This would return call, static call, and delegate call to be valid operations within an ef container. call code is a deprecated op code. So we

would not bring that in. It's the same treatment we're giving self-destruct. And also the gas op code would be available within an eof container. Um so if you open this up uh I should share this. Let me share this link inside the chat. Let me find the chat. So if you open up the summary, this gives the summary of the the final state of all the um all the all the op codes that are um added and all the op codes that an ef container cannot use. Um and it's it's a relatively much smaller list create if necessary for the for the new create path jump for relative jumps. the uh call code self-destruct deprecated and code size and code copy also

similarly for the um for the code introspection. The changes to the EIPs are not terribly large. Um the only EIP that has a functional change is 3540. Um we update the list of band op codes and provide this behavior to all. um the remainder of the of the EIPs either change text in rationale or motivation or if it's a meta EIP the lift of which EIPs are in there. Um the changes to testing code the testing code is very well set up to handle a change like this. EF wrap brings all of the pre- steel team tests um into uh into the ETH tests and we

would just need to update a few parameters to say which op codes are valid for EF and which op codes are not. So we would get all of the existing um legacy tests also apply to EOF. Um we would not need to then write tests for extra because those EIPs would be removed. Um we could repurpose the ext then be able to do gas testing directly. Changing the client codes is also pretty simple. you need to update your dispatch tables. Um, update any other places where you're preventing eof op codes from being used outside or other outside non eoof op codes from being used inside ef call from your instruction dispatch.

Um, clients should consider removing exe call but that's not required. And the changes to the test net plan um, basically things move left two weeks. Um, we keep uft plan one in place because it's basically done. and we're just waiting for for teams to finish implementation and the DevNet 2 plan would remove um the new the new EIPs that we're implementing and would simply be the EIP where we are um changing the op code tables. Uh we would expect we could ship this two weeks after EF devet one instead of a month and because of this we anticipate that we could be ready um for all protocol changes for EOF before the first Fusaka DevNet zero change uh test net. Um so this next to at least removing two weeks out of the

continued work for EOF and makes it likely so that we will be done before June 1st with major protocol changes. Um still left up are the possibility of EIP 7834 the metadata section and uh the payoff code. Those remain in CFI and those will be determined via the uh existing EIP the existing ACD process if they go into scheduled or if they go into decline. So that is epsilon's recommendation going forward after having listened to all the feedback and considered all the implications um not just the developer experience but to broader things um such as crosschain calls um and uh things like account abstraction wallets and

there's a lot of uh use cases where being able to specify an external gas value is essential and looking into that there really is no other good option other than to let them control the Um, I haven't looked at the chat. Thanks, D. There wasn't, there's a lot in the chat, but I think the one relevant question is that Lucash just posted, "What are the downsides of going with option D relative to the other ones?" Um, so why do options A, B, or C as opposed to D? No. Full EOF versus option full EF. Yeah. Okay. A is full EOF.

Yeah. So it's just that we lose the ban on gas introspection or is there right right the ban on gas introspection goes away and we would lose the ban on reading um code that is not eof um both however escape hackers exist. Go ahead. I I think the point is um what do we lose by bringing those back rather than so why did we ban gas introspection in the first place is maybe the the good of this question. So the reason to ban gas introspection in the first place um the motivation there um was to make gap schedule changes easier. When we change

a gaff schedule, we always have problems with people who have hard-coded values either directly in their contracts or in their developer tools and suddenly things start breaking. If it's a developer tool change, those can be updated. But if it's in the gas, if it's in the contract code, any gas schedule change has a potential of breaking contracts. Um, this is a problem with some contracts because we updated the S load and S doors way back before 2020. And it wasn't until we brought in EIP 2929 and 2930, but there was a way to um unfreeze those contracts because we changed the value of a S load from 100 to I think 2,500 which was a very expensive change and broke some contracts because they hard-coded values and expected that gas

schedule not to change. So the main motivation of banning gas introspection was to make it so that if there's ever a gas schedule change, the only place that you would have to update any of these hardcoded values would be outside the VM in places like developer tools and pass in the values from the um from the transaction. That was the vision. That was the main motivation for trying to banic asset introspection. um as as we've looked at more and more youth cases and especially in the past week a lot more have come up um that are very clear that there are there are a few legitimate cases where you absolutely must be able to specify a gas value and we've not been able to come up with a good solution um that is not far removed from simply allowing them to continue to

specify the amount of gas that they're passing in. Um so it's it was a deep introspection. We wanted to try and um force people to do good auditor practices, but I think at the end of the day um that's not going to um that's not going to be possible. So that's why we support now um removing the band gap introspection and leaving it as an audit and maybe even maybe even a compiler warning um to say this is a really bad idea. Are you sure? And of the use cases where it's a bad idea and they're sure, they tend to have sec the compelling security reasons and they're aware of the risks and they're aware of the breakages that may happen um if a gas schedule changes. So the people that are

still doing it um with with you know they're either really aware of it or nothing that can be done will will make them pay better attention. So um in the end forcing this this good auditor recommendation um is not going to work out as much as we would like it to. Okay. And there's one more question from Felix I think should address before moving on is would there be merit to option D prime with gas introspection enabled and code introspection disabled? So um so we just pull out EIP 769 but we keep the EXE code, copy code, hash code size, op codes band. So what we're going

to need to do to adjust that is there's a couple of use cases where they do need to know what kind of account is it? Is it a smart contract account? Is it an EOA? Is it a delegate? So to fix that, we proposed um two other what I call symbolic introspection op codes um extrets that will allow you to do those common introspections and do it as part of the VM rather than having to read the first bites of the contract and figure it out yourself. Um the reason for unbanning that is while we're you know working on improving developer experience um we the thought is um we can remove that as well um to keep the developer experience the same um because really we're just you know we're just doing things for them in

those in those dynamic introspections um in those in those new uh symbolic introspection op codes um and it's not that much different from allowing them for eof op codes to see the first two bytes. So from this was this decision to keep to restore those three op codes is done with the developer experience in mind and as vector mentioned you can escape hatchet. Okay. Um I think it would be good to hear um Hrien from Open Zeppelin had his hand up a few minutes ago. um given that this was in part like uh

brought up because of the impact on dependencies like I don't know Adrian if you want to share a bit on your perspective there and uh yeah that I think we should hear from client teams. Yeah, I mean so I want to say two few things and maybe it's not really relevant anymore after the conversation move to other things but regarding toolings like open zeppelin being compatible with v so first of all that's something we really want to pursue and we want to work on that obviously one of the reason we haven't done much work on that is obviously we felt like the tooling was not really ready for us to work on that we need to have a hard hat or a foundry thing that that supports ef we need to have a compiler and so on And that's not something we've had a lot of

bandwidth to focus on. But just very quickly regarding everything that was discussed in terms of changes that have to be done to the code. You have to understand that it's very different whether you are addressing something like unisop. It was mentioned in the chat that unisop is maybe not a good example but at least I think it's a good example in the sense that they control their codebase and they control how it's compiled. In the case of open zeppelin or or solady for that matter because I think it's the same problem. We want to address the needs of as many developers as possible and changing our code base so that everything that is in line assembly becomes ef compliant means that we would serve the needs of eof users but all of the sudden anybody that as a developer wants to build legacy EVM

contract would not be able to use our code. That would be a big backwards compatible change for us and our users and that's not something we want to do. So in the end what it would possibly end up being that happening is that we possibly have need to have two versions of our codebase depending on what you how user want to compile their contracts with different capabilities. That's really something we are not looking into it. We're not looking into but unless like there is good backwards compatibility with with EVM like those small change are just the tip of the iceberg. In the end it will be a massive issue for like getting the right dependency depending of your compilation path as a user.

Got it. Thanks. Um yeah. Uh yeah, Fed, what was your point about? Just want to make sure we only have limit time. So um hi. So we're a new team on this is just an opinion from new people. I don't want to be disrespectful to anybody that work on this for the last years. From my point of view, Ethereum is losing momentum against competitors that has been happening for the last year and a half. on I think that correct prioritization is going to become even more important than before and that's why I think we need to start thinking backwards from the customer to the product from the product engineering and from engineering to research and not the

other way around sometimes having research that um is not connected with the development of a product is great especially when you want to do a big change but in general when you want to do small changes it's always good to think in terms of like is this going to impact the the customer for the better or for worse So us personally like we don't uh we're not against UF uh for technical reasons but more for business reasons or I don't know if the word business is the best one here but it's like we don't believe it's align with what users want. This will take time testing this will take time. I think in the last call people already mentioned the migration from Python 2 and Python 3. That was a very simple thing to do

technically for users but it was a huge mess on Python didn't have a huge competitor like at that time Ruby was the competitor in some way or JavaScript but they were working on another niche. We have a competitor uh we don't see how doing these changes will improve uh the experience of our users and we think there's other things that should be prioritized. So TLDDR we don't think in any way ef is useful for Ethereum on mainly the reason is there's other things that are more important and I think we need to start thinking in terms of what's needed on what we need to prioritize to win rather than is this a good solution that would improve things by a small delta. So that's our position.

Thank you. Um yeah and I I think this is good context so to hear from the different client teams. Um so I have posted the order in the chat. I think it would be good to hear from Reth first which were uh the ones to to raise this issue and and and now seeming most strongly against. Then Nethermine had good articulation of why they supported it and then GU seem pretty split and then we can do base with Aragon and I do think like yeah as part of that um you know it would be good to kind of highlight like why you still think EOF is is worth investing the resources on and also um yeah why you think option D is like a good compromise. Like there was a comment in the chat by Alex a bit earlier that you know is it clear that

option D uh asking if it's clear that option D warrants having an entire new VM maintained forever. Um given that uh we we aren't going all the way. Um so I think yeah if you want to kind of highlight your position and maybe go into those um that would be helpful. Um do you have to start anyone from rest on them? Yeah. Um yeah, so our order of preference is mainly one we could just add the uh swap Duke 17 to 32 up codes with no eof.

Um we think this mainly because it fixes for example stacked deep. Um and it seems like a very uh low like very low complexity thing to do and low risk thing to do. Um and I think it would still allow us to ship the next fork very quickly. Um the second, you know, in order of preference, the second option would be option D. Um this I think is much much uh better than any of the other eof options mainly because it allows immediate compatibility from most of this Linda ecosystem. Um so it means

that we can actually have like significant adoption and see most of the benefits of ELF um almost immediately. So this is like this like we should be able to compile things essentially. Um, I would also like to note that like if there's anything we're concerned about with, you know, introspection being an antiattern, um, I think these warnings could even sit at like a higher level of the stack.

Uh, for example, it could be a lint that were done on static analysis. Uh, this doesn't necessarily have to be a compiler warning if or or something that you could enable for example optionally. Um I think tooling is yeah tooling and in libraries is kind of the best way to prevent these kinds of antiatterns. Um so yeah I think uh you know having introspection would be a fine tradeoff if we're to do the um but yeah that's essentially why uh why we have our position.

Thanks. Um, yeah, Nethermind, do you want to articulate a bit your point of view? Uh, yeah. So, EOS doesn't break anything. You can interrupt with legacy. You can still deploy legacy. You can use legacy to doc hatches if you want to do gas limiting routing. Um, we support EOS. um we wouldn't support the alternatives in Faka. Um and uh we were split on option D. Um Aean, could you give some points on uh against option D?

Okay. Uh can you hear me guys? Hello. Uh yes. Yes. Perfect. Okay. So for option D we were well adding gas introspection and adding code introspection introduces a lot of like unpredictability to code. So we have this project where we try to AOT or JIT legacy bytes code and the fact that there is the sole existence of gas up code makes gas analysis or gas amotization extremely not straightforward during the

pre-ompilation analysis and for code introspection. It's basically first it is an antiattern. Second, it makes even formal verification tools for that would work on the bite code level almost unreasonable because it allows code to essentially in a way to modify itself and run itself and that's not pretty good to verify stuff. And also the fact that legacy bytes code does not separate between code and data that makes it again if we were to reach the future where we will go to

risk v or we will start to AOT or JIT this smart contract it would make it extremely hard to compile bite code to risk v or to whatever assembly we're targeting and uh we will end up again with interpreters alongside other VMs or another interpreters working in parallel which is undesirable. EF would full EF would be like the bridge to that or if we just stick with EF it would be the ideal version to go with and uh so yeah that's why I am against gas introspection coding suspension being

removed. Thanks. Um yeah and and the uh the support on um bringing back the op codes is more of a pragmatic if we reach cons if it's easier to reach consensus rather than um yeah technical uh and also uh there's this thing we are introducing a bunch of up codes we are removing other bunch of up codes so there would be there is expect there an expected period where tools such as compilers, other tools, planters, etc., etc., they would take a period of time

to catch up to these changes, right? So, expecting that every construct would compile since day zero is a bit unreasonable to to begin with. So yeah, it' be it'd be like saying we shouldn't have shipped 7702 because wallets aren't ready six months ahead, right? Okay, just to be mindful of time. Um, yeah, can we hear from GU, please? I think GU is probably the most split team. I'm not sure. Okay. So, I mean, we had an internal discussion about this uh even before and um I guess it's kind of

the the question is mostly like I mean since I'm the spokesperson for GU right now I would say that let's just go with option D like I said in the previous discussion where we already decided to go with EOF. I feel like paddling back now is not a good option. And um just in general, I do feel like the EVM as a execution environment has been neglected a little bit and EUF basically catches us up. It does make significant improvements to the EVM's design and I feel for me this is kind of the main motivation. So um

it's not so much that um there is any one specific change in EOF that makes it really exciting. It's more like it's just an overall update to the EVM. And these things are inherently hard to do but I feel like it is kind of necessary to like at least get ahead on this process and see where it's going. Also, for example, just simply introducing the uh versioning of the containers is a good change and just having the containers in the first place is a good change and all of these things can really help uh us in the future. It's hard to say uh whether they will help us

on launch day likely not. There won't be any contracts on launch day using EOF and this is just something inherent in these types of upgrades. But I do feel like over time we're probably not going to regret adding it. So um that's why I am for it. Uh with regard to this option D versus other options, I have been a proponent of option D from the start because I always felt that for example gas introspection is just so much of a critical part of how contracts work that I would I basically could never see like how we can cleanly remove this. And if we had removed it then it would just mean more

contracts would basically stay to the legacy forever because if as long as the legacy contract option is available which has more features is not really going to help us. So I feel like the option D is kind of better like it opens up UF for more people to actually use. I do feel like with option D I'm I'm sure that over time as for example also tooling default shift we would just see a lot like you would have to make a conscious choice to use legacy EVM and I think it's just a choice that not a lot of people would actually make.

So I feel like option E is the best and yeah not sure if we would should allow other people from G to speak or we should just leave it at that. I do think like I don't know if like client you want to share your perspective but yeah you've been pretty engaged and are also the author of the uh the new proposal so I think it would be good to hear your perspective. Sure. Yeah. I mean, I think my perspective has been pretty steady for the past couple years at least, but in general, I think there is a lot of push back against EOF and the spec is continuing to change. And no one really understands the entire implications of

EOF outside of very small number of people and you can see this by even Georgios and Julio changing their opinions very late in the process after we've already accepted it. So I think my personal view continues to be that improving the existing EOF and is is the right path to be going down and we should understand what our long-term vision is for the EVM and what our long-term vision is for the execution environments. It just doesn't feel like the right time to deploy a major change to the EVM right now. Um, so yeah, I think our stickiest attribute of Ethereum is the developer experience and EOF is

um possibly causing us to lose that. Um, okay. And then uh let's do Bassu and then Aragon after. Yeah. So, um I actually like option A. Um I personally am open to option D. All of our team is open to option D as it stands right now.

Um, I think if we value getting rid of introspection, if we think that that is a design goal that we need to have moving forward, we should adopt it as soon as possible and option D while a compromise is insufficient to do that, right? we don't actually get all the things that we can turn off by um fully abandoning introspection. This may be an oversimplification, but I do think this is the root of the problem that we have here. If we as a developer community are

not unanimous on the threat that introspection poses to the VM, we should really get that settled out. Um and so my recommendation is actually option A uh but open to option D. Um so happy to elaborate that more if necessary but I think reducing it down that simply does crystallize the discussion. Thanks and yeah let's hear from Aragon.

Um so our position um hasn't changed. We still support EF and I think it should be either option A or E. Um well obviously option A is cleaner but oh sorry no not option E option D A or D uh option A is of course cleaner but uh I think even option E brings uh sorry option D uh brings enough benefits and it's worth doing. Yeah.

Okay. So, every client team, just to be explicit, has at least some support for option D. So, I think of the EOF versions, this is the only one we should consider. Um, I don't think there's enough support for option A anymore. Um, I do think then there's two things that are worth uh asking. One is if we do option D, um it means we potentially never do another version of EOF and so we should see it as not like a stepping stone, but we should be okay with it being, you know, the forever EOF. And then if we do want to ban code

introspection, then we'll have an EOF v2. So this means if we do option D, we have to be okay with either we never ban code introspection or we um or we maintain three version of uh of EF. And then I think the other point that came up a lot um the other point that came up a lot is that um you know this takes away from other priorities like we uh have other things to do. we said we wanted to scale the gas limit and so to the extent we want to work on those things working on eof will take resources away from that. Um, so I think those are the two things worth considering like, um, yeah, if any client teams feel like

this changes their view, please speak up. Otherwise, I think we can hear from a couple more people. Um, yeah, outside client teams. Um, let's do Carl first. Yeah, very briefly. I feel like the reason no one is against option D is because we've decided to make it toothless. like we have so little conviction in what we're trying to ship here that it's like, oh, we find the version where no one can be upset at it anymore and then go ahead and ship that. And I feel like that's really the wrong way to be going about this. Like either we should decide that we like a feature and that we've done enough research and whatever that that this is what we need for the like benefit of the future of the EVM or not.

Um, so I really don't like this this option D and I feel like settling on option D is an option here is really not a great one. Um, let's maybe do Powell and then Duncan and then we'll do Fday. But want to give the chance people haven't spoken yet first. Yeah, I wanted to clarify the um the option D uh because I noticed some mistakes. Maybe there are typos in the in the saying, but option D removes code in introspection of UF code. So we will not be able to read UF code. So we'll only be able to read legacy code.

I think that's significant difference. Um yeah, so that's that's it. Yeah. Option D uh seems toothless if you're ignoring the experience at the application layer, right? It's it's a compromise, yes, but it's a compromise because the user experience, the application layer experience of full EOF breaks so many things that it completely hinders adoption. And so, you know, yes, it's a compromise, but it's one of those like would you rather have something or would you rather have nothing because nobody

wants to use it because it breaks too many different flows. Okay. But I mean, maybe it's just the cross-section of the the the community I see, but I don't see anyone at the application who's been asking for this. I feel like I I agree with what you're saying, but if if if no one's asking for this, why are we choosing like again it's an option designed not to upset people? I'd say Solidity like pretty strongly supports it, but yes, that is one layer um like below in the stack.

Um yeah, and then Viper is not supported. Yeah. Um yeah. Do you want to do feday and then Felix? Yeah, it's the second time I speak in uh in these type of meetings. I have been only listening for the last few months. So I don't want to be a pain in the ass. But I will say it very clearly. A this was not well I I don't see anybody asking this. B I think uh there's a potential case where new issues will arise uh in the future on the compromise doesn't add much to the table. And to me this shows that the full process of development is uh pretty non-standard in any uh project. It's true that Ethereum is strange and different than the rest but I think I believe uh that even if UF

was good this is not the normal way of like creating on prioritizing things like there should be a person saying like we want this yes solidity wants this but Viper that from my point of view it's an objectively better compiler uh doesn't have this type of issues. So this could even be solved on the on on solidity on the solidity compiler. So the TLDDR were against it. I'm going to close it in one second. We're against it. I understand that ref is also against it, but they accept the compromise on uh also Viper. So that's all.

Yeah. And look, I agree with the process uh having issues. I do think that like this is kind of a weird spot to completely change the entire process. Um, we literally agreed that we're going to re factor awkward devs for Glamsterdam and and going forward. I think the motivation for EOF is also like pretty long-standing like people have been wanting to do these types of changes to the EVM for several years um at the very least EVM developers. And so you can you can argue that like yes there was not enough community feedback or input. Um and I think this is something we we do have to move towards but we I don't think we can like ship an entire new process overnight uh in the

middle of like finalizing the scope. Um so there is like a a a uh a difference there. Um yeah you Felix. Yeah thank you. So just uh my comment is also going to be on this point of like nobody has asked for it. I think the is an unrealistic expectation that the application also of Ethereum would ask for a specific improvement of the EVM. So the EVM as an execution environment was designed a long time ago and it's kind of a bad design but that hasn't stopped anyone from deploying applications on it because to be honest

most applications are there for the value that is within the system and they are not really there for you know like how awesome the EVM is. So the motivation for EOF is just to improve the EVM in ways that have been researched for a long time to meaningfully benefit it. So there are a lot of changes in like EOF itself is a collection of changes and it's a lot of things rolled into this one upgrade which is supposed to improve the overall environment and then I guess we could have the same debate you know later in a couple years when we were going to say

you know nobody asked for EF version two but to be honest I feel like it's a bit independent because we're not really expecting the uh authors of contracts to redesign the system uh by themselves. That said, the um overall process of changing Ethereum is an open one and it is possible unlike in let's say a normal process. It is actually possible in this case for users to raise specific requests, push them through the pipeline and ultimately get the protocol changed for their own needs. And I feel like this is something that is happening in this case as well. Like people have been pushing these proposals through the

pipeline for a long time and they have built up solid arguments for why we should do it. For example, solidity has put forth a very very thoughtout argument for why they believe that just incremental improvements to the stack handling are not sufficient. And also they have explained at length why it doesn't affect vipers because they basically don't use the stack in the in in in this way. So I don't think it's really possible for us to just say nobody has asked for this because people have asked for it and also like everything that could be considered has been considered before for this with regard to this change.

Thanks. Um, yeah, Charles, do you want to Yeah. share your perspective? Um, hello. Yeah, we can hear you. Great. Um, I think that if you're going to break backwards compatibility, you shouldn't say that it's like an improvement to the EVM. It's just like a new VM and it should be uh sold to users that way instead of telling them that it's like an improvement to the EVM, but it like breaks all applications. Um, and I' I've already stated my position on

this in, you know, previously multiple times and in today's agenda. Um, but just to reiterate, I for at least Viper, uh, which is another compiler team, um, we don't need it. Um, I'm open to improving the EVM, but I think that UF just couples and packages together too many changes that aren't individually justified. And um I don't know, there's always this like pressure to like ship EF ship ship ship because like there's going to be no room to get upgrades into the EVM in the future. And I think that encouraging that from ACDE is harmful to the EIP process. Um, and it's resulting in this

weird situation where UF has become this huge package of features um that aren't individually justified on their own. And um I think that taking a step back would be a really good thing. Thanks. And okay, two specific things that came up in the chat that um I think we should explicitly address is um one whether uh eof breaks any existing solidity contracts and uh basically potential solidity flows and I believe this is correct uh in the case of create and create two and then two whether

option D actually allows you to do introspection on an eof contract itself. Um so could we just uh yeah clarify those two points if so for uh assembly blocked debris call out code like create 2 and also stuff like call code and self-destruct and jump and jumpy um those would not compile. Um that's really hard to to avoid when we're not allowing certain op codes in the container. Um but those are also corner cases and in the case of a create um that's not a contract you'd want to just blindly bring over to eof. So there would be changes but they would be sensible if you're using the create facilities in the solidity language. Um those should compile. It's when you go

into assembly blocks. Um as far as introspecting ef option D um says that you could ext0000 um in legacy as well as in in eof. And that was the plan going forward. Um if there is strong desire to be able to read the eof code completely um that can be done. Um writing eof code um is something that is going to be difficult to maintain the um the features that we need for uh for the transformation and for for the ability to support things like risk v. Um so if if that is something that is absolutely essential

we could add that um is as far as as far as the read but right now if you read EF00 the core functionality of extract is that it addresses a contract or not remain. Um, now as far as the utility of this, if we were to go to a place where we, you know, could come recompile it to another ISA and you could read all the EO contract, that's not such a bad, that's not an impossible thing to support. Just when you do the recompilation, we would need to add a separate data fork that has the original equivalent UF code to go with it going forward. So that, you know, being able to read all the UF code does not break this going forward. Um, but the intent

was to have the the best solution for that. But if this is a deal breakaker, we can have it read the entire EOF contract. Okay. Does this answer people's questions about backwards compatibility? And yeah, Felix. Yeah, sorry. I'm not sure if I'm cutting off Charles here because he also has his hand up. Maybe he still has his hand up from before. Yeah, but I was I was is your point about what Dino just said or Yes, it is. So, I just wanted to clarify also that just to just to to drive it home even more that the

um the incentive for um designing EUF in the way it is is not really for the benefit of the application authors because we do want to support things such as this transpolation that Dano just mentioned. This is a client essentially like an EVM implement's concern but the current structure of the EVM doesn't allow us to do this because the the the application layer can at any point basically create uh contracts. So this is one of the reasons why for example EUF is is in some in some places more important to the authors of the VM itself because it makes it possible for us to ship improvements to the AVM that we otherwise wouldn't be able to ship.

It's just that these improvements then wouldn't really apply to the legacy environment and in the long term this will just mean that the uh legacy environment will become more expensive to to operate than EUF because we can run the EUF contracts faster for example. I don't think that this is really a concern that like I mean yeah it it changes the basically we're trying to make this change that allows us to have a better EVM while at the same time not breaking the application developer experience. So this is really the the main motivation for for for EUF and um yeah that's basically all I wanted to say.

Thanks um Charles. Yeah. Um I just wanted to add that uh if option D is like what people are voting on, I think that um I know that this document from epsilon has been open for a few months but um it is like basically a different spec with different scope and I think it um I'm not sure that all the interactions can be understood over the weekend. I certainly can't. Um, and so I think it may need some um I don't know more like I don't want to like be like stalling but um or like promoting that

but I think it is more than can be voted in a single week and and I think that um yeah needs a little bit more time at least to get Thanks. Um let's do actually let's assume Marius and event splitting it. Sure. Um I just wanted to say that um I don't think we will make a decision today. I like it seems like no one is being convinced by the arguments that the kind of other side is putting forward and we will keep in this in this stalemate. um forever. So now now the question is what do we do now? Um and I

think there's there's two options. We either say we're we're not going to we're not going to change anything because we agreed at some point that UF is going to go in and that is our that was our decision back then when we had consensus and uh we keep it this way or we say um we don't we don't agree and we're not coming to an agreement about EOS anymore and so it has to go out and um I I'm I'm I'm I'm still torn and I think a lot of people on this call are torn between the two options and they don't really know what um what the right decision would be. Um in the past in

these cases we kind of always defaulted to not doing something, not changing something um because that's the safer option. Um that's yeah that's all I wanted to Thanks. And I guess yeah to add to that like um I agree pretty strongly that the cost of shipping the wrong team um the wrong thing sorry is much higher than the cost of delaying. I will say that like this has been the story with eof many many times and earlier variants of it. So I think it is possible that you know if we don't ship this then we lose people's interest in wanting to to pursue these changes. that's maybe fine,

but um we should be aware. I think this is like the cost in a way that we pay. If we wait, we kind of um yeah, we kind of burn out people who who work on this stuff. Um and they don't see it go live on the network. Um yeah. So, but and I do think like yeah, if we if we do not uh ship or if we do not move forward with eof today, then we should agree to just remove it from Fusaka. It doesn't say anything about what we do to the EVM and other forks, but you know, it obviously send the signal to what's got it. Um, let's do um Ben and then try to get through the list of people and try to wrap up. Yeah, just just following up on the the

introspection some clarity. So, you can introspect legacy contracts on on option D. You can introspect legacy contracts from EOS. You can introspect ef contracts from both but the eof will return just two bytes. So you will the 99% use case of checking is this a contract. You can you can do that with that introspection. You're not going to use an eof contract data onchain from a legacy contract because you would you would do it in reverse. you deploy a legacy data contract or you'd be calling the eof contract from an eof

contract in which case there are um data container introspections on eof from eof. So there is an introspection where you can introspect the data sections as part of the OF but I I don't see why you would want to be introspecting the full container system from uh using code introspection because now you've got to parse it and do all this and that's that's very expensive to do it on chain. I'm not sure what you'd achieve with it.

Thanks, Ru. Yeah, Amad. Yeah. Um, so quickly I want to reiterate that adding a UF is a feature. It's like adding an op code, right? Um, nothing that exists break and if you don't want to use it, you don't have to. And this means that like we are putting EOF in an argument like if I add an op code then all the existing contracts or once they compile they should use this op code and if no existing contracts use this op code as soon as this op codes land on mainet that means that this op code is

useless and we shouldn't be using it. This argument is like I I don't I don't understand it like it's it it there is time. It will take time for the migration to happen. This is normal. We chose EOF to be like this for reasons. I am not an expert on why we did EF with no gas introspection. I am not an expert on why we chose to do EOF without code introspection. But these were done in years of research and hard work by a lot of people. and coming in now and saying, "Oh, but existing contracts will not you be able to use this new feature and that's the reason why we should remove all of these decisions that we have already researched and made for actual

important reasons for the EVM and for Ethereum is is is not the right thing to do for me." But yeah, that's all I want to say. Thanks. Um, Anscar. Yeah, I just wanted to say I mean clearly the process here has been very broken. Um, I think we are luckily at least in a position where we're currently in a in a moment in time where a lot of things are changing in Ethereum. Anyway, I am very high hopes that starting with the glam process, we will have a much more functioning process. I think we'll also have to spend a lot of time thinking about how we can for example have user interest developer interest much more in the loop for future EVM changes. So all of this I

think will improve significantly for future folks. That said we have to make a decision for Fusaka. I think we really need to make a decision today. We have spent way way way too much time on this in the past. I actually think in terms of process the process has been primarily broken and violated by people that are opposing EF. Um I think kind of they they they failed to have enough support to to to stop it from being included for the initial fog and then last call the decision was made to to to decide already today which was very short time. Now the very short time was not enough to really fully understand the options. I yeah so I think primarily the failure was was on that side. That said I just think it is impossible to ship a feature that has so much

contentious feelings as UF still has. like it's just you you cannot possibly ever ship a feature where people feel so divi divided on this. So I just think even though I feel like the team did everything right and I I I I think the process has been more um followed by by them than than by the opposing side I just think at this point we have no choice but to just pull the feature. That's my opinion. Thanks. And one thing I note I just posted in the chat is that like yes core devs write the code for the hard forks and like there is like some majority that that supports this. Um but core devs don't decide which hard forks actually get activated on Ethereum. Um

to the extent they do it's because they ship non-contentious features. Um and even though like there's a high cost of forking the other like way for people to exit is to just use another chain. Um, so I I do think like this is something to to take into consideration. Um, yeah, let's do Andrew and then my client. Um so yeah it's been talked about Ethereum staying competitive and uh um focusing on big things or important things and I totally agree with that but I think not shipping EF will hinder that because it's a well thought through improvement and a lot of

people have been putting a lot of work on it and uh as I think most people would agree option D is uh actually it solves most of the potential critique of the eof it brings enough benefits. So if we kill eof now then I think it we will find it more difficult to do the uh like the non non-trivial um improvements to EVM going forward. Thanks. And yeah, I agree this is right.

Uh like we can say we will ship EOF maybe in the future, but we should recognize that like it will demoralize a lot of these people um and have the most experienced EVM contributors and that is a cost to pay. Um yeah uh does he like yeah I just want to quickly raise a few points that I made in the chat. I think in general we should be focusing on changes that support users and not changes that support the EVM implementers. There's a long list of things that we could be doing and things that would be more noticeable and provide more benefits directly to users.

So I think the fact that the biggest proponents of eof are client teams and solidity is something that's concerning. I don't see near as much support for it on the app layer. And then you know in general it seems clear we don't know what to agree on here and to me that's a decision in and of itself like if we don't have conviction we should remove uf from fusaka and we should just focus on fixing stack too deep. Thanks uh again Joy Menson. Yeah, there's been a lot of discussion around the the process here and that um you know the process concluded that eof

option A was the path forward. But you so I'm an application dev and it's not clear to me that that research and that process took feedback from the application layer into account. Right? You know there it's not clear to me where the venue for that is. It's not clear to me when an EIP is sufficiently solid that application devs should begin reviewing the applica the impact on their applications. Um, and if you have opinions, you know, beyond screaming on crypto Twitter or posting on Ethereum magicians, where's the place to make that voice heard? So, I think that's a lot of where this um this feeling that the feedback is late arriving. You know, the process is being violated. um you know were making emotionally driven

decisions rather than rationally considered ones because there was a large section of Ethereum stakeholders who weren't included in that process structurally maybe apathy maybe you know a lack of sense of urgency but that's really where the um the mismatch of expectation and the feeling of uh violated process is coming from. Yeah. Thanks. Um, Julio, um, yeah, I just wanted to say that if UF doesn't make it into Fuzaka, it will probably never make it into Ethereum, at least in in my head, because it's getting bigger and bigger and

bigger. And also, so we need to be honest with oursel about that. and uh and I think that it's kind of too late to to just remove it from inclusion because we already went on with the process and as Anar already said it the process kind of was broken by anti-UF people and I think that maybe we can do but we can learn from this in the next time but I think we should we we should do a UF just for the sake of perspective in the process.

I I pretty strongly disagree with that. Like I think we should really try and stick to the process and it's and it's hard to um like yeah get credible commitments about what we're going to do next if we don't. But we we shouldn't like the process exists to serves the out to serve the outcome, right? Like and most of the time it works and it does the job and the process by definition will fail in like exceptional circumstances. And I think this is what we see here. Um, personally like I I like I don't care much about eof. I'm not an EVM developer, a solidity developer. Um, I've been like in touch with the people who've worked on it for the past many

years. Um, I don't feel super comfortable keeping it in in Fusaka given the amount of push back. Like I think um Moody had a comment saying you know he's one of the core uh solidity and application developers and you know he should be like excited if EOF comes in and and he's not like my sense is that if we do want to overhaul the EVM in such a way um the thing we should do is to do this in conjunction with like smart contract developers and and the tooling community more broadly. Um, I understand Solidity is quite supportive, but the fact that we have Viper being pretty strongly against is also kind of

a strong signal. So I it it feels like if you wanted the right process for EOF specifically, it would have to be one that just brought these stakeholders on board much earlier and and you know designed something that both EVM maintainers and the client teams and kind of tooling uh providers and application developers all really like. And yeah, I I I don't feel like that's been the case here. Um, and I know we're already 20 minutes over time, but yeah, at this point, my suggestion would be to remove EOF from Fusaka. Um, to not add anything in its place. I think we should keep uh pure as a target. We already have all this gas

limit stuff and a couple other small EIPs. I think from a process perspective, saying like we don't open the door to anything new feels right. like um and I know that there's like the swap and do EIP, but like it I don't know. I feel like if we do want to improve the EVM, we should actually like make that the focus of a fork and like do it right. Um and yeah, like like there are some CFIDs that we can we can talk about on ACD next week, but I would not like open the door to new proposals.

Um, and yeah, I understand like some of the client teams and like maybe a bunch of them will disagree. Um, and yeah, I think this is a a hard call. Like I uh yeah, I just don't see a world where we push eof forward and don't have it become an extremely contentious topic um and and and effectively compromise the work. And this is not even getting into the specific technical issues. Um yeah, so I yeah I don't know like I I know that basically four out of the five client teams may disagree with

this. Um and yeah I don't know that we have something like a veto. So if look if the four client teams want to focus on eof and work on it like we should probably go towards that but my opinion is I I don't think we we should do it. Um but yeah I don't know that I get to say like what engineers actually work on dayto-day. Um yeah so I don't know like yeah Justin or yeah uh Tomas I don't know what's your perspective we can see a few other hands before me

um yeah I don't know what about I guess like yeah let's keep it about the specific like moving forward like step so I don't know some uh Powell was that what your hand was about or uh Uh if I may go on, uh I have heard uh concerns about Cordov uh actually uh tipping the balance in favor of uh EOF. Well, that's because the EVM developers had the job of innovating and doing research in this direction and now they have come up with uh their conclusions and uh we have different options. Of

course, some of those are not ideal and our compromises. So, I think uh that's the way to go. And the way we are seeing contentions and arguments against uh may not also give us the correct picture of what uh we all want because uh the natural uh course was that EF was going in into Faka and now in order to stop that you have to even if you are a minority you have to raise your voice higher than uh everything else uh and stir the quiet waters. So I think maybe we are uh hearing very loud noises from the minority even uh when you know the

client teams are agreeing to go with the compromise option D. I'm not a developer of uh EVM or EF for that matter but that's what I think but my question is also around uh things going forward in terms of research and innovation. Uh I know that um on Thursday we talked about or it was brought up that risk uh fee risk five architecture uh or you know any other ISA or you know something new going into ZK friendliness might also uh you know come in in the future.

Now my question is like uh what happens to the the app developers then like they might not be using those features. uh but that's uh where we want to go in terms of where we want to steer uh Ethereum and it's uh mostly up to these researchers and developers to push uh push it in that direction because u abstracted a level higher or a couple of levels higher uh similar VMs can be found in L2s as well but uh from Ethereum's perspective uh this is the circle that actually pushes the limits of innovation forward. So that's that's you know it's reasonable

to expect that uh there is a tight-knit circle which is uh doing uh the bulk of the research and development work. Um also uh testing and whenever you have to push something new it's going to take time. is going to have devets uh and so on and uh the contention around the tooling and the languages uh for the EVM update does make us uh think twice around the readiness but it's not the readiness of the e eof itself uh but rather the readiness of uh the abstractions on top of those uh and the tools on top of

those now agreed that a lot of the business value actually uh resides in those higher levels and uh uh I think towards the beginning of the call as we saw that uh it's not uh that hard of a task if you consider option D to uh go forth and do it and most of these challenges can be near about to completion completely uh ironed out and uh fixed uh soon enough reasonably soon enough and I also agree with Tim that uh if there is a stir, if there is some kind of arguments going on, whatever that may be, that's an indication that

uh maybe not everything is going to go smoothly in the hard folk which we eventually have to push. So maybe we can delay this uh and I would uh actually subscribe to a world where u something like peer das is not dependent on uh the the fate of eof. It's not like if we do not decide to include it ina it would forever be deleted from history. It's it's a it's a far better thing to do to uh have another folk uh solely for EOF which is further down the line from PRA and do PRAS for FA instead and that to solely and also

like not not u not accepting any other new EIPs uh in its place either as uh Tim said. Thanks. And yeah, on this point, I look, new EIPs is something we should definitely discuss on the next alore devs. We're already 30 minutes over. Um, I think today's decision should just be eof or not. Um, I think Justin Oh, you just put your hand down, but I think you were one of Yeah, I I was I was in line. I actually don't think this is an EF or not forum. Like, this is to be fair a testing call. And granted, everybody showed up, but it was because, you know, they heard something on Twitter over the weekend. So, no, I I don't think that the the the decision should be made now.

Um, I you know, we're doing the best that we can with this situation. I I appreciate the work that you're doing specifically, Tim, and trying to to wrangle these cats. Um, but the idea that we would do an about face after a pretty hard-fought decision was reached to go with option A about a month ago, I find a little shocking. Um, and I don't know that a vocal minority um should be listened to, but also if EOF is intended to pay off technical debt, I don't know that we take advice from the people that aren't experiencing the technical debt. So, um, you know, I I appreciate what was just said about

decoupling EOF from Pure DOS. I think that's totally reasonable. That should totally be on on the table. Um but you know if if we took the miners perspective into consideration would we have shipped 1559 would we have shipped the merge at some point we are stewards of the protocol and have to be responsible for the tech debt that we are you know acrewing and paying it off. So you know I'm of a mind that we need to stop thinking like product developers and more like platform stewards. So, um I fully expect this to be a much longer conversation to be held elsewhere and I'm sorry we're so over time.

Yeah. Thanks. Um Andrew, um yeah, I think it totally makes sense to separate um EF from Pas and P is probably more important than EF, but luckily it's uh what we have at the moment. we have uh two dev nets and we we should keep doing that and I think we should explicitly uh like like activate ef not by fusaka time but its own time uh and if uh pas is ready before eof we can ship fusaka with no ef but I think the commitment to be if we do that then we should have an e only fork soon after with ef F and this G

gives us time to deliber deliberate on option A versus option D. But to my mind either option A or option D should to go into into a fork. I think yeah based on that maybe what I would propose as a next step like I I do think we should decouple it from Fusaka and remove it from this fork like it's clearly extremely um contentious if you know not within core devs within the community whereas pureas isn't and it feels weird to couple them on that ground but I I would not be comfortable saying we didn't schedule a fork for uh

the EL only just with EOF. This is basically how we got EOF in Fusaka because we split out of Peterra. But what I would propose is we remove it from Fusaka. We then have the Glamsterdam conversations using the new process where we first start to think about what's important in Glamsterdam. Maybe the thing that comes out of that is we want to improve the EVM and do it ASAP and we want an EL only fork. If that's the outcome of that like highle conversation, then great. we can consider an eof only fork. But I I definitely do not want to commit to some some future timeline. So I would just say that like yeah I think in terms of next step like removing EOF from Pusaka feels like the least contentious path

forward. If people who are supporting EOF want to make a strong case for it for Gradam or for an EL only fork, we should do this. But we should do it in the context of like a like revised awkward devs process that takes uh other perspectives into account. Um and I understand that like removing it from Pusaka may be interpreted by a lot of people working on this as like we're never going to do it. And I I think the rest of the community should expect that EOF developers may not be so enthusiastic to keep working on this if it gets removed and uh as it has been in the past. So I yeah that's kind of how I would wrap up is removing it from

Pusaka. We can reopen the conversation for Glamsterdam. Maybe this means an EL only fork but we should um like yeah we we just shouldn't couple those things. And then similarly on the next alore devs we can decide what other CFI IPs we want to bring in but I don't think we we have the time to do this today. Um so I don't know if anyone has like a really strong objection to this or wants to say final thing we can hear that but otherwise this feels like the best path forward at least the worst path forward maybe.

Hello. Oh yeah. Yeah, my I mean my comment out of context a bit uh but really quickly um so my kind of mental model of EOF is that it it consists of the core component and then there were two extensions that were added over over time. One was code introspection and the other one was class introspection and we spent over an hour discussing to this these two extensions and what friction it brings to application layer but actually the core of UF it's it's pretty

transparent to application layer that may be disliked or liked but the core of UF improves the EVM itself and the fact we didn't spend a single minute discussing the core of maybe it's a good indicator that it's actually transparent to the outside world and yeah that was the main motivation I'm sorry this corey eof doesn't maybe affect contracts outside but uh uh that's that's the fact about Thanks. Okay. Well, I think we can wrap

here. I posted PLDR in the chat. Um, I'll open up a PR for uh the meta EIT. Um and and yeah, like I think the process stuff is something you should have on Fusaka because there's so much uncertainty around the process like this feels like a better forum to make the call on eof and I think part of the reason for this as well is every client team both on the EL and CL have like stated pretty often pretty explicitly that pure DAS is the priority and it just feels like there's like technical and social risk the eof at this point that coupling it seems risky. So um again I think there's a world where you

know we do just ship Fusaka and we uh you know we do EOF right after because everybody likes it and that's great but um I I think for now it's it's really not the um not the right approach to couple it uh in the same fork. Um yeah thanks everyone. Um and and yeah also the last thing is uh we can discuss next steps for Fusaka on the E side on TCD uh next week. Um yeah thank you.

Bye. Thank you. Bye everyone. What's up?