All Core Devs - Execution #246

Transcript

Nixo: Good morning. Good morning. We'll get started in just a few minutes.

I think we can go ahead and get started. Good morning, and welcome to ACDE number 246. Today is September 24th. We have some Glamsterdam stuff on the agenda, and lots of, Hegota. PFIs to go through. We'll start with devnet updates for Glamsterdam. Is there someone from the Pandas who can give a… devnet update today?

Stefan Starflinger: Yeah, sure, I can give a short update. So, we've, successfully run through, testing the Gloas fork transition with, in particular Lido and Optimism. to make sure that we can get them to test a smooth fork transition, since the previous ones were a little bit bumpy. And that was quite successful. Everything went smoothly, and the devnet has since been torn down. Regarding devnet 8 and Ketterberget. We have Besu still investigating a performance issue where they've recently tested and are in the process of pushing improvements. So that should, then work better under, benchmarking load tests. And we've yesterday launched, frames devnet, for Hegota as well.

Nixo: Thanks. Okay. So we are, confirmed for the Sepolia fork on October 6th. That has already been merged into the client specs. It was confirmed on ACDC last week. Releases, I believe were supposed to be due on September 29th, which is next Tuesday. next Monday would be better, because the blog post will likely go out on Monday. Can we hear from clients what, what, the progress is on client releases for that? Nethermind is released. I guess we can go client by client, Geth.

Besu ETA tomorrow, gets released. Reth. coming next week. And Erigon. ethrex today, tomorrow. Great. Thanks, guys. Okay, next item on the agenda is, the Glamsterdam Gas Summit. Justin, do you wanna chat about, 200 million?

Justin Traglia: Yeah. Hi there, yeah. So when updating the configs for Sepolia, it appears that we forgot about the gas limit schedule. I'm hoping that we can decide on this here and now so that CO clients can make releases for Sepolia. Ideally, this mirrors what we intend to do for MainNet. After proposing a few options on Discord, it seems that we most prefer to immediately signal 200 million at the Glamsterdam fork. I just shared the link to the PR for that. In the chat, what do we think of this, and can we agree to this now? Or something like this. potuz is asking, is it safe given what Paweł triggered on devnet 8? I don't know.

Ben Adams: I mean, isn't the plan to do it on… Main app, so shouldn't we be testing it on Sepolia?

Justin Traglia: Yes, we definitely should test whatever we intend to do for mainnet on Sepolia.

Nixo: Can you say more about, potus's comment, or can potus say more?

Potuz: Is Paweł here? He can probably describe his attack, but, apparently he's triggered blocks that take over 8 seconds, and there are some clients reporting 13 to 14 seconds to To validate some blocks. And we just can't handle that. That's, that's… yeah, that's… that blocks us. Any payload that takes over 6 seconds is dangerous for Gloas. Valid one, Toni. Valid ones. And the problem is, Maria is saying about the benchmarks, but it seems that there's a disconnect between what's… what's being benchmarked on isolation and what's actually happening on the devnet.

Marius van der Wijden: And those… Are you? Are you referring to the Geth blocks?

Potuz: No, this is the JUMPDEST attack. I mean, there's a particular contract that Paweł deployed on the devnet, and you just hit that contract with a lot of gas. And then it produces a lot of valid blocks that take a long time to execute. And the problem is that if we… and this is even… It's even the lower bound. So, on the devnet, the builders are releasing the payload immediately. So these payloads are being seen at 2 seconds into the slot, 3 seconds into the slot, and still, they take until the next slot to execute. And on an actual mainnet, or an actual testnet, if we are attacked, these payloads are going to be released at 6 seconds into the slot, and they're definitely going to be executed into the next slot.

We cannot handle that situation.

Nixo: Do we have time to do that before Sepolia, Tony?

Ben Adams: I'm on.

Toni Wahrstätter: I'm wondering what Saba is saying regarding benchmarks have no actual network. To me, it feels like we are just missing… those tests.

Potuz: Firstly, the test changed. And I don't think this has anything to do with network, because the devnet already is giving us a bound. These payloads are being seen very, very early. So, it's irrelevant, the issue of the network, because as long as the payload takes 9 seconds to execute, then of course it's going to be brutal, even if the payload is revealed later.

Maria Silva: I'm not sure what attack… you are, referring to potus, but for the T-Store one, we are already integrating it. We have integrating it into the benchmarking, and it was an issue with Besu that is being fixed. So that's my understanding. Like, I don't know what the new attack is with JUMPDEST. So I don't know if someone with more context can speak a bit more to it.

Ben Adams: Are they… are the devnet machines representative? is one question, I suppose.

Stefan Starflinger: I mean, I would say they are representative. They're… They might be even a little bit over-provisioned. I would argue.

Nixo: So, is my understanding that this is a, single contract, or, like, a single attack, that is causing issues, but otherwise, this gas limit works?

Stefan Starflinger: I think my understanding is that you first have to pre-deploy quite a lot before this attack becomes critical.

Nixo: Okay.

Stefan Starflinger: So I think the question should be if we should have the gas limit at 200 million, but I think the PR is more for the fork transition, generally, how… I think it's two parts, like, do we want to, let clients implement and have this kind of, configuration that the CLs, have? kind of a jump in gas limit after the fork, and do we want to go to 200 million?

Justin Traglia: I thought Maria said something in the past that, we needed to increase the gas limit for some reason.

Maria Silva: Yeah, so I guess the reason for increasing it is because of the cost per state byte, so 8037. If we take longer, so… Pam Eliason, what we are doing now is that the cost per state byte doesn't change with the gas limit, right? So this was a simplification. We decided on 8037, and this means that from the fork. Once the fork kicks in, that is the gas costs per byte for all. state creation. And if… what happens is that if we take too long for the… the gas limit to reach, I would say, at least 150, then, essentially. the CAC limit is too small for some transactions, and we could see, like, higher volatility on base fees.

So I think it would be better to decide on the gas limit, and then set it right at the fork, and then it will take 4 hours for the… if we do the 200 million, it will take around 4 hours for the gas limit to slowly go up. And still we do see some… Or we expect some volatility in those 4 hours, but if we let it take more than that, then the more time that volatility will be there. I think I shared an analysis, in the past on Discord, but I can, I can, link it here again. One second. So, I think I agree. This is two different discussions. So, first is the discussion of, is 200 million safe?

And the second discussion is, like, once we set the limit, how should it look like? And I feel strongly that it should look like you set it at the fork. instead of a phased increase. Regarding on what is safe, I think that, I guess, we need to look more into this attack and figure out if it's, worrisome, or if it's something we can fix.

Nixo: Lukasz Curtis, you have your hand raised. Did you want to say something?

Potuz: Oh, I wanted to lower down a little bit the tone. It seemed like I claimed that the chain would be destroyed, but actually, so what happens with these blocks that take a long time to execute is that if you time them correctly, you can reorg the next proposer. Which is the problem, because you… you get your payload included, and then you reorg the next proposer. Your payload is canonical, and you can just say you hold the next… the other slot, you can just reorg an entire block. But this attack is very expensive. you need to, like, waste an entire… you waste a lot of ETH in order to reorder the next proposer, and you don't get to reorder the next block, because you don't get to see the next payload.

So it might be that it's fine. It's not that this is something that can persist. This is not an attack that can be, like, kept for… over time. So we might be fine shipping, knowing that we might have this, but I think we want to be in a situation in which clients can handle The 6 seconds that are allotted, because we are deciding on pricing based on that information.

Nixo: Okay, so is it reasonable to say that we move ahead with 200 million at the fork for Sepolia and write the tests? Wait, wait…

Potuz: It was never at the fork. I think we were scheduling it for a week after the fork.

Justin Traglia: Who is we? I don't think we've agreed to that.

Potuz: Oh, it's… I thought your PR was that.

Justin Traglia: No, I mean, I made 3 different PRs, one was 24 hours after. The upgrade. One was a phased… And one was immediately out. I closed the first two. Because of Maria's concerns.

Nixo: Caba can you say more.

Csaba Kiraly: Yeah, I just think it's not a good idea to do it at the fault, because we are mixing signals from a bunch of directions. and The… the bump will… will bring in. Networking effects and all kind of… effects because of the rock size and so on and so forth. So I would just bump it with the amount that we kind of really placing Gives us, in some sense, or what the pricing needs, and then change it. A week after or something, enough time that things are settling, and then we are changing it. And Maria, you're…

Nixo: Maria, you're saying the floor is 150?

Maria Silva: Yeah, I'd say, yeah, less than 150 would be crazy, and yeah, ideally 200, I feel.

Csaba Kiraly: Why is it lazy?

Maria Silva: Because essentially we are we are increasing the creation cost by 10x in gas terms. And so there will be some transactions that actually require much more gas. I think, like, there's some that require, like, 90 million. And so, that would mean that if you do much lower than that, then for a single transaction, you'll already be at targets, and then the base fee could be a bit crazy, I feel. So, and also, not only that, but the fact that we are Making the increases longer, it would make the… the duration of the stability also takes longer. So this is also.

Csaba Kiraly: Are you guys having slides?

Maria Silva: finance.

Csaba Kiraly: So you are assuming stability, and then it's longer. My problem is that we are… Potentially shooting ourselves in the foot by, by… Trying to do it all together, when we can just spread it out. And, yeah, but I think we should increase by the amounts required by the, by the replacing. I have no idea how much is that. But that…

Maria Silva: I'm saying is like…

Csaba Kiraly: the.

Maria Silva: The value… what I'm saying is the value required is not that far from 200, so why not just do 200?

Csaba Kiraly: I'm surprised to hear that, but I don't know on that, yeah.

Nixo: Caba, have there been any specific concerns about. Or specific incidents that you're concerned about?

Csaba Kiraly: I think…

Nixo: it immediately.

Csaba Kiraly: We don't have an equivalent network on which we tested. We tested many, many things in isolation, and that's really good. It's just… it's different from testing everything together, and… And if we don't want to do it like this on mainnet, then we don't have to do it like this on Sepolia. One thing is the transition, one thing is the… is… is.

Parithosh Jayanthi: There's also the layer of, the gas won't just immediately go to 200 million, the gas limit won't go to 200 million immediately at the block stated. It only starts trending upwards after that, because there's still a voting mechanism. So if you see chaos in the network, that means you wouldn't have the voting mechanism kick in, so the gas won't go up. So, I mean, the gas only goes up if the network is stable.

Csaba Kiraly: Yeah, I'm not saying it will fail, I'm not saying we have… I have evidence it will fail, I'm just saying we have no reason to do it like this.

Nixo: Ansgar.

Ansgar Dietrichs: Yeah, I mean, I just would say… I think, from my point of view. if this is actually as serious as it sounds, then I think the implications are actually relatively serious, just also because to me, Glamsterdam is basically all about scaling, so if it turns out we would end up having overlooked something, and that one thing, basically, is it, I don't know, 5x worse bottleneck than everything else in the fork, then? I personally think… at least I think it's very plausible that we decide that we couldn't roll out Glamsterdam like that, and we might… I mean, it's obviously very possible we might be able to do client optimizations, but if that was not possible, we might, I think, have to make adjustments to Glamsterdam.

Given that, I feel like we should double down on using test nets for actual stress testing, and not I feel like if we are now trying to basically, like, be more gentle in our testnet behavior, then I think we're setting ourselves up for potential serious issue on mainnet. So I would bias both in terms of, like, the transition at the fork boundary, but then also the gas limit we target for on the testnet. I would always aim towards Like, more… Challenging conditions because I mean otherwise we're just risking mainnet.

Nixo: Yeah, agreed. Okay, given all that conversation, Is… it sounds like the, consensus is… We do 200 million at the fork. Is that? Do people feel like that is the best way forward?

Csaba Kiraly: I see the Renaissance also in that point, so. We can go with this for me.

Nixo: Okay. Great. Glad we have solved that. So we will, schedule 200 million at the… at the fork, for Sepolia. Next item on the agenda is the CL block retention window. There was some conversation about this on ACDT, Is Toni here to talk about it? Or Dan. Yeah, Toni said he might be here, but he might not have internet.

Danceratopz: Hey, yeah, I would actually ask, is Jihoon here who brought it up to ACDT? Otherwise, I can give a quick overview.

Nixo: I do see Jihoon on the call if he's able to speak.

Danceratopz: I can… I can motivate it in the meantime. So, basically, Jihoon asked if we could discuss what the size of the CL block retention window should be for Glamsterdam. Basically, 8061, which changed the exit and consolidation churn. change, like, a key CL parameter. But we didn't update the block retention window, which was initially set to that parameter, which has now changed. So this is a CL layer issue. And related to this is that in Hegota, there's a PFI EIP 8383, which reduces this further. So a decision needs to be made on this. And then, related to that, is a PR from Nico. Who wanted to align the bowel retention period exactly with this block retention period.

So that would be the decision for today, but it depends on the value of the first question. So… There was quite some discussion in ACDT on Monday. And the question is whether we can resolve one or both of those issues today.

Jihoon Song: Yeah, I think there are. Multiple questions here. A sense that one is. Reducing CL's block retention period. According to WIC subjectivity period change in GLOAS. And if you were to reduce it, the next question would be whether changing EL's history retention period. To match CL's reduced retention period. And besides that, The other question… is… Nico's PR, Increasing BAL's retention period to match history retention period, which is 33,024 epochs. And… From my understanding, today's discussion… Work to be focused on. Both and history retention period, if I'm not wrong.

Yeah. And in the chat, Kev listed some questions, so… We can also refer to that.

Nixo: Kev, do you, have proposals on what these windows should be?

Kevaundray Wedderburn: So I think EIP 4444 was changed, to be 33,000… And 24 to match the CL retention window. If we change it to match 8061, I believe it roughly halves it. M… For the BAL window, I believe Nico wants to make it equal to the Friday Free 024. And if we, yeah, follow 8061, that would be reduced. So I'd probably group it… group it as follows. I'd say we should probably figure out if the BAL window should equal the CL window. Because I think we agreed that the EL window would equal the CL window. If we say yes to the BAL window equal in the CL window, then there's a question of, should we reduce the CL window according to 8061?

So, yeah. Yeah, so I'd say the first question is, should the BAL window equal the CL window? I can't remember what the BAL window is right now, I believe it's… 33… it's, like, 3,000 or something like this, probably a safety decay of 10%. So we'd roughly be 10x in it, right? Yes, sir. Roughly a 10X.

Nixo: Lukasz.

Kevaundray Wedderburn: Lukasz?

Łukasz Rozmej: So the balls are like a helper structure, right? So they are not really required by the network to function in any way, or it might make… Catching up a bit harder for the nodes that are really, really behind, but they are not really, crucial, so I wouldn't like to have too many of them, like, 2 weeks, 4 weeks, whatever is fine. But, having, like, multiple months of them is probably an overkill. that I wouldn't like to mandate. So that's why the the time for ball retention was chose quite small. And, okay, if I can add one more thing, and about the… about the… reducing the retention window and aligning ELs with that.

I would say it depends on the RAE files hosting strategies. So I know that few organizations are hosting those files. Nevermind is one of them. And I asked our colleagues, do we have an automated way of updating them? And we currently don't. We will work on it. But if we, like, reduce the retention window in the network to, like. a month or something, I think that's more or less what's proposed, yeah, without… Without automating that on all the hosting… providers. That's a big… and having some kind of, also, you know, alerting around that, etc, it's then actually quite… quite important, because if we have, like, 6-month retention window, every few months we can do it manually, but if we have, like, a month retention window, we probably have to completely automate it and have it very reliable on all the operators.

So, those are my… Comments here.

Nixo: Marius.

Marius van der Wijden: Yeah, sorry. Mmm. So I… I… we recently come across this bug on Definite H. And guess where Geth would, Basically, if you shut down the node for 2 weeks. We would, and start it up again, we would start catching the bells. And we would, prioritize bells at the head. Because they were pretty fresh, and they were available. But what that would mean is that. we didn't have any bouts at the point where we are actually sinking. So we have, like, the bouts from the last 3 days, but we don't have the bouts from the point where we're actually sinking from, so 2 weeks ago. And what happens then is. Is, the only way we can catch up is if we go into full sync.

The problem with. Full sync… oh, like, we're full syncing, the… the only way we can catch up is to, Linear execution. The problem with linear execution is that it's, like, an order of 3x slower than parallel execution. And so what we ended up with is blocks that take like, 9 to 10 seconds to execute, because we don't have the power. So if we… Keep this, bowel retention period as too short. Then, it is virtually impossible For someone to full sync. Because, the more we increase the parallelism. The slower a single block will be. So, right now, if the slot is 12 seconds, and our block is, on average, 10 seconds in sequential execution, then.

It is still possible to catch up to that in, like, 10-12th of the time. But, if it's, like, if the linear execution is 13 seconds, while the, while the block time is 12, then you will never, ever, ever, ever be able to catch up in full speed. And, so yeah, I think it would be really nice if we could have as long of a… Bell retention period as possible, so we can, allow for users to shut down their node for a day or two. Install some updates, restart them again, and catch up to the test.

Nixo: Codis, do you want to say that out loud?

Potuz: Well, I mean, you guys are discussing how you guys think, but the point is that we need to serve those blocks. We need to serve them complete because otherwise we're serving invalid data. So, someone needs to keep them. It's not… I mean, the spec requires us to keep them. So, if you guys are not going to keep them, then we are going to keep them, and then we're going to have them doubled. And that's going to be a deep change for us, because at least two clients already just drop everything that is EL-related, and we only keep the CL-related data on our database. We're gonna have to change this if the EL is not keeping them.

Łukasz Rozmej: But you potentially are reducing this window to… to around 4 weeks, right? So, that's not a big deal, in my opinion, to…

Potuz: Yeah, so the only ask from the CL, the only ask is that at least what the CL needs to keep should be kept on the EL. And then you guys can discuss whether or not you want to keep more.

Łukasz Rozmej: Yeah, sure.

Nixo: Marius, do you still have your hand up?

Marius van der Wijden: No, sorry.

Nixo: F.

Kevaundray Wedderburn: Yeah, so just to be a bit more explicit, to ask the question again, should the BAL window equal the CL window? Just to say POTUS's question a bit more explicit. Which would currently be… I believe it's, like, 5 months, unless we decide to reduce the CL window according to 8061. Which would then bring it to about 2 months. So yeah, I guess the first question, it seems folks are fine with, like, the BAL window equal in the CL window. Yes, to Toni's question, it would be… 33,000 epochs, unless we decide to reduce it, which was the next question.

Nixo: And I think the reduction was to 14,000?

Kevaundray Wedderburn: Yeah, it was, like, roughly half, if I remember correctly.

Nixo: Marius.

Marius van der Wijden: Yeah, this is exactly where I would, I would say. I… yeah, in principle, I would say it's nice to have less windows. We have a bunch of windows. But I'm more of a Linux type of guy anyway, so I'm all for reducing the windows. The problem is, if we are coupling two things that are kind of unrelated, maybe a bit related, and then we are talking about. it would be nice to reduce that window on the… on the CL, Then I think… yeah, but then we, like… If we are making the conscious choice to have… to only support one window for two different functions, then that window has to… or whenever we think about that window, or changing that window, we have to think about both of those functions, whether they are still supported.

Afterwards. So, I think going from 5… Months to two months, is fine for me, but in the future, if at some point. we say, hey, this retention window should be, I don't know, 3 days, and now the retention window for the EL also needs to be 3 days, then I think at that point, it's… It's really bad, because we bundled these two… Concepts together that don't… are not 100% the same concept, and now we're changing, the window based on one of those concepts, and not based on both, so…

Nixo: So, if I understand correctly, this is not blocking on testnets, So, is it, Can we move forward by. somebody, either Kev or Jihoon, Or Toni posting a summary of this somewhere that we can align the async. Okay, great. Is there… are there any, points on this topic that we didn't cover that we feel like all ELs need to… to fully understand the problem? Jihoon.

Jihoon Song: Yeah, I just want to ask a question on reducing this window. So, this window is something that EL does not have to perfectly match. It is the minimum window that EL needs to support. And if you were to… reduce this retention window, then my question is, when do we want to reduce it? Do we want to reduce it in Gloas, or do we want to reduce in Hegota? Or we can also discuss this in async.

Potuz: It could be any time, it's not a hard fork at all.

Nixo: Okay. Yeah, then there is no rush in doing it, but, we should… Align on something async, and it is not blocking for GLOS. Kev or Jihoon or Toni, where do you wanna, Think on this. In the ETH R&D Discord? Somewhere?

Kevaundray Wedderburn: Yeah, we can open up a thread on the Discord.

Nixo: Okay, great. Is there anything else related to Glamsterdam? Great. If not, we will move on to Hagoda. So we have two, categories of EIPs to discuss today. The first, we are going to cover, EIPs that were punted from last ACDE. That were likely DFIs, but needed some more discussion, in the meantime. We will start with 8304. 8304 was the trustless log index. I believe that was a default DFI, unless, any clients have adjusted their. Their recommendations for it. And that ask was specifically for,

Besu or Reth, so if either of you guys have… have adjusted your, Recommendations for it speak up now.

Justin Florentine: Sorry for which EIP?

Nixo: For the Trustless Log Index, 8304.

Justin Florentine: We haven't changed our opinion.

Nixo: Okay.

Dragan Rakita: Same here.

Nixo: Okay, great. Shop.

Zsolt Felföldi: Yeah, I just wanted to say that. Yeah, I understand. This is like the trustless, APIs are, like, somehow not so much a priority, for many people, but, I think, for the, like, other further use cases, we will have much more synergy later, and, and so I will Keep working on this project regardless of this decision. So yeah, if anyone's interested, just reach out and. Yep. Let's discuss it async and make progress with it. So yeah, just that. Thank you.

Nixo: Great, so 8304 is DFI for Hegota and Joel will continue working on it. The next one we have is 7979, that is the call and return opcodes for the EVM, I believe we have, some people on the call today who, we have solidity and Viper and Greg. Greg, did you want to say anything about it before.

Greg Colvin: We've discussed it a fair amount before. I don't know if I want to spend a lot of time, or any. re-summarizing it, unless there's people on the call who really want to do that. In the issue itself, I've linked back out to what people would need to read to fully understand the proposal, and 8173 on foundations of control flow. I've tried to answer a lot of the questions that I've heard come up, questions I see in the chat after I finish talking. I can't I can't be reading what's happening there while I'm trying to talk. So I think that's there in the proposal itself. I get into some performance measurements we did. On, just on some purely computational examples, and those show, If you can compile.

If you have this, and you produce static, properly. Properly valid code, 8337 is a proposal for actually showing the code is valid and a proposal that lays out the five criteria for what that would be. It then shows that, yes, you can get modest increases just from an interpreter, if you compile the EVM code to a register code, from a stack code to a register code, you can get, like, 2x 2x performance increases on purely computational contracts. If you compile it down to machine code. You can see like 5x. If we were to add 64-bit operations, which we have proposals for, but haven't moved forward yet.

We can see, like, 50x increases. And this is compiling down to RISC-V code. Yeah. And doing ZK proving on that risk fee code, you get the same, essentially the same. performance increases. So we can see 50x increases by starting with EVM code and compiling it down to RISC-V code, and then running. I'm running a zk prover on that one, and I'd have to go back to the proposal to remember which zk prover we used. And when I say we, I basically mean me and Claude. And so there's that. And the only new stuff is me and Claude basically generated prototype implementations for solidity Viper.

Geth and EVM1, put them together, to do end-to-end testing, of solidity and Viper, and really leaned on solidity. Had to fix some bugs, do a little patching to solidity, and… We're able to basically able to run that whole thing. So end-to-end all the solidity tests pass, compile down. pass, validate, so I think we've shown that this is not at all in the way of solidity. Okay. That's that.

Nixo: Can I just… Cool. I'm gonna, before I call on Dragan, I'm going to ask, if solidity wants to speak.

Radek | solidity: Yeah, hi, Radical Society. So we had, we shared our opinion in the, in the EF Magician's thread. I posted it also in the chat. And to sum this up, we are, So so basically, of course, when it will be delivered. In the fork, we will be using Tendon implemented. And, and yeah, and, and basically, Basically, it's like, it has some, some properties, properties we like, and, yeah, so that's the solidity opinion. Also, we, we didn't have time to discuss, also the proposal. 8337, which looks like a natural follow-up of this, but I have a strong feeling that it would be… we would have, much bigger we would be much bigger, much, much more in favor, if it will, if it will be included, like, after this change. So, yeah.

That's our opinion.

Nixo: And then Viper. Is Charles here?

Greg Colvin: I don't think he could make it. He and I have had discussions on this one, and a lot of discussions over the years. I know that if you ask him about the proposal, he will… he will say. I like 2315 a lot better. If you ask him, will you use these? He will say, well, of course, that's not even a question. When he reviewed what… You know. what the code looked like using them, you know, he's saying, yeah, that's a lot better, and you should try it on Venom. I bet we could get, you know, even more elegant, output. So… I can't get a… I can't say for sure, that he likes it a lot or something, but I know for sure that he… that he would definitely use it, and thinks he could get, better… better output, from his code generator, if he had it.

And that he really wants… he really wants, in some proposal, some sort of JUMP fee, or other… other sort of vector JUMP so that he doesn't have to use, a dynamic JUMP for the initial, selector.

Nixo: Okay, I'm gonna call on Dragan first, because he had his hand up, and I… I skipped it.

Dragan Rakita: Yeah, 7979, yeah, we do support it. I think the code destination should be removed for EIP. But we talked with our team that do SOLAR, basically SOLID compiler, and they would like to use it. So yeah, it is support from RedSight.

Nixo: Does that mean that you're changing, the score that you had initially given it?

Dragan Rakita: Yeah, I'm not sure exactly what we scored it. I don't think we DFI it, but,

Nixo: see.

Dragan Rakita: C. But. Yeah, I think it's fine with that, but we would like to see it in the hard fork.

Ben Adams: Oh, sorry, mic issues. Yeah, we, we strongly support this. And think that… I mean, it's… I think everybody, as far as I'm aware, thinks it's a good idea. And it's it's just been for like nine years. It's like, well, you know, it's not. It's not urgent, it's not urgent, and so… And that'll just continue going on forever. So I think we should get it in the fork. Because it'll never be a better time.

Nixo: Can we hear from some other client teams? Maybe Besu.

Justin Florentine: Yeah, so I think… thank you for, solidity for weighing in on that. That does change our opinion on it a little bit. We are actually… we have it at a B, I believe, right now, and we are open to moving it to an A.

Nixo: Okay. Got it. Do we have anyone from Geth who wants to weigh in? If not, we will assume that Geth remains at a B. So that… is, to… to. Votes of support from Besu and Nethermind. ethrex says… A DFI, but not strong DFI. Do we have any, strong opposition to including this? or to moving it to CFI.

Ansgar has… some…

Ansgar Dietrichs: Right. I mean, I just wanted to… to say, I feel like, kind of given that we're currently going through the… list of… kind of DFI candidates. I mean, also, obviously, I don't want to slow down the ECHO process too much, but I feel like to me, the choice right now is more between, on these individual EIPs, a… do we today DFI them, or do we leave them up in this kind of, like, basket of… middle, like, kind of, like, middle-of-the-road EIPs that are not clearly CFI or DFI, and we have to kind of, like, take them one by one at the end, and move on. I feel like there's, like, this list of really strong CFI candidates, and I would maybe

Go through all of the have gone through all of those first so that we get a feeling for the overalls. FogScope. And how much room we have before we then deal with all of these could-go-either-way EIPs. So to me, like, right now it feels more like then the takeaway would be we just don't DFI it for now, but I wouldn't then just immediately jump to CFI. But I'm also obviously, like, I'm happy to have clients go either way, just wanted to mention.

Nixo: Yeah, I'm getting strong CFI vibes from the clients right now. I think that it's… I think that it's fine if we CFI it, and then we later decide to move it to DFI, considering that DFI is, supposed to be an irreversible decision for the fork. It's supposed to be, like, a definitive way to say no for a feature for a fork, and we don't want to leave too many things in PFI at this moment, because we only have two more calls to decide on everything. I… I'm gonna propose that we move it to CFI. Does anybody want to strongly… Oppose that? Okay. We're getting thumbs up on CFI and move forward. Great. Let's see Fi. 7979.

And move on to, the next one, which is 8163. That was a DFI candidate. We just wanted to hear from some L2s. Or other EVM chains. Is there anyone on the call who is from an L2 or other EVM chain and wants to talk about it?

Piotr: Hi, I'm here. I'm from the Mononaut Foundation and yes, there was a request to produce examples of demand. for 8163 and I posted them from our end in the EIPS Magicians post. I found also some evidence that the other alt elements want or experimented with custom mop codes, which is Tron and Rootstock. There also was a message of support from the Arbitrum Nitro team that they would like to see a reservation made like this. And… yeah. That's it.

Nixo: So in the conversation that has happened over the past two weeks. and the comments that have been posted. I posted some ETH magician, an ETH magician thread in all… in the ETHRND Discord. Do any clients want to speak to, changing their mind on this, on this opcode? I believe that it was, a no-op from, the L1.

Piotr: Correct, yes.

Nixo: Ben?

Ben Adams: Yeah, we… we essentially don't do anything. But just… guaranteed not to do anything in the future.

Piotr: Correct.

Justin Florentine: Besu team, we like not doing stuff so much, we promoted this to S tier since our last call, so… That's where we're at.

andrew (erigon): From Erigon, we promoted it to the BTF.

Nixo: Did you say B as in boy?

andrew (erigon): Yeah.

Piotr: idea.

Dragan Rakita: From red side, it should not be DFI, maybe C or maybe even B. We don't want to block this, this like nope, it's easy to do and it's like. Be friendly with others, so it makes sense to do.

Nixo: Given that this is… Okay, ethrex says, see? Given that this is, an easy ask and. doesn't add much to the fork scope. Are we okay CFI-ing this? Is there any opposition? Okay, 8163, is the CFI, then.

Piotr: Thank you.

Nixo: The next one was 8360… where is this one? Maybe not on here. 16… Okay, this is the TCreate opcode. Milos, do you want to, give an update on this? So, the history of this is that it was proposed in time, but the original proposer, did not bring it to a call, so it was not added to forecast rank, which is why it has, few rankings on on forecast.

Milos | enso.build: Yeah, So, we made some updates, I will give some context. This is for TCreate, which is a new opcode for creating contracts that only exist for one single transaction. You can think about them as disposable contracts or ephemeral accounts. They gave some names. This is a use case, that has been there since a while. I think Axelar and Socket were first doing it. And nowadays, it's widely used by… for payments, deposit addresses, cross-chain, intents, limit orders, and stuff like this. It's currently possible by appending a self-destruct in the same transaction. Though the Gramsterdam update, doesn't, doesn't, give gas refills anymore for Glamsterdam. And this is… should be kind of treated as a bug, in my opinion, because we are basically paying for.

State that is not, used. So, basically, the idea is, that we will have this that will cover the breaking change that was introduced with Glamsterdam. Wait, so… Yeah, I can name some teams. There is ZeroDev building on this, and so Flashnet, and some others in the past. I think we're running on, like, 1,000, 2,000 transactions per day on Ethereum. It's a kind of a use case that scales better with price, because they're disposable. So, on Binance Chain, there are, like, 10 times more, I think a couple of hundred thousand transactions per month. And in general, I think this is quite important because otherwise this basically moves this use case to either other chain or to a centralized approach.

I'm championing the creator. But I think the main priority should be just having this use case enabled, either with TCreate or by restoring the gas refuse. But as far as I understood, the self-destruct will be deprecated soon, so…

Nixo: Does this EIP have dependencies that it would have to go in with it?

Milos | enso.build: I think so.

Nixo: What are those dependencies?

Milos | enso.build: I think are listed in the EIP.

Nixo: Oops. Where… besides, like, I guess the dependencies are here, but I don't know which ones of these are… Oh… So, 7928 is already… That one's already in, that one's already in. Are there any EIPs that need to be, like, scheduled with Hagoda? Because these are all…

Milos | enso.build: I think Josh was better.

Nixo: You're welcome.

Milos | enso.build: Jochen, I'm sorry.

Jochem Brouwer: Yes. Can people hear me?

Nixo: Yes.

Milos | enso.build: Yep.

Jochem Brouwer: Yes, so this EIP is like a standalone EIP, so no other EIPs have to be scheduled with Hakota to focus in. There seems to be some confusion because I see some chat about this toy. T loads, that's also implied, but S store and S load behaves as T store and T load in this EIP, but this is like EIP, but this is 1153, so that's already part of the chain. And maybe to add like my own opinion here, like I see a lot of clients, they are against this change. I want to say that we are, well, somewhat effectively deprecating and removing this feature of the EVM. Without giving an alternative. So we are essentially taking away an engineering opportunity from the EVM what is now more actively being used. And I personally think that we cannot do that. We should have scheduled an alternative for this in Glamsterdam. We did not do so. So that means we should do that now in ECODE.

Milos | enso.build: Yeah, I mean, to add on this, this kind of operation are having 6 times their gas cost. For a state that is not consumed, it's very important for application that this basically gets done, sorry to say, but it's like… It was made a process mistake by removing this, which is not a future use case, it's currently used by multiple Companies.

Nixo: Ben.

Ben Adams: Yeah, I think… I think some of the use cases of self-destruct are… will… can be covered by SETCODEFROM, which is… can go in, but there are some extra ones. That aren't covered. And so I would be for this on the basis that it would mean we could completely get rid of self-destruct. After.

Dragan Rakita: Yeah, I'm thinking the same. The reason why we DFI self-destruct removal is because there was no alternative in Hegota. So, the grade can be alternative to… Basically, the current usage of self-destruct, then we should probably do it. The question is the same that was mentioned in the chat is, do you want to do it now in Hegota? Maybe there are some edge cases around it, how to do it with gas, how to do it with new account, how to do it with storage. Maybe it's too much for Hegota. I don't think so, to be honest, but it is a valid question to make.

Nixo: and.

Milos | enso.build: I agree. Sorry, just to add on this, if… If it's too much for Hegota, I think the gas refill will need to stay until self-destruct is completely deprecated.

Nixo: So, what would happen… so this feature is being removed in Glamsterdam, and you're proposing it for Hegota, so what happens in the interim?

Ben Adams: It's not being removed in Gramster Dam, but the gas costs sort of get prohibitive in some corner cases.

Milos | enso.build: Yeah, I mean, the future is removed because the point of using it is that you get the gas back because you don't consume the state. So, yeah, now it's just… Even adding the gas to Cyber Destruct, I believe, adds some gas. It's like you cannot is it that is not a future anymore, because the point of the future is to have it ephemeral so you don't pay the cost for it. Since it's a disposable payment flow type of use case.

Nixo: Okay, so question for the teams that have not weighed in yet, do we feel like You guys have… The wherewithal right now to, weigh in, or do you need more time to consider this? Ben, and then Maria.

Ben Adams: I mean, I'd say a downside of not putting it in and the change to the cost of self-destruct will mean that people won't use self-destruct and they'll just leave tons of contracts around because that will be cheaper.

Nixo: Maria.

Maria Silva: To be honest, I think the discussion of this EIP should be done together with the proposal of deprecating self-destruct, because I feel like the decision we take there will also inform the decision we should take here. So I feel strongly that we shouldn't DFI this right now, even if clients feel they want to DFI it, so I would… Ask for, maybe pushing it to that, the same time we have that discussion.

Nixo: Okay, it sounds like… okay, so the… we're not ready to make a decision quite yet today. I would ask the champions of this, of this EIP Milos to please engage with, the clients, and for the clients that haven't submitted. Recommendations for this to take a look, and on the next call, we can make a decision.

Milos | enso.build: Yeah, sounds good.

Nixo: Okay, let's see, we can, Okay, so there were two, EIPs last, call that. were basically alternatives to each other that Maria has asked, us to… or has said that basically we need, mainnet data. In order to make a decision on it. On whether or not we do 8368, 8372, or, neither of them. And so, basically, these things cannot be, decided on until then. And, my understanding was that it was at least 30 days of data. after, Glamsterdam, so… My proposal is that we leave both of these in PFI. With a note that we may need it after Glamsterdam. Does anybody have a preference?

The alternative is that we move both of them to CFI, or one of them to CFI, and just switch it out if, if… the other one is needed. Does anybody have any opposition to just leaving these as PFI? Okay, I would just leave them. There, then. And we can move on. Okay, so we can move to the, the highest rated, EIPs. and make decisions on these. I've asked the clients to, flag any concerns, and, Mark has added this nice spread feature, which shows that the higher number is the more contentious ones, which means that there's a bigger spread between people's opinions on them. So let's start with 7906. Does… this is the highest rated one. Does anybody have… want to flag any concerns about this one?

Suyash.

Suyash Shandilya: Yeah, not a concern per se. Hi, I'm a treasurer from Firmware, but this would be really great for, us offline signers, hardware signers, like, so just a strong recommendation for this. That's it.

Nixo: Okay. if there's no opposition, then we can move this to CFI. Great. Let's move 7906 to CFI and move on to the next one. We have… 8250. Which is, keyed nonsense for frame transactions. Does anybody want to raise any concerns about this one?

Great, then we can move this to CFI. I think this was a Batch of… Account Objection 1, so yeah, 8272 is the other one. I'm just gonna go back to this so that I can… Another frame transactions, one recent roots for frame transactions. Makes sense to CFI these. All together. Time for concerns is now. Great. Moving this one to CFI. Okay, remove bloom filters.

This one… Wow, this is the third fork it's been proposed for. Does anybody have any concerns with this one? This was, if I remember correctly, a dependency for another one correct. I think, Kev, this was a dependency for one of the ones that you proposed. and Ben?

Ben Adams: Oh, sorry. Yeah, this is, essentially moving technical debt. We do all these calculations, we send it across the network, nobody uses them, so… why do them? And why send them on the network?

Nixo: Great. I think this is… Okay, this is, an easy CFI, then. Move on to 8368. CPSB recalibration for new gas limit. This is rated highly. Please. Wonderful.

Maria Silva: This is the one that we are leaving as CF.

Nixo: Oh, it is, you're right, it is. Sorry. 8253. Bump nonce of zero nonce storage accounts.

Łukasz Rozmej: That one, Some people wanted to include it in Amsterdam at last second, and we decided to go with… Hegota.

Dragan Rakita: We are responsible people.

Nixo: Does anybody want to flag anything with this one?

Jochem Brouwer: Yeah, just stating that this is the EIP-7610 replacement. So we SFI'd EIP-7610 for Glampsterdam and then last minute we DFI'd it and this is the replacement for it for you.

Nixo: Okay. Let's see if I got one, then. And. Next one is 3298, remove storage clear refund and refund cap. Looks like Erigon and ethrex had, lower tiers for it. Do you guys want to flag anything specific?

Andrew Ashikhmin: No, nothing. It just we thought it was a lower priority. That's it.

Nixo: Okay. Well, I get to be the good guy Ansgar was the bad guy last call. I just get to be with the CFI decisions. Okay, that can be a CFI. And then 8131. This is the unified transaction content floor. And this is, the last of the, Easy CFIs that I have asked clients to look at, so. Does anybody have any flags with this one? Unified Transaction Content Floor.

This is all A or B, so… Okay, easy CFI. We have 14 minutes left, but I had not asked anybody to go through any of these, so basically for the next call. I would just ask that clients look through, the remaining, I think, 11 EIPs. And, the champions, Progress anything that they feel has changed since, The clients made the recommendations. And then we will spend the next two calls going through those 11 EIPs. Does anybody want to say anything about the remaining ones? That maybe will give clients more color on them. for next time.

Great, Toni, which one is… or, sorry, Ansgar, which one is that?

Ansgar Dietrichs: The block access list byte floor. I was just a suggestion, if clients don't feel like they're ready today to make a decision, that's totally fine. I personally just think They both basically go hand-in-hand in some sense. The idea is to overall have a more unified Approach to data pricing, like, in Hegota, it, to me, makes sense to do both of these. But I mean, yeah, there's more varied ratings, so… I just wanted to bring it up as a potential, if we wanted to use the time now, instead of just ending.

Nixo: Yeah, Toni, do you, want to say anything about, like, the coupling of these two?

Toni Wahrstätter: Yeah, can you hear me?

Nixo: Yep.

Toni Wahrstätter: Yeah, as Ansgar said, I think I think they should be seen as a bundle because if we only do one of them, then the worst case block size will stay the same. If we do both of them, Then basically every byte. That we have in the payload will be priced. At the floor. Yeah, I think clients should consider both of them.

Nixo: Okay, given that we… that the recommendation is to couple them. Are there any, opposing views about Just see if I'm this with with the other one. Does anybody feel like they need more time? To look into it, since this is not one. that clients were asked to look into before this call, Dragan?

Dragan Rakita: Yeah, I think it should be CFI. I think we marked it as C because there is slightly more complexity with measuring the amount of items inside the ball. But it is interesting idea and we should in some way restrict the block size. Basically that was… Increased by the ball. So CFI it now it looks correct. Then we… later we can talk about it when they're how to do it, and what are the drawbacks and everything like that.

Nixo: Okay, then… CFI, this one, going once, going twice. CFI. I saw a comment in the chat. Kat or Justin.

Justin Florentine: Yeah, regarding chat, there's a lot of traffic on SETCODEFROM. I wouldn't mind hearing from the crowd, about the migration path that, allows SETCODEFROM to… to retire ECDSA keys.

CPerezz: I have an entire well, it's tiny, but explain with images how all of this works. But basically, the idea is fairly simple. Here you have the lingo. You can pull SETCODEFROM, and you will go to a pure code, wallet. If you still want, for some reason, with a code wallet, the EOA feeling, you can enable it with frames, but it will not be native. If you want to have code in your EOA, you just need to use 7702. So, SETCODEFROM basically allows you to get rid of the EOA, and get rid of the delegations, and migrate to a full code slash post-quantum account, or smart account. And if you want… you don't want to go all the way, and you want to keep your EOA natively, you can just use 7702 as it is today.

So, that is mostly it.

Ben Adams: I'd also like to highlight the second benefit of it, which is When deploying contracts, especially since we've increased the price of it, both in call data and, state gas. If you're doing something, say. Like Uniswap V2, V3, where they they create liquidity pools which are identical code. They pay pay the full Gas for the contract, even though essentially it's just changing a… Code hash, so you… with this, you could change it to only paying for a code hash. And one of the ways Currently, RANDA is maybe you do a proxy instead. But then you're paying, you know, you're introducing a double call. And also we've… Told people not to trust proxies.

So it's sort of a dual benefit.

Nixo: You're gone.

Dragan Rakita: The reason why is DFI for us is basically We want to delay decisions related to the Change the code. Anything related to, like, after post-quantum thing? After the frames came. Because with frames, you have new mechanisms that we need to figure out how they're going to work, how the user's going to basically use them. And the idea is let's delay SETCODEFROM or anything that's led to EIP7702 or setting code or anything like that after frames come. That was the reasoning for DFI-ing, not a strong one, but that's the thinking that we had.

Nixo: Nico?

Nico: Yeah, I think it's a reasonable thing to do, to just wait, but unfortunately, like, the timing is going to play against us here. Because that would mean pushing these two EIPs to ISTAR. And then that clashes with, pessimistic or optimistic, depending on how you view this quantum transition timeline. So. If we take a scenario where like end of 2028 we're doing ISTAR and Then we are kind of. Plain… of… Yeah, you're kind of playing with the risk that Sometime in 2028, there is a big Progress and big headlines saying that Q-Day is near, and then… we would be in a very unfortunate situation. So, yeah, I do hear the arguments. Do you just wanna…

Wait to see frames in actions before going through this, but it's, it then becomes a very risky bet, and… And this could be an emergency fork sometime end of 2028. Beginning of 2029, so yeah. That's. So yeah, basically, I think. This should go… in ISTAR. But yeah, for timing reasons.

Dragan Rakita: Just to mention, this is not a strong opinion at all. It's like if people SETCODEFROM is like even a small change to the protocol. So if people, clients want to do it, so it seems fine to CFI.

Nico: Oh, and that would be a… Also, the same for 8151.

Nixo: Great. Given that we have, 2 more calls to make decisions about these now 10 EIPs. I was gonna say we can delay it, but there is a comment that we should CFI it today, with a lot of thumbs up. Do we have any opposition to that? Does anybody want to, have more time to look into it?

Justin Florentine: I think Besu might… we have this at the C tier? We are finding these arguments compelling, but maybe not super compelling, so we would be able to more fully make that decision in some time.

Nixo: Ben? Okay.

Ben Adams: Yeah, there was a comment that it wouldn't apply to things like existing Uniswap contracts, and that is correct. But there's no safe way to do that, because it requires… All of the existing code to be known about, so you couldn't do, like, set code hash, because some… some ELs would say, oh yeah, I do have this code hash, other ones would say, oh, I don't, and so you'd end up with a consensus split. So that's why it's SETCODEFROM, because you're saying. I'm setting my code hash to an account that already exists on chain, and that can be verified. Whereas, CodeHash can't be verified that it's used by an existing account. And you might have that code hash.

In your code database.

Nixo: Nico, is your hand still up?

Nico: Sorry, was Steve…

Nixo: Okay. I'm just gonna punt this one for the… to the next call, since Besu said that they would like some more time to look into it, and we do have. hopefully plenty of time, assuming that Glamsterdam doesn't take up too much of the next two calls. So, we now have 10 EIPs, to look into, and I will post a, a list of those EIPs, just to make sure that there's no, confusion. In the ExecutionDev channel and EtherRD before the next call. We have 3 minutes left. Does anybody want to bring up anything else that we have not covered yet? Fantastic. Great job, everybody, today. Okay, see you guys later.

Radek | solidity: tax code?

Justin Florentine: Good work, Nick!

Andrew Ashikhmin: Thank you, bye bye.

Potuz: See you.

Łukasz Rozmej: Thank you.

Jochem Brouwer: all.

Kevaundray Wedderburn: there.

Jochem Brouwer: that.

Fredrik Svantes: if.

Ansgar Dietrichs: 5 1.

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