AllCoreDevs - Consensus #176

|2026-03-19| Agenda: #1941| canonical JSON

Transcript

stokes:Hey everyone! Welcome to ACDC176.

stokes:Which I believe is the right number.

stokes: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.

stokes:on the Discord.

stokes:And in any case, yeah, so we have today's meeting.

stokes:And I think we just moved the meeting number to this date, so number 176.

stokes:Issue 1941 on the PM repo, I put the link here in the chat.

stokes:It's the same issue that we had from when we would have had the last call.

stokes: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.

stokes: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.

stokes:And…

stokes:Yeah, so we have some things for Glamsterdam. I think the main topic for today will be ePBS.

stokes:a few other things, and then we'll touch on Hegota, towards the end of the call. So…

stokes:Let's go ahead and get started with Glamsterdam.

stokes:First off, would anyone like to give, any observations or updates from devnet 0? So, we did launch ePBS to devnet 0, very exciting.

stokes:I think the start was a little rocky. I was even looking yesterday, and, you know, it looks pretty good. Participation is alright.

stokes:There's also a new thing I saw on DORA for proposals.

stokes:And that one also looks alright. I think every so often there's some rocky epochs.

stokes:But, yeah, otherwise, as far as I've seen.

stokes:Yeah, my teams are working on, just working through any bugs there, and getting to a stable devnet 0.

stokes:Anything else we should, yeah, acknowledge whatnot zero right now.

stokes:Barnabas?

Barnabas:Yeah, so currently we have, Prysm, Lighthouse, and Lodestar, pulling the chain forward. We have onboarded now every single, SIA client.

Barnabas: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.

Barnabas:I have tested, exits yesterday. It was working on a local environment. Lighthouse is still unable to process exits.

Barnabas:And, we just did a bunch of deposits, on, 00.

Barnabas:As well as, Lido is also doing some testing.

Barnabas:So, as long as nobody is triggering exits, the change should survive. If we're gonna see an exit, then,

Barnabas:Yeah, Lodestar and Prysm is gonna be able to process it, but Lighthouse is going to have a hard time.

Barnabas:also the… the epochs that you mentioned, Alex, before,

Barnabas:we seem to be missing a few blocks, Prysm seems to be missing a few blocks randomly. Maybe they can give us an update,

Barnabas:I'm not sure if they have investigated it.

Barnabas:Good job.

terence: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.

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

terence:No, this is…

stokes:Okay.

terence:No, no, no, this is because of we… for… to essentially to… to send for a choice update to GATF,

terence: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.

stokes:Okay, gotcha.

stokes:Sounds like a straightforward fix, then.

stokes:At least I hope.

stokes:Cool. Wait, there was something Barnabas said that I had a question about,

stokes:When you said the… when you're talking about exits, are these validator exits or builder exits?

Barnabas:It doesn't matter.

stokes:Okay.

Barnabas:Right.

Barnabas: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.

Barnabas:And, yeah, Lighthouse is just unable to process the whole exit. I'm not sure if anyone from Lighthouse is in the call.

Barnabas:I do see Mark.

ethDreamer (Mark):Here, I'm just not sure I can comment on this.

stokes:Well, in any case, yeah, they're…

stokes:are a number of things that, yeah, people are finding, as we go through, yeah, just operating devnet 0 and seeing what happens.

stokes:Let's see, so…

stokes: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.

stokes:I was…

stokes: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.

stokes:Getting to…

stokes: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.

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.

Potuz:This is an issue that was found… found and raised by Nico from Lodestar. The… the issue…

Potuz:few words is that, when we call to get the PTC with a head state at slot 31,

Potuz: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.

Potuz: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.

Potuz:That's one thing. The other thing that was raised is with the issue of

Potuz: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.

Potuz: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.

Potuz: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.

Potuz:And that part… and the contract, the system contract that keeps the block routes

Potuz:We'll have a gap of blocks that are missing.

Potuz:So this might affect mostly, pools.

Potuz: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.

Potuz: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,

Potuz: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.

Potuz: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.

Potuz:ePBS will have, and this was already mentioned in ACDC, I'm just repeating it now for all the LDEVs, ePBS will force reorgs

Potuz: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,

Potuz:This is something to be aware, and this is something that needs to be specified.

Potuz:Finally, the thing that Terence mentioned, this is not really what was causing, failed blocks on… on…

Potuz:for PRISM. But here's an issue.

Potuz: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.

Potuz:This means that the block root is…

Potuz: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

Potuz: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.

Potuz:That means that the save head, the justified head, and the finalized head should always be sent to the engine as the parent hash.

Potuz:Of the block… the consensus block that had the right block route.

Potuz:So this is a change that I suspect clients haven't had yet.

Potuz:Okay, so that's the last one.

Potuz: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.

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…

Potuz:Putting whatever payload that, block root had.

Potuz: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.

Potuz:But that's also wrong, and we were also putting it when it wasn't on-chain, which is even worse.

stokes:Right.

terence: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

terence: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.

stokes:Yeah, no, thanks for bringing that up. And yeah, that was a good summary.

stokes:Marius, you've had your hand. Let's do that next.

Marius Van Der Wijden (M):Yes, regarding the EL stuff…

Marius Van Der Wijden (M):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,

Marius Van Der Wijden (M):During sync, if we reorg to a block in

Marius Van Der Wijden (M):Basically, our sync mechanism and our block advancing mechanism are racing.

Marius Van Der Wijden (M):And, so if you give us a Foxtrase updated during sync, and we change the canonical…

Marius Van Der Wijden (M):Statue of, or the canonicalness of a block.

Marius Van Der Wijden (M):Then that will crash the sync.

Marius Van Der Wijden (M):So what I've done right now, for…

Marius Van Der Wijden (M):only for the devnet, is to say that Yes, we are accepting,

Marius Van Der Wijden (M):We are accepting reorgs to the parent, but only if we are not syncing.

Marius Van Der Wijden (M):The syncing state is not super clearly defined in our codebase, and so it might be also

Marius Van Der Wijden (M):a bit different between clients, but I think there can be… These issues where we are…

Marius Van Der Wijden (M):Currently syncing, or we are not… we just started a new sync cycle, and then we get this reorg.

Marius Van Der Wijden (M):And then we reject the block

Marius Van Der Wijden (M):with, I think we rejected with the syncing.

Marius Van Der Wijden (M):Error, or, like, the sinking flag, just so that consensus layers are aware that

Marius Van Der Wijden (M):reorgs to a parent might not succeed if your EL node is in a state where it's

Marius Van Der Wijden (M):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 (M):Yeah, but at least in our implementation, that is very different. Like, we are checking The canonical… canonicalness…

Marius Van Der Wijden (M):Of the node in a different path.

Marius Van Der Wijden (M):Then when we… then the payload attributes. Like, the payload attributes are happening way later.

Marius Van Der Wijden (M):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.

Potuz:Because that's what honestly can happen.

Potuz: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.

Potuz:But that's… that was already the case, because you were already syncing, so the next proposer.

Potuz: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 (M):Yeah, I'm just saying that's something that CLs should be mindful of.

Marius Van Der Wijden (M):I should know that we might pull you into…

Marius Van Der Wijden (M):Into optimistic mode if… if we are getting this,

Marius Van Der Wijden (M):a reversal of the head. And for ELs to also be mindful that we might have these, these reorgs that are kind of…

Marius Van Der Wijden (M):Changing the canonicalness of blocks there.

Marius Van Der Wijden (M):That are also included in the sync.

stokes:Can't that already happen, though?

Marius Van Der Wijden (M):Not like this.

Marius Van Der Wijden (M):Okay. Like… If we have marked a block as Canonical… It is…

Marius Van Der Wijden (M):yeah, it's a bit different to uncanonicalize it. This is, like, a new way of doing that.

Marius Van Der Wijden (M):So… Thank you.

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 (M):Yeah, I think both, refinement to the spec and making sure that we have capacity.

Marius Van Der Wijden (M):to maybe do engine API check, too.

stokes:Okay.

stokes:Is there an issue here, or something written down?

stokes:That will help me check this.

stokes: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.

Potuz: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.

Potuz: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.

stokes:turns.

terence: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.

terence:So, I don't think the attribute…

terence: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:I see.

terence: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 (tbenr):Is that a similar thing that we're already happening when we do late block reorg and the fork choice filtering?

Enrico Del Fante (tbenr):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 (tbenr):Yeah.

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

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

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

Enrico Del Fante (tbenr):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

Potuz: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 (M):Well, not really fine.

Marius Van Der Wijden (M):It's just… Like, yes, it's fine from a technical perspective, but from…

Marius Van Der Wijden (M):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.

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…

Potuz:the Yale just replied. Okay, yeah.

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 (M):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

Potuz: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.

Potuz:This requires a majority of clients voting incorrectly to saying that a payload did not exist.

stokes:But what does incorrectly mean? Like…

Potuz:Well, today…

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.

Potuz:So they were voting for the previous consensus block with Committee Index 0, and this means that they were voting for the empty

Potuz: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.

stokes:Right, but it seems…

Enrico Del Fante (tbenr):really possible anyway.

Potuz:I didn't hear Enrico.

Enrico Del Fante (tbenr):So it was on Stoked.

Enrico Del Fante (tbenr):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 (tbenr):Yeah, but I don't even want…

Enrico Del Fante (tbenr):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 (tbenr):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 (M):Yes, it only affects notes that are in the syncing mode. The problem is the syncing mode is…

Marius Van Der Wijden (M):is a bit iffy to find, so if you are sending us on a…

Marius Van Der Wijden (M):On a bigger sidechain, then we might go into syncing mode.

Marius Van Der Wijden (M):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

Marius Van Der Wijden (M):After the initial sync, you will also be kicked into

Marius Van Der Wijden (M):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.

stokes:Yeah, and as I understand, even if we think it will be rare, say, on mainnet, this could happen.

stokes: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.

stokes:Right.

stokes:Okay.

stokes:In any case, I will track this somewhere, and yeah, we will do what we need to do to harden the specs here.

stokes:And or implementations, yeah, just to make this, work how we want.

stokes:Okay.

stokes:Since we've gotten into it, so yeah, there are a number of things, Poda's touched on, I think, most of them already.

stokes:Let's see, let's circle back to this 4788 issue.

stokes:So, yeah, I think Players gave a pretty good summary. Essentially, now that we can have, empty execution payloads under ePBS,

stokes:4788.

stokes:Doesn't quite work, like we expect.

stokes:And the question now is what we do about it.

stokes:So…

stokes:Yeah, there are a couple options. One of them is to do nothing, like Potus said, which is what I kinda lean towards now.

stokes:And the reason why is because, given the way we have different, history accumulators, on the beacon chain.

stokes:You can still get to the data you need, and maybe the proof looks a little bit different, but you can still do so.

stokes:From there, yeah, PK brought this up, that it is possible that

stokes:If you need to go through this different path.

stokes:The proofs might become bigger than we would like.

stokes:And at that point, I would like to quantify the impact.

stokes: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.

pk910:So we at least have all the beacon routes for blocks that have withdrawals and everything included.

pk910:Would be a counter and middle way of both.

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.

stokes:There would be a number of beacon blocks, new execution blocks, and then you would get to… the next…

stokes:4 slot, let's say.

stokes: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.

stokes: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.

stokes:And, like, part of my…

stokes:Point here is I don't think people really need the intermediate beacon box with empty payloads.

stokes:And if somehow they do, They can go through this more indirect route.

stokes:So yeah, like, I think either do nothing, or yeah, we try to pass these, quote, missing routes, or…

stokes:let's say it differently, we passed the route that we would otherwise miss today.

stokes: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.

Potuz: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?

Potuz: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.

Potuz: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.

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…

stokes:There's just no way to change anything.

stokes:Dima?

Dima Gusakov | Lido: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

Dima Gusakov | Lido:three blocks away, or something like that. That's true. However, there are at least two cases that we have already identified in Lido.

Dima Gusakov | Lido:that do require us to point to a specific consensus layer block. The first case is when the consolidation happens. So,

Dima Gusakov | Lido: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

Dima Gusakov | Lido:Belong to, say, different entities, or different staking modules, or different structures, or different owners within a protocol.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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…

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:And since we are gradually introducing ZK Oracle to, later on, probably replace the trusted Oracle.

Dima Gusakov | Lido:We indeed need to point to a specific consensus layer block which… or slot, that corresponds

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:This information now is reachable in a different way, hands.

Dima Gusakov | Lido:development, maintenance, and so on is required. So, in general, I am not a big fan of,

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:So, to summarize it up, it will be way better if we will keep the original behavior of,

Dima Gusakov | Lido:4788.

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

stokes:Yeah, that makes sense.

stokes:Yeah, thanks for the context.

stokes:Mmm… Okay

stokes: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

stokes:Less cumbersome.

stokes:Otis, would you…

stokes: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

Potuz:And that is quite expensive. This adds, like, 22 hashes, but the thing is that we always have the parent hash.

Potuz:Which points to the parent block, or the parent root for a block, which points to the parent block

Potuz: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.

Potuz:Then it just adds a single hash to prove against the block that you're interested in in the worst scenario.

Potuz:So I think it's, I think it's really cheap to prove against blocks.

Potuz:And not the state.

Potuz: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

Potuz:If we prove with block roots, it should be just, essentially, just as cheap as it is today.

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

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.

stokes:What I think the highest cost is would be changing the system contract. So, yeah…

stokes:Strongly prefer to not do that.

stokes:Then from there, the question is, yeah, how nice can we make it?

stokes:I think some combination of option one, which is where we add this rule that you would send

stokes:The most recent non-empty beacon block as the parent.

stokes:I think that handles most of the things.

stokes: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.

stokes:Is a good mitigation there?

stokes: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.

stokes:Okay.

stokes:Any other comments on this one? Otherwise, we'll move forward.

stokes:Okay.

stokes:Okay, the next thing I had here, this was also something POTUS mentioned with, this PTC issue.

stokes:So… I linked what I think, as of yesterday, was…

stokes:the latest, active PR to handle this.

stokes:There was another one from NFLAG.

stokes:That, looks like we should also look at. So… Yeah.

stokes:Mmm… These are the straightforward solutions.

stokes:Given today?

stokes: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.

stokes:And then at that point.

stokes: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.

stokes:That being said…

stokes:There is some argument that having them in the blocks and process like we do today makes things a bit more stable.

stokes: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.

stokes:I believe, POTUS, just from talking on Discord, seems like you'd prefer to keep it as is.

stokes: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.

Potuz: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

Potuz:The… on a split decision, or if you can convince the next proposer that he should reorder payload.

Potuz: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.

stokes:Yeah.

stokes:That intuition makes sense.

stokes:The part that I haven't done myself yet is just look deeply enough into the fork twice to see if this actually holds.

stokes: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

Potuz: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.

Potuz:The question is, what happens if a proposer decides to build on top of empty, for whatever reason?

Potuz:And then in that situation.

Potuz: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.

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

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.

Potuz:So…

Potuz:these kind of things might… might be resolved by the proposer asserting, these are the ones that I'm considering.

Potuz: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.

Potuz:But on the other hand, not including this and not allowing proposers to reorg payloads, I think, allows

Potuz: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.

stokes:Yeah.

stokes:Okay, so… In any case, like…

stokes:As is, we do need to…

stokes:say, merge one of these PRs.

stokes: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,

stokes:Does that.

stokes:So, in any case, I think today, at least for now, I would ask people just to look at these.

stokes:And… Yeah, ideally… We can make a decision in, like, the next week.

stokes:Like, possibly even by ACDT on Monday?

stokes:Oh, do you want to say more about that, Potus?

stokes: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…

stokes:Gross.

stokes:Okay.

stokes:So, okay, yeah, take a look…

stokes:I think, yeah, to fully grok this, it's actually pretty subtle.

stokes:But yeah, take a look, and then…

stokes:Let's just keep chatting about this, perhaps by next ACDT.

stokes:We'll feel more strongly about one route versus the other.

stokes: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…

Potuz: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.

Potuz:But, the one thing that will be a hard force will be this, so this will force a new debit.

stokes:Right. Assuming we don't go down this other route of even just taking them out and handling this a different way.

stokes:But yeah. Okay.

stokes:We… yeah.

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

stokes:Yeah, yeah, yeah, yeah. But no, more just, like…

stokes:I think, yeah, okay. No, just for my own, understanding of the timelines here.

stokes:But yes, it would be, for sure.

stokes: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,

stokes:review these PRs, slash if you prefer one over the other, please add a comment on the PR as well.

stokes:That would be helpful.

stokes:Okay.

stokes:Let's see. So… what is… at the beginning of this call, you touched on these two things that we just discussed.

stokes: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.

stokes:There was also this issue that we were discussing for a bit around…

stokes:the syncing semantics and reorgs there. I don't see something written down right now to track that one, but I will do something.

stokes:Unless I can find something that exists already.

stokes: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.

stokes:One more thing that I think we still need to discuss a bit more was this concept of the variable PTC deadline.

stokes:Certainly, you know, the flow should be to iron out the current devnet.

stokes:And, yeah, just all the mechanics there.

stokes:But then I think there's at least some interest in exploring this variable PTC deadline, in a future devnet.

stokes:So…

stokes: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.

Toni Wahrstätter:This is one of those open points that are still discussed with ePBS.

Toni Wahrstätter:Like, should we do a variable payload deadline that is independent from the PTC deadline?

Toni Wahrstätter:And…

Toni Wahrstätter: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

Toni Wahrstätter: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.

Toni Wahrstätter:So there is EAP7976, that is CFI for Glamsterdam.

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter:So, if we want to anchor the payload, the variable payload deadline, based on the uncompressed block size.

Toni Wahrstätter: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.

Toni Wahrstätter:So, I have some charts in the blog post.

Toni Wahrstätter:Yeah, I don't have a strong opinion on it, and would just say, yeah, let the clients take the shot.

Toni Wahrstätter:But I, I definitely think, Yeah, we should find.

Toni Wahrstätter:solution there.

ethDreamer (Mark):Right.

stokes:Yeah, Mark, yeah.

ethDreamer (Mark):Yeah, I spent a while

ethDreamer (Mark):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,

ethDreamer (Mark):End.

ethDreamer (Mark):I mean, it seems like if we don't do a variable deadline, we're forced to basically set the block,

ethDreamer (Mark):The block deadline back in order to accommodate the larger…

ethDreamer (Mark):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…

ethDreamer (Mark):You know, we've artificially…

ethDreamer (Mark):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.

ethDreamer (Mark):For execution, with a variable deadline, which is not nothing.

ethDreamer (Mark):But I agree with… certainly with Tony's conclusion that EIP7999 seems like the…

ethDreamer (Mark):Real way to solve this problem.

ethDreamer (Mark):It… That was just my attempt to quantify this, in terms of, like, how much

ethDreamer (Mark):How much can actually be gained, and…

ethDreamer (Mark):Yeah, like I said, 300 to 500 milliseconds for execution.

ethDreamer (Mark):Is what I had found.

stokes:Okay.

Toni Wahrstätter:Yeah, fair.

Toni Wahrstätter: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.

Toni Wahrstätter: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

Toni Wahrstätter:Then, most of the blocks would have a deadline at second floor.

Toni Wahrstätter: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.

Toni Wahrstätter: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,

Toni Wahrstätter:Which is, I guess I get where it's from, but I think it should be…

Toni Wahrstätter: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.

Toni Wahrstätter:At least as of Glamsterdam. And…

Toni Wahrstätter:Then the formula already improves, but we're still, like.

Toni Wahrstätter:We would still end up with a very early payload deadline.

Toni Wahrstätter: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.

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.

stokes: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.

stokes:Okay.

stokes:Let me find the agenda…

stokes: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.

stokes:Especially for, you know, as we think about devnet 1 and potentially devnet 2.

stokes:That being said, I think we have plenty to do for devnet 0 right now.

stokes:Zooming out just a bit from there, I did want to think about Glamsterdam, devnet 0, and, like, our path there.

stokes: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.

stokes:And that would mean merging the two different CL and EL work streams, both BALs and also PBS. But then from there.

stokes:That would be nice.

stokes:In terms of us now merging the streams and being able to work together on the actual hard fork.

stokes:Does anyone have any thoughts on that timeline?

stokes:Oh yeah, okay. I mean, this is what I meant, end of April, sorry, but yeah, mid-April.

stokes:Essentially before I interrupt, is what I'm getting at.

stokes:Vernabus, I think we can just make a call on the PTC Monday, and I think that's gonna be fine.

stokes:Okay.

stokes:It's, at least from the lack of responses, this doesn't seem,

stokes: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.

stokes:And… cool.

stokes:Okay, I think that'd be good.

stokes:From there, there are a few things, that are Glamsterdam-related, but not as specific to the seal.

stokes:And a few things that were on the agenda from what of… what would have been, last ACDC's time slot.

stokes:Let's run through these.

stokes:I believe it was… okay, Spencer wanted to SFI the Baldemna to EIPs into Glamsterdam.

stokes:Okay, he also says he won't make the call, so I guess he's not here.

stokes:But yeah.

stokes:Anyone opposed to this?

stokes:I think my first question would be, is devnet2 stable enough?

stokes: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.

Stefan Starflinger:So far.

stokes:Okay.

stokes:Does anyone have a reason not to SFI these?

stokes: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.

stokes:So I'm not trying to delay another week, but, you know, it,

stokes:It is slightly more appropriate to handle next week.

stokes:For example, I don't know if, you know, the right amount of EL devs are even here today.

stokes: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.

stokes:We make SFI decisions on ACDT.

stokes: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.

stokes:Do we think we can make that happen for Monday?

stokes:Okay, how about we… Oh yeah, Osberg's saying he wants to discuss next week on ACDE.

stokes:Okay. Then, sure.

stokes: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.

stokes:And… yeah, we can get into that conversation there.

stokes:Okay. What I was gonna say on guard, then, is Barnabas could optimistically try on Monday. But again, I think it needs to be,

stokes:Like, it can't be just, like, a few…

stokes:EL teams being like, yeah, let's do this. Like, it should be, should be the full set.

stokes:That have the option to weigh in.

stokes:So, in any case, let's fall back to doing this next week, I would suggest.

stokes:And, okay, it sounds like you guys can discuss further.

stokes:Okay.

stokes:Okay, next thing, the SSZ Engine API.

stokes:So… this was from Julio, he had some PRs, I think I also saw a very similar PR from Barnabas.

stokes: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.

stokes:And I think now there have been some, benchmarks to prove this point.

stokes:So, there was a thread on Discord that got quite a bit into, this.

stokes:And… yeah, I don't know if anyone would like to…

stokes:Okay, there are 122 messages.

stokes: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.

stokes:Do we want to go ahead and try to do this in Glamsterdam?

Barnabas:So,

Barnabas: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

Barnabas: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…

Barnabas:go into SSZ instead of JSON.

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

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

stokes:Yeah.

stokes:Marius, and then Julio.

Marius Van Der Wijden (M):Yeah, so I… I think…

Marius Van Der Wijden (M):I personally think we should take this opportunity to also rethink the engine API. Makes no sense to me to just…

Marius Van Der Wijden (M):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,

Marius Van Der Wijden (M):maintenance burden on all of the ELs.

Marius Van Der Wijden (M):I think the way I would… I would like to do it would be to take this as an opportunity to rethink

Marius Van Der Wijden (M):how we are doing the engine API, how we are doing versioning in the engine API,

Marius Van Der Wijden (M):How we are defining structs in the engine API, and so on.

Marius Van Der Wijden (M):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.

Marius Van Der Wijden (M):And so, yeah.

Marius Van Der Wijden (M):I think… Yeah.

stokes:Yeah. So, I mean, yeah, that sounds like a much bigger set of work than just supporting SSZ as an optional transport.

stokes:So, how do you think about… That…

stokes:I guess you're saying you think we should just go ahead and do it now?

stokes:Julia?

Giulio:Yeah, so actually, I think I… I mean, so first of all, I agree with Marius, mostly directionally.

Giulio: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

Giulio: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

Giulio: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…

Giulio: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.

Giulio:Like, you can… first, you can do the SSZ thing, and then…

Giulio:You can, you can, you can also…

Giulio: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…

Giulio:Yeah, maybe there needs to be some ideas on that.

Giulio: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.

stokes:Yeah, that makes sense.

stokes:Sure, Bernos?

Barnabas:Yeah, I would be just curious to know, like, what kind of exact changes Marius was thinking about making.

Barnabas:It says that, like, the versioning is a bit ugly, but, like.

Barnabas:Like, I'm not sure what the exact solution is that would make it less ugly.

Giulio:Wha…

Marius Van Der Wijden (M):Yeah. Kind of what Raul is saying, what Perry is saying, the versioning system of the engine API method, it's just really…

Marius Van Der Wijden (M):Thumbs?

Marius Van Der Wijden (M):And, the way we are, we are constructing structs, means that, at least with the…

Marius Van Der Wijden (M):with the engine, with the SSZ implementations that we have, we need to create a new struct for every, fork.

Marius Van Der Wijden (M):I think the CL devs have the same problem.

Marius Van Der Wijden (M):Instead of fixing that problem, we are kind of now…

Marius Van Der Wijden (M):Importing that… the same problem to… to the EL.

Marius Van Der Wijden (M):And, yeah, it's, Then the…

Marius Van Der Wijden (M):The way we specify some parameters, the way we specify functionality and behavior is kind of…

Marius Van Der Wijden (M):Very annoying, like, the way we specify error.

Marius Van Der Wijden (M):errors in the engine API,

Marius Van Der Wijden (M):And I think all of this needs to be… Oh.

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,

Raúl Kripalani: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.

Raúl Kripalani: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.

Raúl Kripalani:receiving a, like, receiving blobs, for example, then it can tell the EL

Raúl Kripalani: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.

Raúl Kripalani:Basically implement some traffic shap… we can implement traffic shaping that allows both

Raúl Kripalani:Layers to actually act as one, and not kind of, like, be conflicting with one another,

Raúl Kripalani:And… and kind of, like, you know, over… over shared resources. But this would require, like, different… maybe, like, a different set of…

Raúl Kripalani:I think it requires a different set of, interaction patterns, so right now, we have this RPC, approach, which is…

Raúl Kripalani:synchronous, and we'll probably need more streaming, like, streaming-oriented patterns, and maybe there's, like, some WebSockets, kind of, like.

Raúl Kripalani: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.

stokes:Victoria?

Giulio:Yeah, I guess… yeah, I guess… I guess what I think maybe…

Giulio: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…

Giulio:you know, a next-gen API instead, or whatever name we want to give it, honestly.

Giulio: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…

Raúl Kripalani:API would be another effort, but it doesn't necessarily… like, you could technically conceive a world in which you still do JSON, right?

Raúl Kripalani: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:Yeah, actually, yeah, okay. Well, we can do it incrementally, it's not like we need to do everything in one go.

Giulio:So… yeah, I mean, honestly.

Giulio: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.

Raúl Kripalani:And it's, it's, it's, it's just absurd.

Giulio: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: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: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:I understand what you mean, sorry.

Giulio:So… But anyways, what I wanted to say was.

Giulio: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.

Giulio:And what ended up coming up was

Giulio: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.

Giulio: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.

Giulio: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.

stokes:Okay, yeah, let's zoom out a little bit. So…

stokes:Yeah, sounds like there's certainly interest in making some change here.

stokes: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.

stokes:So, yeah, would Barnabas' PR be a good place to start? And, yeah, if you care, we can move forward the conversation there.

stokes:Okay, thank you, Barnabas. Yeah, so take a look at this PR764, and yeah,

stokes:I think the question is just, yeah, fitting in, actually getting something together, but

stokes:Yeah, sure, Julia, if you want to bring it up there, that would make sense.

stokes: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.

stokes:Okay.

stokes:There was one more thing that's not quite a gooda, so let's just go ahead and knock it out.

stokes:And, this was from Bowman Ops. I'm not sure how you see the handle.

stokes:But essentially it was a standardization question for the JSON web token, I believe is what this stands for, secrets.

stokes:This is going, yeah, quite back into history.

stokes:But there was an ask for the client behavior here, just so we could tighten the spec,

stokes:I think this is saying…

stokes:It might be a should, and the question is if we can make it a must.

stokes:But in any case, does anyone have any thoughts on this?

stokes:Let me grab… I think this is the relevant pure.

stokes:Yeah.

stokes:I would imagine, given how old this is, clients

stokes:Have some way to handle this, and… It works, TM.

stokes:Okay, yeah, if you want to dig into this more, take a look at the PR, but otherwise…

stokes:Let's go ahead and move on to the next topic.

stokes:Which is Hegota. So… Yeah, two things here.

stokes:One of them is just around timelines for scoping, so…

stokes:We have picked the CL headliner for Hecata with FOCIL.

stokes:They are still working on the EL side to pick a headliner there.

stokes:I believe the plan is to make a decision next week on ACD,

stokes:For the headliner. And then from there, I will go double-check the ETH Research post, where we're kind of tracking this formally.

stokes:But in any case, the suggestion would be that we open up Nod Headliner.

stokes:let me say this differently. We would open up the non-headliner proposal window, as of that call, so a week from today.

stokes:And then…

stokes: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.

stokes: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.

stokes:But, something to have on the radar.

stokes:And… last thing on the agenda… let me just take a look, I think we've covered the other stuff.

stokes:Mmm… Okay.

stokes: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.

stokes:So, I think the idea is they would want to propose this as a non-headliner EIP for Agota.

stokes: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.

stokes:And then we can wrap up today.

stokes:After that.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:And the core idea of this EIP is to add a so-called custom sweep threshold for validators with compounding withdrawal credentials.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:after 2048 ETH for OX02 validators, but rather select any value in the middle while still utilizing OX02, which means that

Dima Gusakov | Lido: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

Dima Gusakov | Lido:Or today's issue.

Dima Gusakov | Lido: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,

Dima Gusakov | Lido:But it's not, like, equally divi…

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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

Dima Gusakov | Lido:a small, but very useful thing. Now to…

Dima Gusakov | Lido:A bit of a technical details on how this functionality actually works, and why we believe that

Dima Gusakov | Lido:it would not introduce any additional risks or concerns to the protocol. So, first of all.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:So, no major changes here, the same architecture of the contract, the same fee inhibitor, and so on and so forth.

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:the state, particularly

Dima Gusakov | Lido: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,

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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

Dima Gusakov | Lido:ETH that will be accumulated on their validator, and get the rest swept.

Dima Gusakov | Lido:So that was a short description, again, to wrap it up.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido: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

Dima Gusakov | Lido:From our talks with ecosystem participants, with homestakers, with professional operators.

Dima Gusakov | Lido: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

Dima Gusakov | Lido:everyone who is running validators on Ethereum.

Dima Gusakov | Lido:Thank you.

stokes:Cool, thanks, yeah, that was a nice overview.

stokes:There was some discussion in the chat…

stokes:And… yeah, I guess I'll say, yeah, we did originally consider something like this with the consolidations design in Pectra.

stokes:Ektra got a little too big for its own sake, and so it was not included, but yeah, in general.

stokes:This is a nice idea, and yeah, something, something to consider.

Dima Gusakov | Lido:Yeah, and a quick comment on that. Yes, this idea indeed was considered back in the day when Pecture was about to go live.

Dima Gusakov | Lido: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.

Dima Gusakov | Lido:and no significant support from participants like protocols and maybe other, staking participants. However, right now, it is apparent

Dima Gusakov | Lido: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

Dima Gusakov | Lido: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

Dima Gusakov | Lido:With this limit, even if a solo staker with just two validators would transform

Dima Gusakov | Lido: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

Dima Gusakov | Lido:goal we are trying to achieve so that we can enable fast finality and many more other features.

stokes:Whoa.

stokes:Yeah, thanks for the intro, and again, we will get deeper into the knotted Liner EIP set, in the future.

stokes:But yeah, this is a good one to have on the radar.

stokes:We are tired.

stokes: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 (M):Bye.

Chat Logs

stokes:https://github.com/ethereum/pm/issues/1941

Potuz:Alex, if there's time I'd like to go quickly over the open issues on ePBS so that it appears in the minutes and then call the right people to weigh in?

Parithosh Jayanthi:Replying to "The whole pandaops t..." Instructions unclear, running rm -rf /

stokes:Replying to "Alex, if there's tim..." Sure, do you want to go over Barnabas now?

stokes:Replying to "Alex, if there's tim..." I have a similar question

Potuz:Replying to "Alex, if there's tim..." sure

stokes:Seems like this is the main PR: https://github.com/ethereum/consensus-specs/pull/4992

nflaig:there is another alternative PR to fix it https://github.com/ethereum/consensus-specs/pull/5020

nflaig:just opened that like an hour ago

pk910:the issue potus is talking about: https://notes.ethereum.org/@pk910/4788-epbs

James He:Not urgent but another issue. For proposer preferences we would like to replace eth/v1/validator/prepare_beacon_proposer and /eth/v1/validator/register_validator endpoints with it. But the protocol spec proposer preferences can only be sent out for the next epoch. This is an issue for a multitude of edge cases, Also originally called out by Nico, ideally it could be revisited. https://github.com/ethereum/consensus-specs/pull/4777#discussion_r2634788761

Dima Gusakov | Lido:For Lido, restoring missing records is the best option. Otherwise, we will run into a few issues.

pk910:Patches just mentioned in discord that for RP the block root thing is a issue too: > rp uses state proof for validator withdrawal credentials, balances, and withdrawals, if i recall correctly

terence:PR to support reorg head’s ancestor: https://github.com/ethereum/execution-apis/pull/770 Please review EL devs

Potuz:Thanks Alex

Dima Gusakov | Lido:To be fully honest, Lido will not fall apart if we have missing records. But we will have to spend A LOT of money and effort to adapt to it. Over the past 2 years, we have done our best to add permissionless proofs wherever possible to reduce the protocol’s reliance on Oracles. Hence, the exposure to changes in 4788 for Lido is significant at the moment

Potuz:Let's have a more focused chat. I suspect the changes would be minimal if any just keeping things as they are now

stokes:Replying to "To be fully honest, ..." Do you have a link to e.g. some solidity using 4788?

stokes:Replying to "To be fully honest, ..." Ideally we can find a way so its transparent under epbs

stokes:Replying to "To be fully honest, ..." An example would help

Tomás Arjovsky | Lambda | Ethrex:Hey, Tomás from ethrex exec client here. @Potuz what you mentioned is ELs needing to support executing blocks from a parent/ancestor or reorgs to exactly the parent block? That is, just marking head/head+some ancestors as non-canonical?

terence:Its basically this PR: https://github.com/ethereum/execution-apis/pull/770

Potuz:Replying to "Hey, Tomás from ethr..." yes, we may need to reorg to a previous block in the chain

Tomás Arjovsky | Lambda | Ethrex:Replying to "Hey, Tomás from ethr..." ok interesting, I think we already support this, but I’ll check if our test cases cover it correctly. Thanks for the link terence!

Marius Van Der Wijden (M):But then thats iffy ux, right? Getting the update 12 sec later

terence:Replying to "But then thats iffy ..." Right.. that was my point. I don’t know how much this affect UX

Marius Van Der Wijden (M):Replying to "But then thats iffy ..." The cl knows that the head is bad, but keeps el in the dark until the next block

stokes:Replying to "But then thats iffy ..." Still wrapping my head around the issue but can the CL just update the EL as soon as it knows?

terence:Which turns out to be a really good tests, we found so many bugs because of it

stokes:right

terence:You won’t propose if you are optimistic anyway

Potuz:But still the question is that for CLs that reorg to a back node, they will get SYNCING if they were *already* receiving SYNCING correct?

Potuz:BTW, I am fairly certain that the proof becomes not larger than a couple of hashes

Marius Van Der Wijden (M):Can we not just populate the 4788 contract with the missing roots

Potuz:I'll post the full proof of this using the parent hash

stokes:Replying to "Can we not just popu..." What timestamp do they correspond to

Marius Van Der Wijden (M):Replying to "Can we not just popu..." Hmmm

pk910:Replying to "Can we not just popu..." yea, that's part of the problem. we can't insert multiple reoots with the same or multiple system calls. we need separate execution frames that mimic the block time of the empty missed payloads

Potuz:@Dima Gusakov | Lido don't you have the option to choose that slot?

Potuz:then you can just point to a full slot

Potuz:WRT consolidations: those are processed on full slots so you can prove against the parent hash I think?

Dima Gusakov | Lido:Replying to "WRT consolidations: ..." I need to look deeper here. The time for analysis was pretty small NGL

pk910:I think it's 3 intermediate hashes to profe via the parent_root (header has 5 fields, so deph 3). so yea, basically +3 hashes per missed slot. but it makes proof path verification more complex

Potuz:Replying to "WRT consolidations: ..." There's plenty of time for this I believe, and everyone is open to fix it the best way for everyone so I don't think this will be a problem at all

Potuz:Replying to "I think it's 3 inter..." it's not linear in the missed blocks though, cause you will have the child block to the one you're interested always

Potuz:Replying to "I think it's 3 inter..." so it's always just one jump that you need

stokes:https://github.com/ethereum/consensus-specs/pull/4992

stokes:https://github.com/ethereum/consensus-specs/pull/5020

Toni Wahrstätter:For those interested in the different FC possibilities, created this to help me study it: https://nerolation.github.io/ePBS-ptc-fc-table/

Potuz:That's not the simpler one though, that moves complexity to the cache

Potuz:that's the one that has the least size impact on state though

terence:The simple one is where we can just use the state for the cache

terence:Similar to proposer look ahead

Potuz:I have no strong preference

Potuz:whatever clients decide is fine by me, just to be clear we're shipping this in devnet 1

nflaig:Replying to "That's not the simpl..." 4992 still requires a separate ptc cache which is one of the main reasons I don't like it

Parithosh Jayanthi:Replying to "For those interested..." This is super cool!

Barnabas:What is the ensurance that on ACDT we can actually make a decision regarding this PTC stuff?

Barnabas:we have been dragging this on for a long time

Toni Wahrstätter:Variable Payload Deadline Post: https://hackmd.io/@Nerolation/B1GKtAUcZg PR: https://github.com/ethereum/consensus-specs/pull/4843

stokes:Replying to "we have been draggin..." It needs a tad more analysis

stokes:Replying to "we have been draggin..." But I’ll track it so we can sort it out

Potuz:Replying to "we have been draggin..." we can just decide 100%, we've called for clients for a long time, so we will make a decision with whomever is there on monday

stokes:Replying to "we have been draggin..." We can focus on devnet-0 issues before needing to make a decision here

Potuz:Replying to "we have been draggin..." specially cause AFAICS there's no one with a strong feeling about any of these PRs

stokes:Replying to "we have been draggin..." Yeah, im also ok w/ just making a call monday

stokes:Replying to "we have been draggin..." In that case I will try to do a bit more thinking about the fork choice in the event we can make the protocol simpler

Dustin:yeah not all snappy implementations are the same. it's a format, not an algorithm

Potuz:Replying to "That's not the simpl..." yeah me too, my preferred one I believe is 2 epochs (or even 3) in state

Potuz:Replying to "That's not the simpl..." but 4992 allows to at least always use head state to get the ptc, while the new version has branches depending on the slot number

Marius Van Der Wijden (M):5s execution deadline pls

Anders Elowsson:Can we think this over a little longer?

terence:Replying to "That's not the simpl..." 4992 is good with me, that I’m certain we won’t need another off chain cache and can use the state for it. (Except for beacon api use case)

stokes:Replying to "Can we think this ov..." I don’t think we need to make a decision on this today

stokes:Replying to "Can we think this ov..." But it will be time soon

Marius Van Der Wijden (M):We could just ship it in h*

Potuz:Replying to "We could just ship i..." we can ship it any time, it's not a hard fork

Potuz:Replying to "We could just ship i..." and its trivial to implement

stokes:Replying to "We could just ship i..." It needs to be coordinated though right?

stokes:Replying to "We could just ship i..." Essentially a soft fork

Potuz:Replying to "We could just ship i..." What Toni's proposing is reasonable: wait until we have a reasonable solution, whatever we do is fine. @alex I don't think this really needs to be coordinated

ethDreamer (Mark):Replying to "We could just ship i..." Deadline parameter only hard forks :p

Anders Elowsson:Replying to "We could just ship i..." I suppose there are some interactions with pricing.. I.e., to accommodate a variable deadline being as useful as possible, if it is done

Potuz:Replying to "We could just ship i..." PTC voting is kinda irrelevant in 99% of cases

Kevaundray Wedderburn:Execution time turns into proving time; so 6-7 seconds would be great there

Potuz:The only thing I disagree with Toni is that linear regression *is the only reasonable* thing to do, cause broadcast is linear in size

nflaig:Replying to "That's not the simpl..." I am also fine with putting everything in the state so we can remove the off chain cache

Toni Wahrstätter:Replying to "Execution time turns..." What if execution time also turns into gas limit increases :D

Potuz:Replying to "That's not the simpl..." I think it's the best of all, since it also affects hashing in the best way

Parithosh Jayanthi:Target mid April tbh

Parithosh Jayanthi:Otherwise we risk overlapping with interop

Potuz:Replying to "That's not the simpl..." perhaps we can put 3 epochs and be done with duties as well

terence:Sounds good to me

Barnabas:We should make a decision about PTC then today

Toni Wahrstätter:Replying to "The only thing I dis..." I can see that argument but we should then not interpolate as of 3.6 but pick a later point in time

Potuz:Replying to "The only thing I dis..." yeah the constant term should be benched correctly

Toni Wahrstätter:Replying to "The only thing I dis..." Also, broadcast in linear, but we would anchor on uncompressed sizes, which changes the situation

Ansgar Dietrichs:Are we talking CL side or EL side?

Potuz:lol

Ansgar Dietrichs:Ah, right, I think it should be an acde decision

Stefan Starflinger:epbs-devnet-2 doesn't exist right? :D

Barnabas:Can we make sfi decisions on ACDT?

Barnabas:we usually have around 50ppl

Potuz:ACDT had very low volume when I go there

Ansgar Dietrichs:Replying to "Can we make sfi deci…" Maybe we should first discuss on acde? Going forward that might be fine

Ansgar Dietrichs:I am not strongly opinionated though, fine to be overruled

Ansgar Dietrichs:Acdt could at minimum have a recommendation maybe

Toni Wahrstätter:Replying to "I am not strongly op..." I'm strongly opinionated to not overrule ansgar

Barnabas:ppl usually don’t speak up anyways lol.

Ansgar Dietrichs:Replying to "Acdt could at minimu…" Will discuss with Barnabas

Potuz:yes, let's SFI that right now

Potuz::)

Dustin:Is SSZ ok in the EL now?

Giulio:yo

Giulio:Someone summoned me

Cayman Nava:does it need to be synced with a fork? can be built opt-in

stokes:Replying to "Someone summoned me" We are talking about ssz engine api

Potuz:Replying to "The only thing I dis..." we need to find a way of using compressed sizes here

Giulio:SSZ yees

FLCL:not bound by a fork

Ben Adams:Is via discovery

Potuz:+1 to Marius point, but that kind of thinking delays shipping though, until we get the "perfect API", we're bottlenecked by JSON

Potuz:SSZ can be used right now

Toni Wahrstätter:Joking aside, proving can start earlier anyway. This is the latest time when the payload must arrive the attesters. Builders will have to make sure their block is proven and might have time for the prove until the ptc deadline, independent from the payload deadline

FLCL:What exactly would you change?

Barnabas:we would need to have rest support anyway

Barnabas:there we can mess around with the versioning a little bit

Toni Wahrstätter:Replying to "The only thing I dis..." agree yeah, that would be the cleanest solution. Worth discussing async or at some point in the future what the blockers are there

Marius Van Der Wijden (M):Meta versioning 😅

Giulio:yes

Parithosh Jayanthi:Engine API version versioning system

Raúl Kripalani:I would like to see a more fluid interface so EL and CL can coordinate tightly

Justin Florentine (Besu):all api versioning is dumb

FLCL:CL has a bit different approach of types maintanance per fork

Parithosh Jayanthi:Replying to "all api versioning i..." Gotta compliment guilio and jacek for their restraint in not jumping on this and saying we should get rid of EL/CL split altogether

Stefan Starflinger:Replying to "all api versioning i..." single binary?

Dustin:Can't speak for Marius,, but some of the things I've had in mind are: fcU bundles too many things, for example, e.g., setting head vs triggering sync or checking head validity vs setting new head validity being conflated. Inability to ask in any deterministic way whether a block is valid in a way which doesn't trigger a bunch of interference with other operations

Dustin:There are a bunch of semantic points

Justin Florentine (Besu):the best solution to api versioning is "dont", the second best is mime types

Dustin:basically right now engine API supports optimistic and and only optimistic sync, and that's always been the case

Dustin:but that's decreasingly useful

Justin Florentine (Besu):Replying to "all api versioning i..." besu/teku has considerd this for years, we're still kinda "meh" on the value add

stokes:I think I’d suggest “engine api next gen” for interop, and think about more iterative change before that

Dustin:also, the basic notion of exchangecapabilities is one big TOCTOU

Dustin:might as well just try to use $FOO, not ask to use $FOO

Parithosh Jayanthi:Replying to "all api versioning i..." I agree 😄

Dustin:Replying to "CL has a bit diffe..." Yeah, what the CL and EL consider a "mess" might vary

Potuz:Replying to "all api versioning i..." problem is Vouch and company, we will never get rid of the damned API

nflaig:we have Eth-consensus-version header for this on beacon-api so we don't need to bump the api version just because the type changes

Marius Van Der Wijden (M):Rlp on cl

Parithosh Jayanthi:Replying to "Rlp on cl" Really tempted to abuse mod rights on this one

Barnabas:Replying to "Rlp on cl" Marius, you may be excused to leave this call right now

Potuz:Replying to "Rlp on cl" lol

felix (eest):Replying to "Rlp on cl" mods crush their skulls

Stefan Starflinger:flatbuffers+ssz :D

Raúl Kripalani:I don’t care SSZ vs RLP, i just want binary and zero copy

wolovim:Replying to "Rlp on cl" good luck here forkcast summary job

Stefan Starflinger:Replying to "I don’t care SSZ vs ..." not a fan of deserializing?

FLCL:SSZ is not simple, it needs safety checks and parallelisation. Need not MVP level

Barnabas:Barnabas’ PR: https://github.com/ethereum/execution-apis/pull/764

Potuz:Replying to "I don’t care SSZ vs ..." If this sentence makes it so that we go with RLP, you'll be in charge of implementing it in Prysm @Raúl Kripalani

Giulio:fine

Giulio:I think we can rediscuss in ACDE£?

Mercy Boma Naps-Nkari:This is the PR https://github.com/ethereum/execution-apis/pull/297 I was hoping to get input from client devs on. So far, the feedback I got from Nimbus was they prefer a #302-like approach which is the (fixed secret for localhost) over #297's OS-specific paths due to some complexity concerns. While from Lodestar is open to implementing default behavior but there was questions on overall impact since tooling already handles this and CL/EL often don't share filesystems. Waiting for more input from other client teams before deciding on the best agreed upon approach on this, thank you.

Barnabas:I know might be a stupid question, but any CL’s opposed to this? 764

Raúl Kripalani:Replying to "I don’t care SSZ vs …" Deep inside i knew i was making a mistake putting those two words together in a sentence

Giulio:@FLCL I would be happy to do it in Nethermind theb

Giulio:To prove you wrong 🙂

Dustin:Replying to "The only thing I d..." well different snappy implementations exist

Dustin:Replying to "The only thing I d..." Nimbus uses its own for example, but the general point is that it's a format, not one compression/encoding specification

stokes:https://github.com/ethereum/execution-apis/pull/297

Barnabas:I think changing defaults so late is a no go

Marius Van Der Wijden (M):Replying to "Rlp on cl" Btw can we get a ranked list of talking time? Who are the biggest yappers on acd

Barnabas:Replying to "Rlp on cl" Probably stokes 😂

Parithosh Jayanthi:Replying to "Rlp on cl" Ranked list for chat would also be cool

Barnabas:Replying to "Rlp on cl" oh crap

Raúl Kripalani:Replying to "I don’t care SSZ vs …" @Stefan Starflinger we don’t get rid of deserialization (unless we send blobs binaries without any framing), but with SSZ we can use the data from the network buffer without making another alloc

Raúl Kripalani:Replying to "I don’t care SSZ vs …" Which we can’t do in JSON because of the base64 decoding penalty

Marius Van Der Wijden (M):Replying to "Rlp on cl" Yeah the interesting point would be position 2+

Potuz:Replying to "The only thing I dis..." I have strong opinions on this, this is not going to cause a split view: PTC is irrelevant unless the next proposer is going to reorg the payload, which it shouldn't. I think it's fine to use different algo's as long as their outputs are not TOOO different

Marius Van Der Wijden (M):Replying to "Rlp on cl" Ansgar will likely take the top spot

Giulio:Replying to "all api versioning i..." Nah, I am realistic in my expectations 🙂

Giulio:Replying to "all api versioning i..." I hope this is enough work from for now 🙂

wolovim:Replying to "Rlp on cl" Congrats you found the only feature that jitsi has and zoom does not

Potuz:Replying to "Rlp on cl" > Btw can we get a ranked list of talking time? Who are the biggest yappers on acd Can we not do this on this call?

Dustin:Replying to "The only thing I d..." so it works until it doesn't?

Marius Van Der Wijden (M):Replying to "Rlp on cl" We could download all the youtube live streams and feed them to an ai

Potuz:if you have a lot of 2024 validators and you worry about your partial withdrawals logistics/costs, please send me one of those 0x02 with 2024ETH and I'll pay your withdrawals from the remaining one :)

Barnabas:Is there a a reason this (EIP8148) couldn’t be done on the app level?

stokes:Replying to "Is there a a reason ..." You need the consensus layer to be aware for it to be useful

Potuz:Replying to "Is there a a reason ..." also how would you implement this, someone needs to trigger the txs.

Barnabas:Replying to "if you have a lot of..." 2048 you mean?

Enrico Del Fante (tbenr):Replying to "if you have a lot of..." 2024 ? 🙂

stokes:Replying to "Is there a a reason ..." We did consider this w/ the original consolidation design, but decided against given how big pectra was getting

Potuz:Replying to "if you have a lot of..." lol, can't edit

Greg K | Lido:Replying to "Is there a a reaso..." The whole point is to use the sweep withdrawal algorithm of the CL

stokes:Replying to "Is there a a reason ..." Its a nice idea, just adds yet more complexity

Barnabas:Replying to "if you have a lot of..." potuz forgetting powers of 2 was not on my bingo sheet 😂

Dustin:the pectra consolidation design already proved to be a bug factory

Potuz:Replying to "if you have a lot of..." I still don't even know where the number 2024 comes from

Greg K | Lido:Replying to "Is there a a reaso..." but looks like without this feature, 0x02 adoption is too low..

Potuz:Replying to "Is there a a reason ..." complexity I don't think it's an issue, but I would worry about performance

Jihoon:A spec PR for EIP-8148: https://github.com/ethereum/consensus-specs/pull/4901

stokes:Replying to "Is there a a reason ..." fair

Barnabas:Replying to "Is there a a reason ..." why can’t lido submit the manual partial withdrawal for validators that opt in for this ?

stokes:Replying to "Is there a a reason ..." Perhaps the champions could do a PoC to get some initial numbers

Barnabas:Replying to "Is there a a reason ..." like enable this feature for your customers, and submit the tx on their behalf

Dima Gusakov | Lido:https://eips.ethereum.org/EIPS/eip-8148

Greg K | Lido:Replying to "Is there a a reaso..." the point is to allow every validator use this feature, not only Lido ones :-)

stokes:Replying to "Is there a a reason ..." Yeah its not just a lido thing

Greg K | Lido:Replying to "Is there a a reaso..." especially small validators benefit more from this (e.g., 60 ETH validators)

nixo:https://dune.com/butta_ethereum/maxeb-0x02-and-consolidations

Barnabas:I personally don’t think this is the reason people are not consolidating, but rather becuase they are lazy.

Potuz:perfect timing!

Summary

14 highlights · 2 decisions · 4 action itemsExperimental

fork status and schedule

PTC fix will force DevNet 1; only hard fork requirement00:48:09
Target Glamsterdam DevNet 0 mid-April (before Interop)00:57:55

epbs critical issues

PTC issue causes state-dependent committee changes; needs decision Monday00:10:12
4788 will have gaps for empty payloads; protocols prefer backfilling00:13:46
ELs must support reorgs to parent blocks under ePBS00:17:38
Finalized/justified heads must send parent hash to engine, not block root00:43:50

devnet status

DevNet 0: Prysm, Lighthouse, Lodestar operational; Nimbus/Teku/Grandine issues00:06:40
Lighthouse cannot process exits; will break chain if triggered00:07:44
Prysm missing blocks due to wrong payload hash in FCU00:08:06

engine api redesign

SSZ Engine API optional transport shows significant blob performance gains01:04:46
Debate: ship SSZ immediately vs redesign entire Engine API first01:05:52
ELs want semantic fixes: FCU bundles too much, no deterministic validity checks01:10:10

hegota planning

Non-headliner proposal window opens after EL headliner decision next week01:19:14
EIP-8148 proposed: custom sweep threshold for 0x02 validators01:22:49

Decisions

ELs may return SYNCING during reorgs to parent; CLs will handle optimistically00:19:40
Target Glamsterdam DevNet 0 mid-April before Interop00:58:26

Action Items

All CL teams: Review PTC fix PRs 4992 and 5020; decide by Monday ACDT00:42:40
stokes: Contact Lido, Rocketpool, EigenLayer on 4788 impact; analyze proof complexity00:32:23
Ansgar/Spencer: Discuss BAL DevNet 2 SFI on next ACDE (March 26)01:01:38
All EL/CL teams: Review SSZ Engine API PR 764; discuss redesign scope on ACDE01:17:18

Targets

Monday March 24 ACDT - Decide PTC fix approach00:43:06
Mid-April 2026 - Glamsterdam DevNet 0 launch00:57:55