All Core Devs - Testing #85

Transcript

Danceratopz: Good morning, everyone.

Louis Tsai: Good morning.

Justin Traglia: Good morning, Tim.

Danceratopz: Or is the CL breakout agenda quite light for today?

Barnabas Busa: Hello?

Danceratopz: It's probably just me.

Barnabas Busa: Sorry?

Justin Traglia: Yeah.

Danceratopz: Can you hear me okay?

Barnabas Busa: Yeah, pretty good.

Justin Traglia: Fine.

Danceratopz: I was just wondering if the CL breakout is quite light for today. Oh.

Justin Traglia: I haven't looked at the agenda. Let me look.

Danceratopz: Okay, let me post the link, one sec. And Barnabas… Sorry, I'm hosting today because Mario, doesn't have very good internet.

Barnabas Busa: That sounds good.

Danceratopz: Would you mind? starting the breakout sessions.

Barnabas Busa: Yeah, I mean, I can even spin it up now, and then people can just join later.

Danceratopz: Perfect.

Barnabas Busa: I think it's a bit it's it's a problematic if the beer caption is already Prysm. Yeah, I will do it once you announce it.

Danceratopz: Oh yeah, perfect. Awesome. Thanks a lot.

Justin Traglia: So Dan, yeah, I mean, the agenda itself was sort of light.

Barnabas Busa: Yah.

Justin Traglia: But there's still value in having a CL breakout call. I'm sure we'll have stuff to discuss.

Danceratopz: Awesome. Perfect. Yeah, I'm sure you'll find something. There's quite a few topics on the EL side, which… Not re- not relevant to CL devs, so, it's worth it anyway.

Justin Traglia: For sure. Yep, I'll lead the CL side.

Danceratopz: Perfect. Thanks a lot, Justin.

Hello, attendance today. Let's hope people start showing up. The bot was important after all, Ben. People need the book.

Ben Adams: There he was.

Justin Florentine: Good morning, Ethereum.

Felix Lange: Hello.

Danceratopz: Good morning. Alright, looks like we got a few people after all. Let me just quickly. Okay. Good stuff. Alright. Let's make a start, everyone. So good morning, everybody, and welcome to ACDT number 85. It's June 29th. in 2026, and I'll just drop the agenda in the chat for you all. Mario created the issue, but unfortunately he has bad internet today. So I'm taking over the moderation for him.

And I think we launch straight into DevNet six status and see how things going there. Would someone from Eve Pandrops like to give an update there?

Barnabas Busa: Yeah, so throughout the weekend, we have made some deposits in order for us to be able to do some consolidation testing. We haven't done those yet. We will probably proceed with that throughout the week. But unfortunately, Prysm, the major player that got all the deposits in. seem to have some issues. I think the Prysm team is still investigating what the specific issues were. So, in the meantime, what we did is just slash those validators, so we can actually test the… Eddie… 45, I think. where we are excluding slash validators from the validator set, and that seemed to have worked quite well. I don't think any. Forking happened due to that. So that's good. And right now we have seemed to have recovered the network fairly well, and we decided to also deposit Nethermind.

But Nethermind seems to have some issues, syncing, as far as I know. Maybe also the Nethermind team can give us an update. So, as of right now, I think only Prysm and Besu is still offline, and Actually, I'm certain whether it's a CL or a EL log. But yeah, I hope hoping to hear from prism and another mind.

Marc Harvey-Hill: Yeah, for Nethermind, I've just found a bug from running the newest execution release fixtures. So I'm working on fixing that, but that could probably be what's causing the issue.

Danceratopz: Awesome. Thanks a lot, Mark. potuz?

Potuz: On Prysm, it's not really clear. I was pinged by this. There were some minor bugs, but I started reviewing why they were offline today. And the first two notes that I grabbed was one with Nethermind and it was a bag of Nethermind, it seems. It was reported on Invalid Block, and then the second one was with ethrex, and then ethrex was dead already, requesting us to… to blow the DB, and someone Reply that, they already know what the bug is, and they were… already had a fix for this. I am looking still at Besu, I'm not sure yet, but from my end, it looks like The two notes that I grabbed, it was on the EL. It's just too much of a coincidence that Prysm is causing this. It's only Prysm that is offline. So it might be something that Prysm does that triggers something on the EL, but I'm not sure.

Danceratopz: All right. Thanks a lot for the update, potuz. I guess we'll see how the Nethermind bug fix reacts and kEIP an eye on it and see if it's triggered again. Has Erigon joined the DevNet yet? Aura.

Barnabas Busa: Rest does have a brain chat. And as far as I know, also, everyone doesn't have a working branch yet.

Danceratopz: Okay. And you…

Dragan Rakita: We'll probably have something later today. So yeah, I, yeah, that's basically.

Danceratopz: Awesome. Thanks, Dragan Nice one. And from Erigon?

Andrew Ashikhmin: Yeah. So we'll probably have something tomorrow.

Danceratopz: Perfect. Alright, thanks a lot. And, I'm sorry, I don't have my finger on the pulse here, but is Teku on the… on De.

Barnabas Busa: Yes, they were the first ones.

Danceratopz: Oh, tech was 1st one. Sorry. All right. Thanks a lot. Per Good to hear it.

Barnabas Busa: On the sales side, we are missing, Grandine.

Danceratopz: Okay. Anyone from Grandine here that wants to comment?

Saulius Grigaitis: Yeah, so I think we should be ready in the coming days. still need some some fixes and some small changes.

Danceratopz: Nice.

Saulius Grigaitis: But yeah, like likely this this week.

Danceratopz: Okay, perfect. Alright then. Is there anything else someone wants to add about DevNet six? So, just in general about today's call, I think there's… quite a few, repricing topics to go through, which we'll handle in the EL breakout. And Justin will lead a CL breakout for those who want to head over there. Before we start the breakouts, because there's not many comments on the… agenda, I just wanted to bring up 8282 and ask if There was something that we need to discuss there to move things forward. I believe Felix has made a PR to the system contract.

Felix Lange: Yeah, I can. I can talk about this. There are actually 2 things right now. So the 1st thing is Yes, some of the stuff. I started working on this last week. So yeah, and one thing I noticed it is that the EIP had a lot of… Assets attached to it, but we have since removed them. And I think that's good. So the change that we made now is basically that we will grind further on the contract in the SysASM repo, and then once we feel like it's good, we can just update the EIP with the final bytecode. And I made some changes to sysasm, so the bytecode is also always committed to the repository. So this means if you want to launch a devnet with whatever version, you can just take the hex bytecode off of the repository and just directly

Copy it to the Genesis or something. So before it was always a bit weird, like the actual bytecode, you have to have to somehow like create it yourself or, I don't know. So this is maybe the one update that I can mention. And then regarding the contract itself, so I merged the initial version to the CISAISM repo, including a change that raises the fee for every request that's added, so this was something that we discussed before, also in the context of the other contracts that are very similar, like 7002 and so on, but we never implemented that change there, and I guess it's, like, has a bit less danger for for this one, but then for the… for the builder deposit, somehow people got a bit afraid that it would somehow jam the queue if we didn't do this. So, yeah, I mean, I implemented that, and that in itself is not that complicated. I also analyzed a bit the behavior. I think what we have now is, like, kind of fine.

And, then there was a suggestion, I think from PK that there should be, We should maybe kEIP it more flexible in terms of the queue parameters. So at the moment, for all of these contracts, they are basically all of these contracts are the same, like 7002 consolidations And now the builder deposits, builder exits, they are all the same design. So basically it's a queue that the users append to and then we take out some number of requests at each block and forward it to the CL. And so the queue has these parameters like how many it will pop off the queue for each block. And then also this other parameter, the target, which is used to readjust the fee for entering the queue. And these parameters are hard coded in the contract. So then PK came around and he was like, yeah, can't we just pass the parameters into the contract for each block? So then we could have a fork that updates the queue parameters later.

And I… this is the thing that I implemented, so there's an open PR on SysASM where I implemented this. It has some challenges, though, because kind of the fee computation is designed to work with specific parameters, so… If and we can't. forward all of the parameters, so we basically, we would only have this, like, target and max forwarded for each block. But then actually, since we now kind of want to compute the fee for each user request, we would have to store the current version of the target inside of the storage of the contract. I didn't implement this, and I think it's a bit… Too complicated, kind of. But… basically, there's some discussion points, and I just really want someone who's interested to look into the PR and also make some comments. I posted some diagram… Some plots there of the… what the fee looks like,

it's a bit bumpy now with this, so this may be something that could be interesting. And then the other thing that we have to discuss is that there was a suggestion from, I think, Nico, I don't know if he's around, where the… Okay. We should maybe reduce these fee parameters, actually, because that has some kind of implication on the CL's. build a life cycle. So, if the builders are able to enter the system too quickly, then they might be incentivized to basically just kEIP joining and leaving, and it could expose some kind of attack. And so, by reducing the rate of entry into the system. by a lot, we could potentially optimize some other parameters in the CL specification, so I guess Nico should explain this part, but we should also make a decision about this.

I think.

Danceratopz: All right, thanks a lot, Felix, for the update. Sorry to leave you waiting, Tony, but Nico was… is Nico in the house today?

Nico Flaig: Yeah, I can quickly add more details to that. So basically right now we have this really large, in my opinion, target of 32 and a max of 256. And the problem with that is basically you don't get the rate limit from the contract itself when it comes to builders dosing the validator withdrawal swEIP. So builder with that can always do a top up deposit and then re trigger a withdrawal. And basically, it's still pretty capital intensive to do this. But they can basically block, 15 out of 16 validator swEIPs, per block doing this. And kind of what we use right now is the rate limiter. There's the withdrawal delay. By setting this really high or high enough, it becomes too expensive for a builder to do this.

But if we set the target to a value like 8 and the max to 64, then the max a builder can do, even if they bring up a lot of capital, is that they cut the validator swEIP in half, basically. Which is acceptable, in my opinion. So, because this would be the worst case, And there's really no need to have this high target and max for the builder deposits. So I think we should just set this low.

Danceratopz: Okay. Thanks, Nicole. Did that answer any questions, Felix?

Felix Lange: Yeah, I personally don't have any questions about this. I just wanted to bring it up for the discussion. Okay.

Danceratopz: Yep.

Felix Lange: So I wanted, now there was also this thread in the comments. I think the alternative to making the fee parameters updatable via the system call would be to just launch a new contract when we want to change the parameters. I think this is overall a good idea, but then if we want to do this, we should kind of plan for it now and have some mechanism that can disable the contract. Because in that case, we could just make it so that once we decide what the new contract's gonna be at the fork boundary, we're just gonna make it so that any further deposits to that con- to the old contract are impossible. So they would just revert.

Yeah, well, self-destruct is kind of a bad idea, because if you send value to self-destruct… I mean, first of all, self-destruct doesn't work anymore, and second, if, you know, like, it's just the problem is that when calling the contract. It really just has to revert so then it's like what we would do is we would just put in the mechanism that we already had with this, like, excess inhibitor, or whatever it's called. Basically, there would be a check that says. if the contract has been disabled, then reject the deposit and just revert the transaction. And then, so this would reduce the danger of having like, deposits get lost, basically. So if you want, I can just raise a PR that implements this. So then the… if the system call is invoked with some special input, it would set this flag, and then from that point onward, no… no deposits would be possible anymore. And then we could just…

deploy a new contract ahead of the next fork, and just In the fork block, trigger the system contract one time with this input, and then it's over, and then from that point, we just start pulling a new one. seems like a pretty good solution to me I don't know like maybe it's preferable to trying to have the feed be dynamic it is much easier to analyze the curve when the feed parameters are static so.

Danceratopz: We've got quite a queue of people who'd like to speak. Tony, is your is your comment linear on the discussion now, or.

Toni Wahrstätter: Yeah, I think I think I very much agree with Nico's point that we can lower the limit there to 64. I think it was. I think that's still enough. And regarding the Pr. From Pk. I would… I would be supportive of that. Like, I think this is, like, an easier… an easier thing to do than redeploying a new contract, and then… getting the transition right, because you have to do two things. You have to prevent people from depositing, and at the same time empty the queue, while potentially on the new fork, we already have a new deposit contract, so… I would… I would even prefer we… go into the contract state and change it there. I would prefer this over deploying a new contract, just to kEIP things simpler, but it seems like PK's PR

gets that done too, so I would support that one.

Danceratopz: Okay, thanks, Tony. potuz?

Potuz: Yeah, so I don't have a strong opinion on this one, but the reason for… The max being, reasonable enough, or at least giving it a lower bound is that it might be very profitable for a builder to censor the other builder's entry. And… what we want to make sure is that, there are enough builders at the fork. So if for some reason they can't be onboarded, for whatever reason on… Depositing before the fork. Then whomever becomes the first builder after the fork can try to prevent other builders from entering. That was a reason to have, originally a large number of deposits allowed. When we were going to use the same contract. So my understanding is that lowering the target makes this…

more expensive for them to, to be able to censor other builders. Now about the max, I'm not… I'm uncertain what is a reasonable number. It would be good to have these numbers into account whenever you guys decide the parameters. But that was the attack. Builders trying to queue, not only… They could DOS the validator exit queue, but they could DOS the builder entry queue, and that might be very profitable for them to do.

Danceratopz: Thank you, potuz. Barnabas.

Barnabas Busa: Yeah, so the alternative to bring in a new system contract at the next fork, And basically disabling the old one, how would we handle the fork transition itself? Because I think that's… that's one of our… Key issues right now, as well, that during the… the fork. We might have to wait for the finalization of the new deposits. Like, right now we will be handling it via the, Validator deposit queue, and then at the fork, we're gonna need to just process all those deposits basically in one slot. And, make sure that they… They can get onboarded and propose in slot 2, or whatever, The slot number will be.

Felix Lange: So, I have some quick comments on this. I strongly prefer, like. making a new contract, because, like, having the contract be dynamic, it's just kind of weird, like, I don't really… I mean, yeah, it's possible, but also kind of… we have… it's… it kind of breaks with what we've been doing so far, and it really is a lot easier to analyze when the contract is standalone. And I don't think it's that big of a deal to, like, change the address. The address is going to be pretty much random anyway, we always just generate it. Before we deploy the contract, so it's not installed at, like, a fixed known address, it's just, like, the address will just become known once we deploy it, and then…

we will be able to make people deposit to the right contract, for sure, I think. And then the other thing is, yeah, draining the… so the way the process would work is we would first Disable the contract, and then we would somehow have to empty the queue, so this means we would have to call into it, like, a bit longer. Just to just to remove any of the remaining. deposits. It is… I understand. We could also make the new contract, like, read off of the old one until it's empty. like, that's that's another thing we do. there are, like, I think the design space is very open, actually, for these things, and that's, like, the whole reason why we are, like, when we are entering this world of system contracts.

We haven't really fully explored, like, the kinds of things we can actually do there, but it's like, like, leaning into the possibilities of contracts basically means, yeah, we can use things such as a proxy or stuff like this, and it's totally okay.

Barnabas Busa: Yeah, but it can also open up a new… Type of attack vector, the more complex the contract will be.

Felix Lange: Yeah, I understand.

Barnabas Busa: Maybe more RESTful will be as well.

Felix Lange: However, you just have to imagine the attack space is very limited. As long as the contract doesn't call out into any other contract, basically the balance is going to be safe. I think that's something we should just… be aware of. So it's like the worst thing then could be like we somehow. Miss a deposit, and then it, like, it doesn't get credit, so it, like, gets lost. What? This weekend, I think… ensure with some testing. So I was also, initially, I was also thinking, oh my god, yeah, the danger is so high, people are going to be depositing all this money into the contract. Then I kind of realized that The the. Yeah, like I said, since the contract, there is no way to extract value from the contract at all. It's like the danger is actually not that big.

Danceratopz: Bk mentions in the chat that he's not very keen on changing a public address, later fork, and… Announcing the address once is a bit different than updating, changing it later.

Felix Lange: Yeah, I understand the concern.

Danceratopz: All right. potuz thinks we all shouldn't spend too much time. Because we don't have builder churn on that contract. Tony, you've been waiting for a bit.

Toni Wahrstätter: Yeah, I agree with PK. I would also prefer to kEIP it clean, and to have all the EL requests always coming from the same address, and not change that, during a fork. So I would prefer to have it on the same address, and I think this is all theoretical stuff, in case we don't like the number that we picked for Glamsterdam, right? So if it turns out that in Hegota we still think, like, 64 is a good number, then we… Don't even have to discuss that anymore, and otherwise we could just deploy a new contract in case this becomes a problem.

Danceratopz: External.

Felix Lange: Anyway, I just want to say we can kEIP discussing this. I wanted just to bring up these topics because I really got into this like contract implementation last few days and I felt that we should kind of wrap this up now and just make a decision. And there are actually so many things we could do. and ultimately it's more like a taste-based choice. I think there's no good reason to do it one way or the other.

Danceratopz: All right. Thanks, Felix. Yeah, I think I think that's a good point. I think, Essentially, we've just brought up quite a few different approach or like a different approach or a different way of thinking about these system contracts. And I think it's good that we have time for this here in this call. But I think we can continue these discussions async now. Unless someone wants to add something else. to this discussion. Okay. All right. Thanks, everyone, for sharing your thoughts. I think since we're all very focused on DevNet 6, I don't think there's anything that we need to talk about for DevNet 7 on a shared basis yet. Is there anything that we would like to discuss before going to the breakouts?

Barnabas Busa: I think it would be good to have an idea of what kind of change do we expect on W7. Just so everybody is aware of it.

Danceratopz: Okay, yeah, that's a comment.

Barnabas Busa: So, from the CL point of view, it looks like it's going to be 7688. The forward compatible data structures. And from the EL side, I am really not sure if there's gonna be any change.

Stefan Starflinger: I think we will discuss in the breakout. Mostly, and we will, I guess, iterate on the existing EIPs. Depending on the discussions.

Barnabas Busa: Right, but there's definitely no more EIPs to include them. It's just going to be possible changes to existing EIPs.

Stefan Starflinger: As far as I'm aware of, yes.

Maria Silva: Right, I agree also. I think it's just, At this point, from my understanding, it's… there's still an open question on how to meter, authorizations, and that relates to 8037, the state growth EIP, and 2780, the transfer ZIP, Yeah, that's that's the only open issue. Now.

Dustin Brody: There are ongoing questions with the Balls, there's 3 variations of some. Aspect of… Balls set. I guess my question is, is that… going to change for DevNet 7? Is that gonna be resolved at some point? It seems to have been kind of dragging on.

Toni Wahrstätter: Yeah, this has been resolved, and the resolution was that we kEIP it as is. Of course, I definitely don't have a strong opinion on that point, so if client teams still think, okay. we want to change that for DefNet 7, then I'm fine with it. But so far, the majority of clients have been saying they want to kEIP it as is. While other clients were advocating for those efficiency improvements from that change. So right now, the default is it will change as is. But this is for the PAL-related point. There was also something about 8037, which I'm not super dEIP. DEIPly informed about that had also different options.

Maria Silva: Yeah, those are the topics we'll be discussing on the breakout today. And yeah, it's mostly related to authorizations.

Barnabas Busa: It would be nice if we could get the pretty much final scope for the changes. This week's ACDE. And I think we can aim to do the same for next week's ACDC on the sales side.

Danceratopz: Very cool. Thanks. and All right. Thanks, Maria. Without further ado on to the breakouts.

Barnabas Busa: Yeah, the breakout rooms should be available now.

Danceratopz: Great. Thanks a lot, Barnabas. Thanks a lot, everyone.

Justin Traglia: I promise.

Danceratopz: Break out.

Barnabas Busa: See you guys.

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