All Core Devs - Consensus #176

Transcript

Alex Stokes: Hello! How's everyone?

David (dionysuz): Hello, doing well.

Alex Stokes: Cool. Okay, let's give it… hmm, yeah, another minute or two, and then we'll get started.

Justin Florentine: Good morning, Ethereum.

Alex Stokes: Good morning, Justin. I feel like with that, with the tone, Justin. With the presentation, you could, have, like, a talk show. An Ethereum talk show.

Justin Florentine: If Ethereum ever needs a aging dad as its MC, I'm your man.

Alex Stokes: Okay. We do need MCs all the time. Let's see… It says there are 47 people. The counter always seems much higher than the number of squares on the Zoom screen. To me, at least. Okay, let's just wait until 3 after. Oh, it is 3 after. I don't think there are that many bots, I guess. In any case…

Ben Adams: There's 3 pages. Grossly.

Alex Stokes: 3 pages. I mean, I recognize. A lot of them. Anyway, okay, let's, let's get started. Let's see, is Josh here? Usually he helps with the stream.

David (dionysuz): I'm, I'm here in place of Josh to help out, so yeah, I can…

Alex Stokes: Perfect.

David (dionysuz): go whenever.

Alex Stokes: Thank you. Yeah, let's get started.

David (dionysuz): Alright, it's live.

Alex Stokes: Okay, thanks. Hey everyone! Welcome to ACDC176. Which I believe is the right number. We had had a meeting scheduled on March 5th, which the agenda was a little lighter that week, so we decided to go for an async version of things. on the Discord. And in any case, yeah, so we have today's meeting. And I think we just moved the meeting number to this date, so number 176. Issue 1941 on the PM repo, I put the link here in the chat. It's the same issue that we had from when we would have had the last call. And there are a few things that I think we made some progress on that were scheduled for the 5th, but we'll touch on them today, just to tidy them up.

And otherwise, yeah, I think since, there have been a number of other threads that have become relevant, so let's touch on those today. And… Yeah, so we have some things for Glamsterdam. I think the main topic for today will be ePBS. a few other things, and then we'll touch on Hegota, towards the end of the call. So… Let's go ahead and get started with Glamsterdam. First off, would anyone like to give, any observations or updates from devnet 0? So, we did launch ePBS to devnet 0, very exciting. I think the start was a little rocky. I was even looking yesterday, and, you know, it looks pretty good. Participation is alright. There's also a new thing I saw on DORA for proposals.

And that one also looks alright. I think every so often there's some rocky epochs. But, yeah, otherwise, as far as I've seen. Yeah, my teams are working on, just working through any bugs there, and getting to a stable devnet 0. Anything else we should, yeah, acknowledge whatnot zero right now. Barnabas?

Barnabas Busa: Yeah, so currently we have, Prysm, Lighthouse, and Lodestar, pulling the chain forward. We have onboarded now every single, SIA client. Nimbus is having, peering issues, Teku is having unknown issues, and for Grandine, we're just waiting for a new branch, but, they confirmed that they were able to, not participate as well in the local criticis test. I have tested, exits yesterday. It was working on a local environment. Lighthouse is still unable to process exits. And, we just did a bunch of deposits, on, 00. As well as, Lido is also doing some testing. So, as long as nobody is triggering exits, the change should survive. If we're gonna see an exit, then, Yeah, Lodestar and Prysm is gonna be able to process it, but Lighthouse is going to have a hard time.

also the… the epochs that you mentioned, Alex, before, we seem to be missing a few blocks, Prysm seems to be missing a few blocks randomly. Maybe they can give us an update, I'm not sure if they have investigated it. Good job.

Terence Tsao: I'll have a PR out to fix that. We can merge that, hopefully, in the next two days, and yeah, we… yeah, I… we have figured out the issues for that.

Alex Stokes: Was this with the parent block that we were discussing on Discord?

Terence Tsao: No, this is…

Alex Stokes: Okay.

Terence Tsao: No, no, no, this is because of we… for… to essentially to… to send for a choice update to GATF, We were using the run, save block hash and finalized block hash. We were using the reorg payload as the block hash. Because of that, GET doesn't recognize it, and we were not able to… we were not able to reprint this block.

Alex Stokes: Okay, gotcha. Sounds like a straightforward fix, then. At least I hope. Cool. Wait, there was something Barnabas said that I had a question about, When you said the… when you're talking about exits, are these validator exits or builder exits?

Barnabas Busa: It doesn't matter.

Alex Stokes: Okay.

Barnabas Busa: Right. Exit is an exit, from the point of view. So, yeah, so the endpoint for the builder exit is now supported by Prysm and Lodestar. And, yeah, Lighthouse is just unable to process the whole exit. I'm not sure if anyone from Lighthouse is in the call. I do see Mark.

Mark Mackey: Here, I'm just not sure I can comment on this.

Alex Stokes: Well, in any case, yeah, they're… are a number of things that, yeah, people are finding, as we go through, yeah, just operating devnet 0 and seeing what happens. Let's see, so… Yeah, unless there's anything else to add concretely for devnet 0 right now, again, there are a number of issues, I think, across most, if not all, the clients, but people are generally aware. I was… Yeah, okay. So actually, BOTUS wanted to, say some things in chat, which is also something I wanted to touch on, just in terms of, yeah, the status here. Getting to… where we are today to, the current spec, and I think that might be what you're talking about, Photos, unless you mean something else.

Potuz: Yeah, it's… a couple of things are on the specs, and other things are really just on implementation.

Alex Stokes: Okay. Yeah, you wanna give us an overview?

Potuz: Sure, I just want to be quick, because mostly I just want to call for people that are involved to, like, weigh in, and I just want it to be this on the… on the minutes of this meeting. So, there are a few things that we need to make a decision. One of them is already in the agenda for today, which is this issue of the BTC. This is an issue that was found… found and raised by Nico from Lodestar. The… the issue… few words is that, when we call to get the PTC with a head state at slot 31, we might get a different PTC than at slot 32, even with the same state that just advanced to 32, and this may cause a split when a block for that slot 32 might become invalid. There are a couple of PRs that are open on the spec to fix this issue. This is an issue that needs to be fixed.

Or we just don't include at all, PTC attestations on blocks. There are a few options. This option should be waiting, and I'm hoping that for Monday, client devs will show up already with at least an opinion, so that we can just choose. That's one thing. The other thing that was raised is with the issue of proving things on the CL side. Today, we have a block route that is exposed with a slot of delay on the EVM, and this block route might be actually, would change semantics. when there are several block routes that actually are happening on the CL side, but they come without a payload. This is a new feature of ePBS, that you can have blocks on the CL that don't come with a payload.

And then the problem is that the next payload that actually builds on top of a few of empty blocks, it will include the parent's block root. And that part… and the contract, the system contract that keeps the block routes We'll have a gap of blocks that are missing. So this might affect mostly, pools. that are staking pools that are proving, for example, withdrawals, or proving about slashings, or proving anything on blocks directly on the… on the… on the CL side. There are a few options. I'll write down a full… what I think is the right fix, which is not do anything here, and have pools proving, using the parent block hash. I think it's just… just cheap. There's another option, which is proving using the P1 state, but that, PK from PandaOps showed that, this was,

that this was just too expensive. So again, if pools come up and say, this affects us this way, we want this fix, or if you just want to sit down with us and discuss what are the options, that's gonna be great. I see that, Dima is already mentioning this, for Lido, so, okay, so that's… it's good that Lido is already looking at this. There's, another option, which is the engine API. ePBS will have, and this was already mentioned in ACDC, I'm just repeating it now for all the LDEVs, ePBS will force reorgs to a previous head. So not only a rear, but just a rollback of your head. And if that happens, the engine should allow us… not should, must allow us to build on top of previous blocks. So if we send FCU with a previous head, this should not return an error on the EL,

This is something to be aware, and this is something that needs to be specified. Finally, the thing that Terence mentioned, this is not really what was causing, failed blocks on… on… for PRISM. But here's an issue. When we track finalization and justification, or safe head, or anything, this is also going to, affect the fast confirmation rule. We track just the block route. This means that the block root is… what people are voting on for targets or whatever it is. It's true that we have enough information to track whether or not we're voting also for the full or empty target, but that's not what is in the spec today. So when we finalize a particular block route, we are not finalizing nor justifying the payload that was committed in that block.

That means that the save head, the justified head, and the finalized head should always be sent to the engine as the parent hash. Of the block… the consensus block that had the right block route. So this is a change that I suspect clients haven't had yet. Okay, so that's the last one. That I had to have on the minute. So, it's mostly ELDEFs and, and pools that should show up and talk about these issues.

Alex Stokes: Okay, yeah, thanks. This last one, is this what Tarynge is supposed to hear in the chat with this PR?

Potuz: No, that last one was… so, prison was doing something even worse. Prison was taking the blocked route and just… Putting whatever payload that, block root had. even though that payload might not even be on-chain, which is even worse than just… than just putting it, so we were putting that payload if it was on chain, or if it wasn't on chain. So the engine is not complaining if we put that payload when it was on chain. But that's also wrong, and we were also putting it when it wasn't on-chain, which is even worse.

Alex Stokes: Right.

Terence Tsao: What I put in the chat is actually what Potas talked about on the third point, where that the EL needs to support reorg on top of empty. Not… not only full. And then we actually solved that issue, Prysm solved that issue again. So, yeah, we need this, hopefully, review and merged soon.

Alex Stokes: Yeah, no, thanks for bringing that up. And yeah, that was a good summary. Marius, you've had your hand. Let's do that next.

Marius van der Wijden: Yes, regarding the EL stuff… So when I implemented it, I implemented it a bit naively, and what happened is that, guest nodes, kept crashing, and the problem is that, During sync, if we reorg to a block in Basically, our sync mechanism and our block advancing mechanism are racing. And, so if you give us a Foxtrase updated during sync, and we change the canonical… Statue of, or the canonicalness of a block. Then that will crash the sync. So what I've done right now, for… only for the devnet, is to say that Yes, we are accepting,

We are accepting reorgs to the parent, but only if we are not syncing. The syncing state is not super clearly defined in our codebase, and so it might be also a bit different between clients, but I think there can be… These issues where we are… Currently syncing, or we are not… we just started a new sync cycle, and then we get this reorg. And then we reject the block with, I think we rejected with the syncing. Error, or, like, the sinking flag, just so that consensus layers are aware that reorgs to a parent might not succeed if your EL node is in a state where it's Yeah, it's not fully synced yet.

Potuz: But in that case, we shouldn't even send a payload attributes, right? So it doesn't matter.

Marius van der Wijden: Yeah, but at least in our implementation, that is very different. Like, we are checking The canonical… canonicalness… Of the node in a different path. Then when we… then the payload attributes. Like, the payload attributes are happening way later. So, but what you're saying is basically we should only accept this if we… if you're also sending payload ad reviews?

Potuz: Right, so if… no, we might… we will send you an FCU with a previous block. Because that's what honestly can happen. if you… I suspect that if you respond with an error here, it's kind of irrelevant, because it's… the worst that can happen is that we're… it's going to put us optimistic. But that's… that was already the case, because you were already syncing, so the next proposer. will only be able to propose if it wasn't optimistic already, so it's fine, in which case that guy didn't have an error, and every node that became… that was optimistic is just going to import nice… nicely the next block, so I think it's… it's no problem.

Marius van der Wijden: Yeah, I'm just saying that's something that CLs should be mindful of. I should know that we might pull you into… Into optimistic mode if… if we are getting this, a reversal of the head. And for ELs to also be mindful that we might have these, these reorgs that are kind of… Changing the canonicalness of blocks there. That are also included in the sync.

Alex Stokes: Can't that already happen, though?

Marius van der Wijden: Not like this. Okay. Like… If we have marked a block as Canonical… It is… yeah, it's a bit different to uncanonicalize it. This is, like, a new way of doing that. So… Thank you.

Alex Stokes: Yeah, okay. So what would help here? Like, is it a refinement to the spec? Should we just make sure we have testing in place for this? Something else?

Marius van der Wijden: Yeah, I think both, refinement to the spec and making sure that we have capacity. to maybe do engine API check, too.

Alex Stokes: Okay. Is there an issue here, or something written down? That will help me check this. Yeah, photos.

Potuz: I actually think that we might be able to help. The way we work now is that we actually send an FCU, to propose on top of Latcha Reorg. So I think we might be able to coordinate in that we are only going to send this type of reorgs and this type of FCUs only when we are sending actual payload attributes. Because I think for a node that is just syncing, doing that, such an FCU that rolls back is kind of useless. If you're not proposing, because you are going to… the proposer will send such a thing, and will just actually cause a reorg on the EL. So, an attester that is just syncing can just send the next FCU with an actual, honest reorg on the EL.

Alex Stokes: turns.

Terence Tsao: But there's also another use case as an RPC provider, right? If you're an RPC provider, you're using the head on the RPC endpoint on the execution layer client, you may get the wrong information if they rework back on top of empty. So, I don't think the attribute… is enough. We probably need to do this regularly for FCU as well.

Potuz: No, that's… I mean, that RPC provider is going to be providing an information over its last head, which was that in the EL. And then the next block that is produced is going to actually reorg on the EL, and it's going to reorg the RPC provider as well.

Terence Tsao: I see. Yeah, I need to think more about this.

Potuz: So I suspect that the EL only needs to deal with this when it's dealing with a proposer that is sending a payload attribute to actually trigger block production on top of a previous block.

Enrico Del Fante: Is that a similar thing that we're already happening when we do late block reorg and the fork choice filtering? So, when we roll… so it's what happens, at least in tech, we roll back our head to the previous block, and then we produce the next block on top of the ancestor, and we don't send FCU, in that case, rolling back the head, so it should be kind of similar thing.

Potuz: Well, no, that's what I wanted to avoid, actually. So for the CL reorg, we're doing this juggling and this thing that is just artificial because the EL doesn't know how to deal with this situation, so we actually avoid sending an FCU.

Enrico Del Fante: Yeah.

Potuz: When we suspect that we're going to be reorging.

Enrico Del Fante: That was the reason why we should… we have to do this send, design.

Potuz: Yeah, shoot over, right, FCU, whatever.

Enrico Del Fante: Yeah, yeah, the shoulder of the rock.

Potuz: dirty in the spec. But now, not even that's going to work, because you don't really know If you need to reor back, that's going to depend on other attestations, so I think at least we should allow these FCUs when we are proposing. And if we're not proposing, it's fine.

Marius van der Wijden: Well, not really fine. It's just… Like, yes, it's fine from a technical perspective, but from… from the UX, it's pretty bad, because the CL knows that the block is… that the EL is giving out over the RPC is bad, and it waits until the next block.

Alex Stokes: Yeah, in that case, can we just have the CL update the yellow when it knows?

Potuz: Well, that's what we're doing now, and this is what's causing the errors from GET. I'm happy if we keep it that way. We send FCU, and then… the Yale just replied. Okay, yeah.

Alex Stokes: And maybe I didn't follow, but then, Marius, you're saying there's an issue with this current behavior?

Marius van der Wijden: Well, no, like, the current behavior is fine as long as we are very clear that if the sync is still happening, that we can just return syncing to the GA.

Potuz: We should make very clear that, for people that are listening, we should make very clear that it's not that we're going to be rolling back head. This is happening on devnet just because clients are voting incorrectly for empty blocks. So clients are signaling You should roll back, but in normal behavior, normal situation with the chain, with or without blocks, we're not going to be rolling back ahead. This requires a majority of clients voting incorrectly to saying that a payload did not exist.

Alex Stokes: But what does incorrectly mean? Like…

Potuz: Well, today…

Alex Stokes: Composer has, like, the correct view, but somehow a majority has a different view?

Potuz: No, so, what's happening on the devnet is that, well, I think this was changed lately, but what's happening in the devnet is that Lighthouse and Lodestar did not include the committee index being 1 when there was a missing payload, a missing block. So they were voting for the previous consensus block with Committee Index 0, and this means that they were voting for the empty consensus block. So that forced Prysm to reorg the payload, and that's what caused, causes all of these previous reorgs. But, as soon as Lighthouse and Loadstar fixed this, I think this stopped happening.

Alex Stokes: Right, but it seems…

Enrico Del Fante: really possible anyway.

Potuz: I didn't hear Enrico.

Enrico Del Fante: So it was on Stoked. Just saying that it is still possible that this thing happens.

Potuz: It is… it is possible that it happens, but it will require a very… it's not going to be as common as in the devnet. It's going to be something very, very unusual, as reorgs are unusual today.

Enrico Del Fante: Yeah, but I don't even want… CLs to trans… start being optimistically in sync, where they start.

Potuz: But what Marius said is that it's not that you're going to become optimistic. What Marius said is you are already optimistic, and it's going to return you thinking.

Enrico Del Fante: Are you sure?

Potuz: Perhaps Marius can repeat, but I understood that this would affect only nodes that were already syncing.

Marius van der Wijden: Yes, it only affects notes that are in the syncing mode. The problem is the syncing mode is… is a bit iffy to find, so if you are sending us on a… On a bigger sidechain, then we might go into syncing mode. Or if… if there's, I don't know, a bigger reorg, like a normal reorg, then that also might… might put us into syncing mode. So it's not… not just the initial sync. It can happen that After the initial sync, you will also be kicked into the syncing mode. Like, if the CL tells us, hey, we want to go to this block, and we have no idea about that block, that might put us into syncing mode.

Alex Stokes: Yeah, and as I understand, even if we think it will be rare, say, on mainnet, this could happen. And then if we want to change the behavior, we should definitely make sure it happens. Like, this isn't just, like, a, oh, transient devnet thing. It'll work itself out. Right. Okay. In any case, I will track this somewhere, and yeah, we will do what we need to do to harden the specs here. And or implementations, yeah, just to make this, work how we want. Okay. Since we've gotten into it, so yeah, there are a number of things, Poda's touched on, I think, most of them already.

Let's see, let's circle back to this 4788 issue. So, yeah, I think Players gave a pretty good summary. Essentially, now that we can have, empty execution payloads under ePBS, 4788. Doesn't quite work, like we expect. And the question now is what we do about it. So… Yeah, there are a couple options. One of them is to do nothing, like Potus said, which is what I kinda lean towards now. And the reason why is because, given the way we have different, history accumulators, on the beacon chain. You can still get to the data you need, and maybe the proof looks a little bit different, but you can still do so. From there, yeah, PK brought this up, that it is possible that

If you need to go through this different path. The proofs might become bigger than we would like. And at that point, I would like to quantify the impact. Does anyone else have any thoughts on this problem right now? Or references on how we handle it?

pk910: I think there would also be a middle way, when we basically put in the parent routes of full beacon blocks only, so we only have the gap for the empty ones. So we at least have all the beacon routes for blocks that have withdrawals and everything included. Would be a counter and middle way of both.

Alex Stokes: Right. So, yeah, this kind of gets very deep in the weeds, but, how it happens is that you would have a beacon block, execution block. There would be a number of beacon blocks, new execution blocks, and then you would get to… the next… 4 slot, let's say. And then, yeah, like, one option here is, I think this is what you're just saying, just not PK, like, you pass all of the intermediate routes. I think you could get away with just passing the previous… so the previous beacon block that was not empty. Which, again, this… the semantics are, like, pretty intricate, but at that point then, I think what happens is it looks transparent to ELs today.

And, like, part of my… Point here is I don't think people really need the intermediate beacon box with empty payloads. And if somehow they do, They can go through this more indirect route. So yeah, like, I think either do nothing, or yeah, we try to pass these, quote, missing routes, or… let's say it differently, we passed the route that we would otherwise miss today. bonus?

Potuz: So the intermediate blocks will include a lot of information that might be useful for pools. Has this validator been slashed? Has this validator exited? And a bunch of things that can actually happen on the CL. The problem is that these things will not have any impact at all on money until the payload actually arrives. So, if the question is, has this validator been slashed, do we really need to know that it was slashed in this block, or it's just enough to know that it is slashed now? has this validator withdrawn? Do we really need to know that it withdrew in this particular CL block, or do we need to know that it was fulfilled in this particular EL block? And withdrawals is very special because there will be no withdrawals in those empty blocks anyways. There's only withdrawals in the first one.

and then the chain of empty blocks will just not process any withdrawals anyways. I think this can be exploited just using the parent block, and that's it.

Alex Stokes: Right, yeah, like, there is no execution for these empty payloads, so in terms of the EVM, which is where you would consume 4788, it… There's just no way to change anything. Dima?

Dima Gusakov: Yeah, first of all, yeah, I do agree that most of the information that is on the consensus layer is not required to be delivered… like, the proof is not required to be delivered precisely against the exact block. So, for example, slashing, you can just prove that the validator is slashed, and it doesn't matter if it's this block or three blocks away, or something like that. That's true. However, there are at least two cases that we have already identified in Lido. that do require us to point to a specific consensus layer block. The first case is when the consolidation happens. So, We really need to have two adjacent consensus layer blocks, the one where consolidation was still pending, and the other one where the consolidation was applied, so that we can… we can do a correct accounting of balance being moved from one validator to another, and if these validators

Belong to, say, different entities, or different staking modules, or different structures, or different owners within a protocol. That is crucial. The other thing that is way bigger and way more problematic and not that obvious, honestly, is to have the ability for the ZK Oracle. So, we use oracles in Lido. Right now, we are still using, trusted oracles, unfortunately, to argue about, the TVL of the protocol. So, what's the… total balance of the validators as of a very particular slot. And again, even though there are no changes on the execution layer regarding to that, the protocol needs to have a very precise information about what was the balance of all of the validators within the protocol at a specific slot.

And since we are gradually introducing ZK Oracle to, later on, probably replace the trusted Oracle. We indeed need to point to a specific consensus layer block which… or slot, that corresponds to a particular slot, so that we can make all of these ZK proofs against this particular one. And again, even though, as I mentioned in the comments, it's not like the end of the world, and everything, Alex, you are mentioning, and what Potos is mentioning, is correct, that this information is still reachable. This information now is reachable in a different way, hands. development, maintenance, and so on is required. So, in general, I am not a big fan of, Changing stuff, just because it's easier to change this stuff, and then later on require protocols that do rely on a previous behavior to now adapt to new behavior, unless the option to keep the old behavior is

prohibitively expensive for the Ethereum developers. So, from my point, and from Lido point of view, I would say that it will be way better and way easier for us to have this missing roots back propagated in this or that way, and if you refer to the document linked, it's either option 3 or option 4. It's, again, it's not the end of the world, but if we will go with the missing blocks, it means that by the time of Glamsterdam, we would have to redo a significant portion of the protocol that relies on those trustless proofs. And over the last years, we did a great job at adding this permissionless proofs to as many places as we can, so that the reliance on oracles is lower and lower.

So, to summarize it up, it will be way better if we will keep the original behavior of, 4788. And it would save us a tremendous amount of effort that can be reallocated to other places, like stuff that we are currently working on, like consolidations of the whole curated set, and in the future, transforming our community set into OX02 as well, but this all requires time and effort, and whenever we introduce such a change that requires an intermediate attention from our side, we are getting further away from achieving long-term goals, like, again, increasing the number of OX02 validators in the network.

Alex Stokes: Yeah, that makes sense. Yeah, thanks for the context. Mmm… Okay In terms of moving forward, so yeah, POTUS has this idea to think about the parent hash, because I think that just makes the proofs Less cumbersome. Otis, would you… Are you thinking we do… let's call it option 1 from PK's doc? Just do nothing?

Potuz: I haven't seen, I haven't seen what, Pique wrote. Last time I spoke with him, we were thinking about using the fact that the block accesses the state, and then using the state to prove against And that is quite expensive. This adds, like, 22 hashes, but the thing is that we always have the parent hash. Which points to the parent block, or the parent root for a block, which points to the parent block And once you have a parent root, then you can just provide the parent root, and it's only one hash to access your block root. So, since we always have the block that we're interested in on-chain, or its child on-chain. Then it just adds a single hash to prove against the block that you're interested in in the worst scenario.

So I think it's, I think it's really cheap to prove against blocks. And not the state. It requires changing contracts, so I empathize with this. It might be that it's just the same cost, but then just changing the contract, and auditing the contracts, and whatever it is, and deploying these new contracts might be just already prohibitively expensive for pools, so I empathize with their points. I have no opinion, I'm just saying that If we prove with block roots, it should be just, essentially, just as cheap as it is today.

Dima Gusakov: Yeah, the other small thing here, and I'm super sorry that no one from Rocketpool is here, because their architecture is slightly different from Lido, and in Lido, we can basically do upgrades via a governance vote, which is complex and costly, but not impossible. For Rocketpool, they have a different architecture where it might be even more problematic for them not to, like, develop and deploy the code, but to make their mini and now mega pools to upgrade to this thing. So I'm not that well into rocket pool architecture, but I think we should definitely reach out to them directly and ask how much of a problem it would create for them, because their architecture is slightly different from Lido.

Alex Stokes: Yeah, I can make sure we talk to them. I also believe EigenLayer uses 4788, so yeah, we can do sort of an impact analysis here. What I think the highest cost is would be changing the system contract. So, yeah… Strongly prefer to not do that. Then from there, the question is, yeah, how nice can we make it? I think some combination of option one, which is where we add this rule that you would send The most recent non-empty beacon block as the parent. I think that handles most of the things. there are possibly some transitions only in the beacon blocks that would be missing, and then you'd have to go through this more indirect route, maybe, than what POTOS is suggesting.

Is a good mitigation there? In any case, yeah, we'll need to do a little more analysis here, but yeah, we should definitely figure this out in, like, the next couple weeks, in terms of how we want to actually move forward. Okay. Any other comments on this one? Otherwise, we'll move forward. Okay. Okay, the next thing I had here, this was also something POTUS mentioned with, this PTC issue. So… I linked what I think, as of yesterday, was… the latest, active PR to handle this. There was another one from NFLAG. That, looks like we should also look at. So… Yeah. Mmm… These are the straightforward solutions.

Given today? I looked into this some earlier this week, and I started to go down this thread where I'm not sure we actually even need to put the payload access stations on-chain. And then at that point. we have more flexibility, I think, in the specs, and we can just say, hey, you know, you're expected to have these committees cached, and then you just use the appropriate committee for the right slot, and then there's no issue with the state changing on you. That being said… There is some argument that having them in the blocks and process like we do today makes things a bit more stable. I started looking more deeply into the fork choice to try to wrap my head around this. I don't have a clear answer there yet.

I believe, POTUS, just from talking on Discord, seems like you'd prefer to keep it as is. Is that still correct?

Potuz: Just for disclaimer, I believe Francesco is fine with removing them, and I would just take Francesco's voice, unfortunately, is over mine. But I also believe that it's clear that it… well, I am wary about ex-ante reorgs that can be produced by removing this. If you can convince somehow the The… on a split decision, or if you can convince the next proposer that he should reorder payload. and then it turns out that the next proposer is being reorged because he tried to reorg a payload. I think having the PTC in the block ensures that the view of the proposer is the right one.

Alex Stokes: Yeah. That intuition makes sense. The part that I haven't done myself yet is just look deeply enough into the fork twice to see if this actually holds. Because I think it's possible today that this works more like a hint to the next proposer.

Potuz: No, no, no, no, so the proposer… so it is a hint to the next… the proposer is never forced to reorg a payload. So the purchase today is such that the proposer always has a decision to build on full if he's seen a payload, and if he's seen a payload, it doesn't matter what the PTC done, he's verified the payload, he can always build on top of full. The question is, what happens if a proposer decides to build on top of empty, for whatever reason? And then in that situation. we might want to allow that proposer to actually build on empty, if there was a split view, if there were cubications, if there were a bunch of situations. And in those situations.

this PTC on the block ensures that the proposer's view is respected by the testers.

Alex Stokes: Okay, because then that same proposer includes the payload attestations that everyone else then sees?

Potuz: Yeah, because imagine, for example, the PTC is actually, equivocating. It's sending attestations to attesters, and it's sending a different attestation to the proposal. So… these kind of things might… might be resolved by the proposer asserting, these are the ones that I'm considering. there's no slashing for PTC, for example. This is one of the few things that gets… it's not that it's very important, and I'm also, like, envisioning a not-canonical behavior by the proposer, because if the proposer had processed the payload, he should propose on top of full. He shouldn't be proposing on top of empty. But on the other hand, not including this and not allowing proposers to reorg payloads, I think, allows Timing games with builders, and… and off-protocol arrangements of the next proposals with the builders, so that the payload can actually come later, and a bunch of other things.

Alex Stokes: Yeah. Okay, so… In any case, like… As is, we do need to… say, merge one of these PRs. And then at that point, I'd prefer, like, the simplest thing that gets the job done. And it looks like this latest PR, 5020, Does that. So, in any case, I think today, at least for now, I would ask people just to look at these. And… Yeah, ideally… We can make a decision in, like, the next week. Like, possibly even by ACDT on Monday? Oh, do you want to say more about that, Potus? Because, yeah, that's what I meant, is it just has the least impact on the state. Because otherwise, you know, like, in general, we just keep adding things to the state to patch these issues, and then the state becomes…

Gross. Okay. So, okay, yeah, take a look… I think, yeah, to fully grok this, it's actually pretty subtle. But yeah, take a look, and then… Let's just keep chatting about this, perhaps by next ACDT. We'll feel more strongly about one route versus the other. What do you mean we're shipping this into that one? Like, one of these PRs?

Potuz: Yeah, so this is the one thing that we are… that it will require hard fork. So this is the only feature that will force a new devnet. I think we are… all of us don't have complete implementations of ePBS, that's why we're seeing a lot of bugs, and not even bugs, just things that we haven't implemented, and we keep implementing and testing on devnet 0. So devnet 0 is very useful for us. But, the one thing that will be a hard force will be this, so this will force a new debit.

Alex Stokes: Right. Assuming we don't go down this other route of even just taking them out and handling this a different way. But yeah. Okay. We… yeah.

Potuz: Taking them out is also hard pork, so…

Alex Stokes: Yeah, yeah, yeah, yeah. But no, more just, like… I think, yeah, okay. No, just for my own, understanding of the timelines here. But yes, it would be, for sure. Okay, so yeah, I think that's all we're gonna do on that one for now today. So, yeah, please take a look if you have a minute, review these PRs, slash if you prefer one over the other, please add a comment on the PR as well. That would be helpful. Okay. Let's see. So… what is… at the beginning of this call, you touched on these two things that we just discussed. there was this engine API PR, that I think is smaller in scope, that I think we just need to merge, and this is 770, to be clear.

There was also this issue that we were discussing for a bit around… the syncing semantics and reorgs there. I don't see something written down right now to track that one, but I will do something. Unless I can find something that exists already. One more to discuss. So yeah, I was trying to keep a list of, like, kind of open things in terms of getting towards Glamsterdam devnet 0, where we would merge this all together, and then move forward, you know, and probably towards shipping Glamsterdam. One more thing that I think we still need to discuss a bit more was this concept of the variable PTC deadline. Certainly, you know, the flow should be to iron out the current devnet.

And, yeah, just all the mechanics there. But then I think there's at least some interest in exploring this variable PTC deadline, in a future devnet. So… From there, I think I just wanted to bring it up, just so everyone's aware of the status there, although Tony had a document, and yeah, if you'd like to say a few words, Tony, this would be a good time.

Toni Wahrstätter: Yes, I will quickly post it into the chat, including the PR. This is one of those open points that are still discussed with ePBS. Like, should we do a variable payload deadline that is independent from the PTC deadline? And… I thought it might make sense to, also look into the call data pricing, because on the EL, we have, call data pricing that is very much focused on Capping the worst case while staying as much backwards compatible as possible. But this also means that the worst case block size can also include quite a lot of execution. So there is EAP7976, that is CFI for Glamsterdam. And with that, EAP, the worst-case block size is capped at… at 60 million gas, you would be at 1MB, but you could still use, like, over 90% of the gas for execution.

And there has been a discussion among clients to enfrind snappy compression, but what I read was clients are very much against it, because this could lead to other failures, consensus issues or something. So, if we want to anchor the payload, the variable payload deadline, based on the uncompressed block size. then I don't think it's a good idea, because you could create a 1MB big uncompressed block, and one block compresses to 100 kilobytes, the other compresses, not at all. So, I have some charts in the blog post. Yeah, I don't have a strong opinion on it, and would just say, yeah, let the clients take the shot. But I, I definitely think, Yeah, we should find.

solution there.

Mark Mackey: Right.

Alex Stokes: Yeah, Mark, yeah.

Mark Mackey: Yeah, I spent a while comb into the ZATI data to try to figure out what we were looking at in terms of how, basically the end-to-end dissemination time varies with the payload size, End. I mean, it seems like if we don't do a variable deadline, we're forced to basically set the block, The block deadline back in order to accommodate the larger… payloads that are slower to propagate. And then… but on the average case, payloads are significantly smaller than the… those more extreme cases. And so… You know, we've artificially… lowered the gas, basically, and I think the headline from the results that I saw is that we should gain somewhere between 300 to 500 milliseconds.

For execution, with a variable deadline, which is not nothing. But I agree with… certainly with Tony's conclusion that EIP7999 seems like the… Real way to solve this problem. It… That was just my attempt to quantify this, in terms of, like, how much How much can actually be gained, and… Yeah, like I said, 300 to 500 milliseconds for execution. Is what I had found.

Alex Stokes: Okay.

Toni Wahrstätter: Yeah, fair. Thanks a lot, Mark. Maybe just to add one more thing, if we want to do it, then we should also rethink if we actually want to just linearly interpolate between 3.6 seconds and 9 seconds, because today. There is a lot of room towards the maximum block size, so the average block size is significantly smaller than the worst case, and if we would just naively interpolate Then, most of the blocks would have a deadline at second floor. And this seems unrealistic, so we cannot demand builders to publish blogs very early, or I guess this would very much defeat the purpose of ePBS helping to scale. So if we want to do it, we should rethink the formula, and also the APR currently has a worst-case block size hard-coded at 10MB,

Which is, I guess I get where it's from, but I think it should be… Yeah, significantly lower, and it should be calculated based on the gas limit, because we know gas limit divided by the coal data cost is the worst case block. At least as of Glamsterdam. And… Then the formula already improves, but we're still, like. We would still end up with a very early payload deadline. eventually giving the CL, like, 6 or 7 seconds to execute, and I don't think we can ever scale the CL to make use of the EL to ever make use of 6 or 7 seconds of worst-case execution.

Alex Stokes: Any other comments on this for now? I don't think we're gonna make a decision today, and yeah, this is… it's just kind of a gray area around how we want to do this. At least for now. So I would suggest, yeah, let's just think about it somewhere, and I think we'll have more clarity in the future. Okay. Let me find the agenda… Okay, yeah, so that was super helpful. Thanks, everyone. Yeah, we need to get through all these things at some point. They're very much top of mind. Especially for, you know, as we think about devnet 1 and potentially devnet 2. That being said, I think we have plenty to do for devnet 0 right now.

Zooming out just a bit from there, I did want to think about Glamsterdam, devnet 0, and, like, our path there. And, again, we'll have to see how this goes, but it would be nice to get to something end of April, in terms of Glamsterdam devnet 0. And that would mean merging the two different CL and EL work streams, both BALs and also PBS. But then from there. That would be nice. In terms of us now merging the streams and being able to work together on the actual hard fork. Does anyone have any thoughts on that timeline? Oh yeah, okay. I mean, this is what I meant, end of April, sorry, but yeah, mid-April. Essentially before I interrupt, is what I'm getting at.

Vernabus, I think we can just make a call on the PTC Monday, and I think that's gonna be fine. Okay. It's, at least from the lack of responses, this doesn't seem, an inappropriate suggestion. So, let's just go ahead and pencil that in. Let's all try to work towards Glamsterdam devnet 0 mid-April, which is roughly a month from now. And… cool. Okay, I think that'd be good. From there, there are a few things, that are Glamsterdam-related, but not as specific to the seal. And a few things that were on the agenda from what of… what would have been, last ACDC's time slot. Let's run through these.

I believe it was… okay, Spencer wanted to SFI the Baldemna to EIPs into Glamsterdam. Okay, he also says he won't make the call, so I guess he's not here. But yeah. Anyone opposed to this? I think my first question would be, is devnet2 stable enough? I feel like that's a pretty reasonable blocker on making something CFI to SFI.

Stefan Starflinger: From my perspective, Definite2 has been pretty stable. So far.

Alex Stokes: Okay. Does anyone have a reason not to SFI these? One thing I can point out is this is a CL call, and not an EL call. And I'm not trying to delay another week, but yeah, it's the EL site on Square. So I'm not trying to delay another week, but, you know, it, It is slightly more appropriate to handle next week. For example, I don't know if, you know, the right amount of EL devs are even here today. Okay, so then let's handle it this way, at least. Yeah, it doesn't seem like there are any strong opinions either way on the CL side, but it does seem more appropriate to be an EL call, decision to make on the EL call, so let's just push this next week.

We make SFI decisions on ACDT. I mean, again, I think if you have the right people at the right place at the right time, then it doesn't matter as much. Do we think we can make that happen for Monday? Okay, how about we… Oh yeah, Osberg's saying he wants to discuss next week on ACDE. Okay. Then, sure. Barnabas, if you… well, okay, I'll… I'll just pull onscar on this. Let's… let's discuss this a week from now on ACDE. And… yeah, we can get into that conversation there. Okay. What I was gonna say on guard, then, is Barnabas could optimistically try on Monday. But again, I think it needs to be,

Like, it can't be just, like, a few… EL teams being like, yeah, let's do this. Like, it should be, should be the full set. That have the option to weigh in. So, in any case, let's fall back to doing this next week, I would suggest. And, okay, it sounds like you guys can discuss further. Okay. Okay, next thing, the SSZ Engine API. So… this was from Julio, he had some PRs, I think I also saw a very similar PR from Barnabas. And my understanding is that what we want to do here is, support SSZ as, like, a transport encoding for the engine API, especially for pushing blobs back and forth, this should help quite a bit.

And I think now there have been some, benchmarks to prove this point. So, there was a thread on Discord that got quite a bit into, this. And… yeah, I don't know if anyone would like to… Okay, there are 122 messages. there's quite a bit here, but ultimately, yeah, I mean, again, I think, you know, I would say this makes sense to do, and then from there we can discuss when. Do we want to go ahead and try to do this in Glamsterdam?

Barnabas Busa: So, I basically proposed this in order for us to be able to do a performance upgrade without needing to even have an EIP for it. I proposed a engine API change only, which could be an optional thing, so we could basically have all the CRs supported basically as early as tomorrow, and, all the ELs could, opt in, and when they… when they end up, supporting, then, the negotiation would basically… go into SSZ instead of JSON.

Alex Stokes: Yeah, I mean, I like that approach, essentially be opt-in for whoever supports it, and then you get the performance benefit.

Barnabas Busa: Right, the major question is basically finalizing the spec and see if the spec is fine by everyone.

Alex Stokes: Yeah. Marius, and then Julio.

Marius van der Wijden: Yeah, so I… I think… I personally think we should take this opportunity to also rethink the engine API. Makes no sense to me to just… do the same thing that we have right now with the engine API, and move it to SSZ. Yes, it's a bit of a performance improvement, but it just adds, maintenance burden on all of the ELs. I think the way I would… I would like to do it would be to take this as an opportunity to rethink how we are doing the engine API, how we are doing versioning in the engine API, How we are defining structs in the engine API, and so on. Because, yeah, that has gotten kind of out of hand. The engine API implementations in the clients are pretty ugly, now that we have done, like, 4 or 5 forks on top of, on top of the original engine API.

And so, yeah. I think… Yeah.

Alex Stokes: Yeah. So, I mean, yeah, that sounds like a much bigger set of work than just supporting SSZ as an optional transport. So, how do you think about… That… I guess you're saying you think we should just go ahead and do it now? Julia?

Giulio Rebuffo: Yeah, so actually, I think I… I mean, so first of all, I agree with Marius, mostly directionally. I think that, kind of, you can also do this in kind of incremental steps, too. Like, you don't need to do everything. Like, you know, if you can introduce a way to optionally support multiple ways of implementing Engine API. You can first do SSZ and then do a better engine API on top of it, without blocking anything. Like, you can… you can have a… you can… you can have three things… work… work on three things at the same time. It's not… I mean, you just need a way to, you know, you need to give away the CL to expose it. So, I think… I think you can pretty much do both, if you really want.

Like, you can… first, you can do the SSZ thing, and then… You can, you can, you can also… in the meantime, try to find a way or create a spec to improve the engine API. It's not entirely clear to me… I mean, I think it can be improved, but it's not entirely clear to me how it can be improved, so… Yeah, maybe there needs to be some ideas on that. But I overall agree directionally. But we can do this in incremental steps still, and people don't need to implement the SSE either, it's optional, so if, you know, if GAF doesn't want to implement it, they just don't implement it. And if Netherland wants to implement it, it's their business whether they're fine with the complexity.

Alex Stokes: Yeah, that makes sense. Sure, Bernos?

Barnabas Busa: Yeah, I would be just curious to know, like, what kind of exact changes Marius was thinking about making. It says that, like, the versioning is a bit ugly, but, like. Like, I'm not sure what the exact solution is that would make it less ugly.

Giulio Rebuffo: Wha…

Marius van der Wijden: Yeah. Kind of what Raul is saying, what Perry is saying, the versioning system of the engine API method, it's just really… Thumbs? And, the way we are, we are constructing structs, means that, at least with the… with the engine, with the SSZ implementations that we have, we need to create a new struct for every, fork. I think the CL devs have the same problem. Instead of fixing that problem, we are kind of now… Importing that… the same problem to… to the EL. And, yeah, it's, Then the… The way we specify some parameters, the way we specify functionality and behavior is kind of… Very annoying, like, the way we specify error.

errors in the engine API, And I think all of this needs to be… Oh.

Alex Stokes: Daryl.

Raúl Kripalani: Yeah, so to add to that, maybe the networking perspective here is, besides kind of, like, the semantics, the versioning, and the error handling and so on, one principle that I would like to… that I would like to see on a revamped, engine API is, something that allows EL and CL to coordinate a lot better about where they are in the pipeline, and specifically on the CL. So, the reason for this is that our resource constraints or requirements are shared, specifically when it comes to bandwidth. So, it really helps if the EL and the CL can be telling each other continuously, where they are in kind of, like, the pipeline. So, for example, when the CL is done.

receiving a, like, receiving blobs, for example, then it can tell the EL that it's done so, and the EL can then throttle traffic, on the mempool accordingly, or throttle, sync traffic, which is kind of, like, not on the critical path accordingly. And ideally, if they have kind of, like, a shared view of bandwidth, they, of available bandwidth, which, like, we have several ways of achieving, then they can. Basically implement some traffic shap… we can implement traffic shaping that allows both Layers to actually act as one, and not kind of, like, be conflicting with one another, And… and kind of, like, you know, over… over shared resources. But this would require, like, different… maybe, like, a different set of…

I think it requires a different set of, interaction patterns, so right now, we have this RPC, approach, which is… synchronous, and we'll probably need more streaming, like, streaming-oriented patterns, and maybe there's, like, some WebSockets, kind of, like. approaches that we can… that we can add here, so multiplexing, there's… there's a bunch of notions from the networking side of things as well, that we can bring into this API design.

Alex Stokes: Victoria?

Giulio Rebuffo: Yeah, I guess… yeah, I guess… I guess what I think maybe… should be done is that we could, take Barnabas Pack, just kind of rename this in, like… sorry, there is a bit of noise because I'm outside. There is, so what we can do is that we can take Barnabas' spec, rename it as kind of to be… you know, a next-gen API instead, or whatever name we want to give it, honestly. First iteration might be only SSE, right? And then maybe we can just, you know, create some kind of devnet, and then iterate over it, and just do all of our… do a bunch of changes to it that we like. I'm not sure, actually, what you can do about the versioning, honestly. Yeah.

Raúl Kripalani: Yeah. So, in terms of, yeah, in terms of change management, what I would do is, I think what Baradabus was… was proposing is basically, like, a content type header sort of thing. I think it's pretty much a direct translation of the types into SSE… to SSE. I think that should be something we do regardless. And then on top, then, like, the next gen… next gen… API would be another effort, but it doesn't necessarily… like, you could technically conceive a world in which you still do JSON, right? for this new design, which we won't do, but, hopefully. But, but yeah, it's… I think it's decoupled efforts. I would go… the SSZ one seems like a pretty quick win, to be honest, especially as we scale the number of blobs.

Giulio Rebuffo: Yeah, actually, yeah, okay. Well, we can do it incrementally, it's not like we need to do everything in one go. So… yeah, I mean, honestly. Yeah, maybe SSZ is just probably… yeah. Yeah, I don't know, I don't have really a strong opinion, but I… but in my… but in my answer would be that doing it incrementally is better, so do SSZ first, and then maybe switch it later.

Raúl Kripalani: For blobs, yeah, for blobs, what's important is that whatever serialization format we pick is zero copy, and that clients implement it in a zero-copy way, because right now, the JSON Base64 encoding, decoding is what's killing us. And it's, it's, it's, it's just absurd.

Giulio Rebuffo: You cannot do it zero copy regardless, because you need to… I mean, unless… I mean, you can.

Raúl Kripalani: Well, with SSZ, you can definitely do zero copy on the reader side.

Giulio Rebuffo: I mean, you do less… I mean, it's a bit more complicated than that, but you can do less copies, yes, but it's a bit more complicated than that. I wouldn't call it zero copy.

Raúl Kripalani: Alright, I had to check. Last time I checked, I was pretty sure that I got a zero version working, but a decent prospect.

Giulio Rebuffo: I know, well, okay, this is going to be in the details, but it's not zero copy unless you send over the C struct over TCP, right? Like, that's zero copy. But, no, no, but I don't want to argue on that.

Raúl Kripalani: Yeah, yeah, I assume, yeah. Yeah.

Giulio Rebuffo: I understand what you mean, sorry. So… But anyways, what I wanted to say was. Yeah, maybe we should just do SSS. Also, SSZ is super simple. I mean, I basically… it took me, like, a weekend to open PRs in, like, 8 clients. It's not like… you know, and it doesn't take that much time to refine them into being decent. It's just, you know, it's pretty simple. I mean, you just… to be honest, I want to be completely clear here. I basically… it was just an… this one… this was just for me, just an AI experiment. And what ended up coming up was honestly, pretty decent. You can… it will take me probably a week to just refine all of these PRs into something that works, and that is decent to look at. I already have made Cortassi's devnets for all of these clients.

And I already bombard them with blobs. I also wrote an article on its research on this, so this is pretty easy, this is pretty quick. Yeah. And to make this code better, you just… I just need to spend probably, like, a week working on this. It's not, like, that much time for me to do. Like, it's pretty… it's one… it's a one-person job to make this happen quickly.

Alex Stokes: Okay, yeah, let's zoom out a little bit. So… Yeah, sounds like there's certainly interest in making some change here. It does sound like a good first step would be thinking about SSZ for especially the blobs. There's a… yeah, it sounds like a deeper conversation around general changes and improvements to the engine API. So, yeah, would Barnabas' PR be a good place to start? And, yeah, if you care, we can move forward the conversation there. Okay, thank you, Barnabas. Yeah, so take a look at this PR764, and yeah, I think the question is just, yeah, fitting in, actually getting something together, but Yeah, sure, Julia, if you want to bring it up there, that would make sense.

But yeah, I think, if anything, the takeaway for today is, yeah, we want to do something here, and then we just need to figure out exactly what that is. Okay. There was one more thing that's not quite a gooda, so let's just go ahead and knock it out. And, this was from Bowman Ops. I'm not sure how you see the handle. But essentially it was a standardization question for the JSON web token, I believe is what this stands for, secrets. This is going, yeah, quite back into history. But there was an ask for the client behavior here, just so we could tighten the spec, I think this is saying… It might be a should, and the question is if we can make it a must.

But in any case, does anyone have any thoughts on this? Let me grab… I think this is the relevant pure. Yeah. I would imagine, given how old this is, clients Have some way to handle this, and… It works, TM. Okay, yeah, if you want to dig into this more, take a look at the PR, but otherwise… Let's go ahead and move on to the next topic. Which is Hegota. So… Yeah, two things here. One of them is just around timelines for scoping, so… We have picked the CL headliner for Hecata with FOCIL. They are still working on the EL side to pick a headliner there.

I believe the plan is to make a decision next week on ACD, For the headliner. And then from there, I will go double-check the ETH Research post, where we're kind of tracking this formally. But in any case, the suggestion would be that we open up Nod Headliner. let me say this differently. We would open up the non-headliner proposal window, as of that call, so a week from today. And then… I think roughly, there'd be about a month, for proposals, and then we would continue the scoping process, with the non-adminer EIPs there. That was all I really had to update there, more of an FYI. I think, again, the next step here will be finalizing the EL headliner for Hegota.

But, something to have on the radar. And… last thing on the agenda… let me just take a look, I think we've covered the other stuff. Mmm… Okay. Yeah, okay, there was a comment, but it's related to this. Let's see, I don't know, if this is Greg or G. Kumote, but they had a comment here just to talk about, EIP8141. So, I think the idea is they would want to propose this as a non-headliner EIP for Agota. And given what I just said, we're maybe a call or two early, but we do have some time, so if someone here would like to say a few words, I think this is a good moment. And then we can wrap up today.

After that.

Dima Gusakov: Yeah, cool. So, let me grab, like, 5 minutes of your time, guys, to give a short introduction of the EIP we are proposing to… as a known headliner for Hegota, this is EIP 8148. And the core idea of this EIP is to add a so-called custom sweep threshold for validators with compounding withdrawal credentials. This threshold basically defines the value of effective balance above which the validator rewards will be swept to execution layer in the same way it currently works with max effective balance. And the main motivation to even introduce this feature is to allow validators not to choose between, like, do we want to get our rewards after we are at 32E for traditional validators, or if we want to get our rewards.

after 2048 ETH for OX02 validators, but rather select any value in the middle while still utilizing OX02, which means that we will now be able to offer this convenience of automatic sweep for any validator that is in between 32 ETH and to 2048 ETH. And as mentioned in the last comment to Or today's issue. A lot of ecosystem participants report that the main reason why they are not consolidating their validators to OX02 is the liquidity problem, because the step of 2K ETH is a pretty significant one, and even if you have more than 2K ETH, But it's not, like, equally divi… precisely divisible by 2K, your amount of ETH is not precisely divisible by 2K, it would mean that for some of your validators, or if you have a lot of them, you will have to do manual partial withdrawals if, for example, your business model does not

correspond to a system where you simply accumulate rewards, and that's it, and when you need this, extra liquidity on the execution layer. So, this applies both to, mid-sized, home and solo stakers. This applies to a professional operators. who might have clients that are willing to have their ETH exclusively at a… at only their validators, and their amount of deposit that they have deposited to… that they have delegated to a professional operator is not a multiple of 2K. So that's the motivation, and we believe that by introducing this very simple and small change to Ethereum network, we would be able to significantly increase the rate of consolidations or migration to OXO2 validators by offering such a

a small, but very useful thing. Now to… A bit of a technical details on how this functionality actually works, and why we believe that it would not introduce any additional risks or concerns to the protocol. So, first of all. The requests to set custom sweep threshold for the validators are made from validator withdrawal credentials, following the same process as we already have for partial withdrawals and triggerable exits and consolidations. So, no major changes here, the same architecture of the contract, the same fee inhibitor, and so on and so forth. Next, custom sweep threshold is set with a step of 1 ETH to match the effective balance increment, so that you can only set your custom sweep threshold as a multiple of 1 ETH, so that it would match

potentially match the effective balance. Next thing, custom sweep threshold can only be set above the current validator balance to prevent usage of this feature for bypassing regular withdrawals. I'm sorry. Which means that, you would not be able to set this threshold below your balance, and then, within the next sweep cycle, get some of your ETH swept. You would only be able to set it above, so that you will need to first accumulate enough balance, and only after that, you will start participating in the automatic sweep. Next thing, custom sweep threshold can be changed at any moment in time and any number of times for a given validator, assuming that the new value that is provided for the custom sweep threshold is below the current validator balance.

Custom sweep thresholds are proposed to be stored as a separate list in the beacon state and not in the validator structure, in the validator object, so that we do not surpass this limit of 8 fields in the validator structure, and so that it would not affect the way how we Merkalize. the state, particularly validator objects. And the last thing is that custom sweep threshold can be set for any value starting from 33 ETH, which is min activation balance, plus 1 ETH, to allow for the maximum flexibility and encourage migration of any sized stakers, starting from those only having, I don't know, like, something like I don't know, 36 ETH, for example, and those who are not using this for ETH in staking at all, moving towards people who have, for example, two solo validators and might want to have this sweep threshold at 64 ETH, and all the way up.

to a pretty large validators or home stakers who might have, say, 1.5K worth of ETH, but they still want to limit the amount of ETH that will be accumulated on their validator, and get the rest swept. So that was a short description, again, to wrap it up. The main idea of this EIP is to make OX02, and potentially OX03, but right now, I'm not sure, because when I was writing this EIP with, my co-contributors, OX03 validators were still validators. Right now, they no longer are. So let's assume it applies to OX02 validators. So the idea is to make OXO2 validators way more user-friendly, so that people can select at which threshold they want to automatically get their rewards, and we believe

From our talks with ecosystem participants, with homestakers, with professional operators. that introducing this feature would significantly increase the rate of migration from old OX01 validators to a new OX02 validators, and would basically make OX02 validators suitable for everyone who is running validators on Ethereum. Thank you.

Alex Stokes: Cool, thanks, yeah, that was a nice overview. There was some discussion in the chat… And… yeah, I guess I'll say, yeah, we did originally consider something like this with the consolidations design in Pectra. Ektra got a little too big for its own sake, and so it was not included, but yeah, in general. This is a nice idea, and yeah, something, something to consider.

Dima Gusakov: Yeah, and a quick comment on that. Yes, this idea indeed was considered back in the day when Pecture was about to go live. And as far as I understood from reading all of the discussions, all of the memos and stuff like that, the major reason for not doing it in Pectra was the concerns regarding timelines, the amount of work required. and no significant support from participants like protocols and maybe other, staking participants. However, right now, it is apparent that this feature is needed, and if we will have time and space in Hegota to implement this, again, relatively simple feature, it will be great to have it now, because right now, it is apparent that Without this feature, the rates of migration to OX02 is pretty slow. Right now, we are at below 20% of stake being on OX02 validators one year after Pectra, and in my opinion, this is unacceptable, and we should do our best to increase the rates of migration, so even if

With this limit, even if a solo staker with just two validators would transform his two validators into one, it would already be a two times decrease in the number of validators. And as we can see from the data, most of the solo homestakers and, again, professional operators are controlling way more than just 64 ETH, which means that we would definitely see a major reduction in the number of validators, and as far as I'm concerned, this is exactly the goal we are trying to achieve so that we can enable fast finality and many more other features.

Alex Stokes: Whoa. Yeah, thanks for the intro, and again, we will get deeper into the knotted Liner EIP set, in the future. But yeah, this is a good one to have on the radar. We are tired. So, I think we go ahead and wrap up for today. Thank you, everyone. I'll see you next time.

Potuz: Bye-bye!

Marius van der Wijden: Bye.

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