All Core Devs - Testing #70

Transcript

Barnabas Busa: Hello, everybody. Let's just give it another minute or two, then we can get started. All right, good morning, everyone. Welcome to all Core Devs testing call number 70 on the 16th of February. Let's get right into it. Number one, on the agenda is, Steel Fusaka and, partial sales update, and I got Bob V3 implementation update.

Can we hear, an update from all the consensus layer clients, how they… what kind of progress they made in the past weeks? Whether they are ready to be onboarded on, Blob DevNet Zero? Currently, we have Lighthouse and Prism. close to ready. Maybe we have someone from Teku that they could give us an update? Or Nimbus?

Dustin Brody: Sure, yeah. LibP2P for us is pretty much ready, so… Now we're trying to get in the rest, in, but that's… That was just, Last week, that, that… Got to a usable state.

Barnabas Busa: Tldr is, we currently have… about 20 notes, each of the notes, or half of the notes are super notes, half of the notes are full notes. There's not that many validators, and I have latency added of 80 milliseconds between each of the nodes, and the MEV node that is publishing the private blobs is limited to maximum of two peers. So, here we are basically trying to mimic a very, very poorly performing network, with added latency and multiple hops in order for us to be able to see the results of GitLab's history without having the GitLab V2 eagerly pushing all the GitLab information out. This is not full pure gas, this is just a partial cells, our escape.

The four pages, I think that's still a research topic. Anyway, I think we can do, like, a proper bigger test once we have onboarded more consensus layer clients. Hopefully, in the next week or two, we can onboard Teco and Nimbus. Maybe a couple of weeks later, others as well? Anyone else, would have client updates regarding, partial cell stuff? Yeah, we can take a look at that offline. I haven't looked into the network, today yet. If no more client updates, then maybe we can move on to Glamsterdam.

And block-level access list update. We had a couple of bugs, throughout the weekend. Stefan has reached out to all the clients regarding the specific bugs. For now, we have reverted into a previous comment that was working. We currently have 100% participation, but hopefully those bugs can be fixed by the, reached out client. Do we have any other, updates regarding local access list?

Toni Wahrstätter: Yes, I have a short update.

Barnabas Busa: Nope.

Toni Wahrstätter: In the last breakout call, we discussed, how we want to deal with a potential DOS vector. Basically, what happens if a malicious builder would fill the block lab access list with a lot of garbage storage reads. And the easiest fix for that was basically to have a hard cap on the items in the block club access list. So this would be a hard cap that would not be limiting to block builders, because you would always first hit the gas limit before you hit the max… Ball item limit, so this is, like. Only a safety guard against, against a malicious builder. I posted the PR, against the EAP into the agenda.

Barnabas Busa: Yeah, I just, posted it here as well, in the chat.

Toni Wahrstätter: Perfect. Yeah, so if you look at it, there's one thing, so in the PR, I say gas available, but this should actually be the gas, limit, so I have to fix that. Also, one thing, in the current PR, we incorporate the max withdrawals and the max consolidation into the formula, which is not super clean, in my opinion, so… This is probably one of the things we want to discuss in the… we can discuss today or in the next breakout call, but essentially how we could simplify that formula. And… One important thing here is… We currently assume that the minimum cost to have an item in the bowl is 2,000 gas, which comes from Putting a storage key on the 2930 access list, and then accessing it.

Which costs another 100 guests, on top of the $1,900 that you pay for the access list, slot. And this might be not needed anymore, or could be simplified if we go for EAP7981, which… Adds a cost on top of the access lists. on the 2930 access lists makes them more expensive. Thus, the minimum cost to put an item onto the ball will increase for that. So there's probably some simplifications that will be done. To this PR, I saw it was automatically merged by now, but, yeah, just as a heads up, I think clients have already implemented something, like this. But it will change. This is nothing that will affect Definite 2 or Definite 3, I would say.

We want to have that check, by definite free, so there will be tests ready by the time But yeah, just as a heads up that there will be some changes coming.

Barnabas Busa: Thank you. Anyone else has any other, Changes, open questions that we still have to discuss regarding blocked access list?

Toni Wahrstätter: Maybe let me just add quick question. Marius, you're referring… is this question directed to me? Like, what is the max gas limit this could support?

Marius van der Wijden: Yes.

Toni Wahrstätter: Okay, yeah, so the… yeah, the formula uses the gas limit, so it will just scale with the gas limit. Currently, the simplest approach would be you take the gas limit and you divide it by 2,000, And this is then the maximum items we can have in the block of access list. Of course, there are some items that are for free. For example, state divs coming from withdrawals or consolidations, because no one pays for them, actually. So, those are currently subtracted in the formula. And, yeah, if someone has suggestions how to implement that, simply. Without using those two constants, the max withdrawal and the max consolidation. I'm open to hear them. But I would say the simplest would probably be we do something like gas limit divided by 2,000,

And just cap it at that. Yeah. Just to make sure that we're not limiting… the goal is to not introduce any new constraints, so the gas limit should be the only constraint here, and we don't want to create, like, a complicated situation for builders here.

Barnabas Busa: Right. What is the… what is the problem with using those values?

Toni Wahrstätter: In my opinion, it's just not super clean, because those values are defined in CL EAPs, so it's the max withdrawals of 16 and the max consolidations of 2. And it will then always need updates in the future. Every time when we introduce new state changes from system contracts, we would also have to update this number. and… Yeah, also if we…

Barnabas Busa: Increase level.

Toni Wahrstätter: I'm not sure, I'm not sure, but I would assume the simplest would just be to simplify The formula. By just not using those constants, and we should be fine too, because we don't… it's just for preventing DOS from an invalid block. So it's not like a super serious attack. But definitely something we have to, We have to make sure that we are not, vulnerable.

Barnabas Busa: Makes sense. I have some other comment, that it should be possible to construct a block, which violates this constraint, because then you will have invalid AVM execution. Jason, do you want to also add something else?

Jochem Brouwer: Yeah, I just wanted to note it, because this constraint It's basically a check which you do on quickly invalidating the blocked over access list. But it should not be interpreted as, like, a constraint which should be checked in the EVM, because you cannot constrict such a block-level exit list.

Toni Wahrstätter: Yeah, exactly. This will be something outside. When clients receive the block level access list over the engine API, this constraint can directly be enforced. So you would directly count how many items does the Block Love Access List have. And if the number of items is already unrealistic compared, with respect to the gas limit, then clients should invalidate the block immediately, without even starting execution. And this is why we need a We need to agree on the formula here in order to make sure that all clients invalidate that block early.

Barnabas Busa: Okay. Well, let's target to check this in the next DevNet, I think, and put it in the scope of DevNet Street. Then there's one more open question regarding an execution API, question. Tony, maybe you can also give us an update regarding this, Pierre?

Toni Wahrstätter: Yes, let me quickly pull it up. Okay, this was the… JSON RPC methods, right? The JSRPC methods were simplified, so… We don't use by block number or by block. hash? Anymore? No, sorry, we, we now use block number or tag, or hash in the JSON RPC. I saw from Karim and Barget that they already approved those changes. Yeah, I think we have an agreement that we go for this. I already updated the description, the PR, so yeah, please have a look, and… would be great to get those implemented for Definite 3. Also, one change compared to DEFNET2 would be that we don't return the… RLP bytes in the response, because this is a user-facing method, so it would be great if we returned the JSON-encoded block of access list.

And the PR, you link in the chat is already, up-to-date with that.

Barnabas Busa: Thank you. Does anyone else have… Anything to add to this, or the previous PR? In case not, maybe we can ask Erigon regarding their readiness for… Balled up into?

Andrew Ashikhmin: Right, so, yeah, we're getting closer, so I think it will still take us a few days. My estimation is that by the end of this week, we'll be ready.

Barnabas Busa: These, the EIPs, or the PRs that we were discussing today, are going to be scoped for the next DevNet. So you don't need to have these, to be onboarded for that material yet.

Andrew Ashikhmin: Right. So, and, the, is get block access list by hash and by number, the, the previous, the previous variant, is it also not part of DevNet2?

Barnabas Busa: No, like, it's… it doesn't really matter, because it's, no service is using this yet. Okay.

Andrew Ashikhmin: Excellent. Okay, got it. Yes, so we are basically… we're working on… we have some draft implementation of everything, but there are still some test failures, so we are working on fixing those.

Barnabas Busa: Great, thank you. Would we have any other updates from CI clients that would want to be onboarded in October Access List DeW2? Doesn't sound like it. So maybe we can move on to the next topic. Which would be gas limit changes. the ETH70 update, last week we launched a new DevNet called NFT DevNet 10, where we activated ETH70. Hmm… maybe someone from… Oh, is that Marius, maybe? Can you give us an update, regarding how this network is going?

Marius van der Wijden: Sure. So, NFT DevNet 10 was launched, and it has some transactions that are not able, like, you cannot sync them anymore if you are Snap-syncing, because the receipts are too large. And we have confirmed Netherland and Gath Current masses are not able to sync the network, and with the ETH70, they are. If you are a client that is trying to implement ETH70, you can just yeah, basically use NFT DevNet 10… In order to, verify that your client is able to… W.

Fabio Di Fabio: Yeah, on Beto's side, I want to share the progress. I'm able to sync the network. I'm… with, externally, so I'm connecting to the DevNet. And I'm finalizing the code, so I can also join directly the DevNet. I think these, this week, middle of week, we should be able to… To join the network.

Marius van der Wijden: Very nice. I think, Reth and Erigon are not… it's not super high on their priority list, because… they, Pull nodes, so they will sync everything anyway. But… It would also be nice for them to serve ETH70. And also, ETH70 is now a prerequisite for ETH71. Eth71, adds a method to get block access lists. And, yes. So, if you want to be, spec compliant, Erigon and Reth, you also should implement ETH70, and then ETH71 for, I think. We decided to move it to Definite 3, right?

Oh, definitely.

Toni Wahrstätter: Yeah, exactly.

Alexey Osipov: From Nethermine's side, we are testing. with, more corner cases. I see now that, either guest sense, nulls, or we, read it as, like, now a race, and block is empty, so I'm trying to figure out it now. And, we'll test, more pairs, like, synchronizing from Another mind, another mind, guest another mind, and so on. Another thing is, Whether we should split packets… should split receipts that are not, like, very big, but still significant. For now, I implemented it in such way that if Something's bigger than one sort of, 10 megabytes,

We can split it… split it… And, yeah.

Barnabas Busa: Alright, so just to recap, for local accessories.f3, we're gonna be adding the, the EIP… changes for, the DOS attack. We're gonna be adding the ETH71. Where 870 is the, prerequisite, and we're gonna be adding the new, RPC call, just an RPC call, that we just discussed. Is there any other change that we expect for Plotin of Access List 3?

Toni Wahrstätter: I don't think so. Don't think so. Only the optimizations, so we wanted to have all the optimizations for… I mean, this is independent from definite 3. We wanted to have them some… sometime between Definite 2 and Definite 3 to make sure that We can finish the benchmarking. But apart from that, maybe the engine API methods, right? There are still the engine API methods. That are also in the scope for DevNet3.

Barnabas Busa: Yes, Fabio?

Fabio Di Fabio: Yeah, I was, thinking about… having, both ETH70 and the ETH71 in the same, bold DevNet 3, does it make sense to just use Merge them together, and have only one… new version of the P2P protocol. It's not a big deal, just to avoid having… Double. to just, deprecate, ETH70. As soon as we have TH71.

Barnabas Busa: I think the idea was that ETH70 is, ready to be activated without any implied access list code.

Fabio Di Fabio: So, before Glamstadam, Okay, makes sense, yes.

Barnabas Busa: Regarding timelines, hopefully we can launch the MS3 sometime next week. Maybe middle of next week? Maybe 25th of February? Cette un pose a… Target? Would everyone be okay with that?

Marius van der Wijden: kind of depends on the other EIPs. If we want to add the other EIPs, I would… Probably… I think we would probably need a bit more time. If we just say, ETH71 and… And the diff… the changes to Bell. Then I think next week should be fine for us.

Barnabas Busa: Alright, Regarding the scope, I completely missed last week's all core devs call. What was the decision there? Which EIPs would be making it into DevNet Street? Okay. So the… was that the one?

Toni Wahrstätter: If I remember correctly, there was 8037 and another one. I forgot which one it was now.

Ansgar Dietrichs: Yeah, as Maria's saying, the, contract says one, Exactly. 7954. And then I think, if I can remember correctly, that one, though, I would double-check with people, is that we hadn't made a call yet whether, possibly, we already have E70, E71 ready. I think that one we just wanted to see. Right?

Barnabas Busa: Yeah, that sounds good. Ben?

Ben Adams: There were a few EIP adjustments as well, like… Changing how… Was it swap-in work? Which I think need to be. scheduled to the change on the fly.

Barnabas Busa: Perfect. Would you have a PR for that?

Ben Adams: I think it was a comment on the last… I see the… I'm not sure.

Ansgar Dietrichs: And yes, sorry, I wasn't aware that I should look into this before this call, but from my memory, I think there was one suggestion at which that was actually rejected, and the other one was just put up for discussion, so I don't think it was decided yet. It's my understanding, but… Maybe I misremember.

Barnabas Busa: Yeah, I can… I can dig that up after the call and, put together a… spec sheet for the next 3. And then we can, Maybe discuss timelines for, on this next week. Let's… let's just try to have everything implemented, 1837 and 7954, and, deeds 17 and 71 as well. And then, let's see if we can still, keep the target date next week, Wednesday. And if it's too tight, then, we just push it maybe a week. to the first week of March. If that sounds good. Mario, would you like to share your concern?

Mario Vega: Yeah, I mean, it's… it seems like an easy change, but do we still have to refill the tests with the… 8037? To be honest, I'm out of the loop on the status of this, in terms of tests, so I will have to check with the team to see if we have done any meaningful progress. But yeah, I'm still concerned.

Barnabas Busa: Okay, does that mean that you would prefer to… yeah, Spencer?

Spencer Taylor-Brown: Yeah, sorry, so, we have, like, a specs PR up for 8037, no tests yet, so I do… share the same concern as Mario, and I think there are some kind of small… spec changes that might be needed for some EIP interactions, so I think Maybe I can comment, or, start a thread in Discord with, some of these potential spec changes, or even create PR, and then we can get movement there. But yeah, I do share similar, concerns with Mario. And just, yeah, because we haven't got tests yet.

Barnabas Busa: Right, would you guys prefer if we just push AD37 outside of the scope of this?

Mario Vega: I don't want to push anything out of scope that was decided on ICD. I think we can start, like, pushing for the tests. I mean, the most concerning part is that, So, some tests are definitely gonna break. I mean, what… we can… we can assess whether it's too many, and just, take them off the release, for example, that could be one possibility. So we only fill the tests that don't… do not break, and we can, run, make a release for the clients to consume, for the tree. But still, it feels a little bit rushed to me, in my opinion, yeah. Yep.

Barnabas Busa: Yeah, so Marius' suggestion would be to push it to the first week of March, or remove the EIP. I would just say that let's try to aim for the 4th of March instead of the 25th of February. And try to ship everything. Would that… Make it better for the testing team as well?

Mario Vega: Yeah, absolutely, absolutely.

Barnabas Busa: Thank you. Regarding another… was it simulate V1, so we would want to have it simulate, Just an appreciated to every single EL client by Divino Street as well. Hopefully, this can also be done. Obviously, that's not a breaking request, but… It's something that's gonna really help us, do some benchmarking. So, please try to get that done as well. And, yeah, Ansgar also mentioned that if 70 would be part of Dentistry, where clients can still support it, or they can still participate even without supporting the protocol. So, yeah. I mean, we don't have to stress test, basically. those big receipts on, Business 3. I think we have a dedicated network for that, that's good enough.

I think 871, Mmm… Last time I checked, I think guest also didn't have its limit. But I can… I can double-check it, Marius. There was the daily hive test that's running to test for these endpoints. Yeah, I can… I can get back to that, mars. Regarding implementing 871, whether we want this in demonstrope or not. What is the ER's take on this?

Marius van der Wijden: Sorry, Egan?

Barnabas Busa: Would you guys prefer to have it 71 in the scope of DevNet Street?

Marius van der Wijden: I don't know, it depends on… I think it kind of depends on the clients that have not implemented ETH70 yet, because they will have To do much more. work.

Andrew Ashikhmin: Yeah, I would prefer if 71 to be postponed, because, yeah, it will be too much to implement both.

Barnabas Busa: Annuity.

Andrew Ashikhmin: We have everything done before.

Barnabas Busa: Yeah, so it's RESH and Erigon, right, that have not yet implemented E70. Anyone from RESH can also comment on it?

Jen: Yeah, I think we provided an image. Let me get back to you. I don't see any blockers for Y70 for us.

Barnabas Busa: Right. Okay. So if it's only Erigon, then I would actually suggest that we keep it in the scope of DevNet 3. And, possibly launch without Erigon, for the next 3 as well, and then, previously have 4 clients at Genesis time, and then we can add everyone down the line when the implementation for them is complete as well.

Karim Taam: Well, just on the Bizu side, we have it, but for the moment, we are not passing half tests, so… I don't know if we have the complete implementation, or if we need to add some fixes. But yeah, just wanted to share that.

Ben Adams: Erigons, fine for sinking, aren't they? Because they don't actually care about the receipt. It's just for serving. That would be the problem. Is that correct?

Barnabas Busa: Right, but that's for 870. We are not talking about 871.

Ben Adams: Oh, sure, sure.

Barnabas Busa: Oh wait, that's also optional.

Marius van der Wijden: Yeah, it's… ETH71 is… is… provides the way of, like, querying dials from other nodes, and that is only used for sync improvements, right, Tony?

Toni Wahrstätter: Yes, exactly. So, we might not need it, but definitely, I guess.

Marius van der Wijden: Then it's optional.

Barnabas Busa: somewhere. Then we're gonna put it in the optional bucket, and then whoever, implements it is good, and whoever's not. Not. So that's… Let's keep it at that. Okay, anything else regarding local access list? If not, then maybe we can move on to the sales side, EPBS or not. Do we have any client updates from… Any sales teams?

Stefan Bratanov: I can speak from Techo. Making a little bit of progress. So we implemented the Beacon API for the execution payload. But at the moment, we don't support finalized retrieval of execution payloads. So I guess for DemNet0, that'll be good, so that nodes can sync. Yeah, I'm making progress, but still not there yet.

Barnabas Busa: When would you expect the code to be ready?

Stefan Bratanov: Maybe we can have some version in the next couple of weeks, I guess. And then polish it from there. But, yeah, maybe in the next call, the next testing call, I'll be able to provide better… Timeline for that?

Barnabas Busa: Nope. Yeah, because the original idea was to have our desktop by mid-February, which is basically in two days. So that is probably not reasonable for Taku.

Stefan Bratanov: I don't think so. Well, we can have some cock version, but I would like something more complete, so… Yeah, I think it'll be another week, at least.

Barnabas Busa: Okay. Anyone from prison? Or lighthouse?

Gaia: Yeah, for Lighthouse, we have a DevNet Zero branch that we've been testing locally in, like, a Lighthouse-only Kurtosis network. we're working through some bugs. I think we got block production working, but… Somewhere along the lines of, gossip envelope processing and importing, there's a bug. So we're working on fixing that, and we're hoping by the end of the week, we'll be ready to, like, interop locally with another client, maybe, like, Consensor or something. But yeah, I don't think we'll be ready for February 18th either.

Barnabas Busa: Okay, thank you. Nimbus?

Dustin Brody: Sure. So, I… we have, I mean, Alpha 2 specs, we have block broadcasting, we have most things where starting to work on a fork twice, I know that's not, sort of, super high priority for this, but envelope… the, sort of, the frontier for us right now is really, the envelope… things like envelope syncing. So yeah, Yeah, the gossip stuff we should have, but this is now things like the, sinking, and if the… Backfilling, sort of, of it, when we… when we miss one. through RecRISP, things like this. So, that's… Yeah, I would say, yeah, not… Two days for… two or three days, yeah, not… not gonna, happen. But… Yeah, well… I mean, the other thing is that we have been trying to, test on kurtosis and running into, some of the same,

sort of issues that other clients have reported. I've linked this in a couple places, and I know the steel, the AllCL steel, steel channel. So, yeah, and we… well, I say we, I… it was… this would be… Caleb, I guess, would be the one who's been… who has tried this since, and I don't know what the outcome was, but I know that it was, a little challenging. We were kind of blocked in proceeding to find out how far we… how well it worked, because it just ran into some of the issues on the EL, Sort of mock side. That was earlier today.

Barnabas Busa: That should be fixed, no, I think.

Dustin Brody: Okay. Yep.

Barnabas Busa: Thank you. Luther?

Nico Flaig: So we are having fork Choice, fully implemented, but still needs to be merged. There are a few, outstanding PRs we need to merge. But once that's done, the main part that's missing is just wiring everything up, so the block import works, which will be the major work still left. Yeah. I think we'll also need more than two days for that. It's probably 1 or 2 weeks.

Barnabas Busa: Brendan? Nobody from grinding around. Nobody from prison, I guess? Okay, anybody else has anything else to add, to EPPS.0? Now, this morning, I was actually able to get a consensor To pass all the tests and, able to… do the epoch transition into glass without any balls, just the APBS stuff. Yeah, it's a very unperforming Python client that I webcoded, and are this working?

Also, it cannot appear to any other normal client, so it's not really production ready. Oh, yeah. Next topic would be stable out. Regarding Perf. Is anyone on the call regarding that? I know Netherland had a database issue. Maybe we can get an update on the latest.

Marius van der Wijden: Yeah, I think the network is dead right now, right? At least that was my, my last, last, what I read is basically… All clients… died, but never mind made it the furthest. And, so now NetherMind also died, and we have a chain that is finalized, where we don't have the blocks anymore, because no EL client was able to keep up. And, now the only way of doing that is, to basically re-og the chain. And, create a new consensus layer. Otherwise, we would have to unfinalize something.

Barnabas Busa: Right. Let's discuss this offline then. I think we might need to do a relaunch of the CL chain then.

Marius van der Wijden: Yep.

Barnabas Busa: Okay, that was the agenda for today. Unless anyone else has anything else to add? I can call it a bit early today.

Marius van der Wijden: Take care, y'all.

Barnabas Busa: Thanks, everyone, for coming. See you all next week.

Mario Vega: Thank you, bye.

Toni Wahrstätter: Thank you, bye-bye.

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