stokes:Welcome to ACDC number 177. This is issue 1990 in the PM repo.
Transcript
stokes:The agendas here, in the chat, and… yeah, we have a number of things to discuss today.
stokes: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.
stokes:And if there's time, we'll have an update on some of the BAL work.
stokes:Er, sorry, the repricing worked.
stokes:So yeah, let's go ahead and get into it. So, to begin, we have Amsterdam.
stokes:And… yeah, many of these things here kind of all tied together,
stokes:But maybe to get us started…
stokes: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?
stokes: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.
stokes:Yeah, Barnabas?
Barnabas:Yeah, so ePBS does not…
Barnabas: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.
Barnabas:Which basically requires the 5094, which is, basically the next step on the agenda.
stokes:Okay, so yeah, then let's just go ahead and get into that.
stokes: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.
stokes: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.
stokes: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.
stokes: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.
stokes:Okay.
stokes:Yeah, do we want to get into it? Can you just give us a quick summary?
Potuz:Oh, yeah, so…
Potuz:The issue is that, we are now sending the requests on the envelope, and also including these requests on the block.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz: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.
Potuz:So, it comes with a bunch of trade-offs.
stokes:Yeah.
Raúl Kripalani:And also…
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,
Raúl Kripalani: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,
Raúl Kripalani:suggested, Then, what we can do is simply
Raúl Kripalani:The data structure… the signature would remain the same.
Raúl Kripalani: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.
Raúl Kripalani:Today, The thing that we would do is we would simply…
Raúl Kripalani: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
Raúl Kripalani: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
Raúl Kripalani: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.
stokes:Yeah.
stokes:Quick question for my own understanding.
stokes: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.
stokes:Okay.
stokes:Outpost.
Potuz:Yeah, so…
Potuz:Well, I mean, regard… regardless of semantics or not, like, we could do this, we could, we could, like, gossip blocks
Potuz:Blinded, but this comes with a considerable
Potuz: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.
Potuz:for example, or when you request a block on RPC to be the unblinded one, and then on Gossip to get the blinded one.
Potuz: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.
Raúl Kripalani: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.
Raúl Kripalani: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
Raúl Kripalani: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.
Raúl Kripalani:It's just this particular route in the critical path, adding 1.5 megabytes to send duplicate data, is extremely inefficient.
Raúl Kripalani: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.
Raúl Kripalani:But anyway, one thing that I do want to highlight is that the STF, as I understand it.
Raúl Kripalani: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.
Raúl Kripalani: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.
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.
Nico Flaig: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…
Nico Flaig: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…
Nico Flaig: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.
Nico Flaig: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
Nico Flaig: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.
Nico Flaig: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
Nico Flaig:Doesn't… it's not sufficient anymore, I guess, because the EL could still produce a block that is invalid.
Nico Flaig: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?
Nico Flaig:Too low number.
Nico Flaig:Like, the EL could maybe just say, don't include more deposits into a single block than what this limit is.
stokes:Yeah, I mean, it's possible. I don't know if any yellow devs want to chime in on this.
stokes: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.
stokes:Enrico?
Enrico Del Fante (tbenr):Yeah, I just want to comment on… on Raul's perspective, because…
Enrico Del Fante (tbenr):I don't feel that we may say that the Raul perspective is too much complicated, because I feel like
Enrico Del Fante (tbenr):He's right saying that we could confine this change in the networking layer and the overall client just on
Enrico Del Fante (tbenr):block gossip.
Enrico Del Fante (tbenr):flow, and make everything else, including RPC, exactly… How they are today.
Enrico Del Fante (tbenr):So, just when we receive the block, during the flow.
Enrico Del Fante (tbenr):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…
Enrico Del Fante (tbenr):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.
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…
Raúl Kripalani:the… on the gossip layer, everything else stays intact. We still save the data structure on the store, we serve it over our PC,
Raúl Kripalani: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 (tbenr):But there is a complication.
Raúl Kripalani:Okay, so…
Enrico Del Fante (tbenr):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 (tbenr):Only… only the… only something, actually, to… to…
Enrico Del Fante (tbenr):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…
Raúl Kripalani:You would then be moving the beacon state without…
Enrico Del Fante (tbenr):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.
Enrico Del Fante (tbenr):Yeah, I think, like, yeah, we don't need to have a specific RPC to get just the execution
Enrico Del Fante (tbenr):request unblinded from clients, I don't know if there's any reason to have a specific RPC.
Enrico Del Fante (tbenr):In… But, yeah, it's possible that you just…
Raúl Kripalani:Yeah, so…
Enrico Del Fante (tbenr):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.
Raúl Kripalani: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.
Raúl Kripalani:So… That's… Is that… is that wrong? Is… Is this assumption wrong?
Enrico Del Fante (tbenr):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.
Raúl Kripalani: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
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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…
Raúl Kripalani:It shouldn't… so if you're really only interested in the execution payload at that point, then the…
Raúl Kripalani:cost of receiving the beacon block as well in the response is just residual, it's just tiny, so it shouldn't matter.
Raúl Kripalani:My perspective is a much better space of the design trade-off here.
Enrico Del Fante (tbenr):Yeah, there is also the other side of it, that you have to blind it during publishing, so there is an unblinding, and then
Enrico Del Fante (tbenr):The proposer needs to blind that while doing the pro… the… .
stokes:Yeah, but you just put the hushed root of the…
Enrico Del Fante (tbenr):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…
Enrico Del Fante (tbenr):Strong tightening between the block type and what is on the publishing side, so if some kinds have some…
Enrico Del Fante (tbenr):Assumptions, and they have to break that assumption.
Enrico Del Fante (tbenr):Maybe it could be a complication.
stokes:I imagine there's enough change already with ePBS that that's fine to me.
stokes:Barnabas?
Barnabas:Yeah, that would be my main question here, that…
Barnabas:Do we really want to keep pushing this decision based on,
Barnabas: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,
Barnabas:Even 1.5MB on a 3000 deposit slot is very, very unlikely to happen.
Barnabas:And, we're not gonna get many of those, even on mainnet.
Barnabas:Like, is this really something we have to deal with?
stokes:Yeah, yeah, it's a good question.
stokes:Enrico?
Enrico Del Fante (tbenr):Yeah, I feel like we can definitely postpone this… this. If… so, if the assumption is correct, which is the only way
Enrico Del Fante (tbenr):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
Enrico Del Fante (tbenr):break… change anything on the consensus layer. It will be just a networking change, and we can decide it.
Enrico Del Fante (tbenr):To do this later, after a better evaluation of it.
stokes:Right, so yeah, the proposal would be then to have them duplicated, and someone help me.
stokes: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,
Nico Flaig:like, they are kind of duplicated in the transactions already, right? Like, the…
Nico Flaig:payload itself contains the transactions for the deposits, and you can always generate the execution requests from that. So I think with the
Nico Flaig: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.
Nico Flaig:And then the next proposal needs to include them in the beacon block, but you would get rid of the data duplication.
Barnabas:I would not introduce an engine API change for this.
Barnabas:But that's just my personal take.
stokes:Yeah, and then one quick question to POTUS' comment here, in terms of RPC.
stokes: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.
Potuz: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.
Potuz:5094 in the current status solves that problem.
Potuz:If we remove the request from the block.
Potuz:This problem would go back to the status that was before 1594, And…
Potuz: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…
Potuz:are not really strictly necessary on Consensus. Already 1594 is not necessary for consensus. We just accepted it because it, like, simplifies implementation.
Potuz: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.
stokes:Yeah.
stokes:That's how I'm leaning as well at the moment.
stokes: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
Raúl Kripalani: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.
Raúl Kripalani: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.
Raúl Kripalani: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.
stokes:Yeah, that makes sense.
stokes:In the specs, like, we'd have…
stokes:So, like, yeah, I think the straightforward way that you would do this is you'd have, like, new block types in the spec.
stokes:Maybe this is, like, an optimization?
stokes:Well, that would be messy, too.
stokes:So, in any case, yeah, hear what you're saying.
stokes:It might be… harder than it sounds.
stokes:But yeah, let's, let's get back to the current topic.
stokes:Then, it sounds like we're all in agreement to go ahead and merge 5094 to get past this issue.
stokes:There may be an ask down the line to add this optimization that Rule's proposing.
stokes:And is everyone okay with that?
stokes:Okay.
stokes:Okay, got some thumbs up.
stokes: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…
stokes:From there…
stokes: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.
stokes:There's BAL DevNet 4, eBPS DevNet 2, that's gonna reflect some of the changes we were just discussing.
stokes:And then, of course, the road to Glumpster Dam DevNet Zero.
Barnabas:Congress.
stokes:that…
Barnabas:There's just one more quick PR that I think we should discuss.
Barnabas:5067.
stokes:Okay, well, I think you have 3 now, so do you just want to run through them?
Barnabas:Yeah, so 5061 is basically… clarifies the, growth genesis,
Barnabas:Questions, and, this is gonna be rebased on top of, 5094.
Barnabas:I'm just not sure what the current state of this PR right now.
stokes:Yeah, it's from Brekkie, I don't know if they're on the call.
stokes:Otherwise, yeah, is this something we need to merge before we can move forward with DevOps?
Barnabas:Yep.
Barnabas:Ideally. Okay. So the main reason we need this is, when we're testing out the builder workflow,
Barnabas:Having the builders already available at Genesis basically enables us to get the builders working without needing to make builder deposits.
stokes:Yeah, okay, that makes sense.
stokes:Brekkie left a comment that this should be revisited after 5094, so…
stokes:Yeah, maybe then we can do that, say, today or tomorrow.
stokes:And circled back to this on Monday.
stokes:Oh, okay, he's in the chat here.
stokes:Okay.
stokes:Does 5094 change anything, or it just needs a rebase?
stokes:Okay, it does change.
stokes:So does that work, Barnabis, if we just handle this on Monday, then?
Barnabas:Yeah, ideally, we want to have everything merchant by, tomorrow, I think.
stokes:Okay.
Iván | ethrex:Yeah, it's on…
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.
Justin Traglia:That's the target.
stokes:Perfect.
stokes:Okay.
stokes: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?
Potuz: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,
Potuz: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.
stokes:Yeah, I think Barnabas wanted to talk about that, but also he was gonna cover these two other PRs first.
Barnabas: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.
Barnabas:And ideally, Glamstra Demp Definite Zero could,
Barnabas: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…
Barnabas:ball changes on the CR side.
Barnabas:And then, ideally, in the last day of interop, we could also do, Glamstagram. 1, where we…
Barnabas:basically introduce a few…
Barnabas:or none, no other CL VIPs, and, some or none, BL DIPs.
Barnabas:Because… You can find more details about everything in the issue of the score.
stokes:Turns.
terence:My immediate feedback… by looking at it, is that you want to do ePBS.N2 on Friday.
terence: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
terence:hearing that.
Iván | ethrex:Oh, you know?
terence:part, so I think, like.
terence: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:The idea is that on Monday, we're gonna be spending the holiday, figuring out the ESCL changes.
Barnabas: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:Yeah, but I just don't think, like, there's enough time
terence:between Definite2 and DefNet0. If you want to just bring in Bell, it's just much easier to do everything together at that point.
stokes:Well, unless there's a lot of bugs from merging them. If we relax the time.
terence:Yeah.
stokes:Amsterdam DevNet Zero, does that make everyone feel better?
terence: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…
terence:are minimally touched by 5094.
stokes:Yeah, and so we're not worried about, like, some BAL bug on the EL causing issues with the EPPS state transition, and…
stokes:Breaking things?
terence: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.
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.
stokes:So then Devna 2 stable would give us, like, a good foundation then to work on the merge.
stokes:And… I would imagine that if we just go for the merge, it, will just add more…
stokes:more issues.
stokes:To work through, than otherwise.
terence: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.
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
Potuz: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
Potuz:are even possible, the kind of bugs that balls would just affect on the CL side. I think
Potuz: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.
stokes:Well, there's just one… That would be it, right?
stokes: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.
stokes:So, do any EL devs actually want to speak to us? That might be helpful?
stokes:Or if they're not here, Barnabas, what do you think about just relaxing the timing that you have for Lumpstream DevNet Zero?
Barnabas:I don't think it's the timing that is of question,
Barnabas:from Portos, like, they basically won Glamsterdam Definitely zero.
Barnabas:Next week, Friday.
Barnabas:Right?
stokes:That's the proposal, yeah.
Barnabas:Yep.
Barnabas: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: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.
stokes:Yeah, other… other seal plant tombs?
stokes:I think we've heard from Nimbus, and…
Barnabas:The stock norm is very minimal, by the way.
Barnabas:So that's… that's a minor one.
stokes:Bye.
stokes:Yeah, in that case…
Barnabas:if… if we do end up going with Amsterdam Devon Zero next week, Friday, then I would actually target to do…
Barnabas:block level access list DevNet 3 scope with,
Barnabas:with the Alpha 5 changes from the CR side.
stokes:Okay, and then you'd merge in the DevNet 4 stuff in DevNet 1, or how do you think about that?
Barnabas:Yeah.
Barnabas: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…
Barnabas:Yeah, I would just like to test those separate on, Docker Access List Network before we can,
stokes:Yeah.
Barnabas:Before we can merge it in. But, yeah, they are also…
Barnabas:Quite, isolated, so it might…
Barnabas: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.
Barnabas: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…
Barnabas:end of next week.
stokes:Yeah.
stokes:Okay.
stokes:Then, yeah, I think otherwise, from Lighthouse, no strong preference, but lean towards OneDevNet.
stokes: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.
stokes:with the spec versions part of us just gave.
stokes:So…
Barnabas:Yeah, then Justin would also need to make sure to merge in the slot num and the block.SS list stuff into Alpha 5.
stokes:Oh, man.
stokes:Yeah, Justin says, sounds good to me…
stokes:Terrence, does that work for you?
stokes:Okay, he said yes.
stokes:Okay, cool.
terence: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.
Toni Wahrstätter:or the engine API specs are… link there.
terence: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…
Toni Wahrstätter:The link is up there, there is a PR there.
terence:Okay, and it's up to date, right?
Toni Wahrstätter:Yes.
terence:Thank you so much. Awesome.
stokes:Yeah, do we know if it's, this link here, Tony, under Features 7928?
Toni Wahrstätter:Yes, I think that's it.
stokes:Okay.
Toni Wahrstätter:I will double-check it, but I think it should be right.
stokes:Okay.
stokes:Cool. Okay, so are we good then? At least, yeah, Barnabas, are you clear on the changes to this proposal, and then everyone else?
stokes:We're clear on targeting Clemstrand bit.0, right?
Barnabas: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.
Barnabas:Because we're not gonna have another ACT SQL before that.
Barnabas:So, I would propose that,
Barnabas:we either do nothing, no additional EIPs, I would…
Barnabas: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.
Barnabas:Or option C would be the IP 8080 plus 8061, which is the,
Barnabas:Churn rework and the exit via consolidation queue.
Barnabas:Both of those, still need to be, merged in into the, consensus spec.
Barnabas:I'm just curious, what SEA teams would prefer.
stokes:Any thoughts?
stokes: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:Yeah, I think we should just have a nice target to hit in case.
stokes:Yeah, yeah, I'm thinking, yeah.
Barnabas:I mean, the state.
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.
stokes:Yeah, I think stretch goal would be good.
Barnabas:Yeah, so that…
stokes:what'.
Barnabas:These are isolated VIPs that, people that are… don't work necessarily own Amsterdam, directly, they could also be focused on this.
Barnabas:And they could be, they're pre-isolated, so they could be tested, independently as well.
stokes:Okay.
stokes:Does the client team have an opinion here?
stokes:Otherwise, I'd lean towards nothing, or… these staking EIPs myself.
stokes: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.
stokes:Otherwise, yeah, maybe it's just something we handle, during interop.
stokes:Okay.
stokes: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.
stokes:This is the cell level deltas and the PR to the 8045.
Barnabas:Yeah, so the one… one of them is just, the meta… the IP from Amsterdam.
Barnabas:basically moving the networking EIPs into their own section at 70, 71, and 72, and also adding desirable datas,
Barnabas:mass-working EIP for Amsterdam.
Barnabas:These are all, optional yet this.
Barnabas:I think we have done this in the past.
Barnabas:It's just a formatting change.
stokes:Okay.
stokes:What does optional mean here?
stokes:That it's in the meta EIP, but you don't have to implement it by the fork?
Barnabas:Yeah… Realistically, this is mainly a…
Barnabas:a question of these, ELs, with EV70, 71, and 72. Yeah.
Barnabas:I, I think, they're also working heavily on implementing all three of those.
stokes:Okay.
stokes: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.
stokes:Okay.
stokes:Yeah, does anyone here have an issue with including this PR? Which adds… yeah, 8136?
stokes:to the Meta EIP?
stokes: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.
stokes:Okay.
stokes:We got it, it's fine.
stokes:From Lighthouse?
stokes:Do you want to run this by the AL devs next week, Barnabas?
Barnabas:I mean, the ELDevs, yeah, for formatting wire share, but the addition of the,
Barnabas:of the partial sales EIP that… Doesn't concern them.
Barnabas:Only concerns the sellers.
stokes:Okay.
stokes: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?
stokes:Do we just take it out later? Do we mark it optional?
Barnabas:I mean, the… yeah, the partial cell is optional, and we have two client implementations that are pretty much relatable, so…
Barnabas: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.
stokes:Yeah.
Barnabas:Yeah, you're also allowed to ship partials ahead of Grand Sterdam.
Barnabas:If it would be just nice to start testing it on a… when I…
Barnabas:And, if you have your changes in the trunk branches, just let us know, and then you can,
Barnabas:That's just a joke. Okay, never mind that.
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.
stokes:And, yeah, we should be good there.
stokes:And then… did you want to talk about 8045?
Barnabas:Yeah.
stokes:Wrap up this section.
Barnabas:So, 8445, has a little bit of,
Barnabas: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.
stokes:Yeah, I took a look, and this might look kind of heavy, just because it touches more of the spec rather than less.
stokes:But yeah, I think generally this is probably…
stokes:Some people need about the protocol?
Barnabas:Yeah.
stokes:Has anyone else had a chance to look at this?
stokes:So, yeah, just to reiterate, this would… so 8045 right now, it says if you're slashed, you can't propose.
stokes:And this change just extends it to all duties, so if you're slashed, you just don't do anything.
stokes:Any thoughts?
Potuz:We've never had time to actually check on the problem that this brings, which is the fact that,
Potuz: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.
Potuz: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.
stokes:Those are good points.
stokes:Any other thoughts on this?
stokes:If not, I would maybe suggest Barnabas. We just… Run this again during interop.
stokes:And see if we can make more progress in person.
stokes:Yup.
stokes: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.
Potuz: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.
Potuz: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…
Potuz:with, attributes. But there's no structured changes on the CL side, as far as I can say, besides the payload change.
Potuz: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:If you're, gonna do this engine API change anyway. Do we also want to now…
Barnabas: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.
Barnabas:Introduced in 5094.
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.
Nico Flaig: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.
Nico Flaig: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.
Nico Flaig:And to see if they match to what the builder committed to.
Nico Flaig:But I'm not sure, we just talked about this on Discord, so…
Nico Flaig:I don't think we have looked into the details yet, and it would be good to have ELDevs chime in.
Barnabas:Nico, could you maybe open a PR on the execution API side, so that the EL devs can take a look at that?
Barnabas: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:I would actually target this optimization,
Barnabas:now, because we are touching the engine API now anyway.
Barnabas:So the AIL teams would have to,
Barnabas: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.
Potuz:I think it's an easy change, I just think if we keep piling changes, we're never gonna ship. I want to ship.
stokes:Okay.
stokes:So, are we gonna do this or not right now?
Barnabas: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.
Potuz:It's a consensus change as well.
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.
stokes:Sound good?
stokes:Okay.
stokes:Cool.
stokes:Okay, Justin had one more question.
stokes:I'm not sure what this is.
stokes: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.
stokes:Let's see… interesting.
stokes:Okay…
Justin Traglia:I don't… Just wanting a confirmation.
stokes:I had a chance to look at this.
stokes:Yeah, I don't know. We have a good number of people saying it's fine.
stokes:So yeah, we'll just go ahead and merge it then.
stokes:Thank you.
stokes:Okay, cool. I lost the agenda, here it is.
stokes:Okay, anything else on Glamsterdam?
stokes:Maria wanted to give an update on the repricing stuff, but I think I'm gonna hold that till the end.
stokes:If there's time… So we can cover… I go to stuff…
stokes:Any other Glensteram things for right now?
stokes:It sounds like we have a pretty clear plan to interrupt.
stokes:There are many open questions, but that's… that's the point.
stokes:Okay, then let's move to Hagota.
stokes:And yeah, just a quick reminder, so we've opened the non headliner proposal process, or window, I should say.
stokes:This is gonna run for some time.
stokes: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.
stokes:For people both here and watching this recording, either, you know, now or later.
stokes:Anyone in the community who hears this, yeah, you'll get a notice about that.
stokes:You should assume you'll have, yeah, yeah, probably weeks, like, more than a month at this point, from today.
stokes:But yeah, so…
stokes:We are there, and point being, already today, there were two requests to discuss some proposals.
stokes:So, let me make sure I get this in order. Okay, the first one, from Ocean…
stokes:EIP7716, if you're here and want to take a couple minutes to give us the TLDR, now would be a good time.
Oisin Kyne:Perfect. Am I sharing my screen properly?
stokes:I can see it, yeah.
Oisin 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.
Oisin Kyne: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
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne:And, you know, pictures says a thousand words.
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne:You can see here from research by Tony, kind of two graphs to try and, like, exemplify this.
Oisin Kyne: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.
Oisin Kyne:the kind of key questions that I've kind of, like, pre-prepared or surfaced from people between here and an SFI decision.
Oisin Kyne: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.
Oisin Kyne: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?
Oisin Kyne: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?
Oisin Kyne: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.
Oisin Kyne: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.
Oisin Kyne: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.
stokes:Great, thanks. Any questions?
stokes:One thing that might be helpful is, like, a very, you know, sort of initial early, proof-of-concept implementation, just to de-risk
stokes:the scope here, when we do go to think about including this with other things in Agoda.
stokes:And it might be a little tricky to get that, but I think the more you can do, the merrier.
Oisin Kyne:Bill implied that there was a mock implementation before, I don't know who NC is.
stokes:Nc, I think, from Lodestar.
stokes:But either way, yeah, just something to keep in mind, and if you have someone you've been working with, just follow up.
stokes:Cool. Cool, yeah, thanks.
stokes: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 | Lido: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
Dima Gusakov | Lido:is a… very long leaving.
Dima Gusakov | Lido:deposit front-run vulnerability. So, as you all know, right now, when you make a deposit to a validator.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:For sure. There is a chance that the…
Dima Gusakov | Lido:I wouldn't say there's a chance. There is a possibility for the owner of the validator private key to
Dima Gusakov | Lido:Frontran.
Dima Gusakov | Lido: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
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:And there is no… Like, reasonable way to protect from that, other than sophisticated monitoring systems, other than
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:To ensure that the validator you're making deposit to has not been previously deposited, because, again, the front run might happen
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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
Dima Gusakov | Lido: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
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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…
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:I'm happy to answer any questions, should you guys have any.
stokes:Yeah, I have one that might be straightforward, but how do you prevent front-running of the preregistrations?
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
stokes:Okay, so yeah, it's almost like a pre-commit and then a commit, or like a…
stokes: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 | Lido:This deposit is simply ignored, in the same way as incorrect deposits are handled these days.
stokes:And you burn these.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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
Dima Gusakov | Lido:To resolve this vulnerability.
stokes:Yeah, I guess one more quick question, because we have a few minutes.
stokes: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…
stokes:I do wonder if you can do this with smart contracts, like, you could have…
stokes:A pre-registration gate smart contract that then submits the deposit for you.
stokes:If it matches.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:But the system is complicated and very hard to maintain in between the forks. The other protocols, they use…
Dima Gusakov | Lido:they use mechanism, I would call this mechanism rocket pool-like.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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…
Dima Gusakov | Lido:existing schemes, any existing protocols, especially those making this, 1 ETH pre-deposit.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
stokes:Yeah. Okay.
stokes:Any other questions or comments?
stokes:Okay. If not.
Dima Gusakov | Lido:Again.
stokes:Thanks.
Dima Gusakov | Lido: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.
Dima Gusakov | Lido:And but that would solve a lot of problems.
Dima Gusakov | Lido:So, from the implementation perspective, it's… it's a very simple thing, and from LIDAR side, we are ready to develop an audit
Dima Gusakov | Lido: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.
Dima Gusakov | Lido: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.
stokes:Okay.
stokes:Sounds good.
stokes: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.
stokes:And yeah, we'll have both this and 7716, in the set.
stokes:Okay.
stokes:Then I think we are here. We have the last thing on the agenda. Maria wanted to give an update on the repricings.
stokes:And I think this is mostly, an EL thing, but, yeah, if you wanted to say something, Maria?
stokes: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.
Maria Silva:And, I think, it changes, a few things on how, state-related refunds work.
Maria Silva:And I can give a bigger update on the next ACDE, but it's just to,
Maria Silva: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.
Maria Silva: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
Maria Silva: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,
Maria Silva:probably do a bigger update in the… in the next ACD.
Maria Silva:Thank you.
stokes:Alright, amazing. Thank you.
stokes:If there are no follow-up question or… questions or comments about that, yeah, anyone have anything?
stokes:Spencer here has a link to spec changes for that as well.
stokes: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.
stokes:Okay, cool. Yeah, if there's nothing else, then… yeah, again, I think everyone will be…
stokes:Very busy. Oh, Barnabas?
Barnabas: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.
Barnabas:And just check my comment on ACDC.
stokes:Hmm, okay.
stokes: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.
Potuz: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.
Potuz: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.
Potuz:Having this now undeveloped.
stokes:Okay, yeah, thanks for putting that together.
stokes:Very fast.
stokes:Okay, there was one thing here from Mark, just a heads up, we will have a native account obstruction breakout next Wednesday, 1500 UTC.
stokes:And, the agenda is linked here in the chat, if you want that. Otherwise, it's on… it's in the PM repo.
stokes:And, okay.
stokes:I think, then, that's it. Again, last call for anything else.
stokes: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.
stokes:And I'll see you next time. Thank you.
Potuz:Bye-bye.
Justin Traglia:Hi, everyone.
Chat Logs
00:02:56
stokes:https://github.com/ethereum/pm/issues/1990
00:04:38
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/5094
00:07:33
Barnabas:How much data duplication are we talking about per slot?
00:07:46
Potuz:the max can be large
00:08:59
Nico Flaig:we can remove them from the envelope though but requires engine api changes
00:09:10
Justin Traglia:Replying to "How much data duplic..."
Theoretically, ~1.5 MiB of requests. With today’s gas limit, ~500 KiB. That would require a 2500 batched deposits.
00:09:39
Justin Traglia:Replying to "How much data duplic..."
But the average case is way, way smaller. IIRC.
00:11:05
Justin Traglia:I don’t think we can lower the deposit request limit, because deposits are not queued. Could be wrong though.
00:11:19
Nico Flaig:I think we can Justin
00:11:38
Justin Traglia:Replying to "I think we can Justi..."
Oh okay! Nice.
00:12:01
Barnabas:Replying to "How much data duplic..."
would it not be just for that one slot? How likely that we gonna get 2.5k deposits every slot?
00:12:13
Justin Traglia:Replying to "How much data duplic..."
Yup, it’s not sustainable.
00:13:25
Barnabas:Replying to "How much data duplic..."
whats the duplicated data on a slot where there are no deposits?
00:14:35
Raúl Kripalani:Sounds like regardless we need to make the limits consistent with each other
00:15:34
Raúl Kripalani:The hope is to continue increasing the gas limit over time
00:15:45
Parithosh Jayanthi:Blocks are also often built by builders and they may not respect this particular limit if the block with deposits is more profitable
00:16:04
Toni Wahrstätter:Instead of putting an arbitrary limit on the EL side, we should just price it such that, with a given gas limit, it stays in a range the CL is fine with.
00:16:04
Parithosh Jayanthi:(They often don’t use vanilla clients to build blocks)
00:16:33
Bharath:Replying to "Blocks are also ofte..."
I am really not sure how profitable execution requests are for builders.
00:16:40
Justin Florentine (Besu):Replying to "@Justin Florentine (..."
it is. the vibes are off.
00:16:57
Bharath:Replying to "Blocks are also ofte..."
Whether they have incentives to pack the payload completely at the cost of slowing down their payload broadcast time
00:19:05
Justin Florentine (Besu):Replying to "Blocks are also ofte..."
why would it slow down broadcast time?
00:19:45
Bharath:Replying to "Blocks are also ofte..."
I mean if they pack all the execution requests, their payload size gets bigger which is not the best for broadcast
00:19:53
Bharath:Replying to "Blocks are also ofte..."
If they fill up the execution requests I mean*
00:21:14
Bharath:Replying to "Blocks are also ofte..."
I ll check rbuilder as to see how they pack their execution requests
00:21:38
Potuz:gossip is never a problem, RPC is
00:23:09
Raúl Kripalani:I’m fine with that
00:24:51
Barnabas:5094 solves a beacon api issue basically
00:26:49
Nico Flaig:@Barnabas regaridng engin api changes, we need to do that for BALs anyways, so maybe can revisit that later?
00:26:58
Potuz:edge cases always involve reorgs and proposing on top of a previous payload
00:27:33
Barnabas:Replying to "@Barnabas regaridng ..."
how big of a change is it?
00:27:44
Barnabas:Replying to "@Barnabas regaridng ..."
thats actually true, kinda forgot about it
00:27:44
Nico Flaig:Replying to "@Barnabas regaridng ..."
add a field to new_payload response
00:28:07
Barnabas:We should also discuss: https://github.com/ethereum/consensus-specs/pull/5067
00:28:19
Raúl Kripalani:If too hard: the plan B would be to lower the limits in the way Nico explained (might be worth doing regardless)
00:28:50
Potuz:lowering the limits is not possible without involving extra checks on the EL
00:29:36
Justin Traglia:Yeah we intend to rebase & get this merged before the release is made. Unsure of its current status.
00:29:43
Jihoon:I think he is waiting for 5094 as it will introduce some merge conflicts.
00:29:43
Brechy:I'm rebasing it atm
00:29:50
Brechy:Yes
00:29:51
Nico Flaig:Replying to "If too hard: the pla..."
also worth noting that the current limit breaks at 194M gas limit, and ELs could theoretically be stuck trying to build a payload that will never be accepted by CLs (kinda similar to the 10MB gossip limit situation)
00:30:10
Brechy:It does change
00:30:14
terence:is_parent_block_full goes away in 5094
00:30:54
Raúl Kripalani:Replying to "edge cases always involve reorgs and proposing on top of a previous payload"
This is the risk, but the problem is reduced to “the parent MUST be available”, so if clients are decently designed, there shouldn’t edge case handling in code
00:31:59
Potuz:Replying to "edge cases always in..."
well, designing decently a client to deal with late reorgs is not trivial at all
00:32:00
Justin Traglia:@Potuz currently, the plan is make an alpha.5 release without BAL and follow up this time next week with alpha.6 with BAL.
00:32:05
Potuz:Replying to "edge cases always in..."
and this will add complexity
00:32:30
Dustin:why do the intermediate release of epbs-devnet-2?
00:32:35
Barnabas:https://github.com/ethereum/pm/issues/1990#issuecomment-4260587912
00:32:38
Raúl Kripalani:Replying to "If too hard: the plan B would be to lower the limits in the way Nico explained (might be worth doing regardless)"
Ideally we audit all these interdependent limit layers and turn them into functions instead of hardcoded values that (a) don’t align, and (b) drift over time
00:33:35
Justin Traglia:Replying to "why do the intermedi..."
Just to keep things compartmentalized. Open to putting everything into a single release. Whatever clients want.
00:34:28
Potuz:I also think it's easier to do BAL
00:34:33
Potuz:with ePBS on our side
00:35:20
Dustin:would rather encounter go into interop knowing these potential issues are happening before interop
00:36:07
Dustin:yes
00:36:09
Dustin:exactly
00:36:12
Raúl Kripalani:Stokes saying the words “The Merge” brings up memories from 6y ago 😅
00:36:24
stokes:Replying to "Stokes saying the wo..."
I had the same thought lol
00:36:43
Justin Traglia:What do other clients think? Do we prefer a single release?
00:36:52
Barnabas:bal devnets have other cl changes too like slotnum
00:37:09
Dustin:Replying to "bal devnets have o..."
this is the problem, ultimately, this is why to move to merged asap
00:37:14
Barnabas:Replying to "What do other client..."
nimbus + prysm obviously want to skip epbs devnet 2
00:37:36
Stefan Starflinger:We also have to consider the testing velocity that is impacted after the merge for each stream
00:37:36
Potuz:Replying to "What do other client..."
it's my preference, but it doesn't matter much
00:37:37
Justin Traglia:Replying to "What do other client..."
Their concerns are valid.
00:38:40
kingy_sigp:no strong preference at lighthouse one devnet makes sense
00:39:15
Stefan Bratanov:I would rather go to interop with kurtosis ready and confidence in the code and then on Monday, we can spin up devnet together with debugging and sorting out issues easily since everyone is there
00:39:32
Potuz:yeah my preference is not strong either, just think we're wasting time not merging the trivial changes from BAL
00:40:04
kingy_sigp:Replying to "yeah my preference i..."
it's a good point, I'm trying to think of a reason not to do it 🤔
00:40:37
Justin Traglia:Sounds good to me.
00:40:38
Potuz:are we good with this @terence ?
00:40:45
terence:Replying to "are we good with thi..."
yes
00:41:25
Justin Traglia:https://github.com/ethereum/consensus-specs/tree/master/specs/_features/eip7928
00:41:29
Justin Traglia:I think it’s this, right?
00:41:45
Stefan Starflinger:https://notes.ethereum.org/@ethpandaops/bal-devnet-3#Test-Releases
00:41:48
Stefan Starflinger:also here
00:42:01
Stefan Starflinger:https://github.com/ethereum/consensus-specs/releases/tag/v1.6.1
00:42:09
Potuz:oh this changes the payloadtype right :(
00:42:11
terence:Ya but Im looking for a PR against gloas.. not an existing features spec : )
00:42:45
Justin Traglia:Replying to "Ya but Im looking fo..."
Ah, yeah no PR yet. But the PR would just merge this into Gloas.
00:42:55
Enrico Del Fante (tbenr):Which is the bal xyz link?
00:42:57
Justin Traglia:Replying to "Ya but Im looking fo..."
I will work on this today. Should be simple.
00:43:11
Stefan Starflinger:https://blockaccesslist.xyz/
00:43:20
Parithosh Jayanthi:ATM for interop id like us to just focus on a stable Glamsterdam devnet + breaking it rather than adding more features
00:43:20
Potuz:the header is gone in Gloas
00:43:24
Parithosh Jayanthi:We haven’t broken things at all yet
00:43:28
Potuz:the root would need to be removed right?
00:43:34
terence:Replying to "Ya but Im looking fo..."
Thanks! I think you might want to merge 5094 first otherwise there will be conflicts.. up to you!
00:43:42
Justin Traglia:Replying to "Ya but Im looking fo..."
100% 🙂
00:43:48
Toni Wahrstätter:Replying to "Which is the bal xyz..."
Blockaccesslist.xyz
00:44:17
Potuz:It'd be better to have the actual PR @Toni Wahrstätter, there are nonsense objects there like the execution header. Do you want the root in the bid or not?
00:44:21
Potuz:I assume not
00:44:55
Toni Wahrstätter:Replying to "It'd be better to ha..."
Let me check
00:45:04
Parithosh Jayanthi:+1 for staking EIPs as stretch goal
00:45:12
Potuz:the block changes are weird
00:45:33
Potuz:does the header need to be cached in the beacon state or not?
00:45:58
Potuz:so do I assume that there are zero changes on payload processing?
00:46:09
Barnabas:https://github.com/ethereum/EIPs/pull/11452
00:46:47
Toni Wahrstätter:https://github.com/ethereum/consensus-specs/pull/4526
00:47:08
Toni Wahrstätter:This was the PR but would have to check if somwthing changed since then
00:47:24
kingy_sigp:it's fine
00:47:27
Barnabas:https://github.com/ethereum/EIPs/pull/11443
00:47:54
Potuz:Can I take care of opening the CL spec PR @Toni Wahrstätter
00:47:55
Potuz:?
00:47:58
Potuz:this one seems wrong to me
00:48:05
kingy_sigp:are we allowed to ship partials ahead of glamsterdam?
00:48:18
Toni Wahrstätter:This one seemed wrong?
https://github.com/ethereum/consensus-specs/pull/4526
00:48:37
kingy_sigp:Replying to "are we allowed to sh..."
this was mostly a joke
00:48:49
Jihoon:Replying to "this one seems wrong..."
To put it differently, it's outdated. Gloas spec has changed since then.
00:49:06
Potuz:Replying to "this one seems wrong..."
not that, the changes on the feature are wrong
00:49:07
Enrico Del Fante (tbenr):Replying to "https://blockaccessl..."
Bal CL changes are just a new field (block_access_list) in the payload (with all the consequences with data structures and engine API)?
00:49:16
Raúl Kripalani:Replying to "are we allowed to ship partials ahead of glamsterdam?"
Partial messages? Yes that’s the idea :-)
00:49:24
Jihoon:Replying to "this one seems wrong..."
Such as?
00:49:37
Potuz:Replying to "https://blockaccessl..."
it's just the payload change, nothing else changes, no state and no processing changes
00:49:50
Potuz:Replying to "this one seems wrong..."
there should not be any state and processing changes
00:49:58
Justin Traglia:Ah here’s the SLOTNUM consensus-specs PR: https://github.com/ethereum/consensus-specs/pull/4840
00:50:29
Dima Gusakov | Lido:Nice one to have
00:51:14
Toni Wahrstätter:Replying to "this one seems wrong..."
Feel free to go for it @Potuz , if you want, I can also do it but if you take the shot
00:51:20
Barnabas:not to include 8045 or not to include 11443
00:51:47
Jihoon:Replying to "this one seems wrong..."
Are you referring to ExecutionPayloadHeader-related changes? If so, I think that's what I meant by outdated.
00:51:53
Stefan Starflinger:Replying to "this one seems wrong..."
https://github.com/sigp/lighthouse/commit/a17c447680d655d70f4230f2603f6ad7182f943a
https://github.com/sigp/lighthouse/commit/47094d592c252363911e82ec3c68ac8f4ab05a9d
https://github.com/sigp/lighthouse/commit/658163cfdeeca00a4cd3ff2c36c2c11ef8b12d61
these are the main changes LH made to support BAL
00:52:31
stokes:Replying to "not to include 8045 ..."
11443 if I’m following you correctly
00:52:45
stokes:Replying to "not to include 8045 ..."
Exactly when we include 8045 is another question
00:52:48
Jihoon:Yeah it's because that PR was made before we had Gloas in master. It's just outdated artifact.
00:52:59
terence:I think we should do that to be consistent
00:53:03
stokes:Replying to "not to include 8045 ..."
I was just saying we can touch on 11443 at interop
00:53:08
Barnabas:Replying to "@Barnabas regaridng ..."
@Potuz this
00:53:32
Potuz:Replying to "@Barnabas regaridng ..."
yes, the API changes, that's not my concern :)
00:54:23
Potuz:This makes sense to me, but can we aim this as a post-interop optimization?
00:55:20
Barnabas:🚢
00:56:08
Barnabas:lets aim to 5094 now and optimize later
00:56:14
Potuz:@Nico Flaig if you do that please do it independent of 5094
00:56:15
Justin Traglia:One more small thing. Are we okay with this change by Etan? https://github.com/ethereum/consensus-specs/pull/5113
00:56:20
Potuz:so that we can merge 5094 independent of that
00:56:36
terence:Replying to "One more small thing..."
Good with us. It’s easy
00:56:41
Potuz:Replying to "One more small thing..."
trivial for us
00:56:44
Nico Flaig:Replying to "@Nico Flaig if you d..."
yes, definitely should be separate
00:56:46
Enrico Del Fante (tbenr):Replying to "One more small thing..."
We can yes
00:57:09
Barnabas:Replying to "One more small thing..."
ppl use the approve button on github 😂
01:04:17
Nico Flaig:we had a draft PR a while ago I think
01:04:20
Manu:@Oisin Kyne can you share the link of your slides?
01:04:30
Oisin Kyne:Replying to "@Oisin Kyne can you ..."
https://docs.google.com/presentation/d/1hbkdjHsP_2rTc0zTgXLBf3thYv9FHEcNurWiZKnR6c8/edit?slide=id.p34#slide=id.p34
01:04:48
Dima Gusakov | Lido:https://eips.ethereum.org/EIPS/eip-8205
01:06:40
Nico Flaig:@Oisin Kyne we had this PR for EIP-7716 https://github.com/ChainSafe/lodestar/pull/6851
01:07:25
Potuz:@Toni Wahrstätter I think this is all that's needed https://github.com/ethereum/consensus-specs/pull/5117
01:07:51
Potuz:I'll fix Heze/etc. if that's fine, I don't think you want BALs ont he Bid
01:08:52
Barnabas:8205: IMO Overcomplicating the protocol for little benefit.
01:09:19
Dima Gusakov | Lido:https://eips.ethereum.org/EIPS/eip-8205
01:09:46
stokes:Replying to "8205: IMO Overcompli..."
I think this is a problem staking pools face, FWIW
01:10:38
Barnabas:Replying to "8205: IMO Overcompli..."
It feels like it could be solved on the app side tho?
01:10:44
stokes:Replying to "8205: IMO Overcompli..."
Yeah I have the same question
01:14:43
Oisin Kyne:Replying to "@Oisin Kyne we had t..."
233 line diff, super encouraging! 😄
01:15:38
Barnabas:Replying to "8205: IMO Overcompli..."
Is the idea to go from having to do 2tx to doing 1tx?
01:15:55
Nico Flaig:most of it is fork boilerplate code, the real diff is ~100 lines
01:16:00
Barnabas:Replying to "8205: IMO Overcompli..."
you would still need to do 2 txs, one with pre-registration, followed by the actual sum of eth
01:16:22
Barnabas:Replying to "8205: IMO Overcompli..."
like how is it different than just doing 1eth deposit followed by your actual deposit?
01:17:10
spencer:Spec changes so far: https://github.com/ethereum/execution-specs/pull/2697
Keri & I are working on getting the tests done currently!
01:18:04
marc | wolovim:Unrelated heads up: native AA breakout occurring next Wednesday, 15:00 UTC. Agenda WIP: https://github.com/ethereum/pm/issues/2018
01:18:19
Raúl Kripalani:Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard
01:18:22
Justin Traglia:https://github.com/ethereum/consensus-specs/pull/5117
01:18:30
Barnabas:we still have 13 mins so lets do a live review?
01:18:44
spencer:Replying to "Opus 4.7 is out, s..."
We got 4.6 back!! Woo
01:19:19
Raúl Kripalani:Replying to "Opus 4.7 is out, so we can ship Glamsterdam to mainnet during Svalbard"
Opus models like macOS. Always be one version behind