All Core Devs - Testing #89

Transcript

Mario Vega: Hello, everyone. We're gonna give a couple more minutes, to give a chance to people to join, and we can start.

Hi everyone, just one more minute, then we can start. All right, let's… let's get going. Welcome, everybody, to ACDT number 89. I'll post the chat in the agenda just now. Today is, July 27, 2026, we have an agenda consisting mainly of Glamsterdam DevNet topics, and we have a couple more topics for the EL breakout and the EL breakout today, so yeah, let's just get started. We can start with DevNet 7. Stefan, I see that you are in the call. Would you like to give us an update about DevNet 7?

Stefan Starflinger: Yeah, sure. So overall, the definite held up pretty well over the weekend. But we were also not doing too much to it, and now we started adding some more scenarios again, so I ramped up the transaction count overall with different scenarios, and the network is under a much bigger load, so we can do another analysis there, in case clients have changed anything yet and want to test anything. I think I will leave it running for 24 hours, and then we can see if there's any change to the last spamming round. We still have some issues with, Geth… builder, so Geth is right now, having some gas limit issues and not winning any bids. And also, the Nethermind builder is not winning any bids yet, where we're looking into that.

I think Perry has started, the TISM, scenarios as well. They should, be coming in. Today and over the next few days. And, we're gonna, I think, maybe look over DevNet 8. A little bit, maybe, in this call. as well. I think there are some topics on the agenda for that. as well. I think that's pretty much it overall. I will link the kind of performance-related issue report that I found a few days ago in the chat as well, in case people want to look. Again, at the last round of testing, lots of transactions.

Mario Vega: Thank you. Any comments from clients? Any behavior that has been found in DevNet 7 that needs to be discussed today?

Barnabas Busa: Besu had some bug, this morning after they bumped their image. Maybe they can comment?

Daniel Lehrner: Yes, I can give a quick update. We were trying out some performance improvement, but then realized that this, also introduced, Regression, and then we had some issues with estate handling. we rolled back to a former comet. And now it's fixed again, so we just need to investigate, why this happened. And then we can do the performance improvements again.

Stefan Starflinger: I also have one more thing that came to mind, that I'm testing. Is I'm adding a repetitive builder scenario, where I want to win the 31st slot, at the epoch transition. Every time, and then withhold the block, which I'm currently trying out. But I'm noticing that I'm not winning every time, even though mostly I'm offering a higher bid. And clients are still self-building, in some cases, and not taking the higher bid.

Mario Vega: Alright, any… Do you need feedback from clients or Stefan, regarding that, or…

Stefan Starflinger: It would be good if clients could have a look, at their, bid implementation, or to… See if they always take the highest bid, or if there are some… Reason they don't. It would be good if they could share.

Parithosh Jayanthi: It would also be nice to know when the circuit breaker's live, or if you have, specific logging lines that indicate the circuit breaker's live. Because it just could be that we've triggered the scenario.

Mario Vega: Yeah, Nico mentions in the chat that it's difficult to know at the moment without much info. And also the circuit breaker. Nico, could you chime in on the circuit breaker, or… What's the status for…

Nico Flaig: So for loads that this is rolled out on the DevNet, so at least that could be one reason, but yeah, if the bid is really high, we should pick it by default right now. Unless that one is active, which, yeah, I'm not sure. Like, it depends on the missed payloads previously in the epoch.

Barnabas Busa: So, diverse, client is Teku, by far. I think Teku favors local blocks over, bits. At, like, 90% of the time.

Mario Vega: Okay, seems like more information needs to be gathered then.

Barnabas Busa: It would be very good if we had, some log… logs about the bids that, have been coming in, and that has been rejected or accepted. Right now, some clients, log nothing about the bits. themselves.

Mario Vega: Okay, Prysm mentions that they log every time they ignore a bit, so I don't know if that's the case for the rest of the clients. But we should take a look, yep. Alright, Do we want to keep going in the discussion, or should we switch to… is there anything else on DevNet 7 that needs to be discussed? Today.

Maria Silva: Maybe, can I ask a question? If there are no more topics on the DevNet, I want to… so on, benchmarking, we are starting to run benchmarks on DevNet 7. And, to help me with the interpretation of the results, I just wanted to ask for each EL client, which of you have already pushed the optimizations to Paul DevNet 7, and which, are not yet there, so I can have a sense of, the numbers I've seen, if they are with optimizations or without optimizations.

Mario Vega: Get, I see, Nethermind and… or Besu, or any other EL client do you have? I want an opinion on this.

Dragan Rakita: You mean… Glam, DevNet7?

Maria Silva: Yes.

Dragan Rakita: Okay, right side, everything should be there.

Maria Silva: Okay. Thank you. And for the other clients.

Ben Adams: Yeah, everything's good. We had an issue with… Prior ones, because they didn't support the… Elcl change. Everything should do.

Maria Silva: I'm sorry, but I'm not sure I fully understood what you said it were breaking a bit. Is it merged or not?

Ben Adams: Yes, it's merged.

Maria Silva: Okay, perfect, thank you. And already have ethrex and Besu. For Erigon?

Milen Filatov: Yeah, hi. So, we should have most of them there, like, the branches should match, in terms of optimizations, but… I noticed yesterday that there seems to be some regressions, which I wanted to look into, performance regressions, for things that we previously have fixed. So, I think I might need to look what's happening. But, it's a bit unclear how to run the new… the new benchmarks still. I tried to get some info from Louis, but I think he's away, so if someone can maybe share a bit… if there's, like, a link somewhere with the new instructions for how we run the benchmarks with State Actor and stuff like that, that would be useful.

Jochem Brouwer: Yeah, I will do that after the call. Sorry about the wait.

Milen Filatov: Yeah, no worries, thank you.

Maria Silva: Thank you, thank you. And, for GetH, do we have any update there? Are you guys… have you merged already, or not yet?

Marius van der Wijden: We have everything we need on the master branch, except for the parallel execution. The parallel execution will be merged today or tomorrow, and then we can… Continue off of our muscle branch. With, devnetly.

Maria Silva: Perfect. Thank you.

Mario Vega: Awesome, thank you, Maria. Okay, I think there's no left topics on Glamsterdam devnet. Should we move to Glamsterdam devneten at 8? And planning? Should we start that today? I want to get your opinion on that, Stefan and other folks. What do you think the course of action should be? For Glamsterdam Devonne 8.

Stefan Starflinger: Yeah, sure, I can share the spec sheet, and I think you also have, Testing tracker that I've linked as well. In general, the DevNet should be as similar as possible to DevNet 7, with a few changes that have been suggested, for example, to try to have, disk V5 only on the EL side. So that we can test that, and I've already listed a few of the clients that have, some flags. With that regard, but it would be good in general if, clients could have a look, if it's possible on their end, with the current Glamsterdam branches to just enable, V5. And to not have a V4 fallback that is hidden, so that we have, actual errors that get surfaced, pretty quickly, instead of hiding them.

That would be pretty nice. And I think overall, I've added some, kind of testing focus scenarios that have been discussed, I think, last week in ACDE. That we can, expand on. But mostly, I would go over the, SSZ, especially the fork transition, was one of the more important things that didn't go well in devnet 7. And then… just try to introduce much more chaos into DevNet 8, because we also, guarantee that DevNet 7 is something that people will be able to use, as, the app developers as well.

Mario Vega: Okay,

Stefan Starflinger: So, like Perry said, the builder API.

Parithosh Jayanthi: Yeah,

Barnabas Busa: Are any of these actual changes to the, consensus? So, like. if we would change the builder API, That would not be a consensus-breaking change, no?

Parithosh Jayanthi: I mean, it kind of is, because it depends on how the client's integrated into the client, and that's where you get the block from.

Barnabas Busa: No, but the block looks the same.

Parithosh Jayanthi: Yeah, the block looks the same, for sure. Yeah, you could always roll it out later, but if we want to be feature complete, then this is something that has to go in.

Barnabas Busa: Yeah, but why can't we do that in DevNet 7? So, like, my point is, are any of these changes in the DevNet 8 spec could not just be rolled out on DevNet 7?

Parithosh Jayanthi: Well, the argument is that we would still want at least one more DevNet where everything is done and we have a smooth transition. And I guess to do the smooth transition, you'd want another DevNet at the very least.

Mario Vega: I see the point on Barnabas, just, sorry, you're just racing that, perhaps we could enable these… these, features in .NET 7, and then also, once we tested them truly. test the transition, and then these, features enabled in Demonade for more complete testing. Is that what you mean, Barnabas, or…

Barnabas Busa: Yeah, I mean, I'm just looking at, the spec change sheet, and… Yeah, I do see some consensus-breaking changes, so I guess we do need that.

Mario Vega: Got it, got it. Yeah, potuz, please, go ahead.

Potuz: If I remember correctly, there's a fix to attestation, performance tracking… well, not performance, to attestation tracking that is, Consensus-breaking, so if that gets in, anyways, we need another DevNet for that.

Justin Traglia: Yeah, and I think it will be merged for DevNet8. I can share a link right now. I am planning on talking about this in the EL breakout.

Mario Vega: Cool. Yeah, I think we can talk about the specific, EL and CL, changes in the respective breakouts. Perhaps a more overall discussion of definite date could be if we have a timeline. Does anybody have an idea of the timeline that we want to do for this? If we go ahead? Maybe we can agree on that, at the very least. For today.

Stefan Starflinger: I think right now we have early August, set for, devnet 8. I think, around next week, Wednesday, would be my suggestion, but I'm happy to hear what others think.

Mario Vega: Yeah, Spencer raises an important point on DevNet8, is that we need, probably, the final repricing number, so that's, We need to see the status of that, perhaps. Maria, do you have, like, it's Wednesday… Next week, a good date, for the pricing numbers to be already available, or do we need more time?

Maria Silva: Yeah, I think we need more time, so the status is, we were updating everything for bowl… sorry, for Glamsterdam, Lehner at 7. And, we started to run the repricing analysis, since Friday, and I think now Luis is working on just doing a release for the whole benchmark suite. And I'm guessing we won't have numbers yet by Wednesday. Yeah, because there's still work there, and then, I mean, I would assume maybe next week we could start seeing some numbers. But yeah, I would also… some people out of office, it's been a bit slower.

Mario Vega: Also, from the spec side, if we are… we need to make another release with the new gas repricing numbers, and then let clients run them, so I think… Perhaps, next Wednesday is a little bit tight. Is,

Maria Silva: And, sorry, and to answer Stefan, I'd say DevNet 7 should be enough. I mean, I think I'll still like to do, DevNet 8 for the analysis, but I wouldn't expect the numbers to change, so I think with results from DevNet 7, it should be Strong enough evidence to lock the final numbers.

Mario Vega: Okay, Alright, yeah, I see your point. So yeah, Estefan, so perhaps we can revisit, as you say, launch date on next ACD and see how are things, standing? And then decide on the, on the… on the date next week. We have one last topic that I thought we should bring for DevNet 8, which is the sparse blob pool. I'm really not sure who is the person that posted this, but they mentioned that they want to make it mandatory, to some degree. Let me, put the comment on the chat. Just to check if there's any… Any opinion on this?

Bosul Mun: Hi.

Mario Vega: Or if the person… okay, yeah, Bosul.

Bosul Mun: Sorry, I should raise my hand, sorry. So I am the person who posted this. And… So my suggestion is to make the EIP8070 the dispersable pool. at least is EnginePI changes mandatory for .NET 8? So, right now, EIP8070 has two parts. One is the engine API changes, and the other is the actual cell exchange is 72. And, yes, and… So, the Engine API is a relatively small change, and I think it makes sense to make it mandatory for few reasons. First, it's useful to have GetBlobsV3 and GetBlobsV4 available Both available, because

once client has Pars BlockQu, then Get blossomed 3 will be… very slow, so… So, I think… and also, if we don't have Sparse blob pool, then Get Plus B4 would be slower, so I think having both APIs available is, last client use, whichever. It's more efficient for the current implementation, and also Provides smoother transition to sparse blob pool, and… Also, the fork choice update before with cost study field would be very helpful when we simulate sparse local implementation on EL side, so… if we implement these APIs, right now, then it will be…

It will make a better transition to Sparse blob pool. That's… Right. opinion. I think also the… This execution… the Hive task for… These engine APIs are also almost ready. Yes. But I'm curious about the other client's opinion. As far as I know, the… Prysm writers already have a draft PR for this, and… Never mind ethrex. DAS has implemented this.

Mario Vega: Yeah, I think it would be great to hear from the client teams if there's any opposition on implementing this. Thank you, Bosul for the explanation. Do we have any opposition on getting this implemented and ready for DevNet 8? From CL and ELD, dev clients?

Matthew Keil: Is the, Is it just about the Get Engine API endpoints, or is the intention to do cell-level DAS as well? Because that would be a challenge. The engine endpoints are pretty straightforward, though.

Bosul Mun: Yes, I meant only the engine API part's mandatory, and let… The other part implemented later when we have enough bandwidth.

Mario Vega: There's a good question from Barnabas on the chat, and he asked, what's the point of the engine API if the feature is not there yet?

Bosul Mun: I think we can… test those engine APIs, And if… And we can make the… the other things happen later. And also, right now, some clients has sparse blob pool, and some clients does not. And… I think this… At least we… we have these engine APIs, and Make them to choose which… which API they will use is better. For example, DAS has possible COVID, Since most ZR clients do not have capitalist B4, we are experiencing delay on… get… get blob's request.

Mario Vega: Okay, Do we have any comments from clients? This would mean that we only implement Engine API endpoints by devnet 8. Is that worth it? Should we commit to this? I would love to hear, clients' opinions on this. Okay, if not, I don't think, we can commit to this, because, Does anybody have any opinion, negative or positive, on this topic? If there's no opinion on this, we cannot commit or defer.

Fabio Di Fabio: Hey, on the Besu side, as I wrote. it's possible to implement the EnginePI. Oh, DevNet. 8th?

Mario Vega: Thank you. Any other EL client? Thank you. Any other EL client, GetH or Nethermind?

Marius van der Wijden: Yeah, yeah. So far, so far. Forgets this, like, this proposal is… I'm mainly coming from the GetHe team, so, as Bosul already said, like. Like, we would be very happy to implement this.

Mario Vega: Alright, thank you. Never mind, Reth. Anybody else? Okay, ethrex mentioned no problem on their side. Erigon, another Mind Drive, do you have any opposition?

Ben Adams: Yeah, I think Netherlands, good at this.

Milen Filatov: Yeah, I personally don't really see this as a priority for… Amsterdam, but if it's just the Engine API changes, then that's fine.

Dragan Rakita: Yeah, from Redside, I think we already have it. To be honest, I mean to track it. But they shouldn't be filed.

Mario Vega: Alright. That sounds good. On the CL side, do we have to decide on this? I think, Are there any comments? would mean, basically, that we are using the Engine endpoint, from the CLs. That's the main use case.

Dustin Brody: I guess you… using what… sets. I mean, this has not been… Yeah, I mean, it… use how?

Mario Vega: Yeah, well, that's my… but that's my question, basically. Do we need a SL consensus on this, or not? Maybe, perhaps not.

Dustin Brody: Well, I'm not sure how it's going to be meaningfully tested unless there are at least… there's at least one or two CLs which will drive this, and… and… Maybe they're… I guess Prysm and Lighthouse have, I believe, been… more on the vanguard of this particular thing? Yeah, Lighthouse, sure. Okay, so… Yeah.

Mario Vega: Okay, and Justin mentions that they're… There's probably tests for this? Okay. Anyway, any other comments on this topic? I think we can agree that EnginePI is a go for DevN8. Any other comments? Daniel, please go ahead.

Daniel Knopik: Yeah, just… quick note on FCU v4, because… so I, I, so GetBlobsV4 is gated by capability, but for, FCU, V4? V5? I forget the version. But, yeah, it would be a shame if we got any issues, because only some, ELs understood the… Custody columns… Parameter, so… yeah. And also, like, maybe a wipe check. Because there have been some, Lighthouse internal… well, people that are unhappy that the custody columns parameter is embedded into fork choice update, because it's not really a related thing. It's kind of… the idea is I guess to piggyback on it, But it would be… Not as critical to, you know, support this all at once if this were a separate call, like, update custody columns or something.

Yeah. So I guess the question is, do the… like, maybe, what is the rationale behind embedding it, and do any other clients share the view that we should not embed it in FCU4, but instead… Have a separate one.

Bosul Mun: We also considered having it as a… separate Engine API, like, custody column… update custody column V1 or something, but… the main benefit of moving it into FCU is… As you said, just to piggyback this field, and this is anyway just one field, and it will be called If it is changed, Donna, it will be called on… on every slot, so… and we don't also have to think whether what it… what if this call fails? So, it is mostly for… Not adding… additional Engine APIs and using the current one.

Daniel Knopik: Okay, so… What's currently running on devnet 7? I guess… the custody columns… parameter is not used, because… People seem to be confused about it in chat. So, I guess it's currently, like, that PR that is linked has not really been implemented at all. Or is it, like, an optional parameter, or how is it working?

Bosul Mun: I'm sorry, was the question? Which FCU version is running on devnet?

Daniel Knopik: I mean, it is FCUV4, according to Stefan, but is it… is it FCUV4 with or without custody column? Because Lighthouse is… like, this is not merged yet, so it is not sending… custody column. So does GetH have it as kind of, like, an optional parameter when… you know, processing F34.

Bosul Mun: Yes. It's… we merged FCU V4 with custody column, and it is optional.

Daniel Knopik: Okay, so… we have fine compatibility device if everyone implements it as an optional parameter. I'm not sure if this is specced that way? But…

Mario Vega: And potuz, I see your comment on the chat. Would you like to chime in on this?

Potuz: No, not really. I don't have any clue about this. It just feels the wrong thing to send on FCU. We keep overloading these EnginePI methods.

Barnabas Busa: That's why we're moving it to SSV, so we can keep overloading it.

Mario Vega: Alright, I think we should park this discussion and go to the breaknecks, but I would like to… revisit this. I mean, from EL clients, we have decided that we're gonna implement this, but it feels like there's other… there's still, like. unresolved problems with this PR. Is my sense that we should continue this discussion async before committing to it? Correct? Or, Yeah, Daniel, I see, I see your, your comment on, another, a different call for this, yeah.

Barnabas Busa: I mean, if we're already… already here, we should just make the decision whether we want to include it or not, especially if it's just an EnginePI change,

Mario Vega: Yeah.

Barnabas Busa: If it will unlock some people in testing the sparse block pool, then we should just do that. Yeah, I agree.

Mario Vega: Okay, that sounds good. Okay, let's go with this. If there's any concerns about the EnginePI when clients start implementing it, please raise them as soon as possible so we can, like, pick up this discussion next week also, on the ACDT call, if there's any findings. Okay, sounds good. Perfect, thank you. Alright, let's continue into the breakouts for now. So we have the same format. Basically, there's gonna be a EL breakout on a separate call, and we're gonna continue the EL breakout in this call. Could anybody share the link to the CL breakout? I'm missing that.

Justin Traglia: Just one second. There we go.

Mario Vega: Excellent, thank you. So, again, anyone on the EL stay here. We continue the discussion here. EL, please jump into the other call.

Justin Traglia: I, you know.

Mario Vega: Right, I guess, we can continue on the EL breakout. I listed 3 things, for today. Basically, two of them are merged EIPs, changes. Let me just post the first two. The first one, let's, let's… So here's the first one. Basically, this, the question is on DevNet 8, should be included. or not, so the EIPPR is already mesh, but I would like to, bring up the discussion, and perhaps, Maria, if you can, explain this change, and just for everyone to be in sync, that this is, going or not in the 8? Yes, just for… This is the EIP2780, yeah.

Maria Silva: Yeah, so this was something we discussed. I'm not sure if it was last ACDT or two ACDTs ago, I guess. We… chatted a bit about doing some changes to the repricing EIPs, and this was one of them. So the idea was we are not charging the log cost for other transfer events, and the… this specific call-out of the log transfer actually made the EIP a bit more complicated to understand, and where the values are coming from, and so on and so forth, and so this change is mostly, for the most case, doesn't change any pricing, and just makes things a bit easier to understand. The only exception is for the create transactions. Those do change a bit, and so that's why I pointed this out, so this will require, an update on how

specs and implementations, but initially, when I shared these, I don't think there was any issues raised, and I think it should be included in DevNet 8. And my understanding is, like, they already are working on the specs for this. So I think there's no… big issues here.

Mario Vega: Spencer, do you know if we have a PR for this on the EL side? I'm not sure if I…

Guruprasad Kamath: We… yeah, we do have a PR on the specs.

Mario Vega: Okay, sounds good. It's maybe just a matter of, like, Do we have any objections from this EL? Is this a good change or not? Does anybody have any opinions? Okay, if not, okay, this is… basically going in for DevNet 8, so, yeah. If there are no objections, we should probably merge this on the spec side, and we can make a release, add it to the .NET release. Okay, so next item is also yours, Maria, is this one. Let me see… this is for EIP8037, this is basically just renaming execution gas… no, sorry, regular gas to execution Gas. Could you give a little bit more context on this? This is already merged also, basically.

Maria Silva: Yeah, so this is something we discussed also at the same time we were discussing the other change, and I think this was a proposal from Joham to make the naming of, what was called regular gas to be a bit more forward compatible. And so the idea is, like, going forward, if we do more… if we separate more dimensions, I think what is now regular gas would start to become more like execution gas, so it's gas that encodes the actual execution time that a block takes to… execute. Sorry for saying it twice. But, but so the idea was just a rename. It doesn't change anything on behavior or consensus or anything, it's just a pure… variable naming change. Yeah, and my understanding is that Spencer also Already updated the specs, so… Yeah

I think, if there's no… big reason why this naming doesn't make sense. I think we should… we should go with it.

Mario Vega: Thank you. Luis, go ahead.

Luis Pinto: Yeah, I have a question, because that cost also includes the networking aspect parts, so the blobs and all the… and the call data. Is it fair to call it execution, Gus, in that case?

Maria Silva: So that is the part where the… The forward compatibility comes in, so if we were… to s- do something like a data resource, then, that would be its own thing, and then the execution guys would be execution guys. But I agree that right now, it's sort of… includes… The call data and these things, But… but I guess it's, like. It's… the trade-off is trying to make it a bit more forward-compatible.

Mario Vega: Damn.

Jochem Brouwer: Yeah, I just want to add here, maybe also because I can understand the confusion, like, why are you calling this execute if there is also, like, blob hash opcode, call data opcode? But we have to realize that this data is actually in the intrinsic gest of the transaction. And this is also something that we want to explicitly priced in the future, but this is also explicitly not part of this fork, so, this is why. And just because I know that, from a software point. the naming, the naming of some constant is not, like, super important, but we have to realize that this is the document what the community is going to read, and this is also why it is so important that this is, that we do it right now, because we cannot change this EIP in the future, and this is also why I think this is, like, a super good change. So we just want to make also this point.

Thanks.

Maria Silva: Yeah, sorry, I think that's a good point. So, everything on call data is actually intrinsic gas, even though it counts to the execution gas at the end, It's… Yeah. I don't know, I feel like it's still… better than what we had before. Regular gas is a bit, Like, a weird naming, but yeah.

Mario Vega: Yeah, so dragan, from Reth also says that it's, like, a little bit better. Do we have any other opinions? Alright, If not, also Luis also mentioned that he's fine with the changes, it's basically just a need. I think it's important, yes. But yeah, if there are no other comments, should we proceed to the next point? Oh, or, well, other… other EL… other person from other EL clients, do we have any oppositions on this? Okay. If not, I think we can… thank you, Maria, for raising this point. I think the next steps would be merging this on the ELS spec.

And then also included… I mean, there's no… there's no actual changes on the… on the test, but we… we will include it in the… in the specs on the test. For, for next event. Alright, thank you. And last point for today is… this is a bigger topic, I would say, it's 7997. Basically, there are two open PRs at the moment. Let me just share… The links on the agenda… This is the first one by Toni, and the other one was raised by… Jocham, let me share this too… So, I think the… Yeah, so… but they are both shared in the chat. So Toni, would you mind, going over your PR first, and we can… I mean, I'm not entirely sure, but I think they are trying to change the same thing, so I think the decision this call would be to decide which one should we go with.

Yep.

Toni Wahrstätter: Yeah, I will try to be quick, because this EIP7997 is a no-op on mainnet, and I would… I would say we shouldn't waste any more time on this, because, we're literally optimizing for other chains, but the problem here is that what do we do on other chains that have balls and also activate 7997? And then the question is, should the new contract be in the BAL or not? And also, when we are activating 7997, the factory. do we want to track this in the ball with state access? Right now, no client is doing that, and I would say we should just enshrine that behavior, because for mainnet, it's fine. Of course, other chains would have to think about this, like,

in more detail, if it would make sense for them to add it to the bar or not. But for Ethereum mainnet, we are fine by just keeping all the client's implementations as they are. And right now, the last time I checked, I think no client team is actually, loading their account at the fork transition, except GetH. So, this would mean if a different chain would, also do the clamps that I'm fork, and the factory deployment is not yet there. then only Geth would, actually do the state read, whereas the other clients would not do it, which means they would, diverge when it comes to the bulk. And there would be a consensus issue. So this only affects genes that activate clompsodon.

And have no pre… the factory not deployed yet. So, in my opinion, I think it would be best to just, take what clients are doing, say. If 7997 is happening in a fork, we don't put the address in the ball, and we don't generate a witness, and we don't access it. And this is, as far as I know, what all clients are doing, and what the specs are doing right now. So in my opinion, we might just be able to close the two PRs, or do a third PR that is, like, a very minimal follow-up, basically, clarifying what I just said. and enshining, in the EIP what the specs and the clients are doing, too.

So this is more like a clarification. And I think this came up from… the ZK EVM side, I'm not sure if someone with CKVM knowledge is in this call, and could expand if this would cause any problems, because otherwise I would just say we proceed with that. But yeah, maybe, Jochem, do you want to add something?

Jochem Brouwer: Yeah, from my side. it's about, like, what this EIP says it does, and what it should enforce at the specification. If we add a fork block. do this account read, and insert it into the block access list. This also complicates the protocol a bit, because in the block access list, if we have a maximum size, which is for all the other blocks except the fork block, then at the fork block, we have a block access list, which has a maximum size of actually The… well, that size of the blocks after the block, plus one, so this actually complicates the protocol. So I would say.

Toni Wahrstätter: Yeah, I wouldn't say so, because you add 20 bytes or something. I think this is completely negligible.

Jochem Brouwer: Yes, but if we would have, like, an exact check, then this would be the exact boundary. And the other thing is that this is about, like, what to actually state in the EIPs. I don't think that we should But, yeah, that's, like, my opinion. I do not think that we should state anything in the EIPs for other chains, because this complicates the mainnet specification, because we also have to write code for other chains, and I think we should not do this.

Toni Wahrstätter: Yeah, this is also my opinion. Like, we shouldn't, like, optimizing for all variants of different chains that either have balls, or have no balls, or have the factory deployed or not. It feels like we can just do the most simple thing. And my goal would have been to, end up in a situation where clients don't have to change anything anymore. Maybe Geth could simplify their codebase, but even if we would do the glamsterdam fork now. no client would work all. So this is important to stress here that everything is fine for mainnet, and we have done the 7997, fork already on definites, so things are fine. And… yeah, so just for Kev, because you asked in the chat,

If I remember it correctly, there was a demand to have a witness for the 7997 contract. The thing is, the 7997 contract exists already, so the witness for its generation is, like, long in the past. And with the clamson-Boke transition, we would not read that account. So you could think of at the consensus, what we could do would be we check the account, we check is the code already installed, and if not, we install it. And this would then generate a witness and put the address in the pulse. But instead, what we are saying now is we skip that part.

Kevaundray Wedderburn: Yeah, I think this is fine. It just means that I… I think it just means that the guest programs will come with, this contract, sort of, hard-coded inside of them. I believe is okay.

Toni Wahrstätter: Right. Exactly, yeah. Because, for example, for testing, we have it in the Genesis file, india. This was… this is more about the fork boundary.

Kevaundray Wedderburn: I guess one question, actually, I forget, so… On system contracts, do we include them in the ballot?

Toni Wahrstätter: Yup. So, system contracts are included in every block. Even blocks without transactions have system contract bul entries for, for example, the 2935 block hash, or the 4788 root. And yeah, if we wanted to be 100% precise, we could have a system call that deploys this account At the first block of the fork. This means we would have a new, special logic just for the first block of the bow, and yeah, this is what we are trying to avoid. To basically lock in what clients are doing today.

Kevaundray Wedderburn: Yeah, makes sense, yeah.

Mario Vega: Jochem, just, would you mind, expressing your comment on the chat? Yes.

Jochem Brouwer: So.

Mario Vega: Just for everyone to hear.

Jochem Brouwer: Yeah, yeah, so I currently think that, actually, the EF currently is actually correct, so I don't know why I opened it in my PR, but… So I think we can actually close the two PRIs off this, but I would just restate what the EIP currently says. So this is the live version of the EIP, without any merges of these above PRs. If the chain is already running with gas parameters that no longer allow deployment via the keyless transaction, the only way to add the contract at the expected address is a coordinated irregular state transition, which is outside the scope of this EIP. Client software must not check for the existence of the contract at the fork boundary. So this states both that the EIP is not going to state what the change should do, so it will not specify the behavior if the contract is not there.

And it also explicitly says that the client software must not check for the existence of the conduct at the fork boundary, so that means that there is no ball read inserted at the bulk boundary, and I think this is perfect, because this explicitly says what I think we expressed here just now.

Toni Wahrstätter: Perfect. I would then just, suggest that we close the two PRs and just keep things as they are, and just as a heads up for the clients, so Geth is doing something different now, so there will be There could be a chain where basically guest workers of all depends on the perspective where all the other clients work off, because GF is actually the only one who has some logic installed there. But for mainnet, nothing will happen, so I would say we just close the two PRs, and… and things are fine. And if there is ever Geth being used on another chain that has no, factory deployed, and they have balls, and they want to do clumps to them.

then they should look into this more carefully, because this would mean they would diverge. But for mainnet, we are.

Mario Vega: I would also raise that from tests, I mean, if Get is doing something different, and we cannot hit that different behavior, perhaps we have to expand testing on the EL specs, but I think that would be it.

Toni Wahrstätter: today. We don't have tests for that today.

Mario Vega: Yep. Okay. So yeah, I think we should dig a little bit deeper on the EL specs if there's a different behavior from Get and we're not catching that. Perhaps that's the only thing that we have to do on the specs, but I think that's a testing issue, and we should, like, just dedicate a little bit of time, but that's it.

Toni Wahrstätter: Yeah, the thing is, if you now write the tests properly, then all the other clients won't pass them. For example, all the clients pass the test when… where we just check, is the factory there? And this is the most important thing here. What we don't check is what happens on the chain if the factory is not there. And of course, we could test it. But, on the other hand, I was thinking… We have it on mainnet, so why would we even bother with writing a test for that?

Mario Vega: That is true, that is true. Okay.

Jochem Brouwer: Sorry, because I just want to add that point then, because it is not part of the spec, we just also don't spec it, because it's not… well, it's not part of the specification, so we can't…

Mario Vega: Okay, dragan?

Dragan Rakita: Maybe it's nuisance, but… Basically, we… assume in AIP that we are not going to do deployment at the fork block, because it's already deployed. That's basically the assumption that you're making for the minute, and that's perfect.

Toni Wahrstätter: Right, right, yeah. Makes sense.

Mario Vega: Right. I think we have agreement on this. Is there any other comments from other clients? I think maybe Get, if you guys want to chime in, because you do have different behavior at the moment.

Marius van der Wijden: Yeah, we're not… we're not married to that behavior. I think, like, we… we implemented what we thought was most correct. If everyone else is, like, feeling differently, we can just change our behavior to align with everyone.

Toni Wahrstätter: Yeah, I think both are fine. To be honest, to me, it looks like Gett has implemented it in the most correct way, if there even exists a perfectly correct way. But if you wanna align with all the other clients, you would probably just remove that code again. I think it was called, like, Apply7997 or something at the fork boundary, and then you would do the same as all the other clients.

Mario Vega: Alright. But that sounds good. Alright, any final comments? Cool. Any final comments regarding the entire call? Is there anything else that we want to chat? I think we're out of time, but just final words or anything?

Dragan Rakita: Are we considering devnet 8 as the last devnet? Should we think about the timeline for the testnets and minutes.

Mario Vega: I think we need the SEAL class for that.

Dragan Rakita: I don't know. They're the ketchup.

Mario Vega: Yeah, Toni?

Toni Wahrstätter: Yeah, just as a heads up regarding the repricing, there's also one or two tests, in Bals that also depend on the repricing. So, when we have the final replacing numbers, we also have to Update one constant when it comes to Bala again, which also still needs to be tested.

Mario Vega: Sounds good. Okay. Anything else? Last final comments? Maybe we're out of time already, but… If not, we can wrap it up today. Thanks, everyone, for joining. Have a nice week. Goodbye, everyone.

Jochem Brouwer: Thank you all. Bye-bye.

Toni Wahrstätter: Q, blobby.

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