All Core Devs - Testing #88

Transcript

Justin Traglia: Good morning, everyone. Let's just give a few more minutes for people to join. Then we'll get started.

Good morning, everyone. One more minute and then we'll get started. All right. Good morning, everyone. Welcome to All Core Devs Testing 88. Let's get started. Stefan, are you able to give us updates on Glamsterdam DevNet 7?

Stefan Starflinger: Yeah, sure. So, overall, it seems that the dust has settled, and Glamsterdam DevNet7 is doing pretty well. I'm just in the process of onboarding Erigon, which is the last client, Grandine was before the weekend. So we should have a full house. The only thing is that Erigon and Grandine, being the last, will have a few less validators until more deposits come in, so they might propose a little bit less. We've also added the Death Star to Devnet 7. So there should be a little bit more chaos in the network. And for the ConsensusLayer side. Regarding more testing, I think I will look into adding more and more different testing scenarios and chaos scenarios to DevNet 7. Step by step to see how our clients perform.

And then looking at speccing DevNet 8, especially for some minor cleaning up changes that Maria wants to do to the repricing EIPs. And also, like in the agenda, I think it's great if we have another test for the fork transition. With DevNet 8, at least one more, or maybe we can fit in a few more, before we go to the testnets. That would be my update.

Justin Traglia: Great, thank you. Do we know, or I noticed on DORA that Prysm and the Prysm-Erigon combo is missing slots. Do we know what's going on there?

Stefan Starflinger: I think it's still… some of the clients are still not quite done syncing. I'm still trying out full sync on all of the clients. So, it might just be that it's not caught up quite yet.

Justin Traglia: Okay, thank you. And do we have any expectations for when DevNet 8 will be? Do you think that maybe like 2 weeks from now, or something, or sooner.

Stefan Starflinger: I think we can try to schedule it for next week, but there have been quite a few people on holiday or haven't been here yet because of other reasons, so… I think it might make sense not to rush DevNet 8. I think we have a lot of testing ground, and it won't change too much with DevNet 7 already. So I think next week or the week after would both be fine. I think it depends on when, the changes will be ready, and I think benchmarking also still needs some time to get ready.

Parithosh Jayanthi: We also have our malicious Prysm node. I've updated everything, but I need the Aussies to wake up to review and watch the codebase, but this week we should be having similar situations like Death Star, but… kind of more degrees of freedom via our malicious node. So I think there's still a lot of testing around to cover in .NET 7.

Stefan Starflinger: Yeah, I'd also like to add, I don't want to go too hard on DefNet 7, because we said that it would be available for a broader audience, and so I think that we can, kind of, to the beginnings of kind of doing some more chaos testing and make the network a little bit unstable. But I don't want it to crash. I think we can go full on definite 8 and try to to break it more.

Justin Traglia: Would it be feasible or possible or even a good idea to have a separate DevNet for trying to break things?

Stefan Starflinger: I think clients are doing pretty well. I think we can stress DevNet 7 more, since it's more than, like, 90%. But I wouldn't want to break it completely. So I think that's something we should target .NET 8 for.

Parithosh Jayanthi: Yeah, I'd ideally like to have a DevNet 8, where we have a smooth transition with all the clients, and then a DevNet 9 that's a more non-finality-focused DevNet, and ideally that happens in, like, the next month.

Justin Traglia: Okay, yeah, that would be cool. Any more updates on the DevNet? Maybe from clients, or… general updates. Toni?

Toni Wahrstätter: Yeah, I'd like to add that clients should please take a look at the Book Club Access List Discord. Because I… I think right now the BAL-specific JSON RPCs are still different across clients. And it would be great if… We get them aligned for, definite aid.

Justin Traglia: Would, CL Client Devs be able to give, an overview of what the bugs were at the work transition like from Lodestar, and maybe Teku.

cayman: Yeah, from Lodestar side, we, had a bug in our, SSZ implementation. Where, we were… doing a spread operator, or using the spread operator to pass in a bunch of arguments for each of the Merkle nodes. And when you use a spread operator with too many arguments, it can blow the stack. So this is kind of a… pattern that we should avoid, but it snuck in. So we didn't see it when we were testing small trees. But then when we got to the size of the DevNet with a bunch of trees, several hundreds of thousands of Notes, and it, just air it out.

Justin Traglia: Tristan.

Enrico Del Fante: On the. Our. We are. Oh, sorry.

Justin Traglia: No, you go. Thank.

Enrico Del Fante: Okay. So on the tech side, we are, start merging… Stuff from Devon 7 to Master. We are closer to alignment. There is still… work in progress. barely started on builder API implementation, and probably we still have some Work to do on the… on the Beacon Api. Generally, these are the areas where we are. working on.

Justin Traglia: Has anyone performed more benchmarking for The SSD changes, stable containers. Has it been impactful?

Parithosh Jayanthi: Would this imply rerunning the deposit tests that you had, Justin? Or is there a different benchmark, you mean?

Justin Traglia: I thought that some clients were working on just like a general benchmarking. Not the situations that I came up with or that we came up with.

Parithosh Jayanthi: I'm not aware. Maybe clients can speak to that.

Saulius Grigaitis: Yeah, so for Grandine, we did some benchmarks and we found that there is In some places we have a significant slower. performance. So yeah, we will… at some point, we will need to optimize because of, Of this stable continuous feature.

Justin Traglia: Yeah, I've heard similar from other clients. It's a little bit slower. like 10 to 20% slower with stable containers.

Enrico Del Fante: Yeah, yeah, this is a thing that we… Talked about the last one of the last calls that take we we have. slow, slower implementation. Compared to the non-progressive one across the board, and yeah, it's still manageable, but we need to drill… probably have a… An optimization round at some point. At least we want to make sure that. bigger data… how… how… how big data structure actually behave? Because, we did the basic benchmarking. For now. Probably need to do… need to do a… another round.

Justin Traglia: Okay. Were… were there any, EL issues during DevNet 7 that we would like to discuss, or… Oh. Anything notable.

Stefan Starflinger: I think it was mainly just some inconsistencies with the gas accounting were the main ones. But Nothing out of the ordinary. On the L side. I think it was mostly the SEC containers during the fork transition that were the big surprise, because we had so many exited validators.

Justin Traglia: Was it because of the exited validators or was it just because of the validator set size?

Stefan Starflinger: Mostly because of the validator set size.

Justin Traglia: Okay, thank you Well, great. Is there anything else that we would like to discuss before jumping into the breakouts? The agenda is very light today.

Csaba Kiraly: No, just wanted to ask if there's any. blocker to make this, the Diamat 8 disk v5 only for DLs. We definitely support it on the guest side, and yeah. As far as I know, everyone else should support it, but I want to double check. But then it would be good to run DevNet 8 with diskv5 only. Should that we test also that?

Stefan Starflinger: Yeah, I think that's a great idea. Do clients have flags to disable diskv4 or to only enable diskv5?

Csaba Kiraly: Yeah, I will do a small code to this testnet on it. to be sure, before we run the DevNet, but then it would be good to run the DevNet with that.

Justin Traglia: Similarly, are we using QUIC in the DevNet 7? for the sales.

Parithosh Jayanthi: As far as I know, yes, we have CAIC enabled, but I could be wrong. I can check.

Justin Traglia: Cool.

Parithosh Jayanthi: Yeah, we have Quick enabled.

Justin Traglia: Amazing. Anything else before the breakout calls, or breakout? sessions. Pooja.

Pooja Ranjan: Yeah, I quickly wanted to check on the status of EIPs which are in DevNet 7. Wanted to check if it is OK to upgrade the stage to SFI. As per my understanding, all four SFI criteria defined in EIP 7723 appears to have been satisfied. So, yeah, where we are on that.

Justin Traglia: I have no idea. Maybe someone else can chime in.

Parithosh Jayanthi: Yeah, I think the idea is that we propose or we claim that we are ready to SFI it from the testing team perspective on ACDT, and then in the subsequent ACDC or E, they actually move it to official SFI. At least from the PandaOps team, I think all the EIPs and DevNet7, we think it's okay to SFI. Maybe the testing team could have a similar statement once they look through everything?

Pooja Ranjan: All right, I see that there is a similar feeling from EL's perspective as well. So will it be safe to consider that all proposals may be moved to SFI stage pending the ratification in the ACD call, the next call on Thursday?

Parithosh Jayanthi: Yeah, that sounds reasonable to me, yeah.

Pooja Ranjan: All right. Okay, last thing that I wanted to mention here is there are some proposals which are still waiting to be moved to review, so I wanted to check with, with the team here. how comfortable they are feeling about moving EIP 7773 Meta EIP for Glamsterdam upgrade to review status. Of course, this will be pending on the author's approval for all other EIPs, which is part of the DevNet 7 right now. or just to put it simple. Will anybody object to move this proposal to the review status. Awesome. In that case, authors, if you have PR, please go ahead and add it to the EIP editing office hour, which is there tomorrow, or if they are an existing

PR, please add your approval so it can be considered for the next office hour and be merged before the next ACD call on Thursday. Thank you, everyone.

Justin Traglia: Okay, anything else before the breakouts. Oh, thank you. Everyone for attending the core ACDT session today. I believe… Oh. Toni will be leading the EL breakout if you decide to have one here. And, CL Teams, there's a new Zoom, So please join that link, and we'll continue there. Hi, everyone.

Toni Wahrstätter: Thank you. Okay, I guess the EO. Site will also be very quick today. There were 2 items on the agenda. The first one, I wanted to discuss the JSONRPC. I already introduced the topic. So clients are doing things differently there, and it would be great if clients could have a look. I summarized all the all the points where clients diverge. in a HKMD, So please take a look. And. I agree with Karim, we also then need tests for the RPCs to make sure that

In the future, we are certain that the responses are the same across clients. Is there anything someone would like to add to that?

Stefan Starflinger: I think we already have some JSON RPC tests. I think Chase has been working on that. So it would be good if we could get in touch with him. Maybe I can reach him to talk to him about this. I think I already tagged him in the thread as well.

Toni Wahrstätter: Right. Are those tests just not merged yet?

Stefan Starflinger: I'm not sure if he has any tests on Amsterdam. I would have to look it up. But in general, he's working on… tests for JSON RPC, because there are so many differences between the clients, he wants to have them all pass the same test suits, and it would make sense to add that there.

Toni Wahrstätter: Right? Yeah. Yeah. And it would be creative for box of access list if we get it like consistent from the beginning. So things like error codes. Returning empty lists versus not including them. Things like that is different right now, and I created A PR against execution APIs recently that, clarified all those points where clients diverge. And yeah, so please take a look at this one. It's in the Ball Discord Anything else on that? Any objections for doing this until definite 8?

Dragan Rakita: I'm not exactly on that, but on the traces, subcode traces, should we add gas, state gas reservoir? And… spilled gas. How to edit, I'm not even sure.

Toni Wahrstätter: This is independent now from the bile-specific JSNARPC methods, right?

Dragan Rakita: True, true, true.

Toni Wahrstätter: Okay. Yeah, I mean, I'm happy to have this discussion right now. Maybe clients might need some time to think through, but.

Dragan Rakita: Maybe. I think it's better to do it, I think. And just… Clients hope will be read and figure out something.

Toni Wahrstätter: Yeah, sounds good. But in general, it feels… Feels right. To have that information exposed in some… trace, method. Then let's discuss this async. And then finally, I created a PR right before the call. I will post it into the chat. And this is essentially around EIP 7997, the contracts factory. And the only thing this does is basically adding it, adding the factory to the EOS. via an irregular state transition. And, of course, on mainnet or on our DevNets, nothing would actually change, because the factory deployment is already there. and this PR aligns EELS with what, for example, Geth is doing. Where they check, does the contract exist? And if the factory pre-deploy is not existing.

It writes it to the respective address. So… Yeah. Is there any objection to this?

Mario Vega: I mean, maybe some.

Toni Wahrstätter: Marius.

Mario Vega: Would help here. Can you? Can you guys hear me all right.

Toni Wahrstätter: Yep, ye.

Mario Vega: Okay, maybe some context, could help here. So this was an issue that was raised by Ignacio in some other thread and, in ETHR&D. The problem was that when you are accessing the account to check if the contract is already there. This adds something to the witness, to the execution witness. So we have to be careful where we check if the contract is there or not. That's… that's basically the reason why, the original PR that was raised to EIPs, Repository to remove this check. For existence of this of this contract was was was open. So yeah, basically my, my, my, my feelings that we may, perhaps we should not check. The contract at all, just, just to avoid.

Having different or inconsistent behavior between clients. either a fork boundary or during block execution after Amsterdam. I don't know if that helps, but. But yeah, that's the context.

Toni Wahrstätter: Yeah, this is definitely helpful. I mean, the point I stumbled across this was testing the JSON RPCs and I compared, for example, Erigon with Geth. And there, I suddenly found, like, different paths, because One of them had the. Had the fork boundary, had the factory deployed, and the other didn't. So I'm wondering if this could have more of those side effects downstream somewhere. But I totally get the re… the rationale that you provide, like, this is an… useless state access that we don't need because we already know it's deployed. So yeah, yeah. Hmm. Because right now there is no trace of this, EIP in the specs, basically, because we know it's there, and we put it in the Genesis file.

Maybe that's enough. Curious if I don't… if someone else has an opinion on this one.

Mario Vega: I also just shared the PR, the EIP PR And… In the, in the chat, please take a look. It's already merged, but I think it's, it helps to, like. understand the context here. And basically this thing, this PR removes the mention of any state transition, the regular state transition. And it's… It basically says that if the contract is not there, you should not verify if it's there or not, and you… and if… the gas schedule already makes it impossible to deploy the contract using the transaction that is described in the EIP, then you should rely on an irregular state transition, but the irregular state transition is itself not part of the EIP. So basically it says like you need another EIP, a theoretical other EIP.

And this EIP doesn't describe the derivative transition. I don't think it's gonna be necessary because most of the chains already, have this contract there, so it's like… I don't know. Yep Marius, sorry.

Marius van der Wijden: Yeah, I just wanted to give some context where this is coming from. We had the discussion as well. I'm also of the opinion that we don't really need it, But, like, they were specifying something here that we don't… that is never going to happen on mainnet and it makes no sense to specify it. But others in the team were, Said that, like, we should do it this way, But I think there were no, like, really, like, hard, this is important to do, so… Yeah, I think… But at at least as far as I I. The feeling in the room was like, this is something that we. Might want to do, but it's not really important that we do it.

So, I'm happy to say, hey, this is… yeah, we're not going to change it. Okay.

Toni Wahrstätter: Yeah, I think this is fair. of course, we might then have some differences among… across clients, but, Should be good. I guess I will then just close this PR. If people think we shouldn't include that in EELS. And, yeah. I would have to dig deeper where the actual where it actually surfaces. No, but I think it's fine. Definitely nothing critical. And this is already the last point of the agenda. Is there anything else to add to that?

Perfect. If that's not the case, I think we can end it early. Thanks, everyone. Bye bye.

Marius van der Wijden: Bye bye. Same.

Louis Tsai: Thank you.

Ameziane Hamlat: Thank you.

Stefan Starflinger: Thank you.

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