All Core Devs - Consensus #182

Transcript

Parithosh Jayanthi: Hello.

Pooja Ranjan: GMGM. Pari, Akash would be helping with streaming, so whenever you are ready, just let us know to.

Parithosh Jayanthi: Thank you so much.

Let's give everyone another minute to join in, and then we start. Okay, let's get started. Akash, can you start the stream?

Akash | ECH: Yeah, we are live.

Parithosh Jayanthi: Perfect. Thank you so much. Hey everyone, welcome to ACDC number 182. The first point on the agenda is getting a DevNet 6 update. Barnabas is not available today, do we… could we have it from Stefan, or if not, I can do it?

Stefan Starflinger: Yeah, sure. So, it's been going pretty well. We've, from the L side, had one minor thing with Nethermind, where there was some disagreement for storage reads when a contract reverted. They're still looking into that, and I hope the notes will go online pretty soon. I think we have around 80% participation. I hear it's already fixed. And otherwise, I think from the CL side, it's going pretty well, but maybe someone with more context. There was one Grandine bug that I reported, or not bug, but there was some performance issues that I reported with the Panda CLI. But otherwise, yeah, I think it's going pretty well, and DevNet7… I think we have both releases now from the CL and the EL, so it would be good to get kind of, like, a vibe for when that would be ready.

Parithosh Jayanthi: Do we have any client teams who can speak to that? Okay, maybe as a follow-on topic, I see there's a couple of missed blocks and issues with either Lodestar or Lodestar Ethrex 1. Has someone already looked into this?

Potuz: That's Death Star. They are supposed to be.

Parithosh Jayanthi: Got it. Okay, makes sense. And. Okay, that sounds good. It seems like some of them leads to two-ish missed slots, but I guess we have to… Investigate… yeah, we can rename the validator, so it's kind of clearer. Okay, next item on the agenda was, DevNet 7. What's the, client readiness for DevNet 7? I know that there was a spec release yesterday, both from the CL as well as test releases from the EL. So, are clients already passing all the tests, or what's the status?

Stefan Starflinger: I think so far ethrex is passing all the tests, and I've also been testing them locally. They've been doing pretty fine. And most of the CLs, I haven't tested all of them, but most of the ones I've tested so far seem to be doing okay. And just a very initial one CL, one EL networks.

Enrico Del Fante: We need to update our branch for sure, so we are applying some of the changes, but… Yeah, maybe we will have something. By the end of today, tomorrow, as an updated branch. hopefully.

Parithosh Jayanthi: Okay, great. It seems that Lodestar was ready before the spec releases, so they probably have to check the spec tests. Nimbus is passing all the tests and Tern said Prysm should be ready in a few days. Maybe to Tony's question, EL changes being pushed to DevNet 8. Tony, could you speak about which EL changes? Was this to 2788 or different ones?

Toni Wahrstätter: Yeah, I think this was about 2780. There were some spec changes, and I don't think we… Clients have them already, but maybe Guru or Dragon, maybe Gary. Can, tell us a bit more about that.

Parithosh Jayanthi: Yeah, I think we might have to try and coordinate. So if Prysm and Lighthouse are ready before this PR gets in, as well as spec changes can be released as tests and so on. then I'd propose we do DevNet 7 as is. If it feels like it's going to take longer and all the ELs are ready, then it probably makes sense to include the change if it isn't a big one Does that sound fair?

Toni Wahrstätter: Yeah, it would be great if clients could take a look. Spencer posted the Pr. In the chat.

Maria Silva: My understanding was, like, this was going into DevNet 7, not,

Stefan Starflinger: Yeah, mine also.

Parithosh Jayanthi: Okay, if that's the case, then, where are we on getting it merged and tested, as in test releases happening for it?

Maria Silva: Yeah, I'm not sure how we are in specs, To be honest, on this one.

Spencer Taylor-Brown: Sorry, can I just double check? What change? I accidentally closed my Zoom by trying to look at EIPs, so I'll reach on just now, sorry.

Stefan Starflinger: The question is, how many of the 2780 changes are gonna make it into DevNet 7? And… Could you give maybe an update on what of the 2780 changes you included in the 7 test release?

Spencer Taylor-Brown: So I… I'm sure we're up to date with, there was a new TR, new EELS PR, EIP's PR. From Gary, and discussion in the Discord. And that is why I merged, so I believe we have all of these changes here. I believe this was the latest. and… Yeah, so, I mean, If people… I'm pretty sure we're, like, up to date with all the 2780 changes. And… As far as I know. And the tracker contains this, these new changes that were, I believe, just merged. And was this PR merged?

Stefan Starflinger: I think just today.

Spencer Taylor-Brown: 43 minutes ago, so… yeah, we're up to date with that PR. So I think the only open change as far as I know, is, Tony's, block access has changed, which is quite a small change. So the question is, which we don't have in the tests. So the question is whether we want to add that to Spell DevNet 7 or… Sorry.

Parithosh Jayanthi: Is the change small enough that EL teams would also be able to implement it in the span of a few days? I guess this might be the wrong crowd. I'm just trying to see if we can couple the amount of time the CLs need to implement the latest specs to the amount of time the ELs need with this change, and then we kind of have the same lag on both sides, so it makes sense to just launch with all the changes.

Spencer Taylor-Brown: Personally, I feel like we should add it, but then the question is, is it outside of process, if we just… creating a release with this change. I think on our side, it's pretty easy to add. To the other side.

Stefan Starflinger: I think if it's not too much, we should add it. I think clients are in the middle of developing, and I think it shouldn't be Too much… If it's just a small change.

Toni Wahrstätter: Yeah, I'm just checking the Discord thread and Dragon. And, Karim? have also said they want to include it into devnet 7. I think the same place. For Gary. So it seems like we… clients definitely want to include that. I don't have insight into how far clients are with that.

Parithosh Jayanthi: Okay, if that's the case, then let's include it. Spencer, would you be able to make an EL release so that clients can start passing the new tests, and as soon as we have two clients, we can launch next week, because I would assume that, by then the CLs are also all ready.

Spencer Taylor-Brown: Yeah, we we can. We can tag and release. I guess by the end of today.

Parithosh Jayanthi: Does that work for CL teams as well? Would early next week, be possible for you guys to provide a, plant branch with all the tests passing? I think the only client that hadn't responded earlier was Lighthouse, so… Is someone from Lighthouse here? Okay, let's assume Lighthouse is also ready on roughly the same timeline. That means we can target early next week for DevNet 7. Does that work for everyone? Okay, sounds good. Also, maybe just as a small side note, the clients who were ready and performing local testing, to confirm, this is including progressive containers, right?

Okay. Awesome, that's perfect. That's very good news, then. Any other DevNet-related topic? Any open PRs, et cetera, that we should quickly make a decision on, that would change the timeline?

Justin Traglia: None. Sorry, none that I'm aware of.

Parithosh Jayanthi: Okay, thank you Thank you. Bye. Then moving on to general, Glamsterdam-related topics, Nico wanted to talk about removing blinded execution payload. Do you want to introduce the topic, Nico?

Nico Flaig: Yes, so two weeks ago, we merged this large PR, which defined the produce block v4 APIs. I think it was my original suggestion to add this blinded execution payload. For the stateless flow, sorry, for the stateful flow, because essentially you avoid sending around the payload. But when implementing this, I realized this adds a lot of complexity. So there's, like, 3 topics, and the biggest one, I guess, was that we also need to update the signing flow if we do this. Which is pretty bad, because you also need to update Web3 signer and all the remote signers. And the benefit of this is still. Just a small performance improvement. Because you only save the payload that you don't need to send around, while the big gain of the stateful flow is us not sending around the blobs between the validated client and the payload.

And the beaker node. So, yeah. I'm basically this just removing that. I didn't really put any description on the PR. Barnabas wanted to open this yesterday or wanted me to do this because there was some issue with the builder flow publishing the payload. But there seems to be already approvals on it. But I need to polish this a bit before we can merge it.

Parithosh Jayanthi: Yeah, thank you. In general, it does seem to be a nice simplification. Is there any client team that's against this change? Okay, it sounds like just a nice description, and maybe Yeah, then you should be able to merge it in. Okay, the next point on the agenda I had was, getting a status update on EIP8282, so that's the… new contract for biller deposits. Is the contract now final, and can we start figuring out audit for it, or are there still changes, up for review?

Cayman Nava: Yeah, I can't really speak to all that. I wasn't editing it. Felix was. But from what I can tell, it looks like the dust has fully settled. The, both the fee mechanism now updates. When users interact with the contract, and… We, removed the Inhibitor, which was active. Which prevented use of the contract before the fork. Now there's an unused inhibitor that the system can add, so that we can disable the contract in the future. But that applies to both the deposit and the exit contract. and Nico and Justin worked to tweak the constants for the the target and Max. So I think all of those things are resolved, and, as far as I can tell.

It's in a… Final form.

Felix Lange: Yeah, I can. I can speak to this. It is. good now. I want to mention there, we will have an audit of the contract, and there may still be coming some small changes out of this, but I think we are happy with the semantics of the contracts now. I do want to mention that For the… For the builder exit contract. we still set the inhibitor in the constructor, so it is possible to exit builder before the work, but I think this is acceptable, because these exits would anyway only be processed after the fork and we primarily want people to sign be able to sign up as a builder before the fork comes and then once the fork is active they can exit again so this is the strategy that I chose and regarding the we

Are not using… E. I'll let them know. There we go. is to create…

Parithosh Jayanthi: You were breaking up a bit towards the end, Felix.

Felix Lange: Sorry, I just answered the thing from Joachim. We are already using the Creator tool.

Parithosh Jayanthi: Okay, I think he's saying they're already using the create two method. And yes, I agree. I think submitting Xs before the fork seems in itself fine. Okay. Yeah, okay, I think the EIP language probably needs updating, Kamen, or Felix, or someone else, would you be able to update the language? Thank you. That sounds good. Then we should be ready for an audit. Worst case, once it's live on DevNet 7, and we're sure that it's working, fully as expected, then we could start the audit then at latest. Awesome. Thank you. Terence had a point he wanted to bring up with, add a post, for ProduceBlock v4. Terence or Putus, do you want to introduce the topic?

Terence Tsao: It's mostly POTUS's work, but I can give some background. So we know in EPBS that block production changes, right? You have a bid, you don't have a payload anymore. you commit, and then payload reveal later, so alongside P2P bid, there is this builder API as well, right? So, but with the builder API, there is this… new option of sending authorization, basically, right? And in prison, we will… sign the authorization from the validator side, and then send it to get the bid, yeah? And so basically, we have this implemented and tested, but there's one… I guess one lesson that we have learned along the way is that the identity and the transport should be separate, because one of the first feedback we got was from the CommitBoost team. Basically.

their feedback was that because we're sending the authorization, which is the URL itself, it wouldn't work for them, because the URL is actually the CommitBoost proxy URL. But then the authorization to be the builder's URL. So, in a way, it has to Pass through, basically. Otherwise, the builders will just reject them. And then commit boosts or any proxy, they don't hold… they don't have the validator key, so therefore they cannot sign, right? So we basically are coming to some sort of, discussion or feedback loop. With the auto protocol ecosystem, like sidecars, like MOS, DVTs, so definitely. The more feedback we can get, the better. And in my PR 17124, I posted an example config, essentially, that what I have implemented.

To satisfy such use case. And POTUS's beacon API PR625 is the attempt to standardize it across, which is what I implemented, basically. So POTUS's API basically states that the request body will carry the previewer preference, which has the ART, which has the URL. And also plus some selection knobs like the min bid and per builder boost factor. and stuff like that. So we're essentially at the stage of, like, we basically want feedback from all the, community, from all the ecosystem partners. from all the VC adjustments tooling, for example, Web3 Cider, VOSH, SSV, people also… essentially, the more feedback we can have now, the better, because we want to start testing. Yeah, that's my two cents. Feel free to chime in, potuz, or anyone.

Parithosh Jayanthi: Has anyone else had a chance to review the PR?

Nico Flaig: So I guess if nobody wants to give an opinion. So I'm not concerned implementing this in Lodestar itself or like in CL clients in general. So my concern would be mostly that we support all the toolings and all the staking setups. And, because the config itself is pretty complex, in my opinion. Like, having the ability to do it per validator pubkey, and then also having per builder configs, like minbid and boost factor and so on. So, we definitely need to make sure that other software can support this, and, for example, there's tooling that uses only the KeyManager API to configure the validator client, so we would also need to consider that. I think it's all possible, we just need to get more feedback, as Terence noted, outside of, like, just people in this call.

Parithosh Jayanthi: Yeah, portals.

Potuz: Yeah, so just to make something very clear, clients should default. to just take a couple of flags, like minBid, maxTrustedBid, or whatever it is, you can just have defaults for those values, and the operator should be able to just set a couple of flags And that's it. And then the client itself would send on the API, would fill this list. on a per-builder basis, and just repeat those values. From the point of view of the operator, it should be very simple to set these flags. You can just say, I want these flags for every builder, or I want this min-bid for every builder, or I don't set anything, and you just give me nice defaults for every builder.

The unknown operator should only provide a list of builders that they trust, that they want to have contacted. So I think the complicated part of like having this per builder and having this configurable is either for a very advanced node operator or for someone that runs some keys of their own and some other keys, say for like Rocket Pool or Lido, and then they really need to have a separated list of keys. Yeah, defaults or configurations. But in general, I respect that node operators can just set one value and then the client fill the map with the pair builder values. It shouldn't be complicated for operators.

Nico Flaig: Yeah, I mean, my concern is not really, like, if you can provide a file, this is all possible and easy to configure. But, currently, you can do it via the Key Manager API. Like, you can configure the validator client via that. And I think this n square n matrix, I mean, currently it's not supported, right? So we just need to make sure we come up with a design that also allows KeyManager API validator clients that only want to use that to be able to express the full config, basically.

Parithosh Jayanthi: Where would you want external parties to provide the feedback to? Just in the PR, or what sort of feedback are you guys expecting?

Potuz: The FPR is good and it should be yesterday. We really need this to implement the builder path. We don't have an effective way of sending the signed auth without having this. So this should be like today. And parties should be staking pools mostly and builders because…

Parithosh Jayanthi: Okay, so the explicit ask…

Potuz: Like, both of them.

Parithosh Jayanthi: any staking pool, so Lido, Rocket Pools, everyone else, as well as any builder to provide feedback in, the Beacon API PR625, right?

Potuz: Yeah, perfect.

Nico Flaig: Yeah, I would say in addition it should also be any DVT software because they need to aggregate the signatures to create the signed off request. So, I know, for example, that, Oball has issues if you put the pubkey in there. I haven't looked at the details of PODUS's PR, but yeah, that, maybe we should make sure we have all the details covered there, to also support dbt.

Parithosh Jayanthi: Yes, that sounds perfect. Okay, thank you. Then please provide feedback on the PR, and then we can take any questions on Discord, Ether, and DSalvo. Next item on the agenda was, something that was brought up earlier today on the call, in case we… So Matthew brought up, having a more public-ish DevNet. Something that allows for applications, et cetera, to, test their changes for Gloas. I would propose that's one of the later DevNets, so perhaps DevNet 8, or once we have, like, a stable spec release where nothing is changing again. Would that work for everyone? Something that we can target around next month?

Matthew Keil: You know, the thing that, the reason why I brought this up is it's probably gonna take applications, some time in order to get ready for that. And having some form of a date, and I know it's hard for us to do now because it's mushy, but having some kind of a goal that they can shoot for, because really it's… it's to give applications a testnet to… to… To work from, needs to kind of happen now, or it needs to be announced publicly so that they can prepare.

Parithosh Jayanthi: Yeah, Maria?

Maria Silva: Yeah, I would also add, this is a more EL topic, but I would say for repricings, it's also very important for us to be able to provide such a network sooner rather than later. Repricings will have a big impact on many of DApps, and they need to kind of be able to test how they fail and why they fail and Work on, on changes to the contract, so, yeah, I would also if possible, strive to have that public DevNet as soon as possible.

Parithosh Jayanthi: Do we think we'd be able to get stable-ish clients as well as stable-ish repricing numbers roughly a month from now?

Maria Silva: On the repricings, I would say yes.

Matthew Keil: Okay. The only concern I have is, is a month enough time in order to let, let the community not only know, but for them to be able to get prepared for it.

Parithosh Jayanthi: I think the benefit is that this can be an early version because we will still have two full testnets before we even do mainnet. So this is kind of the first time that we can raise awareness on a lot of changes in a place that they can interact. I don't know if we should delay that too much longer, to be honest, especially because it's a lot of EL changes that people can quite easily test, let's say, especially if it's contract deployments.

Matthew Keil: It's less about the delay and more about just letting people know that it's coming. I think was really… was the heart of, heart of my wanting to bring this up, is, you know, to get the announcement and get them… get them ready and rallied.

Parithosh Jayanthi: Would all the CL teams be able to commit to something early August? I mean, this doesn't have to be mainnet-ready releases, but it has to be Polished-ish. So would that be… would that work for all CL teams? Okay, we have one. Prysm says yes. Okay, let's… okay, Goldstar also says yes. Let's target start of next month, then. So that we can slowly start preparing community testing, still make some changes if we have to before we go live on testnets. We also have some non-finality tests planned for next month, so they should all fit in relatively nicely. And we can keep these on separate networks so that applications are not affected by non-finality testing.

The next item on the agenda was EPBS circuit breakers. We spoke about the fact that it will be client implementation specific. But we still did want to bring it up as to what, approach each client is gonna take, so that we have a brief discussion on it. Has any client already implemented their circuit breakers? What's the approach they will… they're going to take? What's the, status?

Mehdi Aouadi: Yeah, we have an implementation on Teku. It's been reviewed. It's not been tested yet, but yeah, it's ready and would be ready for DevNet 7, I guess.

Parithosh Jayanthi: And what's the approach you guys are using? So when does the circuit breaker trigger on Teku.

Mehdi Aouadi: It's a little bit similar to the existing one, but it's based on the execution payloads, obviously. And basically, we have some options to define A, monitoring window. and some allowed consecutive missing execution payloads and a number of missing execution payloads during that window. and it's also based on the builder index. Since the those indices can be reused. So we check if the builder index is we basically have a a a banning and unbanning logic based on the index. And, we also check if, the, the public key associated to that index has been, updated, if it's the case, so we drop that ban, and, yeah.

Nico Flaig: I don't really get what you do with the builder index. So you blacklist builders or?

Mehdi Aouadi: Yeah, we have… we have a cache. Actually, we keep history of the, if a builder, for example, say. didn't publish a execution payload for, say, 3 consecutive slots, we ban it for a couple of slots, and then we unban it. So we stop considering the bids from that builder, and we just look for the other ones.

Nico Flaig: But it's not really a circuit breaker, right? So it's more like you…

Mehdi Aouadi: Don't consider.

Nico Flaig: So there are bits.

Mehdi Aouadi: If that's the case, we fall back to the self-building process.

Nico Flaig: So if your circuit breaker is triggered, you only self build, or.

Mehdi Aouadi: Yeah, if if if if the circuit breaker is triggered, we we fall back to the we ban that builder, and we fall back to the self building.

Nico Flaig: Okay, it's pretty much what I have in Lodestar as well. So it's we. I kept it pretty similar to what we had pre-close. the only factor, I guess, is you consider payloads instead of blocks, and then I scale the fault inspection window on a… yeah, right, I scale it, if blocks are missed, so I'm not, counting those, but… It's a bit more complex, but not by much.

Mehdi Aouadi: Yeah, it's basically the same logic. We just have that builder index consideration in addition to the block logic we had.

Parithosh Jayanthi: That sounds good. Prysm or potuz, do you want to talk about your approach?

Potuz: So I forgot to bring the full document. I think we want to have something quite complicated, or at least a bit more involved, in which we will allow the operator to set different parameters to what are the payloads that, what are the parameters on payloads that he'll like to have them banned. So we want to have fallback mechanisms in which we fall back to trusted builders or we fall back to P2P builders. So… so there's… there's different scenarios in which we want to… I… to fall back to… I've actually trusted builders instead of, P2P builders, because the P2P builders can be civil attacked. So I promise I'll have a full document written down with all the options. We discussed this in Svalbard. We found a lot of bugs.

on the original approach that we wanted to fall back to P2P, but P2P can be easily civil attacked, and cheaply now, civil attacked, so to… to land a lot of empty blocks. So what we want to do is to have a fallback mechanism in which if we see many blocks that are missing, fall back only to trusted builders. And if we see payloads that are missing from our trusted builders, then fall back to self-building. Yeah. Anyways, I'll promise I'll have something written down complete in the next few days.

Parithosh Jayanthi: Okay, that sounds awesome. Tony had a question?

Potuz: Yeah, I.

Parithosh Jayanthi: Yeah, so true.

Potuz: To answer to Tony, so the problem with P2P is that today is very cheap. I mean, we can argue that this is part of the protocol itself. But today, before Gloas, if a builder wants to, like, flood the network with empty blocks. they could do it. You could pay, you could bid, and you can win the bid, and you will just make a liveness province on Ethereum. You will make, including blocks, very expensive. You're gonna have to, Win their bid. The relay presumably is going to stop this from happening. But… on a situation where we have these P2P bids, and the blocks are so cheap as they are now, someone can just, like, bid them over P2P and win.

and prevent blocks from being included. Again, this is part of the open market we have. In principle, you could accept this, but I think clients can try to prevent this from happening. If we see lots of blocks that are missing, stop. P2P bids. If we don't recognize the builders, we don't recognize the builder IDs, then we can just, like, stop taking bids from P2P, for example.

Toni Wahrstätter: Thanks. Is there a difference between the execution payment and the trustless payment?

Potuz: So the execution payment doesn't really matter over P2P. Over P2P, we don't allow execution payments. And I think this is not an issue about payments itself, it's just an issue about I can just pin up a thousand keys over P2P. If one of them gets spammed, I'm just gonna send bits on the other key. And to answer to Nikos, trusted builders are builders that are working today. Their liveness of the chain today depends on them. If they are not buggy, and if they are working, I think it's better to rely on them before relying on local building. Trusted builders have been resilient, and they are providing us blocks today that are better blocks than if we fall back to local building.

We like it or not. trusted blocks are better than the blocks that my Nuke provides or builds.

Nico Flaig: Yeah, I just wanted to… so we clarified it. So the… basically the issue with falling back to only local would be basically a liveness issue for a lot of DeFi apps, I guess? So so that is the argument. Right? Just to clarify that.

Potuz: Yeah, but also like checking on the health of trusted. builders, it's very easy now on Gloas, because I don't need to be the proposer. I can just see that Titan is not producing blocks, and I can just blacklist Titan immediately. So it's the easy part is blacklisting the trusted builders. The hard part is blacklisting the P. 2 P. Builders.

Parithosh Jayanthi: Do we want to move the discussion from chat to the call?

Potuz: Yeah, so Dima is asking, what about this execution flag that we have this value on the bid? And yes, there is no reason to have that value on the bid. I think it was included just for accountability reasons, so that anyone can actually check In principle, you could Check that there is a transaction that pays that much to the fee recipient in the payload. And this is an option that is there because that value is on the bid on the CL block. But we don't enforce anything on the CL, we just have that value and provide it as an option. That value is there, and it's completely ignored. The only check that we do is that that value is zero for P2P bits.

Dima Gusakov: I mean, what I'm trying to say is that like, right now, you do have this trusted part, and there is a transaction with some amount. However, there are no signs on-chain about what this value should be. When you are now adding this field, and you're saying, okay, for trustless payments for P2P bids, this value should be zero, but for trusted bids, it would likely mean nothing, and it might confuse, I don't know, an external observer, if this value is, for example, is incorrect. So you will have a record on chain saying that for this payload, the EL payment was, I don't know, 1 ETH. But then there is no transaction within a block, which would be misleading for the external observer, which would see that, oh, this is a field that is written on-chain.

But it's never validated, so… I'm pretty much confused about why do we even need this value.

Potuz: It is an off protocol field. An external observer can either ignore it or try to validate it itself. If you don't have it, then, well, you don't even have the information of what that builder promised to pay.

Dima Gusakov: Okay, but… Like right now, the only way how you know what, what Builder promised you to pay is your negotiation with the relay. And, now you have this… like, how this value helps. So would now… would builders now propagate the bids of this standard format over the… across relays as well? Or would they just… act in a way they act right now, when you cannot distinguish a builder block from a locally built block from the on-chain data, because from the on-chain perspective, it's just a self-built block.

Potuz: would identify an externally built block. So the way this works is I contact Titan. And Titan replies to me with a bid, and this bid would tell me the trusted part, the trustless part of the bid is zero, or it could be like one way, and the trusted part is 2ETH. And if I trust Titan, I would just consider those two ETH as part of a payment. Then I contact some random guy that just opens an endpoint. And I contact him because, well, I just want to get more bids fast. And then to that random guy, I would add a flag that says the max trusted bid that I take from that builder is zero.

So this random guy would just receive my call, it would know that I take zero trusted bits from them, and then they will put, say, I give you 0.5 ETH on the trustless payment, and zero on the trusted part, and then I just evaluate, do I want to have from this random guy, half an ETH that I'm sure to receive, or do I want to have one ETH from Titan that I don't know if I'm gonna receive, I trust that they're gonna pay me on the EL, and then I just put whatever bid I want. But this is the negotiation happens directly with both of them. If there are relays, and those relays want to be dealing with these things, I mean, again, this is part of the protocol, and the client would only deal with the relay as if it were a builder.

Dima Gusakov: Yeah, okay, that's understood. I'm trying to understand what stops builders from keeping their operations in the way they do now when instead of propagating a bit, they only propagate a header and then the node just accepts this and pretends that that was a self-built block.

Potuz: Oh, we… you don't… you can't, you need to sign it. So, if the… I mean, that includes, like, adding a lot of support on codebases that at least Prysm would not do, I understand Lodestar would also not do, and I suspect no client would support that. To have that sort of, like, dealing, it would be the following. the… I would need to contact directly a builder, or a relay, or whatever it is. You would need to send me a blinded execution payload bid. That I will sign myself as a self-built. the value of the trusted bid is going to be zero, because we, on self-built blocks, we just put zero for the value of the payment, and then we will just arrange for a payment off protocol somewhere. I will sign the bid as if it was self-built.

And then again, we will have to have another conversation when the payload needs to be propagated. I need to get a blinded envelope that I need to sign as if I built it myself, and then send it. So all of this mechanism, I don't think, is going to be supported by clients. It's possible to do, if you for clients, and you do this, and such a market, develops. It's something that we cannot prevent.

Dima Gusakov: Okay, and why don't we just take one step forward and somehow validate that there is a transaction with like to fee recipient with the corresponding EL payment so that this value would finally become something.

Potuz: That's.

Dima Gusakov: For me.

Potuz: That makes it just too complicated for no reason. And it's also attackable because there could be a transaction and there could be like two. We could validate, for example, on the EL that the balance on the fee recipient was increased, but then the transaction itself on the builder could be involved, could be taken from several sources. Someone could actually send money to the fee recipient, like making the balance increase in a complicated manner. This adds a lot of complexity and interactions between the CL and the EL that seems completely unnecessary. If you are an involved player and you really care about validating this, I presume that you could do this off-chain.

Dima Gusakov: Okay, gotcha. Thank you.

Parithosh Jayanthi: Okay, thanks. Any other follow-up questions for the topic? Okay, I guess next step would be, potuz passing the document which defines how their, How the circuit breaker would look, and probably other clients having this documented somewhere would also help, so that we can use that as a source for our testing. We definitely want to individually test that every client circuit breaker actually works. Anything else related to Glamsterdam that people want to talk about? Okay, Relating to Hegota, there was no strict topic present in the agenda today, but I did want to mention that the Hegota non-headliner window would be closing on the 6th of August. There's already been announced on ACDE last week, so I just wanted to announce it on ACDC as well. We're gonna follow the same process.

So if you have some EIPs that are non-headliners, and you want them to go into Hagotah, then please propose it by August 6th. That being said, there was one more topic on the agenda. Pooja, do you want to, present the EIPs that you had? I think Pooja wanted to update the status of a lot of EIPs, and she had a few topics. Let's say maybe, like, 5 minutes allocated for this?

Pooja Ranjan: Sounds good. Thank you so much, Paritosh, for the opportunity. So I'm back with some of the housekeeping items. I have added the detail in list in the agenda, sharing the link right here. People may please take a look at the PRs that has been created to move the EIPs in Glamsterdam upgrade, which are currently showing in draft status. As we are preparing for more public testnet, we would want to see them in last call, but the first step is to move all these proposals to the review status. So, some of the PRs are already closed. We received approval from authors, and it was possible to make it close, but we are still waiting on approval. For rest of the PRs, please take a look.

other than that, I wanted to bring up a few other important point, which is with respect to eip, 7, 7, 2, 3. The other day we had a meeting of Eip where we discuss some of the processes around network upgrade eips and things like that, and it was highlighted that the proposal 7, 7, 2, 3. may not be the best at the present form. It may accept some of the changes, specification changes, that can make it good as a canonical reference for all future upgrades. I have already shared a PR with respect to the, terminology explanation about stage and status. But there are a couple of other points that we would like to mention here, which was already discussed in the Eip IP meeting, and editors feels like these are the required correction, and we should perhaps do that.

So the 1st correction that we discussed was about the the time period for Dfi. The proposal suggests that Dfi should be removed from the Meta Eep of an upgrade when the Eep is moving to the last call. However, with the discussion shared here in this link. It seems like the better status to move DFI out of the proposal is, when it is moving into review status, because, no matter what happens, there would be at least one Dfi proposal which will be there in the draft status, and our bot does not allow to move any eip if it has one of the required proposal in the less status. That means, if it is moving to review, if it is in draft, even if it is not required, it is mentioned in the eip. It will not be allowing that. So the proposal here is to update eip 7, 7, 2, 3, to clarify dfi process. And what is the best

time for it to be moved into review status. For that, I have already created a PR. If there is a consensus right here, we can perhaps make use of it. The other thing was, like, We are mentioning… PFI, CFI, DFI for all the EIPs which are being considered in the upgrade. However, EIP 7723 suggests that the statuses… the network stage should only be applicable to core EIP. So, that was another important aspect that needs to be considered, and if people agree, we may have to go back and update. The Glamsterdam Meta-E, Pectra, and Fusaka Meta-E. That's not a big deal, those are header formatting changes that we may need to require. We are not removing any EIP from there. We will still keep the other EIP section, but we would want to have the proper header, so we follow what is recommended in EIP7723.

So that's with respect to eip 7, 7, 2, 3. There is one other proposal meta-e for, Glamsterdam. Appier is up to update the Glamsterdam proposal to move all these eips into the right network upgrade stage. In response to Tony's comment on EIP, 7773, and the pr number is 1, 1, 8, 5, 3. I'm gonna just post it right over here for reference. we can move most of the proposal into SFI, and to do that, I would just need clarity from testing team to understand that the DevNet 7 specs that we see in the list is valid, and that is the the only list that should be referred for the Meta-EAP. Currently, I see 22 EIPs in this table that is there, but in my original proposal, we had the 10, sorry.

10 plus 11 plus 5. That means 26 proposals. So there could be 4 proposals which may have been dfied because my original Pr. Was 2 weeks ago, so I'm open to go back and fix it, but just need the clarity from the team that The Devnet 7 spec list is up to date, and that's what should reflect on Meta Eep. Yeah, I'm gonna take a pause here if anyone has any question that I can answer, or any, yeah, recommendation on these changes, please.

Parithosh Jayanthi: For the last one, I can clarify that the .NET 7 page is accurate, but, it would be good to know exactly which link you're referring to. Yes, the ETH PandaOps one should be active, but it would be nice if both the specs team, if the specs team could have a look and confirm this from their view as well. And to, there's a comment from Nixo, and I agree as well, I think defining what, when DFI gets removed is a good idea, so we should do that as well.

Pooja Ranjan: So for that, we already have a PR added. I mean, I have added it here in the agenda itself. So kindly take a look at that PR and we can address it over there because it would require author's approval in order to get this thing merged. I'm sharing the link here for reference. And for updating the Meta EEP with the PR11853, I'm currently going to refer the DevNet7 list that you have shared. If anything is missing, please someone let me know, and I will update it. Or if you are updating the HackMD file? Yeah, just give me a heads up and we can update it accordingly. So that's all on these housekeeping items.

Parithosh Jayanthi: Perfect. Thank you so much. I think that was also the last item on the agenda, so does, as a last call, does anyone have any topic they want to bring up today? Okay, if not, then thank you everyone for coming and hope you have a nice week.

Potuz: See you guys.

Pooja Ranjan: Thanks, all.

Parithosh Jayanthi: Team.

Sam Jernigan: Bye.

Justin Traglia: Everyone.

Toni Wahrstätter: Thank you. Bye bye.

Marius van der Wijden: Bye.

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