All Core Devs - Consensus #177

Transcript

Alex Stokes: Hello! How's everyone doing?

Potuz: Hello?

Alex Stokes: Okay, let's wait, like, another 2 minutes, just to give people some time to join, and then we'll get started.

Okay, let's see, Josh, it says you're here, are you helping with the stream today?

Josh Davis: Yep, you're alive.

Alex Stokes: Okay, thanks. Hi, everyone. Welcome to ACDC number 177. This is issue 1990 in the PM repo. The agendas here, in the chat, and… yeah, we have a number of things to discuss today. You know, in the short term, looking at Glamsterdam and moving forward with devnets there, also some different proposals for Hegota we'll touch on. And if there's time, we'll have an update on some of the BAL work. Er, sorry, the repricing worked. So yeah, let's go ahead and get into it. So, to begin, we have Amsterdam. And… yeah, many of these things here kind of all tied together, But maybe to get us started… We've had ePBS DevNet1 for some time now, but it looks kind of dead. Are there any updates that anyone would like to share?

If not, I think ultimately we'll just talk about our plan for how to get back to a stable devnets, but I'll start it off there. Yeah, Barnabas?

Barnabas Busa: Yeah, so ePBS does not… one is pretty much dead, and we decided on, yesterday, this Monday that we're not gonna try to resort it, and rather, we're gonna be focusing on APPSN at 2. Which basically requires the 5094, which is, basically the next step on the agenda.

Alex Stokes: Okay, so yeah, then let's just go ahead and get into that. Right, so this came up, I think there was an issue with checkpoint sync and just the intricacies here of finalization with the change in ePBS that breaks apart the payload from the block. As far as I understand, I think this PR is in a pretty good place. Here, let me try to… oh, I just got a link, thank you. Yeah, so I think this PR is in a pretty good place. Any comments on this PR? Otherwise, I think we just go ahead and merge it, because it sounds like that's blocking us with the next DevNet. Yeah, photos?

Potuz: I don't know if now, or probably by the end of the meeting, but it'd be nice to have a discussion about, syncing and gossiping. There's arguments still on whether we want to be duplicating… duplicating the broadcast of requests.

Alex Stokes: Okay. Yeah, do we want to get into it? Can you just give us a quick summary?

Potuz: Oh, yeah, so… The issue is that, we are now sending the requests on the envelope, and also including these requests on the block. We added the requests on the PICOM block to keep the state transition function a pure function that takes only the state, the block, and it gives us a new state. If we remove these requests from the block, then we would lose that signature. There's an argument to be made whether or not we want to preserve the signature or not. But that's the current status. And the problem of doing this is that if the request can be actually very large, and broadcasting on this consensus layer side is dead broadcasting on ePBS, because it's just part of the slot that is useless.

So the question is whether or not we want to address this now, or we want to address this in the future if it becomes a problem. That's… that's the situation. There are some ways we could prevent this from being on the block at the cost of making the state transition function contingent to, having that data, that in principle, every node should have it because it is on the payload. It also complicates things on checkpoint sync, because now when you do checkpoint sync, you actually will need the payload from a previous epoch, presumably, to actually get those requests. So, it comes with a bunch of trade-offs.

Alex Stokes: Yeah.

Raúl Kripalani: And also…

Alex Stokes: any…

Raúl Kripalani: Yeah, just to add to that, I've been participating in the discussion as well. So, the question here really is, a data flow question, more than… than simply extending the signature from our perspective. Basically, what I'm proposing is that if the state transition function remains anyway, preconditioned by the node actually having received the execution payload from the previous lot to begin with, if that precondition still exists, any BPS is currently, suggested, Then, what we can do is simply The data structure… the signature would remain the same. the signature could con… could… and the beacon block that is sent… that is provided in the call to the STF would be the expanded form, so this would include the execution request, so everything in the PR stays that it is, as it is, as it is.

Today, The thing that we would do is we would simply… expand. So instead of propagating the execution request twice, once on the execution payload and the second time on the next beacon block, we would just propagate a commitment on the beacon block, and the client implementation would expand that commitment with the data that they already have available before… from the execution payload, before providing it to the SDF. So the… so really, it's… it's a matter of what data is available when, not so much about… from my perspective, it's not so much about, like, a puristic, you know, the puristic side of, kind of like, do we want to extend the signature or not? Like, that's not the gist here. I think the gist is really what data elements depend on what, and what can we count on.

Alex Stokes: Yeah. Quick question for my own understanding. When we're talking about having execution requests on the beacon block, these execution requests are from the execution payload of the previous slide. Is that correct?

Raúl Kripalani: That's my understanding, yes.

Alex Stokes: Okay. Outpost.

Potuz: Yeah, so… Well, I mean, regard… regardless of semantics or not, like, we could do this, we could, we could, like, gossip blocks Blinded, but this comes with a considerable complications on implementation, we would need to have a new object, which is a blinded vehicle block that is blinded in a different way than it is today, and that's the thing that is being gossiped, then we would need to change all of the RPC requests for, like, by range. for example, or when you request a block on RPC to be the unblinded one, and then on Gossip to get the blinded one. I think we're going to continue over-complicating this, over something that was essentially an API problem.

Raúl Kripalani: I mean, I disagree with that. We're talking about the worst-case scenario. Another possibility here is we actually revisit the limits on deposits, because this is… there's 8,192, that's the limit on deposits per slot, per block. So if we revisit this number, then we can make the payload smaller, right? But otherwise, we're looking at a worst-case scenario of 1.5 megabytes, and that is not negligible. And when I actually look at the implementations, I don't think the cost of implementing this… it's a simple expansion. Like, it's just one translation in the data structure. It is a stateful translation, because you do need to have the data that you're expanding available from the previous slot, but it's literally

like, it can be a ring buffer, it could be not even a ring buffer, you're literally just taking the data from the previous slot, otherwise you're not even able to execute the STF in the first.

Potuz: So it just does not, it needs to be curried, right? It's interleaved. It's not just on the gossiping side. Right. The problems are on the RPC side.

Raúl Kripalani: Yeah, but you can store the expanded payload to serve it over our PC. Like, I don't care about the data storage side of things, because the data storage is cheaper than the network. You can store it in the expanded form, and you just continue serving it the way that it's being served today. It's just this particular route in the critical path, adding 1.5 megabytes to send duplicate data, is extremely inefficient. So we're just talking about a compression, or… or kind of like an expansion method. The other possibility here is reducing, like, if we really want to go this way, then we need to revisit the deposits, the limit on deposits. If it can be smaller, then, like, we need to scale this… this value down.

But anyway, one thing that I do want to highlight is that the STF, as I understand it. was built originally, and kind of like this signature that we… that we really care about, for it to be pure, was built in a world in which the execution and consensus were in the same object. Right? This is no longer the case, so something has to give somewhere. I think we can resolve this by, like, this solution that wouldn't… from the data architecture perspective, is just, like, a different scenario, right? So, yeah, revisiting the signature is warranted. I think we can keep the signature intact if we just do this expansion.

Alex Stokes: Nico, then Enrico?

Nico Flaig: Yeah, so I looked into this a bunch yesterday to just see what are even the implications. So right now, the maximum, really, that can be achieved is, 489 kilobytes. Because there's a limiting factor, which is the gas limit. So, with 60 million, that's the maximum you can even do. But even that, requires you to lock up 6.4 million in EVE, because you need to do… these, I think it was 2,000-something, deposits that are possible, and to reach this 1.5 megabyte limit, we need a gas limit of, let me double-check this, 193 million, and it requires to lock up 20… 0.5 million in ETH to even get to that. And the average size of execution requests is really tiny, so I looked at mainnet data from the last two weeks, and they are 70 bytes on average.

I mean, not to downplay this complaint, but there's also, I think, a thing that the SSC size limit is set way too high. I was looking into discussions when that, 6110 PR was implemented, and they set the limit to that, so you don't get into a scenario where the EL could produce a block. That produces execution requests that don't meet, or that… that is higher than this 8,192 limit. But this seems flawed in itself, because if we have a gas limit increase over these… this… over 200, for example, million, then this limit Doesn't… it's not sufficient anymore, I guess, because the EL could still produce a block that is invalid. So, what I was wondering is, isn't there a way for ELs to have this limit as well, and then we can reduce it even?

Too low number. Like, the EL could maybe just say, don't include more deposits into a single block than what this limit is.

Alex Stokes: Yeah, I mean, it's possible. I don't know if any yellow devs want to chime in on this. Yeah. I mean, one thing there is it just adds this other limit that we have to synchronize across layers, whereas I think today it's more the EL just puts whatever they have, and they don't have to think about it. Enrico?

Enrico Del Fante: Yeah, I just want to comment on… on Raul's perspective, because… I don't feel that we may say that the Raul perspective is too much complicated, because I feel like He's right saying that we could confine this change in the networking layer and the overall client just on block gossip. flow, and make everything else, including RPC, exactly… How they are today. So, just when we receive the block, during the flow. Even… even… even before, even before gossip… gossip, validation could be done, expanding things from… from… from what we've received from… from the payload, and everything remains the same in database, and…

all the other RPC. So, I'm not saying… I'm not saying that there might be complications, but I'm saying that it's possible that we could have something that is low impact.

Alex Stokes: Roll. You have your hand up?

Raúl Kripalani: Yeah, I think that's… that's exactly right. Thanks for explaining it, Enrico. That's what I was thinking, is just… the… on the gossip layer, everything else stays intact. We still save the data structure on the store, we serve it over our PC, in… as it's currently being served, everything stays intact. It's just on the gossip… on the gossip layer, instead of duplicating the data.

Enrico Del Fante: But there is a complication.

Raúl Kripalani: Okay, so…

Enrico Del Fante: To be super, super resilient here is we need to cover the situation in which the client doesn't have the payload, and maybe once.

Raúl Kripalani: Right.

Enrico Del Fante: Only… only the… only something, actually, to… to… To be able to import the block.

Raúl Kripalani: Yeah, but then we're back in the scenario with the two roots, right? Because you can't really… You would then be moving the beacon state without…

Enrico Del Fante: It would be just another input to the envelope by the payload by route request. It will trigger that, and the client should download the missing payload. Yeah, I think, like, yeah, we don't need to have a specific RPC to get just the execution request unblinded from clients, I don't know if there's any reason to have a specific RPC. In… But, yeah, it's possible that you just…

Raúl Kripalani: Yeah, so…

Enrico Del Fante: trigger… trigger the payload again, and you can unblind, and everything flows.

Raúl Kripalani: Yeah, so from my perspective, if… and please correct me if this is… if my assumption is wrong here, but the design assumption is that PTC is a strong enough signal of network-wide availability of the execution payload. to execute the STF, now with the… with the non-dual form, so to speak, you would anyway need to have the execution payload. I think if you want to advance… if I'm… if I'm understanding the current proposal correctly, if you want to… if you want to advance the chain, you would need to have the execution payload anyway. So… That's… Is that… is that wrong? Is… Is this assumption wrong?

Enrico Del Fante: Yeah, definitely, you need to have the previous payload if you want to build the next beacon block on top of it.

Raúl Kripalani: Right, right. So then it would be… so if you don't have it, it's either a propagation fault, right, that it didn't get there in time, but also, if PTC was positive, right. then at that point, you also have a BTC fault, in the sense that the PTC signal that we got was not consistent with what the network saw. There's always going to be outliers, of course, but then the fallback path for those outliers would just be conducting the RPC call to one of the… their peers that is synced ahead, and simply fetching the full block. The beacon block, we know, is tiny. So I would prefer that path because it's just a fallback path from our perspective, right, that is not going to be exercised on the critical path by every node.

It's just those nodes that failed to receive the payload in time would just, invoke the RPC, and if I remember correctly from the numbers, the beacon block, the resulting beacon block, was tiny, anyway, so… It shouldn't… so if you're really only interested in the execution payload at that point, then the… cost of receiving the beacon block as well in the response is just residual, it's just tiny, so it shouldn't matter. My perspective is a much better space of the design trade-off here.

Enrico Del Fante: Yeah, there is also the other side of it, that you have to blind it during publishing, so there is an unblinding, and then The proposer needs to blind that while doing the pro… the… .

Alex Stokes: Yeah, but you just put the hushed root of the…

Enrico Del Fante: Yeah, it's… the blinding is… is trivial. It's just a tiny complication, and I don't know if there are clients that have some kind of strong… Strong tightening between the block type and what is on the publishing side, so if some kinds have some… Assumptions, and they have to break that assumption. Maybe it could be a complication.

Alex Stokes: I imagine there's enough change already with ePBS that that's fine to me. Barnabas?

Barnabas Busa: Yeah, that would be my main question here, that… Do we really want to keep pushing this decision based on, you know, potential duplication of, like, 17 bytes, what Nicole said, that would be the average case. I know the diverse case is looking significantly worse, but, Even 1.5MB on a 3000 deposit slot is very, very unlikely to happen. And, we're not gonna get many of those, even on mainnet. Like, is this really something we have to deal with?

Alex Stokes: Yeah, yeah, it's a good question. Enrico?

Enrico Del Fante: Yeah, I feel like we can definitely postpone this… this. If… so, if the assumption is correct, which is the only way we could move forward with this. So, the assumption is this approach is simple. If it is, we can postpone it later as an addition, because it won't break… change anything on the consensus layer. It will be just a networking change, and we can decide it. To do this later, after a better evaluation of it.

Alex Stokes: Right, so yeah, the proposal would be then to have them duplicated, and someone help me. Is this the current status of 5094?

Nico Flaig: So currently, they are duplicated, yeah. But, we don't even need them in the envelope, because, like, they are kind of duplicated in the transactions already, right? Like, the… payload itself contains the transactions for the deposits, and you can always generate the execution requests from that. So I think with the with the PR, we could even drop them from the envelope, but we would need to update the engine API, I think, so the EL can return them. And then the next proposal needs to include them in the beacon block, but you would get rid of the data duplication.

Barnabas Busa: I would not introduce an engine API change for this. But that's just my personal take.

Alex Stokes: Yeah, and then one quick question to POTUS' comment here, in terms of RPC. RPC will change either way, right?

Potuz: No, so the problem is that the reason why 5094 was even proposed was that clients were having problems with checkpoint sync. And the problems they were having with Checkpoint Sync was that they got a state, and they needed to request data from an epoch that was previous to the slot on the state. 5094 in the current status solves that problem. If we remove the request from the block. This problem would go back to the status that was before 1594, And… then to solve that problem again, we're gonna introduce changes on the RPC to come… to… to have the RPC return the unblinded block, and then on gossip, having the blinded block. I think we'll just keep adding complexity over things that…

are not really strictly necessary on Consensus. Already 1594 is not necessary for consensus. We just accepted it because it, like, simplifies implementation. I agree with, Enrico. We should just go with 1594, we agreed that that was the simplification to all of us, and then later on decide whether or not we want to include these changes to avoid the duplication or not.

Alex Stokes: Yeah. That's how I'm leaning as well at the moment. Yeah, roll.

Raúl Kripalani: I'm good with that, I just want to maybe scope what the exact ask is for clients to investigate. Like Enrico said, the current hypothesis is that simply adding a very simple trans… Translation, at the gossip layer only, nothing… nothing in RPC changes, nothing in the store changes, everything remains the same, nothing in the STF changes. The only… the only thing that changes is on the proposer side of things, on the proposer, you would be, instead of… you would be blinding. And on the receiving side of things, it would be expanding, and that's it. Everything else stays the same. And the assumption is that simply by having a cache of one slot, of the previous slot, or the parent slot, would be… would be sufficient. There might be some edge cases here, and I think that's the thing that we're interested in finding out, if there are edge cases that we're not seeing.

Alex Stokes: Yeah, that makes sense. In the specs, like, we'd have… So, like, yeah, I think the straightforward way that you would do this is you'd have, like, new block types in the spec. Maybe this is, like, an optimization? Well, that would be messy, too. So, in any case, yeah, hear what you're saying. It might be… harder than it sounds. But yeah, let's, let's get back to the current topic. Then, it sounds like we're all in agreement to go ahead and merge 5094 to get past this issue. There may be an ask down the line to add this optimization that Rule's proposing. And is everyone okay with that? Okay. Okay, got some thumbs up. Okay, cool. So, let's do that. Thank you, everyone. This stuff, you know, the devil's always in the details. So, in any case…

From there… I forget what these comments are. Yeah, okay. So I think from here, I might hand it over to Barnabas, because he had a number of comments that are kind of all interrelated, just around scope and how we went forward with the devnets. There's BAL DevNet 4, eBPS DevNet 2, that's gonna reflect some of the changes we were just discussing. And then, of course, the road to Glumpster Dam DevNet Zero.

Barnabas Busa: Congress.

Alex Stokes: that…

Barnabas Busa: There's just one more quick PR that I think we should discuss. 5067.

Alex Stokes: Okay, well, I think you have 3 now, so do you just want to run through them?

Barnabas Busa: Yeah, so 5061 is basically… clarifies the, growth genesis, Questions, and, this is gonna be rebased on top of, 5094. I'm just not sure what the current state of this PR right now.

Alex Stokes: Yeah, it's from Brekkie, I don't know if they're on the call. Otherwise, yeah, is this something we need to merge before we can move forward with DevOps?

Barnabas Busa: Yep. Ideally. Okay. So the main reason we need this is, when we're testing out the builder workflow, Having the builders already available at Genesis basically enables us to get the builders working without needing to make builder deposits.

Alex Stokes: Yeah, okay, that makes sense. Brekkie left a comment that this should be revisited after 5094, so… Yeah, maybe then we can do that, say, today or tomorrow. And circled back to this on Monday. Oh, okay, he's in the chat here. Okay. Does 5094 change anything, or it just needs a rebase? Okay, it does change. So does that work, Barnabis, if we just handle this on Monday, then?

Barnabas Busa: Yeah, ideally, we want to have everything merchant by, tomorrow, I think.

Alex Stokes: Okay.

Iván | ethrex: Yeah, it's on…

Alex Stokes: Like, we can do that then.

Justin Traglia: I'm, targeting to make a release today or tomorrow. I would like to get it in before then. That's the target.

Alex Stokes: Perfect. Okay. Otis, did you have your hand up for this?

Potuz: Yeah, so I wanted to ask, is… is there a strong opposition to targeting, Glamster.devNet1 or Definite0, whatever it's called, for interop? I mean, it seems, from our perspective, from my perspective on the CL side, it seems very low risk to add ePBS… to add valves to ePBS, I understand that for a bald DevNet, this is… this might be a problem, so they might want to keep another DevNet that is just pure balls without ePBS, but for us, I think very low risk in just including balds and start testing directly on Glamstone.

Alex Stokes: Yeah, I think Barnabas wanted to talk about that, but also he was gonna cover these two other PRs first.

Barnabas Busa: Yeah, so Bold.NET 4 is targeting to launch next week, Friday, and that is the same day when we plan to launch ePBS FNet 2. And ideally, Glamstra Demp Definite Zero could, be launched on the first day of Interop, which would be this pack of Bold MNT4 plus APPSNET2, without adding any other EIPs. So this would require a new CL release as well, Alpha 6, which would, introduce the… ball changes on the CR side. And then, ideally, in the last day of interop, we could also do, Glamstagram. 1, where we… basically introduce a few… or none, no other CL VIPs, and, some or none, BL DIPs. Because… You can find more details about everything in the issue of the score.

Alex Stokes: Turns.

Terence Tsao: My immediate feedback… by looking at it, is that you want to do ePBS.N2 on Friday. then you want to do Gamson and Death Night Zero the first day of interrupt, then there's not much time in between, right? It's just the weekend, and people are starting hearing that.

Iván | ethrex: Oh, you know?

Terence Tsao: part, so I think, like. My proposal is that I think it would be actually much easier if you just do Glenster and DevNet 0 on the end of Friday, and just skip DevNet 2, because I still don't think it's gonna work if you want to do two devnets back-to-back, but then the only gap is the weekend and people are traveling.

Barnabas Busa: The idea is that on Monday, we're gonna be spending the holiday, figuring out the ESCL changes. And, local access lists are still not stable, and that is the main reason we want to keep it separate, because I'm assuming that ePBS.Net2 is also not going to be stable, and if neither of them are stable on Friday, then having a very messy network will not benefit anyone.

Terence Tsao: Yeah, but I just don't think, like, there's enough time between Definite2 and DefNet0. If you want to just bring in Bell, it's just much easier to do everything together at that point.

Alex Stokes: Well, unless there's a lot of bugs from merging them. If we relax the time.

Terence Tsao: Yeah.

Alex Stokes: Amsterdam DevNet Zero, does that make everyone feel better?

Terence Tsao: So I actually studied, like, the differences, like, the overlapping part is actually surprisingly small, because of the bell changes a couple things. One thing on the beacon state, and then the… and then the payload, the header, and then the engine API code. And turns out those things… are minimally touched by 5094.

Alex Stokes: Yeah, and so we're not worried about, like, some BAL bug on the EL causing issues with the EPPS state transition, and… Breaking things?

Terence Tsao: Well, there's definitely risks, right? But I think that's a possible route. I just think it's impossible to do definite 2 on Friday, then definite zero glamps, and then on the first day of interrupt. There's just no time.

Alex Stokes: Right, but, like, what if we make it the second day? Like, I think, at least what I would say is it's more important to get in one more cycle of them separated, just because, like, we haven't even had a stable DevNet 1. So then Devna 2 stable would give us, like, a good foundation then to work on the merge. And… I would imagine that if we just go for the merge, it, will just add more… more issues. To work through, than otherwise.

Terence Tsao: Yeah, I don't have a strong opinion. I just wanted to mainly point out there's not enough time in between, but if you want to give it more time for DevNet Zero, then that's fine, but in my opinion, I think it's just more productive to just do it all together, but I will let others chime in.

Alex Stokes: Photos?

Potuz: If we decide to do together, then we can start testing on Cortosis now. I think Dustin is probably pointing the same thing. We want to get into Interop already having Cortosis runs on clients, and if we're gonna be wasting a week trying Cortosis only on ePBS, and then later we're gonna have to anyways make changes to run them on Cortosis to check whether balls is changing anything or not. I think it's just wasted time. We can and should start testing with balls on the CL side, and I don't think the kind of balls that you mentioned are even possible, the kind of bugs that balls would just affect on the CL side. I think ePBS bugs could screw up the ball DevNet, make it unstable, so I do understand why EL devs might want to have a separate DevNet, but I think on the CL side, we're going to be better off having just one.

Alex Stokes: Well, there's just one… That would be it, right? Like, I feel like I think that's also part of the calculus here, is, like, the idea is this would be the merged dev nodes that then, you know, both layers are working on together. So, do any EL devs actually want to speak to us? That might be helpful? Or if they're not here, Barnabas, what do you think about just relaxing the timing that you have for Lumpstream DevNet Zero?

Barnabas Busa: I don't think it's the timing that is of question, from Portos, like, they basically won Glamsterdam Definitely zero. Next week, Friday. Right?

Alex Stokes: That's the proposal, yeah.

Barnabas Busa: Yep. I mean, yeah.

Potuz: Probably a timing issue, I don't really mind much. We're not really on a rush, it's just time-saving.

Barnabas Busa: Yeah, I would really want to hear the opinion of other CL devs as well.

Parithosh Jayanthi: Also, please take into note that there are some CL changes already in block-level access list.nets, and those would also be merged into your ePBS branches.

Alex Stokes: Yeah, other… other seal plant tombs? I think we've heard from Nimbus, and…

Barnabas Busa: The stock norm is very minimal, by the way. So that's… that's a minor one.

Alex Stokes: Bye. Yeah, in that case…

Barnabas Busa: if… if we do end up going with Amsterdam Devon Zero next week, Friday, then I would actually target to do… block level access list DevNet 3 scope with, with the Alpha 5 changes from the CR side.

Alex Stokes: Okay, and then you'd merge in the DevNet 4 stuff in DevNet 1, or how do you think about that?

Barnabas Busa: Yeah. Or maybe we can do, like, Amsterdam.net 1 in the first or second day of interop, and, there we could add the, 7976 and 7981 there. I… I would just… Yeah, I would just like to test those separate on, Docker Access List Network before we can,

Alex Stokes: Yeah.

Barnabas Busa: Before we can merge it in. But, yeah, they are also… Quite, isolated, so it might… Also, makes sense. If we can do, maybe, local level access to this DevNet 4 on Thursday instead of Friday, then we could try Glamstagram DevNet 0 on Friday as well, just the day after. If it's, if it's stable. If it's not stable, then I would just stick to DevNet3, assuming that DevNet3 is stable by… end of next week.

Alex Stokes: Yeah. Okay. Then, yeah, I think otherwise, from Lighthouse, no strong preference, but lean towards OneDevNet. So yeah, I mean, I think then I'd go ahead and propose this. Let's skip ePBS DevNet 2, and instead just target DevNet 0 of Glamsterdam. with the spec versions part of us just gave. So…

Barnabas Busa: Yeah, then Justin would also need to make sure to merge in the slot num and the block.SS list stuff into Alpha 5.

Alex Stokes: Oh, man. Yeah, Justin says, sounds good to me… Terrence, does that work for you? Okay, he said yes. Okay, cool.

Terence Tsao: Sorry, I have one last question, if you don't mind that. Is there a block-level asset stack that's out already against consensus Layer, Repo? Because I couldn't find anything out, and I really wanted to implement it, like, last weekend, and yeah, is there something I can do?

Toni Wahrstätter: Yes, this exists. You can go to blockaccesslist.xyz and the CR specs. or the engine API specs are… link there.

Terence Tsao: But is there a PR that's.

Potuz: Yeah, open a PR, man. Stop sending.

Toni Wahrstätter: Yeah, it's.

Potuz: different…

Toni Wahrstätter: Yeah, I'm just on my phone right now, so… The link is up there, there is a PR there.

Terence Tsao: Okay, and it's up to date, right?

Toni Wahrstätter: Yes.

Terence Tsao: Thank you so much. Awesome.

Alex Stokes: Yeah, do we know if it's, this link here, Tony, under Features 7928?

Toni Wahrstätter: Yes, I think that's it.

Alex Stokes: Okay.

Toni Wahrstätter: I will double-check it, but I think it should be right.

Alex Stokes: Okay. Cool. Okay, so are we good then? At least, yeah, Barnabas, are you clear on the changes to this proposal, and then everyone else? We're clear on targeting Clemstrand bit.0, right?

Barnabas Busa: Yeah, one more thing that I would like to discuss is also maybe we can start discussing DevNet1 scope, so that we are, like, aware of, like, what kind of changes we want to be working on during interop. Because we're not gonna have another ACT SQL before that. So, I would propose that, we either do nothing, no additional EIPs, I would… I would not like to offer this as a suggestion, but option B would be to add 8045, which is the exclusion of slash validators. Or option C would be the IP 8080 plus 8061, which is the, Churn rework and the exit via consolidation queue. Both of those, still need to be, merged in into the, consensus spec.

I'm just curious, what SEA teams would prefer.

Alex Stokes: Any thoughts? I think, yeah, I would generally propose that we focus on getting the other stuff stable first, but then, yeah, if we want to have some things queued up.

Barnabas Busa: Yeah, I think we should just have a nice target to hit in case.

Alex Stokes: Yeah, yeah, I'm thinking, yeah.

Barnabas Busa: I mean, the state.

Alex Stokes: I mean, the, like, options that you have here are, like, very nice staking UX things.

Parithosh Jayanthi: Is that defined as a stretch goal for Interop in that case, or what's the plan there? Because I think we haven't stressed anything, and often once we start stressing stuff, we tend to find edge cases, and it's probably very productive if we're together to find those edge cases.

Alex Stokes: Yeah, I think stretch goal would be good.

Barnabas Busa: Yeah, so that…

Alex Stokes: what'.

Barnabas Busa: These are isolated VIPs that, people that are… don't work necessarily own Amsterdam, directly, they could also be focused on this. And they could be, they're pre-isolated, so they could be tested, independently as well.

Alex Stokes: Okay. Does the client team have an opinion here? Otherwise, I'd lean towards nothing, or… these staking EIPs myself. Okay. I guess another way is just take a look, and Barnabas, you could either ask again on Monday during ACDT, or next week, ACD. Otherwise, yeah, maybe it's just something we handle, during interop. Okay. And then, Barnabas, you had, I think, two other comments. Do you want to cover those now, or do you feel like we've covered them sufficiently? We haven't really talked about them. This is the cell level deltas and the PR to the 8045.

Barnabas Busa: Yeah, so the one… one of them is just, the meta… the IP from Amsterdam. basically moving the networking EIPs into their own section at 70, 71, and 72, and also adding desirable datas, mass-working EIP for Amsterdam. These are all, optional yet this. I think we have done this in the past. It's just a formatting change.

Alex Stokes: Okay. What does optional mean here? That it's in the meta EIP, but you don't have to implement it by the fork?

Barnabas Busa: Yeah… Realistically, this is mainly a… a question of these, ELs, with EV70, 71, and 72. Yeah. I, I think, they're also working heavily on implementing all three of those.

Alex Stokes: Okay. We could get a temp check here, then take it to ACD next week, then? Potu, so you have your hand up?

Potuz: I want to ask a technical question, it's going to be fast, but point me later when you finish this topic.

Alex Stokes: Okay. Yeah, does anyone here have an issue with including this PR? Which adds… yeah, 8136? to the Meta EIP? This is generally consistent with what we've discussed in the past, and what I think many of you are working on, so it's not a surprise. Okay. We got it, it's fine. From Lighthouse? Do you want to run this by the AL devs next week, Barnabas?

Barnabas Busa: I mean, the ELDevs, yeah, for formatting wire share, but the addition of the, of the partial sales EIP that… Doesn't concern them. Only concerns the sellers.

Alex Stokes: Okay. I guess the question is, what if we include this in the media IP, and then it doesn't get shipped with Amsterdam? Like, is that weird? Do we just take it out later? Do we mark it optional?

Barnabas Busa: I mean, the… yeah, the partial cell is optional, and we have two client implementations that are pretty much relatable, so… I think others are also working on it. I think it would be a nice stretch goal as well for everyone to try to merge it in by Amsterdam. That's why I would like to list it there.

Alex Stokes: Yeah.

Barnabas Busa: Yeah, you're also allowed to ship partials ahead of Grand Sterdam. If it would be just nice to start testing it on a… when I… And, if you have your changes in the trunk branches, just let us know, and then you can, That's just a joke. Okay, never mind that.

Alex Stokes: It was ambitious, but yeah, a joke, but also ambitious. Yeah, okay, then I would say let's go ahead and merge this in. And, yeah, we should be good there. And then… did you want to talk about 8045?

Barnabas Busa: Yeah.

Alex Stokes: Wrap up this section.

Barnabas Busa: So, 8445, has a little bit of, change that I'm proposing. So, originally, the idea was that, slash editor should be excluded from proposing blocks, but I would like to expand the scoping to, exclude it to… from all the later Qtys.

Alex Stokes: Yeah, I took a look, and this might look kind of heavy, just because it touches more of the spec rather than less. But yeah, I think generally this is probably… Some people need about the protocol?

Barnabas Busa: Yeah.

Alex Stokes: Has anyone else had a chance to look at this? So, yeah, just to reiterate, this would… so 8045 right now, it says if you're slashed, you can't propose. And this change just extends it to all duties, so if you're slashed, you just don't do anything. Any thoughts?

Potuz: We've never had time to actually check on the problem that this brings, which is the fact that, It changes the kind of states that we can use, from being head, or anything that is compatible with the shuffling, to being the right state. having the… not only the shuffling, but the right balances. I'm scared of that change, but I haven't really thought deeply about it, because we're implementing something else. My default would be not to include this and aim it for later, if we find time to analyze that statement.

Alex Stokes: Those are good points. Any other thoughts on this? If not, I would maybe suggest Barnabas. We just… Run this again during interop. And see if we can make more progress in person. Yup. Okay, cool. And then, yeah, circling back to BOTUS, I'm assuming you might have a question about the BAL stuff?

Potuz: Yeah, so I'm reading the spec, I just want to make sure of something. The changes are that we change the payload. And… that's it. Nothing else. I mean, there's a corresponding engine API call, because the payload will have this extra… this extra thing, but it seems wrong to me to have this root, and the header changes in the beacon state. This should not affect the beacon state at all. And I think it's also wrong to change the process execution payload. We should not change the process execution payload at all. So I think the only changes are on structure, just the payload changes, and the engine API changes. And Slot NAM also changes the engine API with a…

with, attributes. But there's no structured changes on the CL side, as far as I can say, besides the payload change. If that's the case, I can open the PR right now.

Toni Wahrstätter: Yeah, I think that's right. That sounds about right, and go for it.

Barnabas Busa: If you're, gonna do this engine API change anyway. Do we also want to now… To the new payload response, add the field to the new payload response, so we would remove the duplicate data that we were talking about in the beginning. Introduced in 5094.

Alex Stokes: Karen says here in the chat, we should do that to be consistent. I think that was about the current question, right?

Nico Flaig: So I think we need to see how ELs handle this right now, maybe before doing that. Because from my understanding, is we sent this as part of the new payload right now, and then the EL basically generates the execution requests from the receipts of the transactions, and then compares the two lists, and if they don't match, then the payload is invalid. So with that change, what we would need to do is the EL sends back the list, and the CL checks the response against the commitment. And to see if they match to what the builder committed to. But I'm not sure, we just talked about this on Discord, so… I don't think we have looked into the details yet, and it would be good to have ELDevs chime in.

Barnabas Busa: Nico, could you maybe open a PR on the execution API side, so that the EL devs can take a look at that? And see if, if it's something that we could, be targeting for the next, DevNet.

Nico Flaig: IS, definitely, I can do that, yeah.

Barnabas Busa: I would actually target this optimization, now, because we are touching the engine API now anyway. So the AIL teams would have to, Make the changes, and this just feels like a small change.

Potuz: Well, it's not really small, because it would affect also the objects that we're gossiping on the CL side, it would affect the way that we're handling things. We expected the request to be on the envelope, and now we no longer would expect the request to be on the envelope. I think it's an easy change, I just think if we keep piling changes, we're never gonna ship. I want to ship.

Alex Stokes: Okay. So, are we gonna do this or not right now?

Barnabas Busa: Maybe let's open the, the PR on the Engine API spec, and then, circle back to it during interop.

Potuz: It's not only an engine API change, it's a PR that needs to be included in the CL repo as well. I mean, it's not an engine… an engine change. It's a consensus change as well.

Alex Stokes: Okay, so then maybe to move forward, if someone can open the PR, we can start to wrap our heads around it, and yeah, we'll figure out if it's an interrupt thing or a post-interrupt. Sound good? Okay. Cool. Okay, Justin had one more question. I'm not sure what this is. Do you… can you give us a summary of the change, Justin?

Justin Traglia: Yeah, it just swaps two fields in the, state. I mean, it makes sense, but it's just, maybe a little annoying to implement.

Alex Stokes: Let's see… interesting. Okay…

Justin Traglia: I don't… Just wanting a confirmation.

Alex Stokes: I had a chance to look at this. Yeah, I don't know. We have a good number of people saying it's fine. So yeah, we'll just go ahead and merge it then. Thank you. Okay, cool. I lost the agenda, here it is. Okay, anything else on Glamsterdam? Maria wanted to give an update on the repricing stuff, but I think I'm gonna hold that till the end. If there's time… So we can cover… I go to stuff… Any other Glensteram things for right now? It sounds like we have a pretty clear plan to interrupt. There are many open questions, but that's… that's the point. Okay, then let's move to Hagota.

And yeah, just a quick reminder, so we've opened the non headliner proposal process, or window, I should say. This is gonna run for some time. I think ultimately, you know, it'd be best to kind of time this with Amsterdam progress, and that's a bit uncertain at the moment, so then that means the end of this window is a bit uncertain, but ultimately, there will be ample notice. For people both here and watching this recording, either, you know, now or later. Anyone in the community who hears this, yeah, you'll get a notice about that. You should assume you'll have, yeah, yeah, probably weeks, like, more than a month at this point, from today. But yeah, so…

We are there, and point being, already today, there were two requests to discuss some proposals. So, let me make sure I get this in order. Okay, the first one, from Ocean… EIP7716, if you're here and want to take a couple minutes to give us the TLDR, now would be a good time.

Oisín Kyne: Perfect. Am I sharing my screen properly?

Alex Stokes: I can see it, yeah.

Oisín Kyne: Sweet. Nice to meet you, everyone. Plan here is to briefly reintroduce you guys to an EIP that we'd like to put forward for Hegota, called, Correlated Downtime Penalties. So the problem that we're looking to solve with this is that liveness failures aren't particularly penalized unless and until you go over 66% downtime. That's when the kind of quadratic penalty kicks in, so for the most part, you know, losing 10% of the network doesn't have a particularly significant impact on those offline, and it, in fact, also penalizes the people online. We think this is a bit of a missed opportunity, and something we can do to try and incentivize people not to have the most correlated setups, so that we're in a better position if ever there is some kind of mass slashing situation.

The EIP is pretty simple and kind of concept, and then the implementation side we can kind of talk about. But, something that's pretty important to note is that, this penalty spikes up literally just at the beginning of this, like, decrease. And it doesn't actually continue to have high penalties while downtime is ongoing. This isn't deliberate such that, you know, the bigger centralized entity that has on-call teams and can, you know, get things rectified faster, don't, you know, have a benefit versus, you know, the smaller orgs. And, you know, pictures says a thousand words. Why does this matter? Right now, I think the validator set is not in really a great shape from a decentralization perspective. Delegating fees are, like, you know, 1% and zero, so a lot of small and medium operators are shutting down.

And a lot of people are kind of agglomerating in a couple of cheap bare-metal data centers in Europe, and I think that proves a risk to the network. As I mentioned earlier, I think a key upside for this is if we correlated penalize on liveness, that will have us in a better position, that we're less likely to be in a correlated slashing position if that ever happens. Generally speaking, the kind of way this impacts the solo stakers and geographically diverse stakers see no change from the usual downtime penalties, and this mostly impacts the kind of larger operators. You can see here from research by Tony, kind of two graphs to try and, like, exemplify this.

So, here in, kind of, his clustering analysis, you can see the smaller clusters, see the reduction in penalty, and looking at it by, kind of, named orgs, Rocketpool and Solo Stakers stand out as the people that get, you know, the biggest reduction in penalties. Everyone else gets mostly a modest increase, if anything. the kind of key questions that I've kind of, like, pre-prepared or surfaced from people between here and an SFI decision. is things like, you know, do we have the curve the right shape? Is this actually enough? Right now, it's set to only have a 4X increase. I'd love to kind of straw poll people that kind of have a decision around. If we did lose 20% of the network, how many, you know, days or weeks does it feel appropriate to make it back, such that you incentivize yourself to, like, change the provider and not end up in a situation where you're, you know, down with 20% of the network in the future?

Questions around, you know, client diversity, small validators, could it increase adversarial behavior? Does timing games come into this? You know, can that, you know, harm the kind of most decentralized end? does it change the STF by much? Could it do anything weird on, like, the chain tip? You know, does this impact operator consolidation? I think that one, not really. It's, like, based on ETH, not on key count, and the usual, you know, opportunity cost of, is it worth it versus other decentralized EIPs. The published research is, you know, one from Vitalik originally, two from Tony. There are links here. I straw-pull some of the client teams, and you can kind of see some open issues that are like, yeah, you know, soft yes, but need to, like, harden some questions.

And that's pretty much it, and would love to get anyone's, you know, feedback, either verbally or in the chat, about things that you'd like to see solidified in this to bring it on the maturity path for Hegota. Thank you.

Alex Stokes: Great, thanks. Any questions? One thing that might be helpful is, like, a very, you know, sort of initial early, proof-of-concept implementation, just to de-risk the scope here, when we do go to think about including this with other things in Agoda. And it might be a little tricky to get that, but I think the more you can do, the merrier.

Oisín Kyne: Bill implied that there was a mock implementation before, I don't know who NC is.

Alex Stokes: Nc, I think, from Lodestar. But either way, yeah, just something to keep in mind, and if you have someone you've been working with, just follow up. Cool. Cool, yeah, thanks. Okay, next up then, we had another proposal from Dimitri here for EIP8205, if you'd also like to take a few minutes to say some words about it.

Dima Gusakov: Sure. Unfortunately, I'm not that well prepared as Ocean, and I do not have slides. However, the thing that I want to present today is pretty simple and straightforward, and probably none of you would need, any slides to understand what we are trying to solve. So what we are trying to solve with, 8205 is a… very long leaving. deposit front-run vulnerability. So, as you all know, right now, when you make a deposit to a validator. Only the first one counts, and the first deposit, larger than 1ETH, for sure, will set withdrawal credentials for the validator once and for all. So, with the delegated staking, where the funds are controlled by one entity, and the validator is controlled, the validator private key is controlled by the other entity, which is the absolute majority of all Ethereum staked.

For sure. There is a chance that the… I wouldn't say there's a chance. There is a possibility for the owner of the validator private key to Frontran. any deposit transaction made by the counterparty that controls funds, so that they insert their transaction with one EVE deposit, setting up withdrawal credentials to their own address, so that any other transaction from the funds holder would land on the validator, but since this validator would already have a different withdrawal credential sat, these funds would effectively be stolen by the owner of the validator private key. And there is no… Like, reasonable way to protect from that, other than sophisticated monitoring systems, other than Doing multiple checks on-chain and off-chain to ensure that your transaction, your deposit transaction as the holder of the funds, or as the counterparty that controls the funds at the moment.

To ensure that the validator you're making deposit to has not been previously deposited, because, again, the front run might happen in the same, in the same block using, MEV relays or whatever. So what we are proposing here is a simple and elegant solution to this problem. Given that, starting from the introduction of EIP4788, which allows execution layer to get access to the data on the consensus layer, we propose to leverage this opportunity and introduce a pre-registration, an optional pre-registration mechanism for the validator keys, so that, before making any deposit, a staking protocol or any delegated staking entity, like using smart contracts or not using smart contracts, can ensure that the pre-registration exists For the given validator key, and that they can safely make a deposit, making sure that their transaction would not be front-run, and the withdrawal credentials would not be set to a different address.

The pre-registrations happen through a simple mechanism of propagating messages from execution layer to consensus layer in the same way as we do for execution layer withdrawal requests, consolidations, and so on and so forth. The pre-registration messages and the pre-registration objects, they have a lifetime, so that people would not be able to overextend the consensus layer state, so whenever you do a pre-registration, there is a lifetime after which the pre-registration is removed. And provided that this information would be stored in the consensus layer staking protocols, and again, any other delegated staking party, would be able to ask for a proof that such a pre-registration exists before making a deposit to a validator key. And that's pretty much the gist of the EIP. So, the core idea here is to fix, to finally fix this deposit run from…

deposit front-run vulnerability that had been with us since the very, very first day of Beacon Chain, and we are living with the Beacon Chain and the consensus layer for more than 4 years already. And this thing had never been fixed, so we believe that the time has come to propose and to implement such a small, elegant, and simple fix to this problem. I'm happy to answer any questions, should you guys have any.

Alex Stokes: Yeah, I have one that might be straightforward, but how do you prevent front-running of the preregistrations?

Dima Gusakov: you are not preventing from running of the pre-registrations, you are simply saying that you will only make a deposit to a validator if the pre-registration exists with the correct withdrawal credential. If pre-registration exists with an incorrect withdrawal credentials, you will not make a deposit. So you are basically getting an opportunity to know beforehand that your deposit will succeed and will land on the validator with the correct withdrawal credentials.

Alex Stokes: Okay, so yeah, it's almost like a pre-commit and then a commit, or like a… It's like an optimistic thing. If you go to deposit, and it doesn't match… yeah, actually, what happens to the deposit then?

Dima Gusakov: This deposit is simply ignored, in the same way as incorrect deposits are handled these days.

Alex Stokes: And you burn these.

Dima Gusakov: Correct, but you have the opportunity, and yes, so this mechanism is optional, and if you want to opt in to use this mechanism, you need to make sure that you ask for pre-registration proof before making deposit. For the others, for those not willing to use this mechanism, they can still continue working in the same way that they did before. So, the beauty of this is that it's fully optional, but for those who are concerned about this vulnerability, there is now a clear path To resolve this vulnerability.

Alex Stokes: Yeah, I guess one more quick question, because we have a few minutes. Yeah, I haven't thought about this myself. I think I talked to Greg about this, actually, at ECC, and haven't had time to think about it since, but… I do wonder if you can do this with smart contracts, like, you could have… A pre-registration gate smart contract that then submits the deposit for you. If it matches.

Dima Gusakov: Unfortunately, right now, with the current state, there is no way to prevent it on the smart contract level, because the game here is very simple. the owner of the validator private key can always be faster than any transaction you would like to do from the execution layer. And the only case when you can guarantee that is when you guarantee it on the consensus layer where the request is actually processed. So, right now, and as Barnabas mentioned, yes, there is a way to solve it on the upside, and, like, we're solving it right now. However, it costs, Lido and any other delegated staking protocol, like, literally millions of dollars every year. to maintain the system. So the current system in LiDAR is probably one of the most sophisticated, because it does not involve, does not involve risking pre-deposits of one ETH.

But the system is complicated and very hard to maintain in between the forks. The other protocols, they use… they use mechanism, I would call this mechanism rocket pool-like. where the… either the owner of the private key is required to post a bond of 1 ETH and make this initial deposit of 1 ETH, but this is not acceptable for the protocols where validators do not post a bond at all. And again, this is the majority of the network. So, the protocols right now are either risking 1 ETH per validator, or having a very complicated system in place, and the problem is that these systems are not standard, and each and every protocol have to pay this price.

So, what we are asking for here, and what we are proposing, is to make a simple change to a consensus layer that would be fully optional, again, and that would not interrupt any… existing schemes, any existing protocols, especially those making this, 1 ETH pre-deposit. But would allow many protocols to, stop maintaining this complicated system and stop spending thousands of dollars and focus, again, on the more important things. like, keeping up with Ethereum and implementing things that are important for Ethereum, other than simply having to maintain this, pretty, pretty heavy-weighted systems.

Alex Stokes: Yeah. Okay. Any other questions or comments? Okay. If not.

Dima Gusakov: Again.

Alex Stokes: Thanks.

Dima Gusakov: Yeah, like, again, I want to finally point out that the change to the consensus layer itself is, like, extremely simple, and please go check out this EAP. It would not break anything. And but that would solve a lot of problems. So, from the implementation perspective, it's… it's a very simple thing, and from LIDAR side, we are ready to develop an audit The reference implementation of the so-called safe deposit contract, where people would be able to provide their deposit signature, plus the expected withdrawal credentials, plus the proof. of the fact that pre-registration exists, and make a safe deposit, no questions asked, through a smart contract that will be, again, developed, provided, and audited by LIDAR if such a reference implementation will be considered as needed.

Alex Stokes: Okay. Sounds good. Okay, thank you. If there are no other questions on that, then yeah, we'll just keep it on the table for later, once we get back to, scoping the headliner proposals. And yeah, we'll have both this and 7716, in the set. Okay. Then I think we are here. We have the last thing on the agenda. Maria wanted to give an update on the repricings. And I think this is mostly, an EL thing, but, yeah, if you wanted to say something, Maria? You could take a few minutes.

Maria Silva: Right, so it'll be fast, it was just to give a quick update. So we had the Amsterdam repricing breakout, last Wednesday, and, we did a couple of decisions on the final, spec for the state growth EIP, so AT37. And, I think, it changes, a few things on how, state-related refunds work. And I can give a bigger update on the next ACDE, but it's just to, just to communicate that, yeah, we've solved the open issues we had on the TIP, so the next spec that Spencer is working on. should be more stable, but also to say that we kind of did a rework on how state gas is charged and refunded. That, I think now aligns much more to

the actual cost. So, we only really charge for state growth when actual state is created, which I think it's, it's nice. So yeah, just a quick update on that. And again, I can, probably do a bigger update in the… in the next ACD. Thank you.

Alex Stokes: Alright, amazing. Thank you. If there are no follow-up question or… questions or comments about that, yeah, anyone have anything? Spencer here has a link to spec changes for that as well. Okay, I believe this is everything on the agenda. Let me just make a quick scan here, but I think we touched on it all. Okay, cool. Yeah, if there's nothing else, then… yeah, again, I think everyone will be… Very busy. Oh, Barnabas?

Barnabas Busa: Yeah, all the EL devs, please start to think about what would you like also in Amsterdam, Dev, not one scope, which kind of EIPs, because we still have a bunch of, EL-side EIPs. And just check my comment on ACDC.

Alex Stokes: Hmm, okay. Potus?

Potuz: I opened the Trivial PR for balls on the CL side. It seems to me that it's only the payload change and nothing else. If we can agree on the engine API changes for the DevNet, that would be great. In particular, it seems to me that it's only the changes on the engine API that we send the balls now on the… with the payload. And, the… the slot number, if we send them on the… on the paid order attributes, I don't know if that should be in the DevNet or not, but let's try to get the engine API ready quickly, so we can just start. Having this now undeveloped.

Alex Stokes: Okay, yeah, thanks for putting that together. Very fast. Okay, there was one thing here from Mark, just a heads up, we will have a native account obstruction breakout next Wednesday, 1500 UTC. And, the agenda is linked here in the chat, if you want that. Otherwise, it's on… it's in the PM repo. And, okay. I think, then, that's it. Again, last call for anything else. Okay. If not, then great, yeah, I think everyone will be super busy getting the deadnets together as we move towards Interrupt, and yeah, good luck with that, everyone. And I'll see you next time. Thank you.

Potuz: Bye-bye.

Justin Traglia: Hi, everyone.

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