Tim Beiko:Thank you very much.
Transcript
Tim Beiko: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.
Tim Beiko:And to wrap up we have some stuff on the history expiry to discuss.
Tim Beiko: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.
Tim Beiko:Spectra will be forking at Mainnet on May 7th at 10 0, 5 utc, this is at the start of epoch
Tim Beiko: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.
Tim Beiko:Anyone have any updates or concerns, or anything around Petra.
Tim Beiko:Oh, yeah, part of this.
Parithosh Jayanthi:We're yeah. Go ahead.
Barnabas: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.
Barnabas:And so far it has gained a bunch of improvements in the past couple of weeks, and
Barnabas: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
Parithosh Jayanthi: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.
Parithosh Jayanthi: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.
Tim Beiko:Anything else on Petro.
Tim Beiko:Cool. Well.
Tim Beiko: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.
Tim Beiko:Oh, sorry. I just muted you. Gary.
Tim Beiko:okay, sweet. Next up on the agenda. So Fusaka.
Tim Beiko: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
Tim Beiko:discuss this.
stokes:Yeah, I am.
stokes:It was mainly just a reminder to sort out the el configuration format for the Vpo eip.
stokes:I believe we have a configuration we like on the Cl. Side.
stokes: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.
Tim Beiko: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.
stokes:Right?
stokes: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
Tim Beiko:use the Genesis or the the like. Yeah, for config files.
Tim Beiko:Oh, Marius, so you had your hand up.
MariusVanDerWijden: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.
MariusVanDerWijden:Okay, maybe he doesn't.
MariusVanDerWijden:But you guys can hear me. Right? Yeah, yeah. So
MariusVanDerWijden: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
MariusVanDerWijden:mechanism that can have
MariusVanDerWijden:other bugs. And and and it can have weird, like interplays with our normal fog timeline.
MariusVanDerWijden:I understand why the Ecl
MariusVanDerWijden: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.
MariusVanDerWijden:similar to what we did with the with the glacier stuff.
Tim Beiko:Okay.
Tim Beiko: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
Tim Beiko:overall picture like is that something el clients would be fine with?
Tim Beiko:Or if if any el client would have an issue, just adding this as a hard fork.
Tim Beiko: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
Ben Adams:better not to invent something new when we already have.
Ben Adams:We're working to sit.
MariusVanDerWijden:Hello!
MariusVanDerWijden:Regarding regarding the proposal from that Alex posted.
MariusVanDerWijden:Yeah. The only thing I would change is to remove the timestamp, because this
MariusVanDerWijden:no real need to have the timestamp in the blob schedule because we have the timestamp for the
MariusVanDerWijden: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
Tim Beiko: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.
Tim Beiko:yeah.
Tim Beiko:Ahmad.
Ahmad Bitar | Nethermind: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.
Ahmad Bitar | Nethermind:Whatever is actually like it. It's it's it is a big like.
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind:in the yeah, in the like. Bpo in the schedule, is there.
Tim Beiko:Yeah. So I guess
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:Yeah, there, there is actually something in the eip. So
Tim Beiko:and yeah, okay, so the eip does not have the timestamp. It just has a target, the Max and the
Tim Beiko:base fee of big fraction. So and maybe the one change.
Tim Beiko: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?
Tim Beiko:If so, that seems maybe a bit weird and maybe a bit bug prone. So I would maybe just change
Tim Beiko:the like config name to be something like vp, o, 1, vpl. 2, or whatever. But
Tim Beiko:would that work for everyone
Tim Beiko:and yeah for clarity? So what I just posted in the chat which is copied from the eip.
Tim Beiko:Basically keep that, and then just use
Tim Beiko:like some generic Bpo and a number naming
Tim Beiko:no fun names. Look, if we want to change it to fund names. We can hash this out, Async, but
Tim Beiko:we could at least use the
Tim Beiko:or if someone wants to come up with a nice convention of like easily incrementable fun names.
Tim Beiko:We can do that. But
Tim Beiko: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.
Tim Beiko:yeah, some.
Tim Beiko: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
Tim Beiko:to change this, to like some some generic name, and then move on from there. Yeah. Some.
Som - Erigon:Sorry about that. I just wanted to say that
Som - Erigon: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.
Som - Erigon: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
Tim Beiko:we only schedule
Tim Beiko: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.
Tim Beiko: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
Tim Beiko: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
Tim Beiko:rescheduled a bunch of forks and put them all in the same release.
Tim Beiko: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
Tim Beiko:have, like an emergency, hard fork that delays them or that removes the future ones. If something comes up.
Tim Beiko:Does that make sense.
Som - Erigon:So, yeah, thank you.
Tim Beiko:Okay? Okay, so let's do that. Then let's
Tim Beiko:Okay, we'll find a better word than emergency. Hard fork to delay the Bpos. But like, yeah, high level, it would be an
Tim Beiko:like a way for us to help us. Yeah.
Tim Beiko:Bpo, intervention. I like this. Okay, so
Tim Beiko: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.
Tim Beiko:Anything else on the Vpo.
Tim Beiko:okay? Thanks. Everyone.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:And then another set of concerns came from a vitalik's proposal around risk 5 where?
Tim Beiko: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.
Tim Beiko: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 | Ipsilon: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 | Ipsilon: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
Danno Ferrin | Ipsilon:of of the of the eest ethereum execution spec test
Danno Ferrin | Ipsilon:as far as clients that pass those tests.
Danno Ferrin | Ipsilon:We have 2 full clients, Baysu and Geth, and as far as
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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
Ben Adams:we're ready to depreciate the
Ben Adams: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
Ben Adams:perhaps a compiler thing. Maybe it's pulling in too much of the libraries.
Ben Adams:But nevertheless, the developer experience isn't, isn't there yet for these updates to be depreciated.
Ben Adams:So the suggestion is, we bring back those up codes, and at a later stage we could do
Ben Adams: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
Ben Adams:rejustified at that point.
Ben Adams:But I I don't think the developer experience is ready right now.
Tim Beiko:And can you expand on the compilation? This is
Tim Beiko:not my area of expertise at all, but, as I understand it, the issue is, if you try to recompile a legacy contract
Tim Beiko: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.
Tim Beiko: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.
Ben Adams:So the idea is, if you just bring those back for now.
Ben Adams: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
Ben Adams: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
Ben Adams:how how they present to legacy contracts, if that makes sense.
Tim Beiko:Okay.
Tim Beiko: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.
Ben Adams:So I don't. I'm just saying that it's not.
Ben Adams: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.
Tim Beiko:yeah.
Tim Beiko:And then.
Dan Cline:Yeah. So from the rep point of view, I think,
Dan Cline:like this, this is like a super super important point, like
Dan Cline:the developer experience needs to be good.
Dan Cline:And if we can't do this, then
Dan Cline:maybe we should just like consider the alternate proposals for like fixing stack to be too deep, and you know, swap 1732
Dan Cline:and just do that for now
Tim Beiko:Thanks. Yeah, it's Dano. And then Ahmad.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:So
Danno Ferrin | Ipsilon: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,
Danno Ferrin | Ipsilon:60 code.
Danno Ferrin | Ipsilon: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?
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:If Frangio raised it in October, and it if we we
Danno Ferrin | Ipsilon: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
Tim Beiko:be okay with this or potentially adjust. Yeah.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon:test that we have in the that pre east test, also again, testing eof.
Danno Ferrin | Ipsilon: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 | Nethermind: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
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind: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
Ahmad Bitar | Nethermind: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.
Ahmad Bitar | Nethermind: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.
Ahmad Bitar | Nethermind: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
Dan Cline:set the timeline for the fork and what we decide to ship around like pure desk and
Dan Cline:very little else.
Dan Cline:Like, I think it's okay to descope things like, I get that.
Dan Cline:You know, we want to stick to things. But like.
Dan Cline:I think I think we want to stick to things in that like if we frozen
Dan Cline: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.
Dan Cline:we're going to like descope it, but I think that's fine. But like
Dan Cline:and the north stars peer to us
Dan Cline: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
Tim Beiko:if people want to tweak eof
Tim Beiko: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.
Ansgar Dietrichs:I. So I'm relatively unopinionated on the kind of the the content of this change.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Tim Beiko:remove it. If we have it in eof one.
Tim Beiko:okay? And then Giorgio's just added, something in the chat. So.
Tim Beiko:okay, so I guess, like, yeah, on this.
gakonst:Sorry. Sorry I'm late at the end. No, no, go ahead.
gakonst: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.
gakonst: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.
Tim Beiko:what's the value of shipping eof without code introspection. If
Tim Beiko:like. Yeah, if we might be shipping a version with code introspective in the future, that just seems like it's adding more complexity,
Tim Beiko:like, and then the other part of this is, if the main blocker.
gakonst:The complexity.
Tim Beiko:Oh, sorry go ahead!
gakonst: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
Tim Beiko:And is it not okay for them legacy contracts to keep using, you know, the legacy code paths.
Tim Beiko:and you know, on day one things like open Zeppelin will not support Eof. But then, potentially, you know.
Tim Beiko:6 months in the future they will have a version that opens upland that supports eof so there'll be like
Tim Beiko:a a lag between the time.
Tim Beiko:yeah, between the time that, like eof goes live and you know, the full developer experience is there.
Tim Beiko:I guess. Maybe. Oh, yeah, Lukash.
Łukasz Rozmej:So it would be good to get
Łukasz Rozmej: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.
gakonst:I look.
gakonst: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
gakonst: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
gakonst: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.
Tim Beiko:Is that correct?
gakonst:Yeah.
Tim Beiko:Yeah, okay, yeah. Yeah. Let's do. Alex. And then Charles.
Alex (axic):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.
Alex (axic):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.
Alex (axic):So so far, you know, haven't really found
Alex (axic):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
Tim Beiko:cannot be solved like it seems fundamentally impossible.
Alex (axic):No, I mean, these are the. These are the assembly parts.
Alex (axic):obviously, you cannot like automatically translate the assembly, part in solidity, because the commitment of solidity is that the assembly part
Alex (axic):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.
Tim Beiko:Charles.
Charles C (vyper):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
Charles C (vyper):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
Tim Beiko:I mean.
Charles C (vyper):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
Tim Beiko:all of the tooling should work. So I guess maybe this is the the other question is.
Tim Beiko:how confident are we that by doing the I believe, was version D of eof. The introspective one.
Tim Beiko:like the developer experience, will actually be
Tim Beiko:unaffected or good. It does seem like it took us quite some time to
Tim Beiko:Yeah, figure out the implications of this.
Tim Beiko: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.
Tim Beiko:in 3 months we're in the same situation.
Tim Beiko:yeah. And then I guess, yeah, maybe to answer point like.
Tim Beiko:how bad it is. How bad is it if we
Tim Beiko:only have Eos support in the developer experience, you know, sometime after Amsterdam.
Tim Beiko: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.
Tim Beiko: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.
Ben Adams: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
Ben Adams: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.
Tim Beiko:and then that would probably be the case, for, like.
Francis Li:I've seen.
Tim Beiko:Future!
Tim Beiko:Oh, sorry!
Francis Li:One second.
Tim Beiko:Oh, okay, I think you just got off
Tim Beiko:what? And I guess, okay, maybe the other thing is.
Tim Beiko: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.
Tim Beiko:but it yeah, is there
Tim Beiko: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 | Ipsilon: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.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon: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.
Danno Ferrin | Ipsilon:it's a discussion we have time to have.
Tim Beiko:Okay,
Tim Beiko:I guess, like, yeah.
gakonst:From there.
Tim Beiko:So yeah, go ahead.
gakonst: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
gakonst:basically what the 2 paths look like for us is either eof without the introspection bands.
gakonst:or given that we have the Charles Ap. Like, do swap, do? 17 to 32, and call it a day.
gakonst: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.
gakonst:you know, by tomorrow, probably.
Tim Beiko:Or I mean, okay. So if you think that's reasonable, then, like
Tim Beiko:on the testing call on Monday, we could be able to make a call on this
gakonst: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.
Tim Beiko:And then, I guess, does any team disagree with that. Does any team feel like they would need
Tim Beiko:one more time to research this, or
Tim Beiko:or already has, like a very strong opinion today that until it's the right path.
Tim Beiko:Okay? If that's the case, then let's move to the risk. 5 conversation. And then
Tim Beiko:and then, yeah, tentatively. Try to resolve this by Monday.
Tim Beiko: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
Tim Beiko:And then, do you know the number for Charles's eip Georgios off the top of your head.
Tim Beiko:or I guess we have Charles here. Oh, 7, 9 0, 7
Tim Beiko:seems to be something that the rest team would consider as an an alternative.
Tim Beiko:yeah.
Tim Beiko:so yeah, do client teams feel comfortable to like review this. And the impact on the developer experience and have a form view.
Tim Beiko:yeah, by Monday.
Ben Adams:I mean since somebody brought up push 0 the this
Ben Adams:an advantage of of eof over
Ben Adams:just a raw change to the evm is eof contracts will fail to deploy
Ben Adams:on like an L. 2 that hasn't got eof, whereas the
Ben Adams:adding the opcodes, the evm will deploy on L. 2, and then fail at Runtime.
Charles C (vyper):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.
Charles C (vyper):Awesome.
Danno Ferrin | Ipsilon: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.
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:okay, anything else on this specific issue before we move to risk 5.
Tim Beiko:Okay? Yeah, thanks. Everyone. I realize this is kind of a last minute curveball. But
Tim Beiko:it is what it is.
Tim Beiko:So yes. Next up like, client you wanted. You wanted to. Yeah, bring up the response issue.
lightclient:Yeah, I mean, I was just trying to gauge the sentiment from other client teams. Basically, there was a post from Vitalik
lightclient:talking about what we could imagine. The farther future of execution in ethereum looks like, and I think.
lightclient: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.
lightclient: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.
lightclient:you know, switching to a different execution substrate.
lightclient: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
Łukasz Rozmej: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.
Łukasz Rozmej:And the second one is potentially tapping to some
Łukasz Rozmej:broader tooling that we could use right. And and in ethereum.
Łukasz Rozmej:So, addressing those one by one performance improvements. I think we can get
Łukasz Rozmej: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
Łukasz Rozmej:there and do some kind of ahead of time compilation potentially.
Łukasz Rozmej: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.
Łukasz Rozmej:The problem is that it's just one big bytecode, and you emit tens of thousands of opcodes.
Łukasz Rozmej:And this is really like any compiler will just
Łukasz Rozmej: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.
Łukasz Rozmej:So that's 1 way of solving the performance thing that we can use. But it doesn't
Łukasz Rozmej:probably solve the tooling question. So the tooling actually goes the other way around. It makes the tooling away more complex
Łukasz Rozmej:rather than simpler, because we need to support this tooling.
Łukasz Rozmej: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
Łukasz Rozmej: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
Łukasz Rozmej:risk v bytecode. Or do we want to stay on a
Łukasz Rozmej:quite high, level, abstract domain focus, bytecode that we that we have full control of?
Łukasz Rozmej:That's that's the question for me.
Tim Beiko:Thanks.
Tim Beiko: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.
Andrew Ashikhmin:I don't know just an idea.
lightclient: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
lightclient: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: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.
Guillaume: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.
Guillaume:But I think it's the wrong reason to
Guillaume: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.
Guillaume:Okay, a lot might be exaggerated, but at least a couple
Guillaume:I don't know if risk 5 is really the perfect Isa for
Guillaume:for zk, zk applications. And I fear that doing.
Guillaume: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.
Guillaume:you know, give up on doing something that we could do now
Guillaume: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
Guillaume: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: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
lightclient: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:Hmm. Fair point.
Tim Beiko:I guess, to that point, though, like
Tim Beiko:what's the timeline on which this would happen? Because, like, you know.
Tim Beiko:ethereum is 10 years old now give or take, we're gonna change the the Vm. For like the 1st time significantly.
Tim Beiko:like. Do we expect this to ship risk 5 in like 3 years or 5 years, or farther than that.
Tim Beiko:And
Tim Beiko: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.
Tim Beiko:and that feels really hard to weigh again. Something we can ship in like 6 months.
Tim Beiko:as there'll probably be many other problems we have to deal between with between like now and when we do this. But.
lightclient: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
lightclient:compilers only focus on eof that there might have this
lightclient: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.
Tim Beiko:If it was like much closer to 2, I feel like I would agree.
Tim Beiko:if it's like much closer to 5. I feel like there's probably still value in doing this. But
Tim Beiko:yeah, I know you've had your hand up.
Danno Ferrin | Ipsilon:Yeah, so.
Tim Beiko:That's it.
Danno Ferrin | Ipsilon: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
Danno Ferrin | Ipsilon:the name of the current Hard Fork, and there's a lot of lessons that we should look and see why
Danno Ferrin | Ipsilon:you want them? Didn't ship and make sure that we don't repeat those same problems with Risk 5.
Danno Ferrin | Ipsilon: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
Dankrad Feist: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.
Dankrad Feist:Can you hear me.
Tim Beiko:And is the implication that like.
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:to risk 5 that, like some people, may have built tooling for it.
Tim Beiko:That then gets deprecated. But then, if metallic has this other comment, saying that we can
Tim Beiko:turn the Evm into a smart contract on Risk 5. I assume. That's also true of Eos versions of the Evm.
Tim Beiko:so that we would keep supporting that. So
Guillaume:I mean, it's gonna be a maintenance burden, right? Because we would have 3 versions of like 3
Guillaume: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
Tim Beiko:and legacy Evm. Regardless of which path we take. It seems like that decision was like broadly made.
Tim Beiko:But yeah, there will. Like.
Tim Beiko: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
Tim Beiko:the alternative path is, you just keep updating the legacy? Vm, forever. And then,
Tim Beiko:yeah, it seems like we were fine with 2 adding a 3rd
Tim Beiko:on a 5 year. Timeframe doesn't seem like
Tim Beiko:qualitatively different. But maybe that's wrong.
Tim Beiko:Yeah, I'm I don't. I guess.
Tim Beiko:Yeah, not to like
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:thing we should base the Eof decision on especially given the amount of certain uncertainty around. Risk 5.
Tim Beiko: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.
Vitalik Buterin:yeah, again, I get no. So the the thing that I was just types typing is
Vitalik Buterin:right? So the way that I think about risk 5 is I mean a couple of things right? So
Vitalik Buterin: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
Vitalik Buterin: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.
Vitalik Buterin:that have switched to it right? And you know, one interesting arguments that I heard actually is that there are
Vitalik Buterin: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.
Vitalik Buterin:and then the other thing is like it does sort of discipline us into ossification, which,
Vitalik Buterin:I think is a good thing in a lot of ways right? Like, I think if we arrest realistically, choose
Vitalik Buterin:risk 5 then like there would
Vitalik Buterin: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
Vitalik Buterin:like, I think if you add to, I know I saw, like python 2 and python 3 get brought up right. And
Vitalik Buterin: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.
Vitalik Buterin:so those are some arguments.
Vitalik Buterin:I guess I'm I'm just reading through questions. Will there be lots of precompiled
Vitalik Buterin:Cisco's? Add to with risk 5? I mean, I think
Vitalik Buterin: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
Vitalik Buterin:the yeah. And then the other type of like, Cisco would be
Vitalik Buterin: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
Vitalik Buterin:like, in general, a big part of the yeah ideas to try to
Vitalik Buterin:minimize the need like, or is to try to
Vitalik Buterin:basically change the Vm without changing everything else.
Vitalik Buterin:And so the yeah, like, you'd be able to interact with other contracts and based in exactly, yeah.
Vitalik Buterin: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
Vitalik Buterin:alright that that's probably the most natural way to do it.
Vitalik Buterin:is risk 5 more efficient. So
Vitalik Buterin:I think this is one other thing that, like, we need to start thinking about right, which is that
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin:sacrifice. And one of the
Vitalik Buterin: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
Vitalik Buterin:regular execution efficiency, which seems
Vitalik Buterin:they're like. Likely, though I think that's something that we should explicitly evaluate. Then, that's like
Vitalik Buterin:something that we should take we should take into account.
Vitalik Buterin: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
Kevaundray Wedderburn: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
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin:efficiency increase. So like. That's the part that I feel
Vitalik Buterin: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
Vitalik Buterin: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,
Vitalik Buterin: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
Vitalik Buterin: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?
Vitalik Buterin: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
Vitalik Buterin: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.
Vitalik Buterin:And the yeah, like
Vitalik Buterin: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.
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin:in the short term, right? So like, I think there are.
Vitalik Buterin: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.
Tim Beiko: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
Łukasz Rozmej: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
Łukasz Rozmej: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
Vitalik Buterin: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
Vitalik Buterin:benefits that are to risk 5 that are not just speed, but rather devx. And
Vitalik Buterin:3 is that.
Vitalik Buterin:The yeah. Like.
Vitalik Buterin: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
Vitalik Buterin: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
Vitalik Buterin: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
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:I guess, with that second path I'm not sure, like, what is the thing
Tim Beiko:that we could learn in the next, say 4 weeks.
Tim Beiko:and give us confidence about this decision like it seems like there's many of these
Tim Beiko:uncertainties that are kind of evolving over like months to year timeframes. But are there specific questions that
Tim Beiko:you know? People feel that if we spend 4 weeks, you know, focusing on this, we would actually.
Tim Beiko:we would actually learn that.
Tim Beiko: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
Tim Beiko:is is is quite high.
Tim Beiko: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
Tim Beiko:yeah, Eof, specifically, not just the entire risk. 5 thing like
Tim Beiko:we need to make this decision. I think we could probably delay it
Tim Beiko:a few weeks. If it was, if we would like learn something quite important in that process. And
Tim Beiko: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?
Tim Beiko:yeah, okay, okay, so it seems like,
Tim Beiko:okay, so it seems like, we effectively don't want a couple of those decisions. If that's
Tim Beiko:the case that I would still say.
lightclient:I think we should. I think we should consider that in the discussion they're totally related.
lightclient:It's not possible to think about them in isolation.
Charles C (vyper):Yeah, it. It's like not free to ship either of these.
Tim Beiko:Correct. So I guess. Okay. But then.
Tim Beiko:independent of risk, 5 like, you know.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko: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.
Tim Beiko:People will have their opinions set on this at a high level
Tim Beiko:And then, like I would lean towards making a call on Monday about
Tim Beiko: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
Tim Beiko:and then
Tim Beiko: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
Tim Beiko:evm improvements in this fork.
Tim Beiko:but I don't think we need to couple this with risk. 5. Beyond saying
Tim Beiko: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: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.
lightclient: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.
Tim Beiko:we should be mindful that
Tim Beiko: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.
Tim Beiko:But yeah, if we, if we think like, the general uncertainty independent of risk, 5
Tim Beiko:is is is too big. Then we can decide to not change anything. And
Tim Beiko:but that should be the thing we we decide. Yeah.
Dan Cline:Yeah, I think. Well, like risk 5 like is.
Dan Cline:you know, relevant to to the conversation like it's it's very possible we don't learn much
Dan Cline: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
Tim Beiko:we should make it. Oh, sorry. On Monday's testing call we make a final call about the Fussaka scope for eof
Tim Beiko: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
Tim Beiko: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?
Tim Beiko:And yeah, Justin, just to be really clear, like I,
Tim Beiko:there is a pure research idea.
Tim Beiko:you know, there's some chance that it actually happens.
Tim Beiko:There's some chance that some version of it happens, or some chance that something completely different happens in 5 years. And then
Tim Beiko:assuming something were to happen like, Is that
Tim Beiko:yeah, it it. Does that change your decision?
Justin Florentine (Besu):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.
Tim Beiko:If if you know that you're gonna have to add this.
Tim Beiko:call it risk. 5. Ask thing in 5 years does do an Eof today make a difference.
Tim Beiko:Yeah?
Tim Beiko:And if not, that's fine, like, I think one argument is like it
Tim Beiko: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
Tim Beiko:to the extent it does.
Tim Beiko:Then, yeah, maybe having like less.
Tim Beiko:like, yeah, maybe you want to keep a separate evm. Now, yeah.
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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,
Tim Beiko: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
Tim Beiko: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.
Tim Beiko: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
Tim Beiko:moving something like this into Fusaka.
Tim Beiko:and okay, that's just into the point. Specifically, the thing that the eip is saying, like, we don't need one.
Tim Beiko: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.
Tim Beiko: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
Ben Adams:after the after the after the chain moved to 36 million. Basically
Ben Adams:45% of it, hasn't we moved
Ben Adams:past 30 million. So it'd be good to get people a commitment from
Ben Adams:Cls and Els that they will change their defaults
Ben Adams:to to be the new hire level.
MariusVanDerWijden: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
Dan Cline:yeah, I mean it. Like, I agree that it's like,
Dan Cline:I mean doesn't really specify much right now. But like, I think that's okay.
Dan Cline:Can serve as like a
Dan Cline:important process document. For now, if anything having a vip like
Dan Cline:not actually specify things is kind of nice, because it
Dan Cline: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
Tim Beiko: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.
Tim Beiko:Related to this one other proposal. That's
Tim Beiko: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.
Tim Beiko: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
Ben Adams:So the Cls went gossip a block larger than including the Cl. Part larger than 10 MB.
Ben Adams:So, since you can do a block 0, even with the change in Petra
Ben Adams:of all Zeros that would put the cap safe cap at a hundred mega gas.
Ben Adams:The inverse. If it's not zeros
Ben Adams:these. The cap is like 400 million gas.
Ben Adams:Just based on the bite size. So if we put a cap of 10 MB minus some margin
Ben Adams:on block building and say, it's an invalid block if it goes over that size.
Ben Adams:Then we no longer have to consider cool data.
Ben Adams:going over that size when building blocks, so we can put more execution.
Ben Adams:And have a higher gas limit than a hundred 1 million. So, for instance, we could do
Ben Adams:the 150, which was the original suggestion for the default change to investigate.
Ben Adams:We can do that if we put a cap on the byte side.
Ben Adams:But it it's unsafe if we don't cap by type.
Ben Adams:because there is an inherent cap in the Cl.
Tim Beiko:Great
Tim Beiko: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
Tim Beiko: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
Tim Beiko: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.
Tim Beiko:yeah,
Tim Beiko: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.
Tim Beiko: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
Piper Merriam: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
Piper Merriam:what is changing in their clients. And there's a link on the Pm. Repo for the meeting today. Of the
Piper Merriam: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
Tim Beiko: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.
Tim Beiko:Okay, so no base suit. No, never mind. No guests.
Tim Beiko:Okay.
Tim Beiko: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?
Tim Beiko: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?
Tim Beiko: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.
Piper Merriam: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
Tim Beiko:people want to cover.
Tim Beiko: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.
Tim Beiko:Yeah, thanks a lot. Everyone.
stokes:Thank you.
Julian Sutherland (Nethermind):Thank you.
MariusVanDerWijden:Bye, everyone thanks you, but.
Orest Tarasiuk (t1):Thank you. Bye, guys.
Chat Logs
00:02:56
Tim Beiko:https://blog.ethereum.org/2025/04/23/pectra-mainnet
00:05:32
Gary Schulte:sorry IDK why zoom is randomly unmuting me lately
00:06:20
Fredrik:Replying to "sorry IDK why zoom i..."
have had the same when using airpods, quite annoying
00:07:37
stokes:Maybe something like this?
"blobSchedule": {
"cancun": {
"timestamp": 1710338135,
"target": 3,
"max": 6,
"baseFeeUpdateFraction": 3338477
},
"prague": {
"timestamp": 1746612311,
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
},
"bpo1": {
"timestamp": 1740693335,
"target": 24,
"max": 48,
"baseFeeUpdateFraction": 5007716
},
"bpo2": {
"timestamp": 1743285335,
"target": 36,
"max": 56,
"baseFeeUpdateFraction": 5007716
},
...
}
00:07:50
stokes:https://discord.com/channels/595666850260713488/1360267444911865876/1360268491139190895
00:07:55
stokes:^ thread here
00:08:47
Danno Ferrin | Ipsilon:I like the code names of bpos being just numbers and not regular names. We can give them fun names outside of the config files.
00:10:36
Barnabas:don’t worry about us lol, we just gotta hack together some json
00:10:47
Gajinder Singh:yes makes sense
00:10:57
MariusVanDerWijden:But we need the timestamp anyway in the fork schedule
00:11:07
MariusVanDerWijden:So this would duplicate it
00:11:14
Tim Beiko:"blobSchedule": {
"cancun": {
"target": 3,
"max": 6,
"baseFeeUpdateFraction": 3338477
},
"prague": {
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
},
"1740693335": {
"target": 24,
"max": 48,
"baseFeeUpdateFraction": 5007716
},
"1743285335": {
"target": 36,
"max": 56,
"baseFeeUpdateFraction": 5007716
}
}
00:11:15
MariusVanDerWijden:(for us)
00:12:02
lightclient:no fun names?
00:12:14
Ben Adams:could find some small town names?
00:12:18
Barnabas:Replying to "no fun names?"
bikeshed#1
00:12:23
Barnabas:Replying to "no fun names?"
bikeshed#2
00:12:29
Dan Cline:Yes would be great to specify in the eip that for example the "normal" chainconfig would add a fork and timestamp. Timestamp in blob param config would also be redundant for us, but not really concerned about that tbh. Bpo1 etc or fun names seems fine to me
00:12:35
FLCL:minecraft flowers
00:12:46
Gajinder Singh:bpo1 bpo2 is just fine
00:12:49
Felix (Geth):Convert timestamp to mnemonics, done
00:13:42
Ben Adams:Ethereum 4 hardforks a year? 🔥😉
00:14:28
Parithosh Jayanthi:The idea behind staggering them is to give us time to halt a future BPO in case we notice degradation that’s unexecpted
00:14:56
Parithosh Jayanthi:Replying to "Ethereum 4 hardforks..."
Hitting my KPIs for sure
00:15:07
Barnabas:it wouldn’t be an emergency hard fork, thats wrong wording imo
00:15:33
stokes:BPO downshift
00:15:34
nixo:BPO intervention
00:16:04
Barnabas:Replying to "BPO downshift"
or upshift
00:16:13
Ansgar Dietrichs:Replying to "BPO intervention"
BPOPO - BPO Parameter Only fork :-)
00:16:15
Barnabas:Replying to "BPO downshift"
we don’t know if we are too conservative…
00:16:31
Carl Beekhuizen:Replying to "BPO downshift"
BPO rev-match
00:16:45
Carl Beekhuizen:Replying to "BPO downshift"
gotta hit that perfect shift
00:17:34
Danno Ferrin | Ipsilon:I’ll start status. Should ben take the compiler change? RISK-V - TBD
00:17:42
MariusVanDerWijden:I spent a week updating our implementation to eof-devnet-1 spec, now y'all want to switch again 😢
00:17:54
Justin Florentine (Besu):doesn't EOF facilitate adopting new approaches like RISCV
00:18:03
Barnabas:Replying to "I spent a week updat..."
typical EOF enjoyoor
00:18:17
Carl Beekhuizen:Replying to "no fun names?"
I prefer
bikeshed a
bikeshed b
00:18:40
Tim Beiko:We can call them BSO forks :-)
00:20:39
frangio:what do you mean you can't compile? can you be more specific?
00:20:40
MariusVanDerWijden:Will adding code/gas introspection not impact zk of eof?
00:20:53
Ansgar Dietrichs:we can’t deprecate introspection though once we ship it
00:21:17
lightclient:Replying to "Will adding code/gas..."
i figured the introspection is more about trying to make it so contracts dont break in the future when changes to the protocol happen?
00:21:20
Ansgar Dietrichs:Replying to "we can’t deprecate i..."
so yes we could ship yet another version without it, but then we’d have to maintain both versions of EOF forever
00:21:23
Barnabas:can any L2’s migrate to EOF?
00:21:40
Parithosh Jayanthi:Replying to "can any L2’s migrate..."
Can, but likely won’t due to tooling support lacking
00:21:53
Ansgar Dietrichs:isn’t it expected that legacy contracts will not be compiled for EOF? I assumed everything would have to be rewritten for EOF from scratch anyway, no?
00:21:56
Barnabas:Replying to "can any L2’s migrate..."
assuming all tooling supports EOF day 0.
00:21:57
frangio:is the proposal to enable EXTCODESIZE/COPY/HASH ?
00:22:01
Dustin:there is no "for now", though
00:22:09
Dustin:that's an illusion
00:22:12
frangio:Replying to "we can’t deprecate i..."
EOF would still not be introspectable afict
00:22:12
Ansgar Dietrichs:Replying to "isn’t it expected th..."
like, do we know whether audit results would carry over? seems dangerous to assume
00:22:30
Danno Ferrin | Ipsilon:I can speak to the “Option D” details
00:22:33
lightclient:Replying to "is the proposal to e..."
and gas introspection
00:22:49
Alex (axic):Contracts which rely on assembly-blocks usually need to be changed, as they escape the abstractions Solidity provides.
00:23:20
andrei:Replying to "isn’t it expected th..."
not from scratch, solidity mostly compiles the same code fine to EOF. incompatibility is on assembly level
00:23:21
Alex (axic):In Ipsilon we have rewritten some of the Solady features using EOF-specific features, and they are actually doable.
00:23:44
Richard Meissner:but the opcodes are only disabled for EOF contracts, right?
00:23:54
Alex (axic):Replying to "but the opcodes are ..."
yes
00:25:35
Richard Meissner:Replying to "but the opcodes are ..."
so the assumption is that the solc compiler supports compiling to the EOF format, but this requires that specific build in functions are not used, which is not the case for OZ, solady and so on. Do I understand this correctly?
00:25:37
Ansgar Dietrichs:didn’t we make a final decision on EOF scope already? I feel like this discussion is violating process - I think we should only reconsider EOF scope for either of:
client implementation issues
security concerns
major strategic reconsiderations
seems like these arguments are below that threshold. I think we need to be better at sticking to prior decisions here
00:25:51
frangio:this is not a new signal i raised this back in october 😭
00:25:53
Felix (Geth):Introspecting EOF lfg
00:25:57
Piper Merriam:Fixing the contracts seems like the path forward here
00:26:07
stokes:Replying to "didn’t we make a fin..."
I think the claim is around the last point
00:26:14
Alex (axic):Replying to "but the opcodes are ..."
Solady and OZ inline-assembly blocks need changes, as they escape the abstraction Solidity provides.
00:26:24
stokes:EOF as SFI’d now may imply a lot more work than we originally expected
00:26:38
Ansgar Dietrichs:Replying to "didn’t we make a fin..."
I think the RISC-V would amount to that, but not some questions around developer experience
00:26:41
Charles C (vyper):what about all the other concerns brought up whose implications weren't understood?
00:26:49
Ansgar Dietrichs:Replying to "didn’t we make a fin..."
(not saying those are not important, it is just too late now)
00:26:53
Ben Adams:Upstream hasn't moved far enough for us to drop them
00:26:59
lightclient:we have a lead of devex, why do we need to create a python 2 -> 3 moment and risk that?
00:28:01
Richard Meissner:Replying to "but the opcodes are ..."
Cool thanks this makes it clear
00:28:41
Vitalik Buterin:My view is the opposite 😄
I think this attitude of "removing things is a no no, but it's ok if things are added on top" is exactly what's driving ethereum toward ever-increasing complexity
00:28:58
Ansgar Dietrichs:the point is - if it really turns out we are making a mistake by not allowing introspection, we can determine this in due time, and ship a fix in glamsterdam. then worst case adoption was delayed by a few months.
if we make a mistake the other way around, we will be stuck with the consequences forever
00:29:37
frangio:the language here seems wrong? introspection will remain unavailable! the opcodes are "neutered"
00:30:02
Dustin:Replying to "the point is - if ..."
I don't have strong views/basis for views on EOF, but I strongly agree with this -- adding things back is vastly easier than removing them
00:30:21
Charles C (vyper):by the way, gas introspection is not even really banned, since you can trivially call a legacy contract "gas oracle"
00:30:57
frangio:Replying to "the point is - if it..."
we're already stuck with legacy. having these opcodes in eof will not make things any worse. the important bit is eof contracts will remain unintrospectable
00:31:05
MariusVanDerWijden:Why can this asm -> eof not be done in the compiler?
00:31:33
MariusVanDerWijden:Replying to "Why can this asm -..."
The way I understand it, a lot of the issues are because people are u gas() in asm
00:31:47
Alex (axic):Replying to "Why can this asm -> ..."
You mean transform legacy assembly opcodes to new ones? The entire point of the assembly block in Solidity is to give full control to the contract author. This would violate it.
00:32:04
Alex (axic):Replying to "Why can this asm -> ..."
However Ipsilon has already adjusted a lot of the features of Solady source code to work with EOF opcodes.
00:32:37
Alex (axic):Replying to "Why can this asm -> ..."
As a way to validate the claim that no feature of Solady becomes unavailable.
00:32:39
gakonst:Hey guys apologies I'm late. Dan i think shared our stance:
- no go w/o existing codebases compiling, remove the bans on things / remove txcreate bs
- if not feasible, given we have the Charles codesize EIP for codesize, consider the alternative proposals for stack too deep like swap17-32
The top mission is PeerDAS 2025. No compromises. Descoping things is fine.
00:32:49
lightclient:but the bigger issue is that we can’t remove EOF later if we decide to switch to RISC-V
00:33:10
frangio:is there a document about what is actually being proposed here? not clear what opcodes etc are at stake
00:33:23
Tim Beiko:@frangio https://notes.ethereum.org/@ipsilon/eof_fusaka_options#D---Introspecting-EOF2
00:33:56
Danno Ferrin | Ipsilon:I agree, peerdas deermines when the fork happens and what isn’t ready gets cut.
00:34:15
Ansgar Dietrichs:@gakonst do you currently see a risk that EL client readiness will be the blocker for peerdas?
00:34:34
gakonst:No
00:34:46
gakonst:But if I have fixed resources and I cannot test peerdas
00:35:01
gakonst:Bc people are testing things that should have been done on eof
00:35:07
gakonst:And we are racing for resources
00:35:15
gakonst:Then thats an issue
00:35:25
Ansgar Dietrichs:I think we all agree peerdas always has priority on testing resources
00:35:29
Richard Meissner:Replying to "I agree, peerdas dee..."
For EOF this means that one of the related EIPs is not ready, EOF should not be included at all, right?
00:35:29
gakonst:10x devops + testing budget plz
00:35:59
lightclient:even if it is easy, they need to audit it
00:36:19
Parithosh Jayanthi:Replying to "10x devops + testing..."
Thankfully we have two testing teams, pandaops is fully testing peerDAS and EF testing is fully looking into EOF
00:37:13
Danno Ferrin | Ipsilon:Replying to "10x devops + testing..."
And I will vouch that the skillsets of those teams are very well aligned for the features they are testing.
00:37:32
Łukasz Rozmej:@Alex (axic) how much effort was it?
00:37:34
Vitalik Buterin:Replying to "And we are racing fo..."
I'd say the bigger argument is that EL effort competes not with peerdas, but with glamsterdam L1 gas increase EIPs, which we ideally should be starting to go full force on ~now
00:37:43
lightclient:changing the source code is the issue though right?
00:38:21
MariusVanDerWijden:Charles chilling in the club rn
00:38:38
felix (eest):"they don't know im currently in ACD meeting"
00:39:04
Danno Ferrin | Ipsilon:The worst part about PUSH0 support is you don’t know it’s broken until you execute the relevant code path that triggers it.
00:39:06
Francis Li:curious why won't L2s have EOF?
00:39:11
Barnabas:Replying to "Charles chilling in ..."
EOF club
00:39:21
frangio:Replying to "curious why won't L2..."
it will just take longer
00:39:42
lightclient:while i think introspection is a major issue, we are hyper fixated on this EOF detail and not yet even discussing the fact that zk-vm teams would rather just have native RISC-V execution instead of dealing with EVM/EOF at all
00:39:47
Ahmad Bitar | Nethermind:What about tx create. This will still require changes
00:39:48
Ansgar Dietrichs:Would it be so bad if ecosystem adoption only really picks up after Glamsterdam? My feeling is we expect limited readiness at Fusaka anyway (especially say on L2s)? And in the meantime we would get valuable signal from early adopters on small Glamsterdam EOF tweaks that would be valuable. And can consider them in due time, rather than like here rushed last minute without sufficient context
00:40:01
Ahmad Bitar | Nethermind:Replying to "What about tx create..."
Regardless of gas introspection
00:40:06
Barnabas:very informal vote ( 👍 for pro EOF) ( 👎 for anti EOF) in fusaka
00:40:13
Francis Li:Replying to "curious why won't L2…"
so that's not an issue right? L2s will have maybe a little delay, but they'll be there, and this should relieve the concern of maintaining multiple versions?
00:40:23
stokes:Replying to "very informal vote (..."
I think we should clarify that this is in fusaka
00:40:23
Richard Meissner:Replying to "while i think intros..."
agree that it would make sense to touch on if EOF in the context of RISC-V is still the best approach
00:40:24
Ansgar Dietrichs:Replying to "while i think intros..."
these need to be two clearly separated conversations. if you want to ask to reopen the general EOF question, that should be separate
00:40:59
Richard Meissner:Replying to "while i think intros..."
yes, the point is more that this conversation needs to happen rather sooner than later (best right now) as far as I understood
00:41:52
Kevaundray Wedderburn:What would be the forcing function for contracts to upgrade to EOF?
00:42:04
frangio:a lag is the best case scenario. the worst case is for libraries to have to maintain separate codebases for legacy and eof. this is literally python2 -> 3 situation
00:42:10
stokes:Replying to "What would be the fo..."
Compiler support/defaults would be a natural one
00:42:17
Richard Meissner:Replying to "very informal vote (..."
For this it would be interesting if RISC-V is a viable alternative in the long run, and therefore it is ok to change the opinion on EOF
00:42:24
MariusVanDerWijden:Replying to "What would be the ..."
gas savings
00:42:41
lightclient:Replying to "a lag is the best ca..."
Guido has literally said if he could go back in time, he would never do 2->3 again
00:42:56
Charles C (vyper):Replying to "a lag is the best ..."
yes, we are going to maintain separate codebases for.. at least several years
00:42:57
lightclient:Replying to "a lag is the best ca..."
why can’t we learn from the mistake’s of others 😢
00:43:04
Łukasz Rozmej:risc-v discussion?
00:43:11
Kevaundray Wedderburn:Replying to "What would be the fo..."
And the main inertia would be around re-deploying and auditing my contract again?
00:43:15
MariusVanDerWijden:Replying to "a lag is the best ..."
Yep this will happen...
00:43:32
stokes:Replying to "What would be the fo..."
Why would existing stuff need to change?
00:43:48
Parithosh Jayanthi:Replying to "a lag is the best ca..."
Would this be the case with any version of EOF or just the currently proposed one?
00:43:57
lightclient:Replying to "What would be the fo..."
it’s the libraries people want to use
00:43:58
stokes:Replying to "What would be the fo..."
I would expect legacy stuff to stay, but new things to take advantage of EOF
00:44:14
stokes:Replying to "What would be the fo..."
But the existing deployments of the libraries don’t need to change
00:44:27
stokes:Replying to "What would be the fo..."
We would need to update the libraries for new stuff
00:44:33
Ansgar Dietrichs:what’s the best resource on the exact proposed change?
00:44:34
lightclient:Replying to "What would be the fo..."
we’re talking about libraries that are bundled in the binary
00:44:39
lightclient:Replying to "What would be the fo..."
which is how many libs are used
00:44:39
frangio:Replying to "a lag is the best ca..."
introspecting eof might not, need to review it
00:44:43
Barnabas:Replying to "What would be the fo..."
would still require maintaining two libraries, esp if there are patches
00:44:59
Tim Beiko:Replying to "what’s the best reso..."
https://notes.ethereum.org/@ipsilon/eof_fusaka_options#D---Introspecting-EOF2
00:45:01
stokes:Replying to "What would be the fo..."
Ya, this is the “py2->py3” argument
00:45:03
Tim Beiko:https://notes.ethereum.org/@ipsilon/eof_fusaka_options#D---Introspecting-EOF2
00:45:14
Charles C (vyper):7907
00:45:23
MariusVanDerWijden:Replying to "a lag is the best ..."
Any version, any substantial change with the evm imho. You would need to know the target chain when compiling your contract
00:45:41
Ansgar Dietrichs:Replying to "what’s the best reso..."
but e.g. Danno also mentioned implications for PAY, so clearly this is not comprehensive
00:46:13
Kevaundray Wedderburn:Replying to "What would be the fo..."
Is OZ willing to make the change if we ship EOF, as soon as possible?
00:46:21
Charles C (vyper):but the differences are more subtle. PUSH0 is simply instruction selection
00:46:21
Parithosh Jayanthi:Please add relevant EOF links to the interop testing call issue here: https://github.com/ethereum/pm/issues/1499
00:46:25
Ahmad Bitar | Nethermind:Replying to "a lag is the best ca..."
Why maintain the legacy contracts once you have the EOF version?
00:46:29
Danno Ferrin | Ipsilon:Replying to "what’s the best reso..."
Option D does not include PAY. I mntion PAY because it has value outside of EOF, but can move to other forks.
00:46:35
Richard Meissner:Replying to "7907"
7907 is confirmed to be shipped with fusaka?
00:47:10
Ansgar Dietrichs:Replying to "what’s the best reso..."
ah, my bad. thanks for the clarification
00:47:18
lightclient:Replying to "7907"
it’s CFI
00:47:21
frangio:a language or library should never expose PAY and CALL as the same function, it would be acase of a feature being available in eof and not in legacy and vice versa
00:47:36
Charles C (vyper):Replying to "a language or libr..."
hence, users need to maintain two versions of code
00:47:46
Charles C (vyper):Replying to "a lag is the best ..."
because mainnet is not the only EVM
00:47:50
Richard Meissner:Replying to "7907"
Gotta love news: https://www.binance.com/en/square/post/23264062999666
00:48:13
Ansgar Dietrichs:to clarify - would we also consider deciding to completely remove EOF on Monday?
00:48:24
frangio:Replying to "a language or librar..."
yes, true
00:48:36
Parithosh Jayanthi:Replying to "a lag is the best ca..."
And not every EVM will upgrade asap, so this migration would take ~years
00:48:41
gakonst:Yes IMO
00:48:50
Tim Beiko:Replying to "to clarify - would w..."
My sense from this conversation is that this would be unlikely, but I personally would only support descoping Fusaka, so removing EOF is one option here.
00:48:55
Kevaundray Wedderburn:I think I’d like some clarification on what the process is here for removing EOF (If we decide to do it)
00:49:28
Danno Ferrin | Ipsilon:Remember eWASM? Pepperidge Farm Remembers.
00:49:36
Barnabas:Please make sure every EL dev that cares or don’t care about EOF shows up to the monday call. Feel like its gonna be an important one.
00:50:11
Ansgar Dietrichs:feels like we are now talking about very uncertain long-term roadmap. this wasn’t really in discussion until a month ago, and might already no longer be an option anymore in a few more months. not a good basis for short term decisions imo.
00:50:11
Dustin:Replying to "Remember eWASM? P..."
people benchmarked it at the time and published stuff to arxiv etc and apparently it wasn't much faster.
also people were concerned about JITs etc
00:50:12
Tim Beiko:Replying to "Please make sure eve..."
Again, here’s the link: https://github.com/ethereum/pm/issues/1499 😄
00:50:22
gakonst:https://github.com/r55-eth/r55 I g2g but this is a project I've been co maintaining with Leo Alt. I think it can get us to really good devex, vs Solana devex which is bad. I encourage people to dive in.
00:50:48
Dustin:Replying to "Remember eWASM? P..."
i.e. some of the ecosystem advantages were hard to take advantage of in Ethereum because if someone hit some optimization thing that took O(n^2) time, oops
00:50:51
gakonst:It's a dual RiscV / EVM runtime where we alrd demonstrars EVM / r5 interop / xcontract calls
00:51:01
Barnabas:Replying to "feels like we are no..."
EOF shouldn’t be a short term decision.
00:51:03
gakonst:The removal of EOF should be evaluated in a vacuum imo
00:51:13
Barnabas:Replying to "feels like we are no..."
its going to affect the whole Ethereum ecosystem forever.
00:51:30
Sophia Gold:Replying to "Remember eWASM? P..."
We should view this through that lens tbh. It's not totally clear RISC-V will be the standard for zkVMs in five years
00:53:04
lightclient:right - but we should decide this before a new version of our high level bytecode?
00:53:21
Ansgar Dietrichs:right. but we have been talking about EOF for over 2 years. now that we just had a final decision, we are bringing up all of these from-the-hip roadmap ideas. seems very bad process
00:53:37
Alex (axic):RISC-V has a large number of variants (between register size and various features). Do we know which variant is being proposed and what kind of complexity we are talking about?
00:54:03
Vitalik Buterin:Replying to "RISC-V has a large n..."
I'd say this is still TBD
00:54:12
ethDreamer (Mark):Bad process yes.. but we’re also at a pivotal moment in development right now, which is what I think is driving the process issues
00:54:44
Tim Beiko:What is the absolute shortest timeline on which something like this could happen?
00:54:46
William Morriss:does the risc-v proposal spec gas?
00:54:56
Dan Cline:It's not just a "which vm" or "we can just implement riscv5" issue right? It's toolchain as well (contract language syntax, IR, precompiles, metering), imo comms with teams that actually are implementing riscv/wasm zkvms on what works well and what doesn't here is crucial
00:55:11
ethDreamer (Mark):Replying to "feels like we are no..."
I still think lightclient’s concerns are valid. Is it possible to continue on our current path but accelerate the evaluation of this proposal so we can make a better decision later?
00:55:16
lightclient:risc-v, wasm, etc, it’s not about the specific ISA
00:55:19
Sophia Gold:Traditional execution will be slower, it won't solve our compiler ecosystem problems, altVMs don't have much traction, and there are zkVM teams using other ISAs because RISC-V is actually not ideal for proving. This may be the right direction to go, but best to wait and see imo
00:55:19
Alex (axic):Replying to "does the risc-v prop..."
Ethereum abstractions are not part of RISCV, i.e. gas or state interaction. There’s a “syscall” to implement these abstractions over.
00:55:32
lightclient:Replying to "risc-v, wasm, etc, i..."
the issue is that people aren’t saying it’s EOF
00:55:33
Łukasz Rozmej:switch zk-VM's to EVM bytecode?
00:55:57
Paweł Bylica:Every commit of evmone is build and executed on riscv32. https://github.com/ethereum/evmone/blob/master/circle.yml#L658-L666
00:56:02
Ansgar Dietrichs:Replying to "feels like we are no..."
fair. but like, then we need to get serious about it. not just acd vibe discussion.
have a defined emergency future-of-EVM breakout process. say we make a final go/no-go decision on EOF in 4 weeks. have an active fasttracked process between now and then to really dive deep on how realistic a near-term VM change like RISC-V is.
00:56:41
William Morriss:Replying to "does the risc-v prop..."
gas can't be done with a syscall
00:56:48
lightclient:people are telling me real time proving this year
00:56:50
Vitalik Buterin:Replying to "does the risc-v prop..."
just count cycles?
00:56:55
Ansgar Dietrichs:Replying to "feels like we are no..."
this is a massive research investigation though. usually ideas like that evolve on the timespan of years. so having a mature understanding in 4 weeks would be very ambitious
00:57:02
Vitalik Buterin:when I wrote the post I had in mind was like 2-5 years
00:57:06
Alex (axic):Replying to "does the risc-v prop..."
Gas would need to be implemented in the “interpreter” or injected. Just like it was done in ewasm or https://github.com/wasmx/fizzy
00:57:31
stokes:Replying to "people are telling m..."
Different from the point at which we would be comfortable with protocol inclusion
00:57:38
Charles C (vyper):fwiw -- if you want compiler and related tooling to get better, we need a stable ISA, not a new target every 3 years
00:57:57
Dankrad Feist:Replying to "feels like we are no..."
agreed at commingling very long term research with short term decisions
00:58:06
Felix (Geth):It won't be end-of-life
00:58:30
Dankrad Feist:Replying to "feels like we are no..."
also given proving is now 15 cents per block, proving is simply not going to be the bottleneck
00:58:47
lightclient:potential for EOF being out python 2->3 moment + we know EOF isn’t the endgame......
00:58:49
Felix (Geth):Even if we enable support for RISCV, we would still support EVM for a long time
00:58:54
iPhone - Radek:We don’t know if it’s doable but we assume that it will happen in up to 5 years.
00:59:07
lightclient:Replying to "potential for EOF be..."
i don’t see what there is to debate, it seems like we aren’t ready to make this change
00:59:10
Felix (Geth):So any work for converting contracts to EOF will be worth it
00:59:22
Vitalik Buterin:Replying to "Even if we enable su..."
the deprecation path for EVM would be to turn it into a smart contract on RISCV, so it would remain available to devs forever
01:00:10
Richard Meissner:is adopting EOF now a blocker for RISC-V?
01:00:17
Ansgar Dietrichs:Replying to "is adopting EOF now ..."
no
01:00:45
Vitalik Buterin:Replying to "Even if we enable su..."
yeah it's also true for EOF
01:00:53
lightclient:we have to always keep supporting it
01:00:55
Ansgar Dietrichs:Replying to "is adopting EOF now ..."
and I don’t understand why “but we have to maintain EOF forever” is a new argument now - this was already a known cost to shipping EOF
01:00:56
lightclient:everything
01:01:15
lightclient:Replying to "is adopting EOF now ..."
but EOF was supposed to be the endgame
01:01:20
lightclient:Replying to "is adopting EOF now ..."
the final version
01:01:31
Parithosh Jayanthi:Replying to "is adopting EOF now ..."
Hasn’t this been an argument that the geth team has been proposing for a while now? i.e, that we need to support 2 EVMs forever
01:01:56
Ansgar Dietrichs:Replying to "is adopting EOF now ..."
yes, but we heard that concern and then made the decision pro EOF anyway
01:02:01
Ahmad Bitar | Nethermind:Isnt the idea of version number in EOF is to support multiple versions of EVM?
01:02:36
Vitalik Buterin:I think the way that riscv (or other vm, eg. cairo) changes EOF discussions is:
It's not EOF vs nothing, it's EOF vs (contract code size increase + swap32). And a big part of the argument for EOF was future-proofness. But if the future-proofness strategy is to ossify RISCV, then that changes things
01:02:38
Dan Cline:Replying to "is adopting EOF now ..."
Still needs toolchain implementation and maintenance for the new vm
01:03:13
Ansgar Dietrichs:Replying to "I think the way that..."
so overall you would prefer dropping EOF?
01:03:16
Charles C (vyper):btw we don't even need swap32 :) we need to fix the memory model
01:05:00
lightclient:we need a stable and credible development platform as soon as possible
01:05:05
Charles C (vyper):Replying to "btw we don't even ..."
https://eips.ethereum.org/EIPS/eip-7923
01:05:20
Ben Adams:will be lots of "precompile" syscalls instead with riscv?
01:05:44
Danno Ferrin | Ipsilon:Replying to "we need a stable and..."
I view imemidate ossification as the real competitive alternative to EOF.
01:06:09
Kevaundray Wedderburn:Replying to "will be lots of "pre..."
And metering
01:06:38
Gajinder Singh:to apply gas which is basic EVM construct, we will need to dev/maintain our own interpreters?
01:06:39
sina:Replying to "will be lots of "pre..."
Possibly also big int arithmetic
01:06:41
Danno Ferrin | Ipsilon:Replying to "we need a stable and..."
every new addition is a precompile or system call, mostly for consensus data.
01:06:47
SanLeo:Going from Legacy EVM to EOF to RiscV in the span of a few years wouldn't exactly spur great confidence for newcomers
01:07:19
stokes:Replying to "we need a stable and..."
The migration to riscv would be backwards compatible with legacy and EOF tho
01:07:22
Ben Adams:Is RISCV more efficient if you are running it on x64 though?
01:07:30
Danno Ferrin | Ipsilon:Replying to "to apply gas which i..."
cycle count looks like a top analogue to gas, others would be ZK proof size / zk circuit count.
01:07:56
lightclient:Replying to "we need a stable and..."
i think the cost matters a lot here
01:08:04
Łukasz Rozmej:How would "normal" execution look like? Risc-v interpeter? Compilation to x64?
01:08:06
Charles C (vyper):haven't multiple zk teams looked at this problem as well, and several custom ISAs were developed as opposed to risc-v (which was also a strategy that was taken by a couple teams)
01:08:06
Kevaundray Wedderburn:At what level of conviction is this at?
We need to change the EVM to a more traditional architecture like RISCV/WASM
We need to change to RISCV
01:08:23
Ansgar Dietrichs:okay so if we really want to seriously reconsider EOF, what’s the process? Decide on Monday? Breakout to study the RISC-V (or similar) roadmap feasibility in more depth?
If we consider completely pulling EOF here, we need to today agree on a final decision process.
And then stick to it for good.
01:09:00
Dan Cline:Replying to "At what level of con..."
IMO first option is how we should be thinking about this problem
01:09:06
stokes:Replying to "okay so if we really..."
We decide monday
01:09:17
Gajinder Singh:Replying to "to apply gas which i..."
proving is separate from execution i think and is always gonna be because bare execution will always be fast
01:09:41
Ansgar Dietrichs:Replying to "okay so if we really..."
my concern is a decision on Monday would not be fully informed. I would prefer the breakout approach.
Happy to be overruled ofc.
01:10:01
Gajinder Singh:Replying to "to apply gas which i..."
(think block production)
01:10:07
Tim Beiko:Replying to "okay so if we really..."
The breakouts are almost an implicit way of removing EOF, though
01:10:10
ethDreamer (Mark):Replying to "okay so if we really..."
Agree with breakout approach as it seems we need more time to evaluate
01:10:24
Tim Beiko:Replying to "okay so if we really..."
If we spend 4 weeks researching this, then we’ll delay EOF 4 weeks, then maybe it’s not ready for Fusaka
01:10:38
Ansgar Dietrichs:Replying to "okay so if we really..."
no, the idea is we continue as-is, assuming EOF goes in ofc
01:10:55
MariusVanDerWijden:Remote Code Execution in the EVM lfg 🚀
01:11:01
Francesco:Replying to "okay so if we really..."
If we get there, would we put it in a fusaka-devnet-1 while still going through this process?
01:11:08
Ansgar Dietrichs:Replying to "okay so if we really..."
yes
01:11:16
Sophia Gold:Right now it seems similar to enshrining the wrong prime field. Many zk teams are using zk specific ISAs like Cairo or newer ones
01:11:26
Parithosh Jayanthi:Replying to "Remote Code Executio..."
You bet we’re gonna run kurtosis inside the evm
01:11:27
Tim Beiko:Continue with EOF, RISC-V “research sprint” and then decide EOF/no-EOF based on this in “a few weeks?
01:11:45
Ansgar Dietrichs:Replying to "okay so if we really..."
I would say have a final fusaka spec freeze by end of may
01:11:51
Barnabas:looking from the point of view of someone that is neither pro or con EOF (try to handle it as a black box) I feel like we are still at the same stage at EOF discussions as we were when I joined EF. (Which doesn’t give me much confidence that its a feature we actually need).
01:12:22
Cody Gunton:There is a revolution in the sort of hardware people have in their hands and on there desks happening right now. Isn’t there a good chance some other GPU/NPU focused assembly language becomes the obviously better thing within 5 years?
01:12:30
ethDreamer (Mark):Replying to "okay so if we really..."
I agree on the need for process improvements, I just also want to point out that the process at this point will likely be disorganized because we are pivoting hard right now
01:12:32
Nicolas Consigny:Would not hurt to have some diversity at this level and keeping Cairo around seems like a low effort high potential thing
01:12:54
lightclient:can still fix stack too deep issue with this https://github.com/ethereum/EIPs/pull/9501
01:13:23
Charles C (vyper):vyper still doesn't have stack too deep 😭
01:13:49
Ansgar Dietrichs:so main decision for today: we decide the fate of EOF:
a) on Monday, based on the comments today
b) in 4 weeks, based on a “research sprint” on RISC-V
01:14:21
Tim Beiko:Replying to "so main decision for..."
How confident are we that (b) actually gives us the data we need?
01:14:53
Richard Meissner:Replying to "so main decision for..."
It would require strong ownership of some team, right?
01:14:57
Ansgar Dietrichs:Replying to "so main decision for..."
4 weeks needs to be enough. I think with proper effort it will be.
01:15:12
SanLeo:RiscV hardware already exists if anyone is unaware, still early days though
01:15:21
Barnabas:Replying to "RiscV hardware alrea..."
they are a POS tho
01:15:35
Dan Cline:Replying to "There is a revolutio..."
I don't think so, CPUs are still best for a lot of things, the hardware for parallel / certain SIMD ops are where the improvement is happening. This is only applicable to a subset of things you would want to do, a subset that I'm not sure intersects with what people want to do on eth
01:15:46
Gajinder Singh:Replying to "RiscV hardware alrea..."
very underwhelming hardware
01:15:51
Parithosh Jayanthi:Replying to "RiscV hardware alrea..."
Yeah its extremely unreliable and hard to use hardware + tooling -> especially compared to arm/x86
01:16:29
Orest Tarasiuk (t1):Replying to "so main decision for..."
So soon™
01:16:44
Ansgar Dietrichs:with EWASM, adding metering logic was hard if I remember correctly - how easy is that with RISC-V?
(sorry if already answered)
01:16:47
Guillaume:Replying to "RiscV hardware alrea..."
For me it doesn't break more than arm/amd64 😆
01:16:50
Richard Meissner:Replying to "RiscV hardware alrea..."
China is actively investing into this 😛 so chances are high that this will improve
01:17:02
Alex (axic):Replying to "with EWASM, adding m..."
Nothing is “hard”. Same problems apply to riscv.
01:17:13
Łukasz Rozmej:Replying to "RiscV hardware alrea..."
Yeah like 25% performance of Raspberry Pi
01:17:26
Alex (axic):Replying to "with EWASM, adding m..."
One can inject code to measure around each instruction or block. Or one can write a custom interpreter/compiler which does it.
01:17:30
Gajinder Singh:Replying to "with EWASM, adding m..."
hard = money required
01:17:47
Cody Gunton:Eli Ben-Sasson says it’s going to be weeks before he provides feedback on this VM vision
01:18:03
Kevaundray Wedderburn:Four weeks is not enough imo
01:18:13
Vitalik Buterin:We would benefit from a research period of a few months, particularly to answer with more finality the question of riscv vs custom prover-oriented vm
though that's obviously too late to decide eof fusaka params
01:18:15
Ansgar Dietrichs:one big benefit of the 4 week project would be that we can then decide whether to launch a risc-v manhattan project coming out of it, to ship it
01:18:30
Barnabas:could we make a decision on EOF independent of study?
01:18:40
Dankrad Feist:the history on architecture upgrades like this is really poor. and that's even without having immutable smart contracts
01:19:05
Sophia Gold:We would effectively be deciding to kill some zkEVMs at what imo is too early a stage. We should decide EOF on merit separate of this
01:19:06
Kevaundray Wedderburn:I don’t think we should delay and evaluate EOF in a vacuum
01:19:08
Dan Cline:Yeah seems like a mistake to hinge our decision of eof on a decision wrt riscv / zkvm
01:19:10
Charles C (vyper):Replying to "could we make a de..."
please don't make us ship EOF, then ship another architecture 😭
01:19:16
Dankrad Feist:even if we solve all the technical problems it may well have a 20% chance of success
01:19:20
Ansgar Dietrichs:Replying to "could we make a deci..."
decision based on what?
01:19:35
Gajinder Singh:Replying to "could we make a deci..."
same issue as verkle vs post quantum transition
01:19:38
Vitalik Buterin:imo no need to start a riscv manhattan project in 4 weeks, 4 months is fine
in the meantime we can put a lot of effort on optimizing the glam short-term L1 scaling eips, that stuff is higher urgency anyway
01:19:42
Ansgar Dietrichs:so then how do we decide on Monday?
01:20:05
Ansgar Dietrichs:Replying to "imo no need to start..."
but how do we decide whether to remove EOF then?
01:20:06
Kevaundray Wedderburn:Replying to "imo no need to start..."
But then what happens to eof?
01:20:10
Richard Meissner:Replying to "imo no need to start..."
this implies that EOF should not be part of Fusaka, right?
01:20:35
Parithosh Jayanthi:Can ACD also decide what we exactly need to discuss on Monday and decide?
01:20:51
stokes:Replying to "Can ACD also decide ..."
Including EOF in Fusaka or not
01:20:51
lightclient:the thing that is most clear is we don’t know the best way to get ZKP in L1, which is a major EL goal
01:20:53
Parithosh Jayanthi:I.e what form of EOF to ship? Or IF eof is shipped
01:20:58
SanLeo:Replying to "so then how do we ..."
VRF
01:20:59
Ansgar Dietrichs:one (obvious) point: this is the last hardfork with free EL space - from glamsterdam on, focus will be on scaling.
So EOF not in Fusaka likely means no EOF ever
01:21:04
stokes:Replying to "I.e what form of EOF..."
More the latter
01:21:12
stokes:Replying to "I.e what form of EOF..."
Seems like we have a good handle on former question
01:21:18
lightclient:Replying to "the thing that is mo..."
which i think means we should not push forward with EOF because it will be extremely expensive for the community
01:21:28
Parithosh Jayanthi:Can client teams also update async team positions if they have one before Monday? It would help us prep a bit
01:21:33
Kevaundray Wedderburn:Are people okay with living in a world where we have EOF and then five years later RISCV?
01:21:44
Ansgar Dietrichs:clarification question: this risc-v conversation would be irrelevant to shipping an alternative EOF version, right?
01:21:47
Barnabas:why maintain one library when you could maintain 3 libraries :D
01:21:51
frangio:bring back incremental eof
01:22:07
Mario Vega:Replying to "Can client teams als..."
Please comment these on here: https://github.com/ethereum/pm/issues/1499
01:22:13
stokes:Replying to "clarification questi..."
I would say no
01:22:25
lightclient:Replying to "Are people okay with..."
no
01:22:31
stokes:Replying to "clarification questi..."
The meta question is what target we should ultimately be heading towards
01:22:33
Ansgar Dietrichs:somewhat insane question - is there maybe one glamsterdam EL candidate feature that could conceivably be pulled into fusaka to replace EOF?
01:22:56
MariusVanDerWijden:Replying to "somewhat insane qu..."
no, we need time to work on client improvements
01:23:07
Łukasz Rozmej:Replying to "the thing that is mo..."
You can come to totally opposite conclusion based on the first statement too: that you shouldn't delay scheduled upgrades based on far future things that might not come to be :D
01:23:10
Tim Beiko:Replying to "somewhat insane ques..."
Yeah, I would not extend the CFI list, especially given the gas limit increases
01:23:10
stokes:Replying to "clarification questi..."
We could do no EOF, the other EIPs for contract size and stack issues; and then one day have a single EVM interpreter for -some_ zk ISA
01:23:19
Francesco:Replying to "somewhat insane ques..."
Nah we can just keep it to gas limit increases
01:23:31
Parithosh Jayanthi:Replying to "somewhat insane ques..."
And probably spend time prototyping stuff
01:23:39
Justin Florentine (Besu):i'm really not sure how to compare something that is a pure research idea to an already engineered and being tested alternative
01:23:42
lightclient:Replying to "the thing that is mo..."
i agree with this for protocol changes that don’t impact users much, but i disagree for things that substantially change user space
01:23:43
Barnabas:Replying to "somewhat insane ques..."
gas limit increase + history expiry will give enough work for ELs anyway
01:23:53
ethDreamer (Mark):Can we at least comb through the idea to see if there’s anything that would obviously kill RISC-V?
01:24:01
Ansgar Dietrichs:“something of that magnitude eventually” is not an update though, that was always an option.
risc-v in 2 years would be a huge update
01:24:35
Tim Beiko:Replying to "“something of that m..."
Right, I don’t think we’ve had this update?
01:24:50
Ansgar Dietrichs:Replying to "“something of that m..."
sounds like some people think that is now a possibility
01:24:54
Gajinder Singh:the question is all we all sold on EOF benefits in short term (and concretely), so is EOF a 10X feature?
01:24:58
Ben Adams:Should we move on to other points?
01:25:25
Ahmad Bitar | Nethermind:Irrelevant point: Building risc-V interpretors in 5 different languages will be interesting
01:25:30
Tim Beiko:https://github.com/ethereum/EIPs/pull/9678
01:25:32
Justin Florentine (Besu):maybe RiscV is inside an EOF v2 container and this is all moot
01:25:37
lightclient:Replying to "the question is all ..."
we can just get the major benefits like bigger code and fixing stack too deep w/o EOF
01:25:59
lightclient:Replying to "maybe RiscV is insid..."
no it’s about arch that the prover is executing on for zkp
01:26:09
Gary Schulte:Replying to "maybe RiscV is insid..."
is risc-v-like change in a few years a foregone conclusion? zkevm’s exist currently. It isn’t clear to me that we have to make this kind of VM rewrite, tooling rewrites, etc
01:26:13
Łukasz Rozmej:If we need to suport EVM bytecode in risc-v by some kind of interpreter, what prevents us from taking existing EVM implementation and compiling it to risc-v. If it has EOF or not then is just a minor difference?
01:26:20
Gajinder Singh:Replying to "the question is all ..."
so lets do that and then evaluate if we need EOF
01:26:32
Ahmad Bitar | Nethermind:Replying to "maybe RiscV is insid..."
Even risc-v bytecode can have a container structure
01:26:49
lightclient:Replying to "maybe RiscV is insid..."
AFAIK zk-evm is basically dead for now and everyone is focusing on ZK-VM where they compile EVM interpreter to RISC-V or the like
01:26:49
Kevaundray Wedderburn:Replying to "clarification questi..."
I think I’d prefer evm over some zk ISA until its clear that a zk specific ISA with its own pipeline is needed
01:26:49
Dustin:does a gas limit thing need to be consensus/an EIP?
01:26:58
Ahmad Bitar | Nethermind:Replying to "maybe RiscV is insid..."
But might be a different structure than eof
01:27:02
MariusVanDerWijden:Replying to "does a gas limit t..."
no
01:27:14
Gajinder Singh:Replying to "does a gas limit thi..."
info EIP
01:27:14
Łukasz Rozmej:Replying to "If we need to suport..."
So you will have EVM interpreter run on RISC-V interpreter, being interpreted in zk-EVM
01:27:33
Łukasz Rozmej:Replying to "If we need to suport..."
Ya Dawg I heard you like interpreters...
01:27:48
Gary Schulte:Replying to "maybe RiscV is insid..."
dead how? linea and zksync etc might disagree
01:27:55
Vasiliy Shapovalov:Replying to "does a gas limit thi..."
EIP doesn’t have to touch consensus code tho
01:27:57
Alex (axic):Replying to "maybe RiscV is insid..."
Thats why this entire debate seems pointless if contract authors are not given access to riscv.
01:28:14
Parithosh Jayanthi:"At some point”
01:29:03
Toni Wahrstätter:Replying to "does a gas limit thi..."
not necessarily, but it makes sense to have some central place for coordination around it. We don't want validators reaching out on telegram asking if pumping the gaslimit is safe. Instead there should be something official that tells validators what is tested and what not.
01:29:19
Alex (axic):Replying to "If we need to suport..."
The main claim is that it is done once by the block builder, then it “won’t ever need to be executed again” (tm), because there’s the proof.
01:29:27
Tim Beiko:https://github.com/ethereum/EIPs/pull/9658
01:29:39
Łukasz Rozmej:Replying to "If we need to suport..."
sure, but I mean about core dev support
01:29:40
Alex (axic):Replying to "If we need to suport..."
But I think that is somewhat unrelated to the EVM level.
01:29:52
Kevaundray Wedderburn:Replying to "maybe RiscV is insid..."
It’s undesirable/dead because theres not a stable abstraction layer between the circuit and the EVM
01:29:57
Trent:Replying to "does a gas limit thi..."
Schelling point to articulate shared strategy
01:30:04
Dustin:Replying to "does a gas limit t..."
meh, it'll just becone another game of #pumpthegas "we can't afford to wait for the next fork"
01:30:14
Cody Gunton:Replying to "There is a revolutio..."
I only mean for making zk provers’ lives easier. They use lots of GPU compute and requirements will go down for that making zk proving more accessible.
01:30:41
MariusVanDerWijden:https://github.com/ethereum/go-ethereum/pull/31705
01:31:09
SanLeo:Replying to "https://github.com..."
"At some point" came pretty quick
01:31:27
Gary Schulte:Replying to "maybe RiscV is insid..."
because the evm is a moving target - this seems like a self inflicted wound. Change the vm because we are always changing the vm
01:31:55
Gajinder Singh:Replying to "does a gas limit thi..."
EIP requires clients to support limit and not break on it, so that way its more than a campaign and require some client effort
01:32:14
Orest Tarasiuk (t1):are “gas eips” supposed to be about ‘sane defaults’?
01:32:28
Kevaundray Wedderburn:Replying to "maybe RiscV is insid..."
Yep I think thats one reason to go the zkVM route
01:32:57
Tim Beiko:They are about getting client teams to increase these “sane defaults” and then update them in the next fork 😄
01:32:58
Parithosh Jayanthi:Which Els have history expiry drop for may 1st in sepolia in their mainnet releases? Or will they make another one before the date?
01:33:08
Ben Adams:Replying to "https://github.com/e..."
Now need CLs to do it for mev boost
01:33:20
Ansgar Dietrichs:I would like to keep the door open for an “optimistic replacement” for EOF if we end up removing it.
One feature we try to fasttrack (second prio after peerdas obv) and only ship with fusaka if ready, otherwise keep for glamsterdam.
only if we find really important one - but my feeling is that the glamsterdam batch is really high impact
01:33:40
Ansgar Dietrichs:Replying to "I would like to keep..."
I will look into this and see whether to bring such a proposal to the Monday call
01:33:40
Łukasz Rozmej:I am not sure to be honest
01:33:42
Justin Florentine (Besu):besu's is still being tested
01:33:43
Dan Cline:Replying to "I would like to keep..."
worth continuing this discussion on discord given call is ending soon
01:33:53
Barnabas:Replying to "Which Els have histo..."
sounds like nobody lol
01:33:54
Orest Tarasiuk (t1):Replying to "They are about getti..."
Wdym 'fork'?
01:34:09
Orest Tarasiuk (t1):Replying to "They are about getti..."
Just client upgrade?
01:34:51
Barnabas:I think pectra mainnet should be higher focus, and then maybe we can reiterate on history expiry next month?
01:35:01
Gajinder Singh:Replying to "maybe RiscV is insid..."
also good to move/abstract away zkp effort out of eth dev bottleneck
01:35:37
Alex (axic):Next final decision 😄
01:35:44
Tim Beiko:Replying to "Next final decision ..."
always!