All Core Devs - Consensus #180

Transcript

Paul Harris: I know our European guys should be at least joining, hopefully.

Potuz: What time is it there, Paul?

Paul Harris: It'll be 9pm in a second.

Potuz: There's no way in hell that you get me into a meeting at 9pm.

Paul Harris: It's a lot better than 12 midnight.

Potuz: Yeah, I think I'd much rather, like, 5AM than 9pm.

Paul Harris: I'd be happy with 5am as well, just not midnight.

Parithosh Jayanthi: Whoa, we already have some Aussies here.

Paul Harris: It's still late for Lucas, though.

Parithosh Jayanthi: Is your initial solidarity.

Lucas Saldanha: Hey, folks…

Potuz: What time is in New Zealand, Lucas?

Lucas Saldanha: 7pm.

Potuz: Oh.

Lucas Saldanha: Yeah.

Barnabas Busa: Perfect thing to get into a call.

Lucas Saldanha: Not too bad. 3 AM, so…

Potuz: I feel like if the world was flat. And, I don't know, the Indian Ocean was… or the Pacific Ocean was larger, would have less problems.

Parithosh Jayanthi: Let's wait another minute. Please call your friends to tell them about the new time.

Barnabas Busa: Wake up the North Americans.

Parithosh Jayanthi: Right, now we're at half the number of people.

Barnabas Busa: Yeah, it doesn't…

Parithosh Jayanthi: Cherish it, Lucas. Take a screenshot or something so you can frame it.

Barnabas Busa: Is wherever you're asleep.

Parithosh Jayanthi: Okay, let's get started then. Barnabus, do you want to start us off with DevNet updates? How's Glamsterdam DevNet 5 going? What's… what are things looking like?

Barnabas Busa: Sure. So .NET5 is going quite poorly today. It went nicely yesterday. there was apparently a peering bug in Prysm, and Grandinee also had a fork choice bug. The fork choice bug was triggered by a malicious Lodestar client that Nico has built yesterday, or the day before that. As far as I know, the Grandine bug is still not fixed, and the Prysm bug might be fixed. It's untested as of now. Potuz just pushed a new commit, and I'm building a new image should be rolling out in a Probably half an hour from now. once the Prysm bug is fixed, we should be, going back to finalization, and Other than that, I think most of the other clients were quite stable.

Parithosh Jayanthi: Potuz, do you want to expand on why… why you guys were sending invalid PTC attestations, or, like, what triggers it?

Potuz: Oh, this was a great find by, by Ayton, and was corroborated by Nico and his bot. So the issue is quite nice, because we need to have a discussion anyways as to what to do with this. So the issue is that PTC attestation should be sent even for if it's not on your… on your… on your branch. Like, if you're… you're a PTC attester, the block that comes is not your head, but the payload that you see for that block is timely, you should attest to that payload, or you… if it's not timely, you should attest that it wasn't timely. The problem is that we were determining our duties with our head state, any other duty for the validator, so the head state is telling us, you are in the PTC committee, you need to send a PTC attestation.

And then we call the beacon to get a PTC attestation, and the beacon says, well, for this slot, I have seen this block with a timely payload, but this block is in a different shuffling, and in that branch, we were not in the PTC committee. So, the validator was asking for duties on one shuffling, it was sending an attestation for a different shuffling, which we weren't in the committee, and then everyone, including ourselves, weren't, were not validating that PTC attestation. We don't check things that we broadcast ourselves. We could have saved it by checking, but I think it's just better not to do this. Anyways, what we should be moving into is into trying to send, at the stage, PTC attestation for different branches on different shuffling. Even if it's not our head shuffling, it's just that we need to check that,

that, well, that, that we are in the committee in that shuffling. The fix that I sent now is the lazy fix. If we… if we see a block for the current slot, but we're not in the shuffling, then we don't even check if we need to send a PTC attestation, we just don't send anything.

Parithosh Jayanthi: Okay, nice. So this was already happening, and this then triggered the peering bug, or what was the…

Potuz: Well, this can only… this can only happen when, you have, a non-finalized situation and very long forks. So we already had these very long forks because of fork choice issues on adjusters on different sides, and then on top of that, we… as soon as this starts happening, then we get isolated, and now we are… every single node of rhythm is on a different fork.

Enrico Del Fante: It means that you… you saw, PTC votes coming from other… other clients. correctly voting for… for the forks? Or you were the only one attempting to do that and doing it wrongly?

Potuz: I think we are the only ones that are doing this wrongly. Oh, Ayton found some Nimbus blocks, But even… even with the same dependent route, 8,000 Nimbus blocks that were attested incorrectly.

Nico Flaig: Yeah, so I previously did some analysis of clients, and it looks like every client just uses the canonical head, or the canonical branch. So, they will not even cast PTC attestations for that branch that you attested to. Because I think it was the Grandinee branch, right?

Enrico Del Fante: Yeah, I believe Teku should, just… Consider the canonical.

Potuz: Well, the problem is that if we are, if we are eventually in a situation in which we're not finalizing, and we have several branches, then if we only send for the canonical branch, we will never achieve quorum on anything. As soon as there's two branches. Then, proposers are going to be free to reorg every payload on every branch.

Enrico Del Fante: Yeah.

Potuz: I think it's a serious liveness risk if we don't… I think we should do an honest attempt to send every attestation, even if it's not on our branch.

Enrico Del Fante: Yeah, I believe… Any, any… low participation branch could… can easily have nothing on… No PTC. So it will be killed.

Potuz: Yeah, that won't be a problem. The problem is if we have a split. If we have.

Enrico Del Fante: Yeah, yeah, I mean…

Potuz: And then, this is kind of easy to do for a powerful agent, create a split for little time, and then we have this proposal boost to try to prevent it, but then, even without proposal boost, if we have no PTC on either side, you can just maintain the branches without any payload.

Nico Flaig: Yeah, so the one thing you mentioned, if we want to do PTC duties per branch, I think this is really difficult. I think this… we never did this, where, like, you do duties on a non-canonical branch, because we always, have the head reorg, and then we track the dependent route, right? So we… we never did this before.

Potuz: Yeah, I think it's… I briefly looked yesterday to try to implement it as a fix for this, and I figured, no, this is going to be a nightmare, so I just sent the lazy one. I'll study if it's too difficult to do, but… It's something to keep in mind.

Nico Flaig: Yeah, there was one idea, so the problem, right, is that we have this absolute number on the PTC where you need to cross the 256 threshold, right?

Potuz: Yeah, but if you want to do it relative to the number of voters, that's even worse. We considered this early on, but that's… that doesn't work even worse.

Nico Flaig: Also, there's another idea which, came in proposed yesterday when we had some random discussion, which is, you basically use your local view, so if you saw the payload timely and available, you will always, vote for that, or pick that. and not listen to the PTC, so you don't need the threshold, and only if the PTC has a maturity against that payload, then you will change your view. So you don't rely on this, or you don't have this problem, right?

Potuz: I… I think this fails, it's too early for me to check, but I think… so we decided not to have attesters, making the decision on the payload, but the proposer, and then the attesters following the proposer, because otherwise, I think this would fail this, the security for the… This would allow, like, late builders, for example, to collude and try to do an ex ante reorg. I mean, if you're going to vote for full because of your view, then you're not going to permit… it's going to make it harder for the next proposer to reorg a payload when he should have reorged a payload, and I think you just make ex ante reorgs easier this way, by a collusion between the builder, so…

Yeah.

Nico Flaig: Yeah, I'm just wondering if you have the safeguard when you have the majority of the PTC saying it was not timely that you… would trust the PTC.

Potuz: Yeah, but the problem with this is that if you hold, like, say, 2% and you create a split for 49% of the PTC saying something, then you can prevent always the majority of the PTC to achieve anything. We'd only… With only 50%, with only 2% of your stake.

Nico Flaig: So is that the issue you also described, or… there was, like, an issue you opened, I think.

Potuz: Yeah, yeah, so it's similar to that.

Nico Flaig: Okay, yeah, I think I haven't thought enough about that to give you an answer, but…

Enrico Del Fante: So, is this a general problem of small committees? So, whenever we decide to… address anything in the chain. With small committees, we end up in this possible situation, correct?

Potuz: I mean, it's… the general problem is that we need to deal with a situation in which a malicious actor can create an arbitrary split, but we are under the assumption that the smaller committees are chosen in a uniform manner, randomly, from the whole committee. So, we are under the assumption that whatever split this malicious actor creates is the same split on the attester's side and on the PTC side. So the issue that I raised, I think it wasn't so… so dangerous, because it would create a different split on the PTC, which is a small committee, and the large committee. But I think for what Nico is describing, this is not necessarily the case.

Nico Flaig: But also, don't we have this already? So if the… if the tester didn't see the payload timely, but the PTC majority says it's timely, we'll go with the PTC, right?

Potuz: Yes, correct.

Nico Flaig: So, and why does this not suffer the same issue as the other way around?

Potuz: Well, because the… you follow the proposer, so what the attesters do is they follow the proposer, they don't follow whatever the PTC says. They follow the proposal, and the PTC is there just to allow the proposer to be able to decide on reorging.

Nico Flaig: Yeah, but with the current spec, the proposal also follows the PTC, right?

Potuz: Not really. So the proposal follows the PTC only in the case where there's a majority that says it wasn't timely.

Nico Flaig: Oh, exactly, but that's the case I want to have as attesters as well, basically.

Potuz: Yeah, and I claim that making the attesters, make the decision instead of the proposer. Comes with a bunch of ex-ante reorgs that become easier. then this was the reason why Francesco wanted… was against having this just in poor choice. We could have just put this in should extend payload. And that would force attesters, instead of, like, this new should build on full. And the reason was because we don't want attesters to make the decision. It also has some liveness issues, too.

Parithosh Jayanthi: Okay, so the fix will be launched on the DevNet soonish, or what's the…

Potuz: It should be already building, but I'm not sure if, I'm not sure if we're gonna be able to catch up to head, though. If we catch up to head, it should be fine.

Parithosh Jayanthi: Oh, nice. Wait, why wouldn't it catch up to head?

Potuz: Well.

Barnabas Busa: It's rolling now.

Potuz: Everyone was having trouble set… everyone was having trouble sending, range… Range payloads and range blocks, so…

Parithosh Jayanthi: Yeah.

Potuz: We start down low, but downscoring everyone again.

Enrico Del Fante: By the way, did you double-check that it's not your bag, and it's actually… Pints…

Potuz: No, I haven't. So last… so we do have, one bug in which So, I'm sure clients are sending something incorrect, because we do log. There is an… there is an inconsistent, there's an inconsistent payload and block. So, this one, we're sure. Some clients are sending inconsistent Payload and blocks. But the problem is that, we are downscoring the… we were downscoring the wrong peer.

Enrico Del Fante: Okay.

Parithosh Jayanthi: Okay, so plan A is gonna be, yeah, recovering DevNet 5. Let's hope that works out. Nico, do you maybe want to briefly talk about, Death Star and what it's doing, and… Maybe what types of bugs we should be focusing on?

Nico Flaig: So the current behavior is really simple, so it just builds on empty, basically. So even if the payload is timely, it just tries to build on empty, and then the… what we should, like, ideally, what should happen is that block should always be orphaned. But, there were some cases where Grandinee and Nimbus together still voted for the block, and then I think… So I… I think, put us, we concluded that, so with… there was, like, a threshold, and then if the Death Star block gets proposal boost, it, like, barely crosses the threshold to become head. I think that was the observation, because we had also, like, roughly… 20% of attesters voting for it, wrongly. So yeah, so that's basically what it does right now.

Parithosh Jayanthi: Nice, very cool. So, once the fork choice bugs are fixed, Tekunically, everyone should be able to handle this.

Nico Flaig: Yeah, DevStar block should never be part of the canonical chain.

Parithosh Jayanthi: Makes sense.

Enrico Del Fante: During my testing, I also had my own Teku, AvilTecho, building late beacon blocks and late… and publishing late payload. I was thinking if this could be… I can… I can provide, An image with the additional Parameters to… to maybe include this in the… in the… in the network if we want to do additional tests. The test for choice.

Parithosh Jayanthi: Yeah, that would be nice. Thank you. Cool. Okay, next item, is it worth discussing DevNet's plans, or should we just for now, focus on DevNet 5? We take it on ACDT on Monday? Okay, I'll take it as focus on DevNet 5 for now. Let's move on to Glamsterdam. The first topic, on the agenda is from James. Do you want to introduce it? Gloas Proposer Preference EIPs?

James He: Sure. Well, this is the Gloas, Proposer Preference APIs, PR for the Beacon API. So this PR, introduces the, two endpoints, the POST and the GET for proposer preferences. It also adds the, server-side event for proposer preferences, and it deprecates the, prepare beacon proposer and, register validator endpoints. One caveat is with the deprecation of the prepare beacon Proposer endpoint. I added to the description of… Beacon Committee subscriptions, that, that endpoint will be used to track

what local validators are connected to that particular beacon node. Right now, Prysm is using Prepare Beacon Proposer's endpoint to do that tracking? But, this is recommending we switch to the Beacon Committee subscriptions endpoint, after this change. So I just wanted to raise this, if there's any… any more concerns. I think all the comments were addressed. So, just wanted to move that along.

Parithosh Jayanthi: Nice. Are there any objections to this change? Okay, cool. Then I'll leave it to the maintainers to merge it in. The next one we have is from… I wanna say, Cayman? Yeah, it's from Cayman, about mandatory quick as primary transport. Is Cayman here? Or can someone speak on our behalf?

Matthew Keil: Yeah, so, feels like Quick is kind of the default, in many, many clients today, even though, We specify, The standard, transport, and so we're proposing to make quick the default with the fallback. So not really breaking change, but just a step towards, towards QUIC as a… as the… as the default transport.

Parithosh Jayanthi: Okay, nice. Does someone from Lighthouse maybe briefly want to talk about that application of Amplex? I think they're doing it soon, right?

kingy_sigp: We're not, we're not deprecating MPLEX, we're just, putting it behind a flag. So it's… it will… you can still run with NPLEX, but the default behavior will be quick.

Parithosh Jayanthi: Okay, got it. So yeah, I think it does make sense to have this in the consensus specs as well. I don't see… I don't think Justin's gonna be on this call. Is there anyone opposing adding this to the specs?

Lucas Saldanha: I think, The only thing for us in Teku is that we are just about to release support for Quick. It's still, experimental. So… ideally… Ideally, we wouldn't just, like, remove, quick, the default one, when we, negotiated the protocol is fine. complex on TCP, it's gonna be a bit harsh at the moment for, at least for the Teku nodes, because we are not enabling it by default for this release, because we want some time to do some more testing. So, we're probably gonna have… This release, quick, supported, but behind the feature flag, and the next release following the… the faux… you know, quick first, and, you know, whatever else later.

Parithosh Jayanthi: Yeah, Matthew.

Matthew Keil: Yeah, Lucas, we, we, were, taking a look at, that PR, and we do know that, or that, that branch, and we do know that, not everybody's ready for quick. We've, made it default on our client, but we know that not everybody has, and that's… it's just an incremental step towards A world where quick is the default, and the only transport, but, you know, obviously it's gonna take some time in order to test and just make sure things are stable.

Lucas Saldanha: Yeah. Yeah, making it the default is fine, because, you know, with the, vertical negotiation, if someone doesn't support it, it's just gonna fall back into TCP with MPLEX.

Matthew Keil: Exactly.

Lucas Saldanha: The biggest, risk for us, what we see is… that pull request on Lighthouse that basically puts it behind a feature flag. So, you know, for most users, if suddenly they are not supporting, TCP anymore with, with Implex, and that might become a big, a big issue.

kingy_sigp: So the reason we wanted to do this ahead of the hard fork is the upgrade rates for us on the last few Minor version bumps we've put out have been slow, despite there being vulnerabilities in those. And the time where we see the highest rate of upgrade is obviously at hard fork boundaries. So, if we make this change at the same time as Gloas, I feel like we're more likely to Create a, A situation, rather than… we have slow upgrade rates at the moment. We do it now, we run our nodes with the MPLEX flag on for a time to bridge the gap. We're less likely to destabilize things. That's the rationale, but…

Lucas Saldanha: So, when are you planning to release this? Like, the actual…

kingy_sigp: Within, by the end of the month, probably the next…

Lucas Saldanha: And do you reckon that's gonna be your final Gloas version?

kingy_sigp: What… what… that won't be our Gloas version, no. But I'm saying we don't… if we… if we… make quick default at the Gloas version, we are more likely to have a large amount of users upgrading to that version all at once, as opposed to upgrading slowly over time, which is what happens now for our users.

Lucas Saldanha: Yeah. I mean, I'm just thinking, is there a reason why that can't go on the next version, for example? Does it have to be end of this month?

kingy_sigp: we have… we have… So, yeah, we can talk about that, not in a public hall, but, yeah, there… yeah, I would… I would prefer to not have it as the default in our next release, but, yep.

Parithosh Jayanthi: Paul and then Sukun.

Sukun Tarachandani: So why are you removing MPLEX? You can just prioritize quickly.

Parithosh Jayanthi: Other way… other way around. So Paul would go first, and then…

Sukun Tarachandani: Sorry.

Parithosh Jayanthi: So…

Paul Harris: I think it's a very similar question, actually. I'm… the suggestion that I've had offline with Lighthouse and stuff has just been that… It continues to be at least enabled, if not default, and that would be perfectly fine. The problem that we have at the moment is that it's not really implemented fully and tested, so… I mean, it's implemented in theory. we just need more time, so I've asked… That we're able to… Get… have the month to get ours ready. And yeah, that's kind of my expectation at the moment, so that's what we're working on. But I think disabling it completely by default is a bit of a risk, and it's… There will need to be a really, really big reason to do it, I think.

kingy_sigp: I mean, I'm not sure how much of a risk it is. We accidentally released a version with it disabled. For about 2 months, and nothing happened previously. So… I'm not super concerned.

Paul Harris: We are a majority client on the network, so it does severely impact on peering, that's all.

Parithosh Jayanthi: Yeah, so, Sukun, and then Potus.

Sukun Tarachandani: I mean, I have the same question. There is no reason to disable MPLEX, right? We can prioritize quick dials whenever the peer supports quick.

Parithosh Jayanthi: Yeah, photos?

Potuz: I empathize with what Lighthouse is saying, assuming that there's some actual reason that, well, anyways, let's probably move on. But, You should weigh in… The potential bugs that you may have against the situation that you will cause. forcing Teku nodes to reach out to non-Lighthouse notes, and then that means that a big parcel of those non-Lighthouse nodes, whatever other clients are, are going to be having to serve Teku nodes, therefore taking less peers from Lighthouse itself, that would isolate Lighthouse more. So if we create a bunch of clusters in which all of Lighthouse nodes are self-peered, because they are losing PRISM nodes now that do support QUIC, but Prysm is now taking, like, instead of 20% of their peers being Teku, now they're going to be 50%, because, well, those Teku nodes cannot reach out to Lighthouse.

So… so this… this is self-reinforcing. It is a danger in itself.

kingy_sigp: Yeah, for sure. Look, if there is a, an overwhelming consensus that we should not do this and give, some more time. We can… we can do that. That's… we're not… we're not trying to hardline anyone or… or do anything crazy here. We've just been pushing this for quite a long time, and it continues to be a surface of, Something that we have to continue to maintain in the current environment. Is taking resources away, and we feel like we should be pushing to move to quick, so, but if, if, Teku can… Pekka can get there in the next few weeks, we can hold off, that's fine. It's not the end of the world.

Parithosh Jayanthi: Lucas and Matthew?

Lucas Saldanha: I was just looking at the pull request, Because there's a pull request on mandating QUIC as a primary transport. Oh, so are we gonna… So the idea is to make quick the primary one, and… be completely optional? or a… mandatory phobic, because I think, like, looking at the wording through all.

cayman: It's specified as should, and not as a must. Right now, so that's, like, I guess a strong recommendation, but…

Lucas Saldanha: Okay.

cayman: If other people have other opinions about that, happy to change it.

Parithosh Jayanthi: Matthew?

Matthew Keil: For what it's worth, I definitely support Potuz's opinion that it causes instability in the network. We do sympathize with your situation, Kingy. We, you know, we're aware of it. But, you know, we do feel the correct stance is, quick should be default, but there should be a fallback, and then the next step would be to remove the fallback at some point, you know, once Nimbus also, has Quick handled and Teku's stable.

Parithosh Jayanthi: Is there somewhere, people would be able to chat with you on this, Kingy? Maybe someday on the Steel server, where all CRs can chime in in one place?

kingy_sigp: Yeah, it's okay. I think that, I think everyone's kind of reading between the lines. I think we can… If that is… The consensus, we can go that way, that's fine. We can have quick as default and have MPLEX as a fallback. I would strongly, strongly, really, really… Beg that we get this done soon, because… We continue to have to… maintain a surface that we would not like to. So, can we just commit to doing this before? Before GLOAS too, so we don't all have this big change all at once, that would be great.

Matthew Keil: Is there anybody from Nimbus on the call that can speak to where their WIC implementation is?

cayman: They posted in Discord a few days ago that they have the quick implementation, but it's not enabled by default, and that they will be enabling that soon.

Matthew Keil: Okay, so it seems like we're pretty close anyway.

Parithosh Jayanthi: Yeah, Lucas?

Lucas Saldanha: I was just gonna say something close to what Barnabas just posted. I think… I do sympathize with this, that, you know, wanting to remove this extra surface that, you know, you don't want to be using everything. So my suggestion would be we can have even the draft request for the consensus to basically completely remove support to it. As part of the spec. And just have it scattered, and for… Sometime in the future.

Parithosh Jayanthi: Yeah, Barnabas mentions, shortly after Gloas? It's not a bad idea at all.

Lucas Saldanha: But I think you should…

Parithosh Jayanthi: I don't.

Lucas Saldanha: If the glow was… we missed it. update, kind of nudge that, Lighthouse wants, right?

Parithosh Jayanthi: That's true.

kingy_sigp: Yes, exactly. I'd like to do.

Parithosh Jayanthi: Maybe it's not edited.

kingy_sigp: The lowest minus 2 months, I think, would be preferable, you know.

Parithosh Jayanthi: Yeah, maybe when we're doing testnet releases is a decent time. I do like the idea of not bad.

Barnabas Busa: Catching a dog.

Parithosh Jayanthi: along with Gloas, because that is… yeah. I don't want to increase the surface area for things to go wrong with Glamsterdam.

Lucas Saldanha: Yeah.

Barnabas Busa: Yeah, like, are we testing quick now on the DevNets? Have, like, all the clients added Quick support as default, for example, Teku on their feature branch for Glamsterdam DevNet 5? Or it's on a complete orthogonal… Glenn.

Lucas Saldanha: We have, we have support merged in our master branch, I think we, we might need to backport it to the DevNet branch.

Barnabas Busa: Can you please do that? And then, We can check who else is missing. I think, at that point, it's only gonna be Nimbus.

Lucas Saldanha: And we also have that pull request on Cortosis to, be able to set up. But anyway, we can talk about it later.

Parithosh Jayanthi: Okay, Thank you guys for that. Leo from Miga Labs has a topic he proposed. It's a beacon API change. To talk about, validator states, you have the Florio.

Leonardo Bautista-Gomez: Yep, can you hear me well?

Parithosh Jayanthi: Yes.

Leonardo Bautista-Gomez: Yep. Yeah, so this is just a minor change on the Bitcoin API. It's related to validators and deposits. The thing is, you know, 6 years ago, when we were working on Phase Zero, we defined two estates for deposits, which were pending, initialized, and pending queued. That basically, at the time, were defining exactly where your validator were in the… was in the workflow, you know, being activated. Now… you know, since Spectra, we have, significant changes. So we had multiple EIPs, that changed things, significantly. In particular, EIP6110 and EIP7251. And we changed the… the queue is not in the process registry updates anymore, which is where you were getting the pending queue status. But now, the real queue, the churn break.

It's moving… it has been moved to the state pending deposit, which happens much, much earlier. In the… in the workflow. So basically, what we want is just to rename, these two states so that they accurately, you know, reflect, where the validator is in the… in the workflow being activated. Because when you are right now getting the, you know, pending queue, you are not in a queue anymore, actually. You are just waiting the look-ahead plus one epochs, and all of the value vectors that are eligible to be activated will be activated, so this is not anymore. a queue in any possible way. So yeah, it's just about renaming this. It's, I think it clarifies things, a lot, and it helps, people that are building block explorers and…

indexers, to reflect, things more clearly. So the blog post is, yeah, has been shared in the, in the chat, and you also have the, TR there, so you can, you can take a look at it. Thank you.

Parithosh Jayanthi: Yeah, I agree. I think if such a change would need to be a version bump as well, so we don't break, existing tooling, but, yeah, it would be great if plan teams can engage on the PR.

Leonardo Bautista-Gomez: Yeah, absolutely. In the blog post, we mentioned two ways of doing this, and we do understand that this is a breaking change, so that's why we are asking the community to provide feedback. We could actually maintain, you know. the old labels at the same time… at the same time that we put new ones for a period of time, and then later renew them. Or we can just do a break-in change and go ahead with that. We will want to hear from the community what we think is the best way to move forward.

Parithosh Jayanthi: Sounds good. Thank you. Yeah, please engage on the PR. Continuing on the Beacon API topic, Barnabas had a proposal for, extending the Pure API. You… you have the floor, Barnabas.

Barnabas Busa: Yeah, so this is, basically a debugging endpoint, that is mostly used for us to be able to visualize, who is scoring down who, and, by exposing the peer scoring, values, we could actually build some nice, dashboard, possibly in DORA or somewhere else, where we could visualize, pre-scoring behaviors. And to do this, I think the… The best would be to add some optional fields in the node peers booking API endpoint, where we set the peer scores that are derived, from the From the different nodes. Curious what people think. the numbers itself don't really matter. We can… we can standardize on the numbers on the consumer side, so, like, if, you know, we're scoring between 0 and 10 on PRISM, and between 0 and 1,000 on Teku, we can just standardize.

Potuz: No, the number is fine, the number we always have. The reason might be… More problematic for us to get.

Barnabas Busa: Oh yeah, but the reason, yeah, the reason would be also just, nice to have. I think the peer score itself alone would be a huge unlock. The reason, would be just, I think one day.

Parithosh Jayanthi: Okay, yeah, I think people can… oh, sorry, Paul, go ahead.

Paul Harris: I'm happy with this one, I like it, but, yeah, the disconnect reason is the main… issue that I have, I don't think it would necessarily be able to be filled out, but assuming that that is not, like, the key… the key thing that you're looking to get out of it, I think it'd be a good win.

Barnabas Busa: This is a dance school reason, could be easier to get. Then the disconnect reason?

Paul Harris: I think so, I'd have to look at the implementation, but the… The actual score itself is fine, because all of that's in the peer context, but I don't know about why it's being downscored, whether that's in the context. But anything we can get could go out as an optional field.

Barnabas Busa: No, of course. Yeah, all of these would be optional, so it's a non-breaking change. I don't think we should introduce any breaking changes to this endpoint.

Paul Harris: Yep, and it might be even worth… I don't know how different clients handle all of this, but one of the things we do in the thought choice output is we have an extra data field where we can put extra fields that maybe might be relevant for, say, PRISM, but not relevant for Teku, so we could do something like that. If we needed to.

Barnabas Busa: So I would like to get this PR merged in, and then we can bike-shot the reasons later on, in case that we find some new reasons that we could summarize on, it would be good. If we cannot get the reasons. I guess that's also fine, but I would really like if clients take a look and actually try to get the reason. Damn, that's well.

Parithosh Jayanthi: Thank you very much, yeah, maybe make it the easiest version possible, and then… Maintainers can take care of the rest. The next section of ACDC is gonna be all builder-related, First thing is builder execution requests. Nico and Kayman, you have the floor.

cayman: Okay, so, yeah, we, of the CIP8282. Basically, we want to add a builder deposit contract. And stop sharing the deposit contract between validators and builders. So, yeah, we found… we were looking at… into this, The existing contract lets through a lot of… A lot of deposits, and There are ways of patching and hashing these deposits to avoid a DOS, but, We think this is a pretty big, complex testing surface that's kind of hidden right now. We looked into it yesterday, we saw a few attack surfaces, and Justin has a few more, and so the question is not, like. Well, we… we… I think we could, probably. Add caches to, to, like… Avoid having to do a bunch of, DLS certifications at once.

But it's more like, should we… And so this is kind of… I think this is a pretty simple, VIP that just routes around the problem at the design level, or at the Without, basically prevents the, the, even the ability of Having to deal with a lot of… Builder deposits at once. So the, the contracts themselves, they're… pretty much… they're almost identical to the EAP7002 and 7251 code. So there is a smart contract risk, right, with having to add a new contract, but I think that it's about as small as it can get. When you actually look at the… The deltas between the smart contracts.

Parithosh Jayanthi: Does anyone want to… ECAP? Do people have immediate opinions?

Dustin Brody: So… I'm not… I like the framing of this, of avoiding, I agree, avoiding the caching, as I've articulated this in the Discord as well, but… however, I'm not having read the EIP as it exists today, it's not that clear to me where the… sort how this achieved those goals, I guess. So, that… Maybe I mis-missed that, or… I'm not sure.

cayman: Right, okay, so, the contract is, the deposit contract is pretty similar to, like, the… Consolidation contract, basically. There's, like, a… EIP1559-ish, like, fee that's attached. And so there's a target and a max. Allowable. Operations to be passed in. Per block, and then those are fed via the execution requests. bus. From the EL to the CL. So it's capped on the eel side.

Parithosh Jayanthi: Yeah, I mean, we also looked at it a bit within PandaOps, and I think photos of streaming is the perfect one there. It sounds like it's the right solution, but it's definitely gonna delay the fork. This would need to be quite a lot of coordination also with the EL, especially if we're adding a new, a new transaction type, or system contract, new execution, whatever, and it'll add quite a bit more work there.

Matthew Keil: you know, this is something that we thought about pretty deeply before we put this EIP forward, because we understood that that is a risk. And we're… The thing that we came back to several times is that it's a lot of copy and paste, because it's just creating two lanes to facilitate the separation of concerns, and… The amount of edge cases and complicated testing and, attack surface and a lot of the other, dynamism that it removes from the system, for some copy and paste. Feels like it probably won't. We think probably won't cause a delay. Because it removes a lot of the edge case testing, and again, it's… it's basically just replicating something we already have existing, both on the EL side and the CL side, and just makes a, you know, a separate lane

To make sure that we're not conflating and creating hidden, conditions.

Parithosh Jayanthi: Yeah, Nico?

Nico Flaig: Yeah, so yesterday I started this thread on ePBS channel, where I linked some testing cases, and because we were thinking a bit, okay, what kind of Different scenarios we need to test, Because right now, we have this problem where you, in a lot of cases, need to check if a validator already exists, or is, like, in the pending queue, and will become a valid validator. So you cannot front-run deposits, and you cannot have the same entity with the same pub key. twice currently, and so with that, with the builder execution request, we would also separate that completely. So that's one main reason why You get rid of all these edge cases that exist currently, where we potentially need to implement caching and verify a lot of signatures.

So I linked the… so Trustin was testing this yesterday, and… the list got, like, 9 scenarios right now. I think, there's a 10th scenario, even, that we can test, and maybe even more. So, I'm not yet sure that, like, the effort to… Like, for all clients to pass these 10 scenarios that we will have is simpler than… Just fixing it the right way. That's my…

Parithosh Jayanthi: Maybe a meta question there, separate deposit contract and or a different deposit type is something we investigated in the beginning for the ePBS design already, right? So why did we decide against it back then?

Nico Flaig: Does Potuz maybe notice? I don't know.

Potuz: Same reason as now. It's the same trade-off, and back then, we decided that not to take that trade-off.

Parithosh Jayanthi: Okay.

Nico Flaig: Yeah, but there are some test scenarios, for example, Scenario 9, where, like, if clients don't properly cache signature verifications, you can indefinitely dose the chain, and it's not even that expensive.

Parithosh Jayanthi: Is it possible that we add this again to the ACDT agenda on Monday? I don't want to take the call on this right now, especially not without Justin around as well. It would be nice to know how realistic a lot of these attacks are, and give clients Sometime to quantify how long it would take to work on caching and things like that. Yeah, Potuz.

Potuz: Yeah, so I wanted to reply to what Dustin is asking about whether or not we should ignore these scenarios or not. No, we should not. But, what I claim is that the attack should be costly enough as to have other attacks that are cheaper. And this is the way we work on everything. Like, you can now buy a block and just make it empty by just bidding on it. You can argue, okay, fine, you might find a proposal that will not take your bid. Okay, you can just send transactions that are just pure garbage, and fill the block, and pay those transactions high enough. You're gonna get your block to be empty, and it's gonna cost you money.

And the same thing with this… all of these scenarios. They cost money. But what we need to do is to be able to, all of our clients to sync those blocks. So that… that is something that you need… you do need. It's… it's not irrelevant. You do need to be able to sync those blocks, because otherwise, whenever the chain actually heals, your client is not going to be able to follow it. Eventually, you need to… you need to be able to sync those blogs in whatever allotted time you have.

Nico Flaig: Yeah, but especially, like, the Scenario 9, for example, I mean, it's not that cheap, but you can spend, like, 10 million, and then basically indefinitely kill Liveness, and it doesn't cost you anything after that initial money, so… I mean, clients… so, for that, you need some implementation on the client side.

Potuz: Wasn't that scenario just sending one transaction? So you make a bunch of invalid validator deposits, and then you just send one transaction per block, right?

Nico Flaig: Yeah, exactly, and you send that in the process.

Potuz: All of these things is that they also rely on the builder being stupid enough that it will not send it. You still need to… you need to survive censorship. Which the builder themselves can do this.

Nico Flaig: But, so you're saying we rely on builders not submitting?

Potuz: No, we just rely on, like, one… one proposer not seeing those transactions, or not including those transactions. And then the chain immediately syncs everything. So, as long as blocks do not include those transactions. that will make you, like, sync everything, you're fine. But also, we should all, once that you… we should all cache the signatures that you've already verified that they are invalid. That's a very simple cache to have.

Dustin Brody: One concern I have about the emphasis on these side caches is that it makes it… There's one aspect of talking about the initial implementation and testing, yes, and that's real, but that's… but that it's not a one-time thing. It's ongoing. It's extra complexity that's directly security, attack surface related that is not let's say, readily testable, because the caches will not be sufficiently homogenous across clients, likely, in, let's say, the consensus spec tests or similar testing. We are, I think, as an ecosystem, let's say, not… optimally great at testing a lot of these edge cases that were in an automated way that have come up, for various reasons. Some of them are just literally expensive to set up the DevNets to do this, etc. But the end result is I would be a little concerned about the correctness in an ongoing way.

of a system which depended on, in an integral way, on the existence of these caches, which is not actually true right now. Ethereum does not depend on the existence of any but almost no significantly long-lived caches. Some clients have them, yes, but I can say it is not necessary, and this would make it necessary. And that's a qualitative change, regarding which is dubious.

Matthew Keil: I also think the hopium that, external builder is gonna do the right thing in all situations when we're worried about nation-state attacks is really who would be doing this. You know, that… that feels… not great.

Parithosh Jayanthi: I think I also agree it sounds like the right solution to go down. The question is if it's the right solution to go down right now. We are in June. The fork was supposed to happen late this year. I don't think adding this would imply the fork happens this year. Saying the quiet part out loud. is this that critical a topic that it's worth delaying the fork by months, is the core question. I feel like I don't want to make that decision today. I'd suggest maybe client teams engaging a bit with this, having some estimates of how much more work getting the cash right would be, as well as having Justin on the call to quantify how bad the attacks are would be useful data points for that decision.

Would everyone feel okay revisiting this again on Monday at ACDT? Okay, thank you. And thank you guys for working on the PR. I think this is a super valuable conversation. Continuing on the topic of builders, or builder-related, Bharat, do you want to introduce the staked builder API?

Bharath Vedartham: Yeah, I wanted to raise it, mainly, that… I've wanted… that PR has been open for a long time, and I think a lot of… I think at least, like, one dev per each… for each client team has, like, seen and reviewed it, so I'm pretty happy in that, and… what I wanna, like, propose, like, after this call, like, I'm gonna merge that PR. And as, you know, clients, like, implement, I'm sure we'll get more information and, like. Maybe, like, issues there, and we can, like, iterate on it, but… that PR has been open for a while, and I think… I don't know if Terrence has already, like, started working on it, but, it's just useful for,

Wistful to, like, merge it and iterate on it later, so… That's, like, one point I want to discuss. Any issues or anything, happy to hear. Cool, cool addict, but…

Parithosh Jayanthi: Awesome.

Bharath Vedartham: Part of the approval.

Parithosh Jayanthi: You have it in. Sorry, go ahead.

Bharath Vedartham: No, I mean, like, with Barnabas' approval, I'll, like, merge that, Yeah, so probably the next thing, you put up, this is more of an issue, like, I just wanted to, like, raise on the surface. I don't expect to make a decision on this, like, as clients implement, probably we can discuss this again. So, we have, like, the submit beacon Block API and the Builder API. what that… basically that does is, like, in Gloas, the builder API is basically, like, you call the builder, get an execution payload bid, let's say you like it, put it in your block, and you send it back to the builder via the submit beacon Block API. You send the beacon block, and using that, they build the envelope and publish it.

So, the problem is that, with this API is… I was implementing this on Prysm, like a prototype, and I saw that the API does have a chance of making the beacon node a little bit more stateful, in the sense that So, if you look at the flow, a validator client Queries the beacon node for a block, the validator client gets back a block, it signs the block, sends it to the beacon node to to publish it. Today, like, pre-gloss, like. at that… at the step when the beacon node receives a signed block, it… it's able to check, okay, is this a blinded block? If this is a blinded block, you call the get payload on the relays.

Otherwise, like, you know, you don't have to do that. But today, like, when you get the sign block back. you just have an execution payload bid. You know whether that's self-built or it's from a builder, but even if it's from an external builder, you don't know if that is, like, a P2Pay bid or a builder API bid. Like, you don't have it in the… bid. So, likely a beacon node will maintain some… have to maintain some sort of mapping where, okay, this execution payload bid mapped to like… this type builder URL, or this, like, thing. And, you'll have to probably maintain that state, because You also want to send the block back to the builder.

From whom they got the bid, because only they have the payload to broadcast. So… a beacon node will likely have to maintain some mapping, and then, like, a validator client… like, a stateless validator client probably, like, will… be a little, like, you know, you can't send the block back to any other beacon node. So… so, yeah, that's, like, mainly the thing. So… Basically, that PR is about, okay, should we have that API or not? If we don't have that API, we just broadcast the block regardless, and the builder, even if that's, like, a builder API builder, will have to listen on the gossip, and, like, reveal the payload accordingly, and we don't have this API, basically.

But there could be some value in giving the block back to the builder, because the builder can help broadcast the block. Like, there's… a common example always is a validator node in Australia. Like, you know, you… the builder helps them, like, disseminate the block better on the network. But then you could also make the case that the block size is much smaller. Right? So, maybe it's not that big of a problem, so… That's basically what that API is about. I expect as clients implement more, they will Have more feedback on this, but if anyone has any now, like, happy to listen.

Parithosh Jayanthi: Yeah, I think this might just be a topic we'd have to delay, because we haven't, I don't think clients have spent that much time on the Builder API yet.

Bharath Vedartham: Yeah, no, I agree, agree. Anyways, I just wanted to, like, raise this as a potential, like, issue, so we keep that in mind. The last thing, I think, is also similar, like, so today in the builder specs, in the Belletric specs, we specify, like. a circuit breaker in that. That is, we basically mentioned That if a circuit breaker is filed, proposers must fallback. Or to self-building, and the heuristics for the circuit breaker are completely client-dependent, implementation-dependent. I just wanted to… before, like, merging, wanted to get a sense whether We should specify the… if there's any value specifying a circuit breaker and, like. A logic in the consensus spec, or in the builder spec, or… Like, stuff like that, just, like, any opinions or any thoughts on that?

Right? Or do we… because there have been discussions in Interop where We discussed, like, more, like, layered circuit breaker approaches, like. Where we fall back from P2P to trusted, then to self-building. Or you can just fall back to self-building. From a spec perspective, like, is this something we've ordered a consensus spec, or do we want to have this in the builder spec? Any thoughts on that? I was closed.

Parithosh Jayanthi: Yeah, Paula?

Paul Harris: We're not gonna have time for a lot of fallbacks, like, it's gonna be pretty much an either-or scenario, given the amount of time that we have, right? So, I think falling back to local is probably fine, and it doesn't probably need to be specified in the consensus, but… Client implementations not being the same is actually a string.

Bharath Vedartham: Okay, that's a good point. I'll keep track.

Parithosh Jayanthi: Okay, Bharat had another point about, Circuit Breaker, but I propose we skip that for now in favor for, Hegota topics, or remainder of Glamsterdam discussions, if that's fine? Okay, last call for anything as Glamsterdam-related. Does someone want to bring up anything today? Yeah, park numbers.

Barnabas Busa: Yeah, just one small thing. So, in the previous weeks, we've been discussing the engine SSD topic. And the… determined that this would be the proper way to do it, so it would be nice if the CEO teams would actually start looking into, adding support for this. I think Geth will have an implementation very soon. It should be a low-hanging fruit for the SEAL teams.

Parithosh Jayanthi: Okay, has any CL team already implemented this? I think you would just need one CL and one EL for you to start testing this, right? Nethermind says they have it.

Barnabas Busa: Oh, Nethermind has the new version?

Parithosh Jayanthi: I'm not sure if I'll see it.

Alexey Osipov: Yeah, we have an APR ready to be merged, but we… Not sure… we're not sure, should we match it or not. Is that a specification that, is, like, stable? One provided by Marius, we are talking about that, right?

Parithosh Jayanthi: Yes.

Barnabas Busa: That's it.

Alexey Osipov: Yeah, there are a couple of unanswered questions there, and It'd be good to have some answers, and then we… We're already ready to launch it. Yeah, we, we had to burn, Barnabas version, but, then we also, have, adjustment PR that, changes it to Mario's one. I'm not sure… actually, I liked Barnabas version a bit more. I'm not sure what we need to… Let's good.

Parithosh Jayanthi: Okay, any other Glamsterdam topic? Cool, then let's move on to Hegota. The first item on the agenda is, EIP8243 from Raul. I think he has a presentation, the floor is yours out.

Raúl Kripalani: Yeah, perfect. Hey, so A243 is currently called Matching Attestations at Source. We're thinking about… well, I'm thinking about calling… calling this… renaming, retitling this EIP to pre-aggregating at source, I think it is more accurate, but, I'm curious about what ACDC thinks. I have not really a presentation as such, but I have, some support material that… that I'm gonna… I'm gonna show. I just… Give me a sec, I'm putting together an explainer microsite with a simulation, with… some stats that have been collected from Beacon Chain, and, so the platform and the API Beacon Chain, and a bunch of other places as well, and from the network. So, bear with me, I hope to be able to publish it this week. But yeah, so basically, 8.243 is about patching attestations at source. So, as we know.

The current network, is… so currently, where every attester is sending a message on the network, to… to a test. And the reason for this is because otherwise, if we were to allow sending aggregates and having aggregates circulate on the network. There could be… this could be a spam or amplification vector where malicious actors could potentially bundle any attestations that they see on the wire and form new aggregates and spam the network with those. So the simple solution is, at the network level, we only allow single attestations. Now, the reality of the network is that we have… we have aggregates of validators. We have operators in the network of different types, that are together, owning or kind of, like, sharing a pool of validators, but most importantly, all of those validators are usually sitting behind a single, beacon chain view. So, Tekunically, they were testing at once. They were testing, like, one entity, right? Because they have kind of, like, this one source of truth. So the gist of this proposal is…

We found a way to make it so that we could Aggregate that we could allow these operators to collect the attestations of the validators that are co-scheduled on the same committee, on the same slot, same point in time, and just send a single pre-aggregated, message on the wire. Currently, with the stats that I've collected from Beacon Chain, this is… the current distribution of the top 10 largest entities by the share validator set. These further decompose into sub-entities, so… There's… there's some give and take in… when… when calculating what the consolidation factor, could be, and this is precisely the simulation that I'm preparing, because I think it's going to be useful for us to evaluate this together. But we are ex… with this, if every validate… if every entity

pre-aggregated at source, with this proposal, we could potentially see a reduction factor of 2x on the wire, and I'll go into… into what that could potentially translate into. So just to kind of, like, give an overview of where the network is sitting today, there is… We have 890,000 validators, as of this morning. And that means that we have around 27,000 or 28,000 attestations per slot. And that means that decomposes over 64 subnets into 435 attestations per slot. If we sum all of this together, the unique data that circulates on the network for every slot is around 6.3 megabytes. I need to double-check on the compression factors and so on here, but basically, this is what, if we were to have 100% participation in a

slot, then this is all of the unique data that we're collecting. Sukun presented some of the proposals that, from the networking team, we had been developing around better wire efficiency for this. There's some normalization that can be done. There's a lot that we can already squeeze out of this, and this proposal adds onto what we can squeeze. So just to kind of, like, give you a broad stroke, this goes into a lot of detail, so I'm just gonna go… I'm just gonna kind of, like, voice over some of the key elements of this proposal. The whole… Idea, or, like, the main notion is that, there is… within… so, say, for example, you've got a operator that has, for example, 20 validators that are scheduled on the same committee, on the same slot. Those 20 validators could, together, just emit a single, pre-aggregated, attestation.

And the way they do that is by selecting one validator from those that is going to act as a batcher. And this selection can be done ahead of time, and it can be orchestrated by the… by the beacon client, as soon as the validator schedule is known. Every validator will then… create what we are calling in this proposal, a batch seal, and it's basically a signature Authorizing that batcher. to include their attestation in the batch or the pre-aggregate. So this is kind of like a commitment of saying, hey, or more… more of a consent for a validator to say, hey, this other validator that is a peer of mine in this set, is… authorized to send an aggregate. That includes me.

And then, when the slot arrives, the validators are gonna emit their single attestations, and they're gonna collect them internally, within the Beacon… the Beacon client is gonna… is gonna collect them. It's gonna form the aggregate, and then it's gonna send that aggregate to the batcher for it to sign over the entire batch. The data structures look like this. there is no SSZ involvement here. There is no changes to SSZ, there is no changes to slashing, there is no change to on-chain data structures. What you're seeing here is just network data structures. The… what lands on-chain is just the attestation as we know it today. So… just to kind of, like, represent this on the wire, we call the single attestation, and we have the batch attestation. The batch attestation is the pre-aggregate.

And it contains everything the single attestation does, plus these three fields. So it identifies the batcher by validator index within the committee. So this is… this is the member of the committee, of course. It then includes the BLS aggregate of all the seals. So, this is basically the aggregate that confirms that this batcher is authorized by all of the validators that are participating in this batch to send a batch on their behalf. And then it includes its own signature on top of this, sealing… sealing over the entire batch. That's basically it. What you see on the left are just pre-images, these are not… this is not data that circulates on the wire, it's just a pre-image that goes on the… that goes into the signing function.

The validator rules are actually very simple. This is, a little bit more… presents them a little bit more complex, because it kind of, like, unbundles the existing validator rules. But basically. what happens is… it hinges on a few principles. First, every validator can participate individually. and as a batcher, only once as each role. So that means that if we have 435 attestations, in a particular committee, then the maximum, if everybody happened to be a malicious validator, and everybody emitted, and, you know, there was… there was… like, the worst case scenario where a single operator owns all of the validators in a particular… in a committee, if that… if that materializes and they act maliciously, the max we could see is 870 attestations. So…

Because every validator can participate individually by sending a single attestation, but also can participate in a batch. Now, this means that spam is completely capped, and this is… a really good thing to have. The other alternative solutions that were even stricter and more aggressive in capping potential spam in… how does introducing changes to… how does introducing slashing conditions, and so on. So, I think this is a really good trade-off space to be. And… so that is kind of, like, one… one of the key validation rules. The second validation rule is that a attestation. Bit can only… You will drop attestations circulating on the wire. If you've already seen that attestation bid included. in… in a previous attestation. So this…

is a simple mechanism to prevent beacon clients from having to track the strength of each attestation. And this is necessary. This can… This is possible because… This amplification is possible because of the… this batch seal. authorization. So, if we were to remove the batch seal mechanism, which is something we considered, then you could potentially have a malicious actor that is aggregating… that is taking two aggregates and forming a super aggregate, and at that point, the beacon chain… the beacon client would need to would need to identify which is the stronger one, and it becomes more… the validation function becomes more complex. This is actually an open point. I do wanna… I do wanna delve into this a little bit more. I think it merits a little bit more consideration before we completely discard it.

But yeah, those are… those are the main, validation rules that we need to introduce, in addition to the… the existing ones that are… that are more structural. What else? Yeah, so what opportunities does… does this unlock? So, of course, it increases information efficiency. for attestations. So, with the same amount of traffic, or with half of the amount of traffic, we can represent exactly the same information. And this compounds over the rest of the optimizations that we've been proposing as well. So all together, it puts us in a really nice place to make attestation, the whole attestation process super lightweight. On the, on the network as a whole, which also means that potentially, because we're hearing from more validators at every point in time.

Once we could reduce… with less traffic, we could, if we were to keep the traffic constant, we could actually reduce the number of subnets, and that would mean that, potentially, what falls out of this is that epochs could be shorter, automatically by this. Now, the this is… this is a trade-off that, I'm not sure, like, we're definitely not gonna, like, make any… any topology changes as part of the CIP, but it is a door that opens up. I do think that MaxiB Consolidation is really… continues being really important, because while this gives us an optimization on the wire and gives us more headroom, and it allows us to like, use that traffic, that practical traffic for other things, and to speed up things, it does not, give us a theoretical bound, right? Because it's dependent on the network

Are you on the validator-to-operator distribution at every point in time in the… in the network. Even though one of the benefits of this is that the mechanism does not require any validator, action, any explicit action, like consolidation does, we're actually seeing the rate of consolidations, like, continue pretty healthily. So, I do expect consolidations are gonna continue, in the… in the next months, but this mechanism adds to that. I think that there will be a tail that consolidations will not get to, and also, like, there is a natural cap to consolidations as well, because of balance, so… We will end up at some point, at one point in time, having validators, even consolidated validators co-scheduled on the same committee. So this would be, this would be additive to that.

And then, a very interesting angle that opens up is because… is the attester privacy, or kind of, like, from the perspective of pay… pay… like, in the space of pay anonymity, set, and there is…

Parithosh Jayanthi: Raul, would you be able to wrap up in maybe another minute or two? Because then we'd like to do Q&A with this.

Raúl Kripalani: Oh yeah, sorry, I wasn't looking at the chat, yeah. So, it is interesting, because we thought, like, I personally thought that it hurt it. validator privacy at the beginning, but really, I think there's a chance that it actually benefits it, because we're creating a standard primitive by which any validator can be. Can decide to delegate their network broadcast to any other validator that's participating in the same committee. Which… It can happen within an operator, but it can happen cross-operator, or it can even become a service in the network that that actors provide to validators, kind of like a K-anonymity set style, privacy, solution. So I think it does open up that angle, from the perspective of, like, weakening validator privacy, which is kind of, like, my starting point when I considered this.

I think this does not add to the current situation, in terms of, you know, what the vectors are. It does not make it yours. So… so yeah, I think I'm… I'm gonna stop there. I see there's a bunch of questions. Sorry, this was a little bit unstructured. I was trying to put together the site and the deck at the same time, and just didn't have time, but there will be a microsite that is a lot more eloquent than what I'm presenting here in the next days.

Parithosh Jayanthi: Thank you so much. Yeah, open floor for questions. Does someone want to go first? Maybe one comment was about, some missing data sets, so Lido and Ripple wouldn't be able to do this? Is this true? Yeah, Potuz.

Potuz: I had a question. What are the chances of a large operator? I mean, I assume that this is going to be larger with large operators. The impact would be larger with large operators. And what are the chances of large operators having aggregators already? So that they can just pick one of their aggregators and just aggregate natively with the current status, instead of going through all of these changes.

Dima Gusakov: I would assume that it's… like, I've never heard of it from any professional operator. Even though they are trying to optimize as hard as they can, but I've never heard of the attestation aggregators or, like, something like that being installed.

Potuz: No, no, what I mean is, we already have this code, and we already have aggregators that are being chosen randomly. The question is, I'd like to see the numbers of what are the chances, if you run a large enough operator, that one of your attesters happens to be an aggregator. Therefore, we can just modify existing plans to aggregate on the source using the aggregator.

Dima Gusakov: Oh, yeah, that's a fair concern.

Raúl Kripalani: You mean in terms of logic and code reuse?

Potuz: Yeah, it meant, like, if… let's say that we had, instead of, like, 16 aggregators, we had thousands of aggregators, and then learn that many large nodes, then you would expect that a bunch of those large nodes would have an aggregator among their validators. Therefore, they could just do the aggregation without any changes to the spec, and without any new structure, without the changes on the validator client to sign the batches, and so forth.

Raúl Kripalani: Right, so… I think we can run the numbers on what the overlap could potentially be there, like, what is the starting point? Because with 16… with 16 aggregators per subnet, We… we could… like, then run the numbers to understand what the probability that any of those aggregators could fall on any of the… of the operators today. And then from there, we could also, like, assess the trade-offs of increasing that number, which is what I'm… what I think, or opening up, or kind of, like, giving freedom for anybody to be an aggregator. The problem with this is that it… it is… aggregations would become a spam vector, right? So… so that's, That's the main… that's the main issue. The problem with this is that… is the fragmentation at the network level, because it's really hard to create a validation rule. So, say, for example, you have

in a committee of 435, you allow, like, half of them to be validators. Or, like, for simplicity, imagine you allow… sorry, aggregators. Imagine you allow all of them to be, to be aggregators. the problem there becomes that you might see 435 different permutations, right? Of the aggregation bits, and… Yeah, that ends up being a potential spam vector, Yeah, we can consider it, though. Just thinking out loud, really. Paul, I see you have a hand. Do you want to go now?

Paul Harris: Yeah, I was just thinking, one of the concerns that I have with this is it's really only aggregating across one channel. We already have… Aggregations across 64 channels, which would mean that there's a lot more benefit to that for each node.

Raúl Kripalani: Jesus.

Paul Harris: Unless you're running literally thousands of validators, you're not going to have a large number in per channel. So… I think something to… something like the existing aggregation kind of solution. is probably… More effective and potentially less expensive? I… and I'm… the… The concept of having to do another round trip to a validator to sign this package does give me pause, because it is a time-critical path, so… I'm not sure that this is a solution That I'm fully on board with at the moment.

Raúl Kripalani: What a lot.

Paul Harris: be in the right direction, but I don't know what the right direction… like, I don't know what the endpoint would look like to be something that everyone would be happy with. But that was just my initial feedback on it.

Raúl Kripalani: Yeah, from a… from the perspective of risk. And, like, architecture, you know, impact? Opening up, from our… from our perspective, opening up the aggregator like, cardinality, I guess, to… to, like, some other number that allows that overlap to naturally emerge within Those operators that have co-schedule validators. I think, like, it's gonna… A, it's gonna become really tricky to find a good number there. B, if anything, it would need to be in… from, like, this is just gut… gut feeling, would need to be, like, completely free, so anybody, any attester is… is allowed to be an… To opt in to be an aggregator, with some lower bound, of course, with some compulsory aggregation happening. The thing is that… Yeah, I would need to look at, kind of, like, the slashing,

Yeah, the slashing… Side of things, and… Yeah. Right now, there's the signature, right? So, like, what is… yeah, it could be. There's some consolidation there, because really, naturally, what's happening is something similar, right? But there is more, like, external-facing Consequences of expanding the… the… the, the cardinality of aggregators. Versus just having this mechanism, which kind of stays internal, right, to the topology, because you don't require re… like, re-architecting anything here. It's just a pre-step that happens. So…

Paul Harris: Yeah, but I think you're gonna need literally thousands of keys on a node for this to be effective. Because you're doing one channel from 32 slots, so… like, if you're still going to have 64 aggregations, the chances of having… I don't know how many people are running more than a thousand keys on a node, but, like, it seems like this is a very marginal thing, unless you're getting all of your nodes, like a large operator, to send all of your validations.

Raúl Kripalani: Yeah.

Paul Harris: single point.

Raúl Kripalani: Yeah. Yeah, the counterpoint there is that, you could Tekunically… like, the reason that you have… that you don't have that packing efficiency is because you have 64 subnets. So if you actually bring in the consolidation together with this, so that you… So that you, say, for example, consolidate to 60… to 16 subnets? right, so a factor of 4, you would then, like, be having more packing efficiency, right? So it's kind of like, you know, like, it goes both ways. That's why I was a little bit hesitant of detaching the consolidation part of this EIP, which was kind of like, you know, as a placeholder there. But yeah, I totally see your point, and there is definitely another, like, part of the design space that we could study here before, like, going one way or another. Yeah.

Parithosh Jayanthi: Last comment from Kotos, and then we have to close up. Okay, The only other thing I wanted to mention today was… yeah, thank you for presenting, your photos. Do you still want to go?

Potuz: Yeah, I just want to mention quickly that the numbers on aggregators should be run, because if we are talking about also, like, decreasing the number of committees. then you can just have more aggregators per committee without enlarging that much number of aggregators, and increasing the chances of one of these large operators having one of the aggregators. So, if we are using the argument that this is going to allow us to have less committees, then we should also use that argument to compare with enlarging the number of aggregators.

Raúl Kripalani: Yeah. Yeah. Yeah, I agree. I think this is a whole, like, study that merits, you know, its own… its own analysis. The other point that I want to make sure that I don't downsell even though I haven't, like, done a lot of solution design for this, so maybe, like, you know, I'm kind of, like, going… going in with a little caution… a little bit of caution, caution here, is I do think that this… this particular instantiation is a useful primitive for privacy, as I mentioned. In the sense that any attester can, like, there could be services emerging that, that allow attesters to channel their attestations through them. But it's also possible that we might be able to, like, achieve that with the aggregator, like, you know, site… like, the other… the other aggregator-based solution.

Parithosh Jayanthi: Yeah, thank you guys for the discussion. We're over time right now, thank you all for the presentation. One thing I did want to mention is there's a ETH Magicians poll on Glamsterdam mascot, so please go vote there for your favorite emoji. That should be it for today. Thanks, everyone, for coming and for trying out the, the different time zones.

Potuz: Yo, guys?

Lucas Saldanha: Thank you, folks.

Marius van der Wijden: Bye.

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