All Core Devs - Execution #210

Transcript

Justin Florentine: Good morning. Ethereum.

Tim Beiko: Good morning!

Maksim | Nethermind: Okay, you guys.

Saulius Grigaitis: No.

Tim Beiko: Oh, let's move over in like a minute or so we'll get started. Okay, Josh, you want to move us to the stream.

Josh Davis: You're live.

Tim Beiko: Thank you very much. Welcome everyone to Acde number 2 10. Briefly touch on Petra's day. Hopefully. Nothing has come up since the announcement, and then a lot of final Fusaka discussions. Around some some tweaks to the scope. And to wrap up we have some stuff on the history expiry to discuss. but yeah, to kick us off. So we announced the Petra client releases yesterday on the Theory foundation blog. If you haven't seen the announcement, I'll post it in the chat. It's also linked in the agenda. Spectra will be forking at Mainnet on May 7th at 10 0, 5 utc, this is at the start of epoch 3, 6, 4, 0 3, 2, so if you are listening to this, and you have not. Updated your client yet. You should go to this blog post and do so. Yeah, it has all the latest releases. There's also some overview of the different features. And then there's a watch party that is scheduled for the fork that's listed in the blog post.

Anyone have any updates or concerns, or anything around Petra. Oh, yeah, part of this.

Parithosh Jayanthi: We're yeah. Go ahead.

Barnabas Busa: Yeah. So in the past couple of weeks I've been testing the Mev workflow for Petra. And there has been quite some bugs and fixes coming to the relay, the Mev. Boost and to the or builder as well. And so far it has gained a bunch of improvements in the past couple of weeks, and we have solid blood production now through Mv. Boost.

Tim Beiko: Amazing. Thank you very much, Perry. Is that what you were gonna share as well.

Parithosh Jayanthi: No. Independently, we're also just using all the client releases the latest ones to make sure that all the typical code paths, including East as well as validator lifecycle tests are passing. So far they seem good. The only test left is Yale triggered exits and a few other ones. We're still adding. and once that's done, I think early next week we'll plan a Shadow fork, so we should have some information on that by Acd next week.

Tim Beiko: Awesome. Thanks. Anything else on Petro. Cool. Well. yeah. Great work. Everyone getting the releases out. Hopefully, things go smoothly for the next 2 weeks, and on the actual upgrade.

Gary Schulte: But right here.

Tim Beiko: Cool. Oh, sorry. I just muted you. Gary. okay, sweet. Next up on the agenda. So Fusaka. yeah. 1st of all, there was something to figure out on the Bpo forks configurations. So let's maybe start there. I don't know if Alex is on the call to discuss this.

Alex Stokes: Yeah, I am. It was mainly just a reminder to sort out the el configuration format for the Vpo eip. I believe we have a configuration we like on the Cl. Side. and I'm not sure if we've decided yet on the El side, what we want to do.

Tim Beiko: I haven't seen anything. and so this is basically what we would add in the El to say at time, slot X, we raise the block counts to a time. Slot y. We raise the block counts to to be.

Alex Stokes: Right? Yeah. There was a proposal somewhere. I'd have to go find it on discord.

Tim Beiko: And is there a reason why we shouldn't? So I know that on the Cl side, doing like quote, real hard forks is is quite complicated, and therefore we have this Ppo schedule. But is there a reason why the El shouldn't just treat these as like hard forks, and use the Genesis or the the like. Yeah, for config files. Oh, Marius, so you had your hand up.

Marius van der Wijden: I think Felix also wanted to say something.

Tim Beiko: Oh, I think, Felix, we just hear you typing, but we can't hear you speaking.

Marius van der Wijden: Okay, maybe he doesn't. But you guys can hear me. Right? Yeah, yeah. So From my point of view, it should definitely be scheduled like a normal fork on the El side. It makes no sense to invent another mechanism that can have other bugs. And and and it can have weird, like interplays with our normal fog timeline. I understand why the Ecl kind of needs to do it, but I would propose for the El to have them as normal folks that are normally scheduled with a new folk. Id. So we. similar to what we did with the with the glacier stuff.

Tim Beiko: Okay. yes. Okay. So what? I guess what? Alex posted in the chat. I don't know how standard this is across clients, but it it gives a overall picture like is that something el clients would be fine with? Or if if any el client would have an issue, just adding this as a hard fork. like like a like a difficulty bomb hard fork, and that's the time. Yeah, then.

Ben Adams: Yeah, I'm I'm sympathetic to Myris's point of view, but maybe it's just better not to invent something new when we already have. We're working to sit.

Marius van der Wijden: Hello! Regarding regarding the proposal from that Alex posted. Yeah. The only thing I would change is to remove the timestamp, because this no real need to have the timestamp in the blob schedule because we have the timestamp for the for the normal folk already.

Tim Beiko: And I guess one thing that might be relevant here is after the Holeski stuff. We discussed this way to verify pair parameterization of the clients for different forks. So this feels like it would be especially helpful here, like we should have a way to make sure that you know all the El Clients have the same set of configs for all of the Vpl forks. And that they are. They will all activate at the same time. yeah. Ahmad.

Ahmad Bitar: Yeah, I I think this was mentioned before, but like not, all clients have the same like kind of way of activating forks. We particularly activate aip per aip. So if the schedule is named by fork, we will have to basically add a field for specific to say, Hey, fork. Whatever is actually like it. It's it's it is a big like. It will be ugly in the code. It will be ugly in the configs. It will be a hassle for the 8 Pando Ops team to deal with as well, in my opinion. I would just include the timestamp in the in the yeah, in the like. Bpo in the schedule, is there.

Tim Beiko: Yeah. So I guess there is a Bpo eip, right? Like, it's 7, 8, 9, 2. If I've got it correctly, so should we just specify this in the eip directly to avoid any confusion like, it doesn't seem to matter too much what we do on the El. And like, yeah, maybe. Oh, like, oh, there is actually something. Yeah, there, there is actually something in the eip. So and yeah, okay, so the eip does not have the timestamp. It just has a target, the Max and the base fee of big fraction. So and maybe the one change. Yeah, the one change from the eip is. I don't know if these numbers that it uses, for the Bpo forks are actually like the timestamp. That's the name of the fork?

If so, that seems maybe a bit weird and maybe a bit bug prone. So I would maybe just change the like config name to be something like vp, o, 1, vpl. 2, or whatever. But would that work for everyone and yeah for clarity? So what I just posted in the chat which is copied from the eip. Basically keep that, and then just use like some generic Bpo and a number naming no fun names. Look, if we want to change it to fund names. We can hash this out, Async, but we could at least use the or if someone wants to come up with a nice convention of like easily incrementable fun names. We can do that. But

I would just not use the timestamp as a name, because that feels like the thing that will cause an issue on some network. Someday. yeah, some. Okay. So it seems like, people are okay with this. Maybe, like, yeah, let's just do a quick pr to the eip to change to change this to change this, to like some some generic name, and then move on from there. Yeah. Some.

Somnath Banerjee: Sorry about that. I just wanted to say that a hard fork is like a drag on operations. So you have to release and like, make sure it goes into time, and others have to like pull the images and sort of update. It's no to be.

Tim Beiko: To be clear. Yes, to be clear, these would all be scheduled at once. The idea is that we only we only schedule like we have a single client release. Say that we do this like in in September, or whatever the Aragon client release already has baked in like the next 4 Bpo forks, or however many we decide to do. So so like, yeah, we we yeah, if we can call that 4 hard forks a year if we want. But the idea is that on the Cl side there's like some high fixed cost to setting up a quote real hard fork, and I don't know what exactly that entails, but someone shared the diff on a previous call, and it was about 94 90 files changing in the clients, whereas on the El side. The fixed cost in terms of like code to do. Fork seems to be pretty minimal. So the idea was that on the El they are sorry on the consensus layer. They can have this setup where they don't need to have this entire fork scaffolding every time, which is what the Bpo's bring, but on the El. Because we don't have much fork scaffolding, we can just

rescheduled a bunch of forks and put them all in the same release. and yes, to Perry's point. The other idea here is that even though they're all included by default, and we expect them all to activate on Mainnet. If you know the Bpo's are like a month apart, or whatever we can obviously have, like an emergency, hard fork that delays them or that removes the future ones. If something comes up. Does that make sense.

Somnath Banerjee: So, yeah, thank you.

Tim Beiko: Okay? Okay, so let's do that. Then let's Okay, we'll find a better word than emergency. Hard fork to delay the Bpos. But like, yeah, high level, it would be an like a way for us to help us. Yeah. Bpo, intervention. I like this. Okay, so yeah, like, let's just change the the name in in the eip to something like Bpo, one bpo, 2, whatever, and then at least we'll have something to work with. And if people want to come up with a better naming scheme we can make another change. Anything else on the Vpo. okay? Thanks. Everyone. Okay, next up. Eof. So there's a couple of different threads here. Originally, the main thing I wanted was just the status updates to make sure we're all on the same page around where Eos is at and and and what the next steps are. I think we should still do this to make sure we yeah, we all have the same context. Then

then some concern came up in in the past the past day or so around compiling legacy contracts and importing them as dependencies in like a post eof world. That's made at least some of the client teams reconsider which version of Eof we should do so. We should discuss this. And then another set of concerns came from a vitalik's proposal around risk 5 where? yeah. The way, I kind of phrase it was that it's kind of concerning that. We have a proposal to replace the Evm with something, even though we haven't already shipped it shipped eof and you know, therefore we're gonna ask the entire ecosystem to migrate to something new, and then potentially, you know, a few years after that migrate again. And you know whether that should make us question kind of the the overall approach we have here. So I guess. Yeah, maybe to start. So we all have the same context.

I don't. Yeah, Daniel, do you want to give just a quick overview of like where eof is at right now? And

Danno Ferrin: Sure.

Tim Beiko: And yeah, and then, yeah, actually, like, yeah, if you have some context around around this compiler or or so, yeah, you could do the status, and then maybe Ben can talk about the compiler issue. Yeah.

Danno Ferrin: Yeah, so as far as the tests, we have. The 1st path of tests for one that includes all the container changes and support for Tx creates those are actually in the main the version. 4.3. I think of of the of the eest ethereum execution spec test as far as clients that pass those tests. We have 2 full clients, Baysu and Geth, and as far as libraries evm, one passes it, and I also have a patch out for yields to pass the test. So we have multiple clients that are passing the test as written and that, you know again, the tests were pretty good at spotting every possible place where we had any of those container changes. So I'm a high confidence that we've got the changes with the tests that will be covered by that. If you can pass all the tests, you probably fixed all the places.

That being said, we still need to do fuzzing. I got my fuzzing library updated to the new container changes and I'm starting working on fuzzing between Geth and Bay. Su. Fuzzing 2 differentially is not necessarily the best thing, because when there's a difference, how do you decide who's right? So we'll get the best feedback when we get a 3rd client, whether that's another mind, or ref to be determined, be best if we could have all 4. But as far as the schedule I put out for the Eof testnet plan. A few months ago I'd say we're still on schedule to launch the Devnet one the week that we released Petra. So we're still there. I mean, there's still a chance that if if clients were later, if bugs are discovered that we might have to slip it out. As is the case with everything but

It looks like we're still on schedule right now. With that.

Tim Beiko: Okay, thank you. And yeah, Ben, do you want to talk about the compilation issue?

Ben Adams: Yeah, so this is about the developer experience and upstream. I don't think we're ready to depreciate the the introspection OP codes because you can't compile uniswap contracts. You can't compile open Zeppelin. You can't compile. So, lady, I mean, this may be perhaps a compiler thing. Maybe it's pulling in too much of the libraries. But nevertheless, the developer experience isn't, isn't there yet for these updates to be depreciated. So the suggestion is, we bring back those up codes, and at a later stage we could do eof supports versioning so we could do a eof 2 second version that depreciates them. But that would be an eip that would, you know, stand on its own, have to be

rejustified at that point. But I I don't think the developer experience is ready right now.

Tim Beiko: And can you expand on the compilation? This is not my area of expertise at all, but, as I understand it, the issue is, if you try to recompile a legacy contract as eof that obviously breaks in many cases, but also some.

Ben Adams: Yeah. So it'd be like, you know, testing whether contract length is this greater than 0? All that sort of stuff.

Tim Beiko: And then, yeah, I. The other issue was something around like even legacy contracts had some concerns like bringing in or or yeah. Sorry the issue that you couldn't bring in many popular libraries like, say, open Zeppelin to eof contracts, because these would not compile right. And that's.

Ben Adams: Yeah, because because they use some of the some of the depreciated features. So the idea is, if you just bring those back for now. then, then they'll continue to work so it'd be fine.

Tim Beiko: So I guess

Ben Adams: I mean, we'd we'd still have the one of the important things of Eof, which is you can't. You can't introspect the Uf. Contracts, you know you'll get. Oh, it's 2 Byte long. It's but you know they'll how how they present to legacy contracts, if that makes sense.

Tim Beiko: Okay. Yeah. Kev.

Kevaundray Wedderburn: Yeah, I guess I'm a bit confused. So did we try to. Did we take an Eof compiler and try to compile non eof contracts? And that broke.

Ben Adams: Yes.

Kevaundray Wedderburn: Isn't that expected? Because

Ben Adams: Well, yeah, I mean, it's sort of expected. But because essentially pretty much everything breaks. Then if that is the developer experience that we go out with. It's it's immediately very poor. So I don't. I'm just saying that it's not. We're not quite ready with, you know. Here's here's open Zeppelin that doesn't use depreciated up codes. Here's a lady that's doesn't use it. Here's uniswap that doesn't use it, etc.

Tim Beiko: And so, yeah, so in practice, it would mean, like, all of these major libraries would have to be rewritten. yeah. And then.

Dan Cline: Yeah. So from the rep point of view, I think, like this, this is like a super super important point, like the developer experience needs to be good. And if we can't do this, then maybe we should just like consider the alternate proposals for like fixing stack to be too deep, and you know, swap 1732 and just do that for now

Tim Beiko: Thanks. Yeah, it's Dano. And then Ahmad.

Danno Ferrin: So one of the proposals. I don't think too much, but he mentioned it in the comment in the Github thread is when we a couple of meetings ago, when we did the introspection options, there was an option called Option D, where we would return all of these opcodes that were related to gas introspection and ext code introspections with the restriction that you wouldn't be able to introspect into Eof contracts which preserve the key band code introspection for the Eof Code, which was the most critical piece so the Opcodes would would then be enabled inside of Eof. And if you tried to introspect and you have contract, you get the Ef 0 0, the legacy we get you get the same behavior on the plain Byte code and the container Bytecode experiences.

So what that would what that would do is that would then allow the contracts to be compiled directly. All these assembly blocks that depend on call gas ext code, copy ext code, 60 code. length and size and stuff like that. Those would all then work but when we went with the the band gas introspection. That the gas would be broken in these contracts was the design intent? So that this is the outcome of it is not terribly surprising. That is having as much friction on the developer. Experience is the new signal. That would allow us to then go with option d and and and bringing those back in. And the impact of this is we would get rid of at least 2 vips from the call, possibly a 3.rd We may or may not do pay, so going with option. D. Would actually reduce some of the scope changes for Fusaka.

If Frangio raised it in October, and it if we we we didn't hear it loud enough, I guess, is is the mistake. There.

Tim Beiko: Yeah, and maybe yeah, to answer, comment around, like, you know, rehashing this discussion again, I agree that like, it felt like we did make a final decision. And I think this, the reason to bring it up again is even though this concern was like potentially raised in the past. It doesn't feel like we actually understood the implications. And so if we want to proceed, we should just be okay with this or potentially adjust. Yeah.

Danno Ferrin: So what this would change from Uof is the Uf. Devnet. One would stay as is as shipped uf Devnet 2. We would get rid of most of the features, and instead just enable the OP. Codes, and for most of the clients that should be a really small lift, because they just need to go into their tables and change a few values. And for the testing, it's actually, surprisingly another small lift, because all the code that we brought in from the old tests. We just have, you know, flags. Table has this OP. Code. Don't convert it into a Uf container test. We just change that table as well, and we then get the same test that we have in the that pre east test, also again, testing eof.

So this going with this option does result in in less scope and less work that needs to be done.

Tim Beiko: Ahmad, do you have your hand up at all?

Ahmad Bitar: Yeah. So like my perspective is a little bit different than the voices that I've been hearing right now. So any upgrade that actually depreciate, deprecates some. A certain feature in the Abm or removes a certain feature is always problematic. The fact that we all we will, we will only disable these features, for Eos is very interesting, though, because if the developers still want to use those legacy contracts that are not Eos based, they can always use the legacy contracts and the libraries will always upgrade to Eof to get the new features, to get the gas optimizations that Uof brings, etc. So all like that worry that the current, like we haven't shipped until we ship the libraries are not going to be updated to the Uf. Version. I don't think any company that, or any entity that works on these contracts is willing to spend time to upgrade these libraries and

contracts and tooling before actually we ship aof, and the fact that we're still having a compatibility mode where the legacy contracts are still working, still, deployable plays the role here that we don't really need to care about. If if eof if these legacy contracts can be compiled to aof or not but yeah, that's that's just my perspective. Yeah. But one more thing I would say is that the important thing here is to to think about like, why did we remove that introspection is is removing that introspection here actually a net positive in the future. And if so, then we should continue with the removal, regardless of the development experience quote unquote that will affect how you deploy your contracts.

yeah.

Tim Beiko: Thanks. Let's do, Dan, and then Anskar.

Dan Cline: Yeah. So I think, like for us, it's very important that, like we set the timeline for the fork and what we decide to ship around like pure desk and very little else. Like, I think it's okay to descope things like, I get that. You know, we want to stick to things. But like. I think I think we want to stick to things in that like if we frozen a certain set of features, we shouldn't add stuff on top like, because that could extend timelines for things. But like, if we notice that like, okay, we want to change this thing in Uf, like. we're going to like descope it, but I think that's fine. But like

and the north stars peer to us And like whatever we have, we should be happy with, otherwise remove.

Tim Beiko: Yeah, I would. I would strongly plus one. This, like, I think at this point we should only make substractive changes in a way like. I I think we don't want to reopen the entire can of worms around the design space of like potential evm changes. If if people want to tweak eof like, you know, maybe we can reconsider that. But I think if people want to do something completely different with the Evm. I would almost, you know. Discuss that for Amsterdam. And like, yeah, have a much smaller smaller scope for for Fusaka on the El side. Yeah, on the car.

Ansgar Dietrichs: Yeah, I I just wanted to say, also put it in chat. I. So I'm relatively unopinionated on the kind of the the content of this change. This might be right. This might maybe would be the better version of Uf. But I think process wise. I think we really should have a pretty high bar to changes here, and in particular, with these types of features in Uf. We talked about this in the past. There's this huge asymmetry, where like, if we get something wrong by adding a feature that afterwards we wish we didn't have, we wouldn't have added, now we're stuck with it forever. Whereas if we determine later that a feature is missing, and it really hampers the adoption of Uf. Or something, we can always add that back the next fork, and yes, worst case, we do lose a few months of Uf adoption, and that is bad. I'm not saying that's not bad, obviously like, but it's a very asymmetric risk situation. And so taking those 2 in combination, I think, basically especially given that, like most people on this call, now like

don't have the context for for this decision. The people that like used to pay attention to ef they don't know that we are now reopening the decision, I would argue, we should like not not change anything for Fusaka, and then reconsider this question for Glam Sita.

Tim Beiko: And this is because, like, yeah, we can always add introspection. Again, we cannot remove it. If we have it in eof one. okay? And then Giorgio's just added, something in the chat. So. okay, so I guess, like, yeah, on this.

Georgios Konstantopoulos: Sorry. Sorry I'm late at the end. No, no, go ahead. Oh, I think Dan maybe maybe shared our sense. But like, just want, like really drive the point home that the point of Osaka should be scaling with period, as that's the top top priority of it. I was really hopeful for Eof as a general like improvement. It seems to me that we can still get the benefits of it if we get rid of the cold gas introspection bands. But I think it's totally fine if we don't have the testing budget or time allocation to get things done. But if anything like ends up compromising period. I think it's going to be gigantic failure. So it's just so so important to like, make sure that, like whatever we ship doesn't compromise that goal.

Tim Beiko: Yeah, okay, so I think everyone seems to agree with that. I think then the question is. what's the value of shipping eof without code introspection. If like. Yeah, if we might be shipping a version with code introspective in the future, that just seems like it's adding more complexity, like, and then the other part of this is, if the main blocker.

Georgios Konstantopoulos: The complexity.

Tim Beiko: Oh, sorry go ahead!

Georgios Konstantopoulos: Oh, just gonna say that the complexity part, I don't think is like the important thing. The important thing is like contracts need to work and compile. And there's too much code that uses all of this stuff right?

Tim Beiko: Yeah, and so and so this, yes. Then the question is like, if we ban introspection, you know, it was always going to be clear that some contracts would have to be rewritten to support that And is it not okay for them legacy contracts to keep using, you know, the legacy code paths. and you know, on day one things like open Zeppelin will not support Eof. But then, potentially, you know. 6 months in the future they will have a version that opens upland that supports eof so there'll be like a a lag between the time. yeah, between the time that, like eof goes live and you know, the full developer experience is there.

I guess. Maybe. Oh, yeah, Lukash.

Łukasz Rozmej: So it would be good to get some opinions from the developers. How hard would it be to amend those contracts to.

Tim Beiko: To compile to uf right, for example.

Łukasz Rozmej: But I don't have this data.

Georgios Konstantopoulos: I look. yeah, Lucas, I looked into that. We've had the of support, like in foundry for a long time. So I've looked into it multiple times. It's not that hard. But ultimately there's just every library in the ecosystem uses assembly, because for call related stuff just for Erc 20, for example, because the l. 1 like just demanded that to happen. So I agree it might not be a lot of work, but it's still you just cannot expect to do this like clone any repository that you want. Like every devil, run into this. It's going to.

Tim Beiko: And we say, because the l 1 required it. This is like the cap. The gas cost optimizations. Is that correct?

Georgios Konstantopoulos: Yeah.

Tim Beiko: Yeah, okay, yeah. Yeah. Let's do. Alex. And then Charles.

Alex Beregszaszi: Just wanted to highlight that in epsilon internally, we actually did change the solely the implementation. Like most of the the pieces. To prove that it can be compiled with us. not talking about the the gas parameter, but rather the create 2 style cases which look a bit more complex to to be accomplished, and those can also be accomplished with the Uf. And those are the pieces we have rewritten. So so far, you know, haven't really found a feature which cannot be accomplished with Uf installation. But obviously it has to be changed in the source code.

Tim Beiko: And then the assembly, I assume the assembly stuff just like cannot be solved like it seems fundamentally impossible.

Alex Beregszaszi: No, I mean, these are the. These are the assembly parts. obviously, you cannot like automatically translate the assembly, part in solidity, because the commitment of solidity is that the assembly part is left intact. That's controlled by the the author. So that's why, you know, we manually have to change it. But all of these changes I mentioned have been done in the assembly parts. None of the other parts have to be adjusted.

Tim Beiko: Okay. Charles.

Charles Cooper: Yeah. Sorry if I have background. But I think it's also going to be a problem when people need to maintain 2 different con source codes for like l twos that don't have uf and uf main like. I already have people complaining to me about like push 0, because they like try to deploy, push 0 to like in L 2. And it doesn't have it. It's gonna be much bigger deal when people are maintaining 2 source codes for every single project, and needed to like, have 2 different audit maintenance and deployment paths for those.

Tim Beiko: Right, and I think that would be an issue, regardless of the Eof version we do, though so the code introspection is kind of orthogonal to that I mean.

Charles Cooper: No, because the Eof breaks semantic compatibility with the EU.

Tim Beiko: Oh, be okay. And then because you can bring in. So if we have code infrastructure in Eos, you can bring in these libraries, and then all of the tooling should work. So I guess maybe this is the the other question is. how confident are we that by doing the I believe, was version D of eof. The introspective one. like the developer experience, will actually be unaffected or good. It does seem like it took us quite some time to Yeah, figure out the implications of this. so yeah, I, I'm I'm pretty concerned that if we just say today, after like thinking about this for a day or 2 like, Oh, yeah, let's just do this other version. It solves our problem.

in 3 months we're in the same situation. yeah. And then I guess, yeah, maybe to answer point like. how bad it is. How bad is it if we only have Eos support in the developer experience, you know, sometime after Amsterdam. like, if there is actually a lag or sorry sometimes after after a few second, like, if there is a lag between eof being live and being adopted. yeah, how bad is this? An issue? Ben.

Ben Adams: I mean it would. It would be a forcing function in a way to get people to upgrade this stuff. But you know we have to accept that the developer experience would be not necessarily great.

Tim Beiko: So, and and then to be curious is the Eof developer. Experience will be not great@firstst

Ben Adams: Yeah.

Tim Beiko: Yeah, and then legacy will remain unchanged.

Ben Adams: Yeah. So I mean, the tooling would probably have to prefer legacy at the start. If you know what I mean. Right?

Tim Beiko: So the yeah. So the tooling would, yeah, would default to legacy. And then and I think this is how forge works. Like, obviously today it's like default to legacy. You have an Eof flag. and then that would probably be the case, for, like.

Francis Li: I've seen.

Tim Beiko: Future! Oh, sorry!

Francis Li: One second.

Tim Beiko: Oh, okay, I think you just got off what? And I guess, okay, maybe the other thing is. what's the cost of like waiting an extra week or 2 to make a final call on this. I know that. We are like progressing on the def nets. but it yeah, is there is there something that like in the next week or 2 will make a major difference if we if we choose one or another? Yeah, I know.

Danno Ferrin: So this affects the Eof devnet. 2. Plan, the 2 main OP. Code, one of the 2 main opcodes, the xt code type and xt code address are completely moot. If we restore the opcodes and keep them in the container as well as in plain byte code. And the payoff code. Is a separate discussion, but it no longer becomes essential if we have access to the old call series, OP codes so that we would need to know before we start Internet. Uf, devnet 2. But since we're not planning on launching Uf devnet one until pector ships. it's a discussion we have time to have.

Tim Beiko: Okay, I guess, like, yeah.

Georgios Konstantopoulos: From there.

Tim Beiko: So yeah, go ahead.

Georgios Konstantopoulos: Sorry team. Yeah, from from our side. I basically like took over the conversation from the red team, didn't have a huge conversation with the team and made the call, for us. If I have like a day, I can collect the team's opinion and like, have a formative updated view on basically what the 2 paths look like for us is either eof without the introspection bands. or given that we have the Charles Ap. Like, do swap, do? 17 to 32, and call it a day. I think these are the 2 most credible paths, and that's what I would invite every team to slip on and like have a response, not in one or 2 weeks, but, like.

you know, by tomorrow, probably.

Tim Beiko: Or I mean, okay. So if you think that's reasonable, then, like on the testing call on Monday, we could be able to make a call on this

Georgios Konstantopoulos: Yeah, yeah, 2 weeks is like, too slow.

Tim Beiko: Yeah, yeah, I agree, 2 weeks feels like a really long time. But okay, that's. And then, I guess, does any team disagree with that. Does any team feel like they would need one more time to research this, or or already has, like a very strong opinion today that until it's the right path. Okay? If that's the case, then let's move to the risk. 5 conversation. And then and then, yeah, tentatively. Try to resolve this by Monday. yeah. And okay, sorry. And before we do that, just question the best resource on the exact proposed change. So the specific eof change that's being proposed is going from the current version to what is listing listed in option. D on the doc. I just shared

And then, do you know the number for Charles's eip Georgios off the top of your head. or I guess we have Charles here. Oh, 7, 9 0, 7 seems to be something that the rest team would consider as an an alternative. yeah. so yeah, do client teams feel comfortable to like review this. And the impact on the developer experience and have a form view. yeah, by Monday.

Ben Adams: I mean since somebody brought up push 0 the this an advantage of of eof over just a raw change to the evm is eof contracts will fail to deploy on like an L. 2 that hasn't got eof, whereas the adding the opcodes, the evm will deploy on L. 2, and then fail at Runtime.

Charles Cooper: Yeah, the issue is that if you have 2 different versions of the source code, the difference between the Euf and the non uf code is going to be more subtle than just faulty or not. For example, if pay ships with euf, but not with non. Uf, there's going to be 2 different kinds of send idioms, and they're going to behave differently, and the fault scenarios are going to like it's going to be like reentrancy versus non reentrancy. Awesome.

Danno Ferrin: And option. D remove that subtlety because you'd be using the same call operations as you would in blame by code.

Tim Beiko: Okay. and yeah, someone posted the issue in the chat for the testing for the testing call. I think it would be good if either Dan or Ben, you want to just write up a quick summary of like, yeah, the different options. And then links for the specs for people to review. And then on Monday we make a final decision on this which hopefully doesn't affect. Yeah, the next. I mean, it'll affect the next couple of days. But we won't lose a 2 week testing cycle over it. okay, anything else on this specific issue before we move to risk 5. Okay? Yeah, thanks. Everyone. I realize this is kind of a last minute curveball. But it is what it is.

So yes. Next up like, client you wanted. You wanted to. Yeah, bring up the response issue.

Lightclient (Matt Garnett): Yeah, I mean, I was just trying to gauge the sentiment from other client teams. Basically, there was a post from Vitalik talking about what we could imagine. The farther future of execution in ethereum looks like, and I think. for the most part, if we think about what we want to accomplish in the next 5 or 10 years with execution clearly having 0 knowledge, proofs of the execution is important, and it seems like from his post and a lot of other Zkp teams. They want to rely more and more on risk 5 or something of that shape. And in the past we've said Eof is better for Zk proving, and that seems true. But we're talking about marginal improvements over legacy, 1020, 30% improvements. And they're talking about risk 5 being orders of magnitude faster. So if we're already talking about.

you know, switching to a different execution substrate. and we haven't even shipped eof. I worry about the amount of work that client teams are putting in. I worry about the work the community is going to have to put in just to support Eof when in a few years we're going to say we really want to do risk 5 now, because we need to support 0 knowledge proving. And we deprecate all of that work.

Tim Beiko: Lucas.

Łukasz Rozmej: Yeah, so I think, like, potentially risk 5 would give us 2 benefits. Right? One is the the potential performance improvements that that we're talking about. And the second one is potentially tapping to some broader tooling that we could use right. And and in ethereum. So, addressing those one by one performance improvements. I think we can get close to those numbers if we stop interpreting evm bytecode in those key provers which I think that is currently being done. So it's being interpreted there and do some kind of ahead of time compilation potentially. And there are already attempts of doing that right. There is Avmc. There is Ilevm in. Never mind that. We're working on the big problem here is that the classical bytecode, the current bytecode is not really friendly to this kind of solutions.

The problem is that it's just one big bytecode, and you emit tens of thousands of opcodes. And this is really like any compiler will just stop optimizing it like, say, it's too big, it cannot optimize it. Oh, Eof solves it in a way, because it can provide a structure. It could provide different subroutines, and those subroutines will be a lot smaller. So there's a potential benefit of Eof with this approach. So that's 1 way of solving the performance thing that we can use. But it doesn't probably solve the tooling question. So the tooling actually goes the other way around. It makes the tooling away more complex rather than simpler, because we need to support this tooling.

That's a downside and an upside right. For now I think the ethereum core developers had a lot control over what's going on ethereum, and if we like, just go with external tooling, we somewhat lose this control. But this might be a good thing or a bad thing. So yeah, that's kind of I see an alternative. I just don't know which one would be better. And that do we want to go to a very, let's say, low level risk v bytecode. Or do we want to stay on a quite high, level, abstract domain focus, bytecode that we that we have full control of? That's that's the question for me.

Tim Beiko: Thanks. Let's do on Andrew, and then Guillaume.

Andrew Ashikhmin: Yeah, maybe it's a stupid question. But why don't we turn the entire Evm into kind of a Turing universal risk? 5 machine? We we have evm one. So we can compile that into risk 5 and enshrine that as the Evm. I don't know just an idea.

Lightclient (Matt Garnett): I mean my understanding is that the I mean we'll have to see if if what Lukash is saying is true, and we can have Evm executed at, you know, some small multiple of the cost of Risc-v native. Then maybe that's okay. But in general, people will want to deploy to the lowest cost environment. And if we're going to use Risc-v or something else like Risc-v as the basis for 0 knowledge proofs, it's hard to imagine that people are going to pay extra to deploy to interpreted, or a compiled version of a higher level system, when they could simply deploy to Risc-v.

Andrew Ashikhmin: I see.

Tim Beiko: I'm Guillaume.

Guillaume Ballet: Yeah. So for having tried to compile the that's not my main point, but just wanted to add, having tried to compile evm, one to always 5. This is, this is more difficult than than you imagine. There's a lot of C plus plus dependency. Okay? Actually, the problem was with 5, 32. There's a lot of lacking headers and and things that make it very difficult. Yeah. So I don't think it's that easy. But the main point I wanted to make is I I think everybody will agree. I'm hardly the the defender of the Us. But I think it's the wrong reason to to not do Eos, because risk 5 I see Zkvms, there's a lot of people in Zkvms that are actually considering switching to wasm.

Okay, a lot might be exaggerated, but at least a couple I don't know if risk 5 is really the perfect Isa for for zk, zk applications. And I fear that doing. You know, it's this. It's the same problem like we we want to. There's this new shiny thing on the horizon. And we would. you know, give up on doing something that we could do now so that we potentially get something in the future. But there are so many moving parameters that that yeah, we we don't know which future we'll we'll get to. So once again. Not not a big euf fan, but but I don't think this is why we should. We should not have euf.

Lightclient (Matt Garnett): Just to. Yeah, respond to that very quickly. I think, in general, I agree with you on that point that we shouldn't let the shiny things in the future always dictate what we can do now. But I think, unlike many protocol changes. When you change the user space, you put a massive burden on the entire user base and community. And we need to hold those types of changes to a higher standard than changing a database or changing the way the consensus protocol works.

Guillaume Ballet: Hmm. Fair point.

Tim Beiko: I guess, to that point, though, like what's the timeline on which this would happen? Because, like, you know. ethereum is 10 years old now give or take, we're gonna change the the Vm. For like the 1st time significantly. like. Do we expect this to ship risk 5 in like 3 years or 5 years, or farther than that. And yeah, I'm my, I'm my skepticism would be like if we think we're ready to do this is in in 3 years. Realistically, it means we're probably shipping it in like 5 years. and that feels really hard to weigh again. Something we can ship in like 6 months. as there'll probably be many other problems we have to deal between with between like now and when we do this. But.

Lightclient (Matt Garnett): Sure. But then you just have the overhang for every formal verification engineer who wants to build a tool or every static analysis engineer that wants to build a tool or compiler developers that want to build compilers only focus on eof that there might have this end of life of the virtual machine, and just a few years down the line. It makes no sense to invest the time and energy into building it.

Tim Beiko: Yeah, I see that like, like in Vitalik posted 2 to 5 years in the chat. If it was like much closer to 2, I feel like I would agree. if it's like much closer to 5. I feel like there's probably still value in doing this. But yeah, I know you've had your hand up.

Danno Ferrin: Yeah, so.

Tim Beiko: That's it.

Danno Ferrin: This isn't the 1st time that an architecture switch has been proposed for Evm. He was almost proposed at Devcon, in Frog, of all places with current. Hard fork. We're shipping the name of the current Hard Fork, and there's a lot of lessons that we should look and see why you want them? Didn't ship and make sure that we don't repeat those same problems with Risk 5. There's you know we talk about when we don't want to rewrite contracts for eof we're going to have to rewrite even more contracts for risk 5. You know. There's a lot of things that are the same. A lot of things that are different. Performance was an issue. And we wasm, is that unique to Ewasm? Or is that going to be a general problem with the 256 bit registers there's a lot of before we really dive into this. We really should take some time to to do a postmortem on Ewasm, and make sure that if we do move forward with risk 5 that we could learn from what's been tried before.

Tim Beiko: Thanks. Dongrat.

Dankrad Feist: I mean, I just want to comment as well like right now, the way that the prover market develops. I generally don't see proving costs as like a big argument in the future. I think it will be a trivial part of transaction costs. So I just think like it's neither going to be a good argument for Uf. Nor risk 5. Can you hear me.

Tim Beiko: And is the implication that like. even if we have Eof, we can just create cheap proofs for this, as we.

Dankrad Feist: I mean either way, like, I don't think I just don't think we should use it as an important argument right now. Obviously risk 5 is a very long term. Research direction, I think uof is a different decision. I think the prover cause should have just no bearings on this.

Tim Beiko: Got it. Yeah, I guess. Like, yeah, I was gonna ask, is actually Richard's question, yeah, if we adopt the of now is the only cost to risk 5 that, like some people, may have built tooling for it. That then gets deprecated. But then, if metallic has this other comment, saying that we can turn the Evm into a smart contract on Risk 5. I assume. That's also true of Eos versions of the Evm. so that we would keep supporting that. So

Guillaume Ballet: I mean, it's gonna be a maintenance burden, right? Because we would have 3 versions of like 3 3 systems to maintain.

Tim Beiko: Correct. So we have to keep supporting everything we ship forever all the time. I think this is true for eof and legacy Evm. Regardless of which path we take. It seems like that decision was like broadly made. But yeah, there will. Like. I think over time. It's realistic that there will be different versions of the Vm. That we will need to support. And then, if we go down this path, I guess that the alternative path is, you just keep updating the legacy? Vm, forever. And then, yeah, it seems like we were fine with 2 adding a 3rd on a 5 year. Timeframe doesn't seem like qualitatively different. But maybe that's wrong.

Yeah, I'm I don't. I guess. Yeah, not to like extend this discussion forever. It doesn't seem like there's like a major short term concern with this, like, there are concerns around long term tooling support potentially additional complexity in the clients. I feel like if we are going to make a decision about Eof on Monday. This is like maybe a secondary thing that should be waited. But it doesn't feel like the primary thing we should base the Eof decision on especially given the amount of certain uncertainty around. Risk 5. yeah, I know. Vitalik, do you have a mic to maybe voice that later.

Vitalik Buterin: Yeah, sorry I I do. I was just that. I could not find the raise hands button, and so I was. Being polite and not circumventing it. yeah, again, I get no. So the the thing that I was just types typing is right? So the way that I think about risk 5 is I mean a couple of things right? So one of them is like, one really big thing about risk 5 is, the fact is, the like, actually sort of the fact that we don't control it. And or I mean, obviously like we'd like, there's many versions of our risk 5. And we'd have to pick one. But we sort of most we don't control it, and

that I I actually think that's a benefit in a couple of ways. Right? So one is that it means that there's this other ecosystem of a whole bunch of other things that have. Yeah. that have switched to it right? And you know, one interesting arguments that I heard actually is that there are some developers who are not ethereum developers right now who might be interested in being ethereum developers who would love to use the same language on chain and off chain, so kind of like a Nodejs type of dev X arguments like, it's just much easier when you use the same. The same code on the clients in the server and their off chain. Logic is in some traditional language, basically, all of which compiles to risk 5. And so having risk 5 just be available is good is good in that way.

and then the other thing is like it does sort of discipline us into ossification, which, I think is a good thing in a lot of ways right? Like, I think if we arrest realistically, choose risk 5 then like there would like the things already gone through mo more than 10 years of people evaluating what OP. Codes to add and what OP. Codes not to add. And so it just like it becomes a commitment, so that you know, if we do it, then that's the thing. And then just from a complexity perspective, like basically like, I think if you add to, I know I saw, like python 2 and python 3 get brought up right. And

if you have to ask the question like, Do you expose the developers? Python 2 and python python 3. Or do you expose python 2 and c plus plus? Then, like the the second feels more attractive, right? And I think one of the reasons why Ian said, if you expose c plus plus, then developers would still be able to code in python. 3. so those are some arguments. I guess I'm I'm just reading through questions. Will there be lots of precompiled Cisco's? Add to with risk 5? I mean, I think the yeah answer is probably, yeah. Well, so there's like 2 kinds of Cisco's right. So there's like Cisco to represent system operations so like sload external call balance whatever whatever. And those would be turned into Cisco's, because that's how risk 5 handles everything. And

the yeah. And then the other type of like, Cisco would be actual precompiles. Right? And I mean, we can. I would say we should just do precompiles in the same way that we do precompiles. Now, we would probably need fewer of them, because risk 5 is natively much more efficient than the Evm is. But like, in general, a big part of the yeah ideas to try to minimize the need like, or is to try to basically change the Vm without changing everything else. And so the yeah, like, you'd be able to interact with other contracts and based in exactly, yeah. exactly the same way right? And so in that case, like, we probably don't even need like a new feature for new type of precompiles we just like, if we have precompiles like, they're a list of addresses that are like from one to 10 or one to 15 or whatever. And for those pre compiles. So we? Yeah, like, if you want to use a breakout, and you just call into that right? So

alright that that's probably the most natural way to do it. is risk 5 more efficient. So I think this is one other thing that, like, we need to start thinking about right, which is that there's been a lot of discussion around l 1 scaling and increasing the l 1 gas limit. And a big part of that for me is that if we're gonna increase the l 1 gas limit. And like, especially go to crazier levels. So like, I, yeah. like, I think, like, I think I've given the number of couple of times of like 10 x in the 2026. Given sort of some of the relatively basic stuff, like delayed execution and double lock access list. But if we go beyond that, then, like, we really need to be clear. What are the limiting principles that we have? Like, what are the yeah things that we're not willing to

sacrifice. And one of the things that's come up is like some limit to like dollars or Watts, or whatever for how much, how long it takes to Ck proof. And like, if zk, proving becomes the bottleneck, then basically the thing that matters in terms of like, how high the l 1 gas limit can go just becomes prover efficiency right? And if prover efficiency actually becomes more important than regular execution efficiency, which seems they're like. Likely, though I think that's something that we should explicitly evaluate. Then, that's like something that we should take we should take into account. I know I feel like I've I've burned through the questions where.

Tim Beiko: I think. Get Kev had a couple more.

Vitalik Buterin: Yeah, sorry. Yeah.

Kevaundray Wedderburn: Was mainly about is is the main argument that we need to switch from evm to a more traditional architecture? Or is this even more specific to risk 5.

Vitalik Buterin: I think I I personally feel more confident in the 1st than the second, like my big picture argument is that it seems like basically, all of these Ek, evms are written are done by creating a Zk Vm for a much simpler vm than the Evm, and then like, basically just taking an ethereum client and sticking it into that vm. and like the like. From what I can tell, they're like almost all done done that way. Right? And so if a yeah approver is done that way, then, like almost for free we get the ability to just directly expose that underlying vm, to smart contract developers. Because as long as we yeah do it, right? We get the sandboxing right? Like, we, yeah, would we just go and expose that directly. And that's just like a massive

efficiency increase. So like. That's the part that I feel relatively more confident in. I mean the choice of like risk. 5 versus something else, I mean, I know other people like Zolo have, or Ellie from a start. Where have suggested arithmetic, friendly vms like Cairo, and like, I think it's good that to have a group of people seriously exploring that hypothesis. And I think, like my like. My own impression after reading people's feedback for a few days is basically that it's either risk 5 or it's something specifically arithmetic, friendly, because outside of the specifically arithmetic, friendly domain. There just isn't anything worth remotely close to the level of adoption and like level of working at the risk 5 has had. But obviously, if it is specifically ck, friendly, then like, there's a good argument that that could give significantly higher efficiency or simplicities, and it seems valuable to explore.

Kevaundray Wedderburn: I guess one thing to just focus this a bit more is, how does this weigh in on Eof? Because.

Vitalik Buterin: Okay.

Kevaundray Wedderburn: There is 5 switch later on.

Vitalik Buterin: Yep.

Kevaundray Wedderburn: Is this also to like? Not do? Eof.

Vitalik Buterin: Right? So I think right. So the way that I think about it is that there's like a couple of aspects to sort of quote dof right. One of them is specific features that we want to introduce, and then the other is there is this underlying philosophy of future proofness? So that covers not things like versioning. It covers things like code sections, and it, it covers like even just the underlying idea that we make a new Vm where things are much more locked down, and so on, and so on. And the yeah, like a lot of the underlying philosophy behind some of those decisions, I feel was made with the idea in mind that, like this would be the end game for ethereum.

But then, if the end game for ethereum that we think makes sense ends up just being. Let's like switch from the evm entirely to some like much simpler either risk 5 or like prove prover oriented. Vm, then that's like a different endgame. And so we should reevaluate how we how we try to extract some of the like dev accent and efficiency benefits that we wanted to get out of out of you off for the in the short term, right? So like, I think there are. But like the whole like contract code, size, increase thing is and the the extra swap dupes is like a good example of that right like. There could be other examples as well.

Tim Beiko: Thanks. Lucas has hung up.

Łukasz Rozmej: Yeah. So for me, it's hard to wrap my head around. How this, how the ethereum in this post risk 5 world with all these etik knowledge proofs will work so in. Maybe we will get, for example, also risk hardware. But for now this, this, the hardware of this, is not the case. So this still needs to the 3 C. Code still needs to be interpreted. It still needs to be gated or ahead of time compiled. So what's the benefit here, except, okay, it's more native to the Z. The current vms.

Ben Adams: Mean the builder. The builders would still have to run interpreters.

Vitalik Buterin: Right? Well, builders and nodes that kind of re execute fully for analytics reasons. But and I think a couple of arguments right one is that like the the provers are a big deal. And like they yeah, might. And like, I think there's a good argument that they will be the primary bottleneck on like, how how high we can safely raise the raise the gasoline in the future. So that's 1 2. Is that like, there's benefits that are to risk 5 that are not just speed, but rather devx. And 3 is that. The yeah. Like. there is a large set of Co. Of contracts, where, if you in like, compile them down into risk 5, they still become much more efficient. And the way to think about this is that

a lot of for like, for almost the the average computation, like the average number that the average computation manipulates is going is a very small number. Right? It's like an index. It's 0. It's 1. It's like a program counter, like basically stuff that fits in 32 bit right? And so the evm ends up wasting a lot of space by using 256 bit for those. And I just the computation ends up being more efficient because in risk 5 would be able to take all of those like index type variables and just treat them as a 32 bit value instead of a 2 56 bit value.

Tim Beiko: Okay, maybe just to zoom out a little bit. So if had bunch of comments in the chat around the process, I think a lot of people echoed this. So with regards to how this impacts eof, there's kind of 2 paths we can take. One is, we assume it broadly doesn't, and there's too high of uncertainty to choose now. So we make a kind of local decision about Eof on Monday. Maybe this is like descoping eof, or. you know, keeping it as is. But we just assume that we will not know much more about risk 5 in the short term, and we should be aware that, you know, there's like this pending potential like other other execution environment.

The other path that I was proposing is, should we have some sort of research sprint around this, where we kind of assume we move forward with whatever version of eof we choose on Monday. But then we have kind of a concern concerted effort over the next month to like. Answer some of these questions. I guess, with that second path I'm not sure, like, what is the thing that we could learn in the next, say 4 weeks. and give us confidence about this decision like it seems like there's many of these uncertainties that are kind of evolving over like months to year timeframes. But are there specific questions that you know? People feel that if we spend 4 weeks, you know, focusing on this, we would actually.

we would actually learn that. Yeah. Yeah. And my sense is like, yeah, 4 weeks if I had to bet. This is more like 4 months than 4 weeks, and then at that point the cost of waiting for eof is is is is quite high. yeah. So look, there's benefits to to to studying this for 4 weeks, like Onsgar says. But I I think here, I really want to focus on yeah, Eof, specifically, not just the entire risk. 5 thing like we need to make this decision. I think we could probably delay it a few weeks. If it was, if we would like learn something quite important in that process. And like, yeah, if if we're not going to learn that much relevant in the next 4 weeks, specifically regarding Eof. Then sure, maybe we can also investigate this. But we shouldn't block our Fusaka scoping decision based on it?

yeah, okay, okay, so it seems like, okay, so it seems like, we effectively don't want a couple of those decisions. If that's the case that I would still say.

Lightclient (Matt Garnett): I think we should. I think we should consider that in the discussion they're totally related. It's not possible to think about them in isolation.

Charles Cooper: Yeah, it. It's like not free to ship either of these.

Tim Beiko: Correct. So I guess. Okay. But then. independent of risk, 5 like, you know. if we assume there probably will be some changes to the Evm in the future, or to like, you know, ethereum's execution environment in the future. that is something we can like wait as an abstract consideration in the Eof decision like, do we want to maintain N equals to Evms today, and then have some 3rd thing in the future that's independent from like the specifics of risk. 5 specific like, and and how that would work, you know. Maybe we end up moving to something else. But I don't know that there's much more we'll learn on that topic in like a couple of weeks. I feel like by Monday.

People will have their opinions set on this at a high level And then, like I would lean towards making a call on Monday about the scope of Eof in Fussaka or not. And this is either we this, either. We ship eof as it currently is, and we're okay with libraries having to update and then and and then the other option is some different version of Eof. And then, you know, there's another option that's like we remove eof, and we potentially do some piecemeal evm improvements in this fork. but I don't think we need to couple this with risk. 5. Beyond saying Eof is unlikely to be ethereum's final execution environment endgame and we should work on getting the final execution environment and game. But that's going to take months to years. Yeah.

Lightclient (Matt Garnett): Yeah, I mean, I feel like, with this layered onto the last conversation about whether or not to have introspection. We just were not ready. We're not ready to make this decision.

Tim Beiko: And then, yeah, so if we're not look, we can choose to not do eof because we're not ready. And, you know, potentially just delay it, quote forever. And it, I think, short term, though we should. we should be mindful that it doesn't seem like there's much desire to do this in, say Glamsterdam. So if we don't do eof in in Fusaka, then we should just assume like for the next couple of years. We're not going to be doing this, and maybe there is like some version of Eof we do in 2 years, when we have a way. Better understanding of the Evm endgame or like the eln game. But yeah, if we, if we think like, the general uncertainty independent of risk, 5

is is is too big. Then we can decide to not change anything. And but that should be the thing we we decide. Yeah.

Dan Cline: Yeah, I think. Well, like risk 5 like is. you know, relevant to to the conversation like it's it's very possible we don't learn much in the short term to the point where we have to make a decision on eof anyways.

Tim Beiko: Okay. So I think by Monday we should make it. Oh, sorry. On Monday's testing call we make a final call about the Fussaka scope for eof people can have different estimates of uncertainty, and we should wait that into the decision. But I don't think we should over index on risk 5 specifically but we can imagine that something of that magnitude is likely to happen at some point, and that might change whether or not we want to do eof at all. Does that make sense? And yeah, Justin, just to be really clear, like I, there is a pure research idea. you know, there's some chance that it actually happens. There's some chance that some version of it happens, or some chance that something completely different happens in 5 years. And then

assuming something were to happen like, Is that yeah, it it. Does that change your decision?

Justin Florentine: Yeah, I think what I'm trying to say is like, I don't even know how to compare those 2 things.

Tim Beiko: Well, it's more. If if you know that you're gonna have to add this. call it risk. 5. Ask thing in 5 years does do an Eof today make a difference. Yeah? And if not, that's fine, like, I think one argument is like it kind of doesn't. And like to the extent we need backwards compatibility with the evm. We're gonna need it with Eof. And we're gonna need to write all that tooling, anyway. And then to the extent it does. Then, yeah, maybe having like less. like, yeah, maybe you want to keep a separate evm. Now, yeah. I do want to wrap this up. Yeah, there is one other important thing we need to talk about today. Again, I think we can continue this discussion offline. But I think I want to talk about the gas limit execution, and then maybe the block limit. But on the last awkward devs we we said that the other thing we wanted to prioritize for for Fusaka is

focusing on raising the gas limit. And obviously the gas limit is not part of like the Hard fork. People can raise it whenever whatever but there is value in coordinating towards actually improving and and scaling the gas limit and figuring out what is a safe value that we can update defaults, for when the fork goes, live again we don't need to wait until the fork to raise the gas limit. If we feel like it's it's kind of safe to improve to increase it. But, The idea is that this eip that I showed in the chat would be like our final backstop, where by the time we ship Fusaka, maybe we realize 80 million gas is fine, and so all the clients ship with 80 million gas, and maybe Mainnet is already at like 60 or whatever by by that point and it's been kind of a weird eip to draft in that. It's it's kind of drafting this

most almost like an idea that we want to focus on this. But it does feel important to have something like that, because otherwise we will just add a bunch of stuff in the fork, and then no one will have time to work on the gas limit and the gas limit will be the same a year from now than it is today. so I know that, like, yeah, there's still a bunch of comments on the eip. But at a high level are people generally happy with moving something like this into Fusaka. and okay, that's just into the point. Specifically, the thing that the eip is saying, like, we don't need one. In theory, there's value in the eip specifying the default. And there's value of the eip as like a reminder that we need to do this work.

yeah. And we have had an utter eip about the defaults, for, like the blob counts on the El side. So it's not like this completely unprecedented thing. Yeah, then.

Ben Adams: Yeah, I'm good with it, because if you look at the gas limit, picks after the after the after the chain moved to 36 million. Basically 45% of it, hasn't we moved past 30 million. So it'd be good to get people a commitment from Cls and Els that they will change their defaults to to be the new hire level.

Marius van der Wijden: Yes, we will change our defaults at some point.

Tim Beiko: And, Dan, you had your hand up.

Dan Cline: Yeah, I like it. I yeah, I mean it. Like, I agree that it's like, I mean doesn't really specify much right now. But like, I think that's okay. Can serve as like a important process document. For now, if anything having a vip like not actually specify things is kind of nice, because it don't really have to do anything. So oh, yeah.

Tim Beiko: Okay. So then I think the next point. So obviously, we, we didn't get this merged and and like done today. But we should get it merged in the next week or so, and then, assuming there's no major objections, we can ssify it. On the last call, but it does feel like we've talked about this general concept for the past 2 calls so like I would move forward with it as soon as we have something merged that we're generally happy with. Related to this one other proposal. That's yeah, that we should review, and then potentially also do to towards increasing the gas limit. Is this idea of adding a cap to the block size at the Rlp level, because there is one already on the Cl. Gossip side, and this would help kind of cap things.

I don't know if Julio is on the call to give like a 1 min pitch.

Ben Adams: He's yeah. He's not on the call. I can give it So the Cls went gossip a block larger than including the Cl. Part larger than 10 MB. So, since you can do a block 0, even with the change in Petra of all Zeros that would put the cap safe cap at a hundred mega gas. The inverse. If it's not zeros these. The cap is like 400 million gas. Just based on the bite size. So if we put a cap of 10 MB minus some margin on block building and say, it's an invalid block if it goes over that size. Then we no longer have to consider cool data. going over that size when building blocks, so we can put more execution.

And have a higher gas limit than a hundred 1 million. So, for instance, we could do the 150, which was the original suggestion for the default change to investigate. We can do that if we put a cap on the byte side. But it it's unsafe if we don't cap by type. because there is an inherent cap in the Cl.

Tim Beiko: Great thanks. And so, okay, I I know we're already at time. So I think people should also review this. But we can make a final call on the next call. And I think for this gas limit one again. It's kind of weird because we said the scope for Fusaka should be finalized. But then, if we agree in the abstract increasing the gas limit, then I expect we will maybe see some minor eips like this come in that like actually allow us to do it. So my proposal here would be, by the next call we merge. And we sfi, the actual gas limit eip, and then maybe this one as well. But we should be open to

small incremental eips that actually help us get 100 million gas being added in Fusaka, even if they don't exist today because we don't know what the actual bottlenecks are. yeah, okay, we're already at time. The last thing on the agenda. So there's some quick updates on history expiry. If people want to stay for an extra minute or 2, I think it's probably worth getting on the same page about that, and then we can wrap up. Piper, are you on the call?

Piper Merriam: I am the Meta eap for history. Expiry is 7, 9, 2, 7. Take a look at it. Sepulia activation happens on May. 1st you're an execution layer client team, please, get some documentation on any changes to your client behavior published, and send me a link to that, so that we can aggregate that stuff together to make it easier for node operators to know what is changing in their clients. And there's a link on the Pm. Repo for the meeting today. Of the each clients repository. That shows where all of the error files are for sepulia data for mainnet data. Things like that. Take a look at that stuff and get documentation out for how your client is changing, based on history drop. That's it.

Tim Beiko: Thank you. Perry has a question which Els have is history drop for sepulia in their main net, releases.

Piper Merriam: Believe I'm aware of Geth and Baysu. But client team should con we shouldn't take my word for that.

Tim Beiko: For guest. This is not turned on by default. Okay, so no base suit. No, never mind. No guests. Okay. We already have time. When is the net? Is there like a next touch point for history, expiry that clients should join to discuss this? If we are doing it in the next 2 weeks.

Piper Merriam: I'm not aware of any further decisions that need to be made. I believe that all of please correct me if I'm wrong. I believe that clients should have everything that they need to act on this.

Tim Beiko: Well, I guess they need a client release. We would need to test this. It would be good to have some like coordination. But what is like the best place for? Yeah. Just people to follow up on this? Is it the discord.

Piper Merriam: Yep, the discord, history, exprey channel. If there's something that you guys need. With respect to to moving this forward, let me know. I I. To the best of my knowledge, everything about history expree has been defined and and finalized, and client team should be able to act on it.

Tim Beiko: Okay? Okay, let's follow up on the history expiry channel. I know we're already a bit over time. So any final thing people want to cover. Okay? If not, well, thanks everyone. So yes, reminder. Monday's call. We will make a final decision about eof and then go from there. And please review these gas limit eips as well. In the next few days we'll try to get them merged next week. Yeah, thanks a lot. Everyone.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.