ePBS Breakout #25

Transcript

Justin Traglia: Hello, y'all. How's it going?

Pooja Ranjan: Hey, Justin. Good, good. So, we are pre-streaming right now. Let us know whenever we are ready to move over the stream. After 14, of course.

Justin Traglia: Okay, will do. I'm gonna go ahead and share my screen in preparation for the call.

Pooja Ranjan: Sounds good.

Justin Traglia: Good morning, Lance.

Lin Oshitani: Hi, good morning. Can you hear me?

Justin Traglia: Yep, can hear you just fine.

Lin Oshitani: P.

Justin Traglia: Good morning, POTUS.

Potuz: Hello, hello.

Lin Oshitani: Hey.

Justin Traglia: Good morning, Terrence. We'll get started here in, like, 2 minutes. Good morning When you go.

Nico Flaig: Hey.

Justin Traglia: Good morning, everyone. Just a couple more minutes. Good morning, Mehdi, Sophia, and Salius.

Mehdi Aouadi: Hi, guys.

Saulius Grigaitis: Bye, guys.

Justin Traglia: One more minute, and we'll get started. All right, let's kick it off, I guess. Hello everyone, welcome to EPBS Breakout Room Call 25. Oh, I'm sorry. Thank you, Fija. I'll restart. Hi everyone, welcome to EPBS Breakout Call 25. Lots of stuff to talk about today, so let's jump right in. I'll quickly go over some of the… or just, like, mention that there are some open PRs that we should probably Try to get merged soon. a couple of testing PRs and a PR from NC.

I can discuss that with POTUS and NC later. And then there are two to-do items, for anyone who wants to pick those up. So just removing some tests which were no longer relevant in GOS, and adding some asserts that were missing, that Terrence pointed out. There haven't really been that much spec work this week, just one small PR merged. I'm guessing client teams are very busy working on their implementations. And then let's talk on that. Anyone from PRISM available to give us a status update on their implementation for DevNet Zero?

Terence Tsao: So we have a bunch of open PRs, and we're not gonna merge them until we have a stable Fusaka release, which is out, should be unscheduled. today, so… which means we want to see how it goes over the weekend, and on Monday, we can start merging them. In terms of open PR, I… we have implemented most of them… most… actually, everything in the Beacon chain.md, nothing else on validator for choice and P2P side, just the Beacon chain MD. And they are all passing spec tests, so that's good. Basically, the existing SPAC test that we have. And, I guess maybe, like, that's the update, but I would like to hear from other client teams, like. what other SPAT tests are we… are you guys passing today? Because I'm passing everything in EPA processing, SSE static, and block operation. I'm wondering if there's, something else that I can be passing, which I am not trying.

And today, so yeah, I'm curious to see what other spat tests people are passing.

Justin Traglia: Stefan, I think you mentioned that TechQu was passing, like, a lot of other tests. Is there anything else that they should be testing?

Stefan Bratanov: Yeah, hi. Yeah, I think we passed all the references apart from Fork Choice. Yeah, all the operations, like block cursing, exhibition sailor Pursing. The bid processing. Yeah, I think that's pretty much everything there's linked. Okay.

Terence Tsao: Why would you feel so strong? That's true.

Stefan Bratanov: Yeah, there are no touches.

Terence Tsao: Thank you. Thank you.

Justin Traglia: Before, we could move on to the other client, Terrence, how are you feeling about, end of October DevNet Zero launch? Is this feel unrealistic to you?

Terence Tsao: I feel it's a little rushed, I mean, like, I'm not saying it's impossible, but it's just rushed, because, yeah, I don't know.

Justin Traglia: Okay.

Terence Tsao: Yeah.

Justin Traglia: Yeah, I guess we have a few more weeks. Alright, let's move on to the next client. Is there anyone here from Lighthouse who can give an update? I'm scanning the member list, I don't see anyone. Okay. Let's move on to Teku, then. Anyone from TechQu willing to give a status implementation update?

Stefan Bratanov: Yeah, sure, I can give it. Yeah, we haven't done that much work as far apart from passing the reference tests. Just a little bit of plumbing here and there. Yeah, not that much money. But, yeah, I think over the next few weeks, we'll… I mean, our work would be easier, given that we've done, I mean, Make things easier.

Justin Traglia: Okay.

Stefan Bratanov: Nothing major, no.

Justin Traglia: And how are you feeling about the end of October artificial deadline?

Stefan Bratanov: I just don't feel it's too realistic. But, yeah, let's say again in a couple of weeks. I… I'm not very confident in the order.

Justin Traglia: Thank you. Onskir says end of October might be nice to not get into DeafConnect-related rush. Not sure how many people here will be attending TEF Connect. Yeah, that's fair. Yeah. Potus, what's up?

Potuz: I think it's… it's kind of hard to… think about end of October, given that ACD decided that we're gonna make a decision on whether to split or not the CIP by October, like, a week from now. So that means that we can't really realistically merge anything on our main branches if we need to, like… splitting this thing is not that it's just removing part of code, it means changing it completely. So, it's… it's kind of crazy to start to merge things when there's no decision that is going to be made until a week from now. Which is already going to be about, like, 17th of October.

Justin Traglia: Yeah, that's fair. Okay, we can discuss that more, I guess, after the trusted… trustless payments discussion. Is there anyone here from Nimbus that's willing to give an update? I don't think I see Ignis or Terzak. Lodestar? Nico?

Nico Flaig: We have some work in progress on the state transition code. I don't think it's passing reference tests yet. But we are at least passing SSC static tests, but that's about it.

Justin Traglia: Okay. Thank you. And, lastly, Grandean, Salius, can you give us a status update?

Saulius Grigaitis: Yeah, so we started to work on that, however, I think we are… Still far from, from the… from a solid… relatively solid implementation that could interop with others, so… so yeah, we started to work on that, and also there is, Subha Sish from, from fellowship program, which I think he is on the chat, he maybe can give some access, some update on, on, on the things that he did.

Subhasish | Grandine(EPF): Yeah, so, majorly, I think, there are open PRs on, peer-to-peer interface areas, so I think, this PR on, the newer topic support, on the, lib P2P side, and, The blocker production code is, sort of ready, but it's, not yet… passing tests, I guess, all the tests, and, we are having some, discussions around Fork Choice.B. We're having some, actual code, I think, around, end of next week, I guess. So, yeah, that's pretty much it.

Justin Traglia: Cool, thank you for the update. And then let's follow up, or follow up back, jump back to Lighthouse. Shane?

Shane Moore: Hey guys, yeah, on my end, I did a lot of these stuff around PTP, like, getting, pillows by… Then by range, but the stuff in the validator client, they'd isolated over there, so just to be able to request, like, from a self-editing perspective, a block, and be able to, send it back, and also for teaching outloop, request and send back as well. We haven't started on anything related to testing. A big effort we want to handle is separation of payload processing. It's gonna be, like, a pretty good refactor for us, and I think that's gonna take some time. But, yeah, that's our update for now.

Justin Traglia: Great, thank you. Anything else that clients would like to discuss regarding implementations for DevNet Zero before we move on to the next topic? Such as blockers, concerns… Anything like that? Yep, Otis?

Potuz: There's a request from someone from Grandin, on Discord now, and I've seen this request before, I think probably from Stefan. Which is about, adding the slot to the sidecars. Even though it's not necessary, it might be good for implementers, and the problem of not deciding on this is that this changes as a Z tests. I'm not sure how bad is it to add this later, or to add it now. Yeah, I don't know. I don't know if we need to make a decision about this today, or if we need to make a… or if we can delay that decision for longer, but this is going to bite us eventually.

Justin Traglia: Hmm. Stefan, do you have any updates on this? Or, like, have you determined whether or not it's… Necessary to have.

Stefan Bratanov: Everyone.

Saulius Grigaitis: Goodbye.

Stefan Bratanov: Yeah, I saw the comment from Brandy, and yeah, it's exactly the same thing that we have in our code. So… Yeah, if we don't have that, then… Any data falling sidecars wouldn't be… receipts and RPC. I mean, we'll get an exception. Unless we record them, I think.

Justin Traglia: Okay, and Salius, do you agree with that, or…

Saulius Grigaitis: Yeah, so my suggestion would be to add the slot number and forget this issue. I mean, I really don't see why we cannot add it. this, So, we would save a huge, factoring, huge changes in the client by bringing, back this, It's a lot better.

Justin Traglia: Would you argue that we should do this sort of, like, retroactively, so that this would be, the spec for DevNet Zero.

Saulius Grigaitis: We are not sure that we will be able to participate in DevNet Zero, But, I mean, for us, it would be better if we do that as soon as possible. So, I mean… it seems that the option would be to add it later, after DevNet0, is that correct?

Justin Traglia: I believe that is an option, POTUST?

Potuz: So, this is just a bureaucratic statement for me. I completely agree that adding the slot is fine, and it might help us. It might help Prism as well. But… so the issue is about, like, which release to target for Definite Zero. I like it better that we've already frozen that, the spec release so that we can actually aim for that. And, a way of, like, making safe is that we are any ways going to, try to attack DevNet Zero without any blobs. So I suspect that it doesn't matter if we include it or not for the DevNet. It's going to be the same, the same because we are targeting not having any blobs for the DevNet, in any case.

So, if that's the case, then we can… we can add it, but then, not include it in the release that is considered for DevNet Zero. Now, if there's no problem in adding it now, and changing the test, and changing everything, let's go ahead and add it. It's not a problem to add it. It's… there's not even an assert on the slot. If we add it, we're going to have to add an assert that the become block root Corresponds to a block for that slot.

Justin Traglia: Okay. I like this plan. If I understood it correctly, we keep DevNet Zero specs the same as they are now. There would be no blobs for DevNet0. We make a PR… with the add slot to Datacom sidecar, and then we would do that for, like, DevNet 1 or something. Right. Yep. Okay, sounds good. So yeah, let's make a PR for that, and we'll get it merged. Anything else? Any other concerns? Okay, let's move on to the next section, then, trusted payments, or trusted or trustless payments. Lynn, would you like to get us started on this?

Lin Oshitani: Yeah, yeah, sure. So, I already talked to my points. not ACTC, but I think there's, like, 3 things that… we should kind of decide upon. Like, one is, like, should we have process payments in the current EAP in the first place? Can we split? And… Yeah, I've asked some people in the ecosystem to join this call, too, if they have any wishes they want to raise. Yeah, the second point is that if we're gonna have it, like, what does it look like? I think, Bottas, you were mentioning some doubts around the current design, that it can be simplified. like, what's the exact… if we're gonna have it, like, what does it look like? And the third point is…

Like. I think we all agree that we should have off-protocol bids to be supported, like, what does that look like? How should it be standardized? I think Terrence, you already started some write-ups, thanks for that, I think… That kind of things. is to be discussed, and for the first point, like, the only point that I want to reiterate here is that I think we're kind of underestimating the coordination complexity that arises from this, like, how do we get it right? Especially if we're, like, having doubts around the design at this point. like, how do we be sure that everyone's happy about it? How do we involve them? Like, for example, like, in this call, I've asked some people to join, but…

we'll probably have to keep on doing that if we want to get it right, and the coordination, like, because I guess you guys also want to… a lot of things to do in the implementation side, we don't want to hijack this call too much, so… That kind of coordination, and… is required, and I think it's kind of underestimated so far. But yeah, if we're gonna do it, we should do it right, so, like, we need to. Be sure that everyone's happy. So, that's my only point that I wanted to add there. If anyone wants to… talk about their point on any of these points, I'm… We'll just… Yeah, feel free to. Peak up, or… yeah.

Justin Traglia: Potus or Terrence, or anyone that… Wants to talk. What are your opinions?

Potuz: I've made clear my point here. It's, one thing is to argue for trusted payments. Which the IP already considers. The IP already allows for this, and we have very good designs for this. So we… we do have trusted payments of protocol. I mean, trusted payments. We do have that. We do have support for that. That was very clear even from the beginning. Now, Removing trustless payments, that's a very different story, and I haven't seen a single argument for it. Now, if we are going to go that route of removing trustless payments. I think we need to analyze practically what are our options, to remove trustless payments. We, well… We need to… we need to decide how we're gonna do this, because it's still not trivial.

By removing trustless payments, how the sign-in is going to happen, the builders will still need to be staked. Because someone needs to sign them. If the builders are not staked, then we need to redesign how MedBoost is going to work, how many back and forths are going to be happening. I mean, the whole specification needs to be done if we actually need to remove… if we want to remove the staked builders from the picture. So, I think people are just… separating not separating, but, like, they are putting in the same bag trustless payments with stake builders, and they are different. The staked building is used for the separation of the payload by the bid. So if we keep stake builders, then it's very simple.

If we don't keep them, well, I want to see a design. I want to see a specification, I want to see a PIP, I want to see the whole thing, the whole package. Like. hand-waving our ways around how the design of the IP will be is one thing. The other thing is actually writing the specs.

Justin Traglia: On-screen?

Ansgar Dietrichs: Yeah, I just wanted to say, I mean, I think these are fair concerns by Potos. I think that, in principle… so here's the case, the somewhat uninformed case, I must… I'm clear, I haven't written an alternative spec, or even, like, have looked very, very closely to what that would look like. Again, my… what I'm thinking of is really just, like, yeah, get a version of… a base version of EPBS that would be without unconditional payments and without state builders, but again, put us as raising concerns that that might not actually be so easy to facilitate, so… that point taken. The reason why I personally would like to see, in a way, base EPBS in just that raw form is that

I still think we should then discuss, do we want this package of stake builders' unconditional payments, and in what form in Glamsterdam? But I feel like that should go through more the general EAP process, because… and here's my argument, basically, like, the reason why I would at least want to consider not having it in Glamsterdam at all is that I feel like it adds extra implementation complexity, just compared to today, right? Like, just this entire CL side. builder balance, build a staking mechanism is just… it's just pretty novel, and so… so there's significant extra overhead, and I… personally think that we are already at the point where EPBS is going to probably be the biggest chunk of the biggest feature in Amsterdam, and so it will take the longest time. I… if we really want to add more things on the CR side, I personally would rather spend our little remaining room, basically, on something like fossil than

stake builders unconditional payments, but at least the point… point being is I feel like that kind of conversation, even if we end up deciding to basically go with unconditional payments. I would much rather have that just as part of the normal EIP discussion process, rather than basically having it baked in with EPPS. But again, all of this is just assuming that we can come up very quickly with inspect that removes these elements, and that actually then does look significantly simpler. If it's not simpler to remove, then all of these arguments are moot.

Justin Traglia: Potus, would you like to respond?

Potuz: Not really, it's already in the chat. I mean, we've gone over this for, like, 2 years. When people actually went through the headliners for the fork already knew what it was. This issue of trustless payments or not is raised… Now, after… after a while, not because of complexity on the protocol, but because of the need to have trusted payments. This is nothing to do with the extra complexity that comes from having the mechanism to actually be paid in a trustless manner. the staking of the builders and all of this is already part of the separation of the payload and the block, and now it sort of, like, seems that people are trying to backdoor a way into, like, removing the whole discussion that we already had on SED and choosing an SFI, an SFI EIP. I find it's kind of weird. It's…

Yeah, I mean, the argument is we want trusted payments, okay, fine, we already have this, and then we're gonna use that argument to remove an SFI, change completely, and gut the whole EIP.

Lin Oshitani: So… Yeah, like, I do see that it's, like, really… Late in the process, all that, but my impression is that, like, the whole SFI was more around like, it was advertised as a pipelining solution, and, like, a lot of this question was around that, like, should we do this discussion?

Potuz: Stake Builders was a solution to pipelining, that stake builders was a way of pipelining.

Lin Oshitani: That's… that's one question I had. So, you think that stake builders is a requirement for pipelining, is that correct?

Potuz: In DCIP, yes.

Lin Oshitani: But, like, in principle.

Potuz: In principle, no, I haven't seen a single design. This CIP was specified 2 years ago.

Lin Oshitani: Yes.

Potuz: And now people are arguing that, no, we don't want to have this because there's no philosophical… there's no proof, there's no theorem that we need to have stakebuilders, but people are not coming up with a spec! And after we've specified an EIP, people are trying to come up with yet another design. We've already debunked many of them. Since Berlin, I had to analyze a new one every week. At some point, this has to stop people.

Lin Oshitani: Yeah, bleep. Let's see your, like… Yeah, concerns around that, but… Like, is it not as simple as just… Unlimited to a header. At, like, the attestation time, and… That's it, like, you just leave everything off.

Potuz: I can argue this here, but I think it doesn't belong in this meeting, but it's not, because if you commit to a header, who's gonna sign it? You cannot just have a BLS signature from someone that is random, that's a DOS, So you do need to have a BLS signature from someone that is already in the state. So someone that you already know is BLS signature, so that you validate the signature. And to have this, you need to put it in the state, and to put it in the state, then it needs to be state, at least one ETH or something, so that it's not a DOS on the beacon state. We've already gone over all of these things, and people have been trying to… have tried to come up with the science, and… and they are reinventing the wheel, because they're coming late to a discussion of problems that we've already tried to solve two years ago.

Lin Oshitani: So it's not, like… I was thinking.

Potuz: And we documented all of this, by the way, very well documented over 2 years ago.

Lin Oshitani: So it doesn't work if Sonner's a proposer, like, as we have right now.

Potuz: It would work if the signer is a proposer, but then you need to redesign the whole mechanism of MapBoost to actually have the builder protected from unbundling.

Lin Oshitani: Okay, I see. Yeah, that's probably the part that I'm getting, but yes, it's not. be… Let's go separately. Yeah, Score, you have your hand up?

Ansgar Dietrichs: Yeah, I mean, I just… Why don't say we should… just split the conversation into two separate concerns. One is the spec, you know, like, as Potus was saying, like, the… is this even viable? Yes or no? The other concern is the governance process. I actually am somewhat agnostic on the spec side. Potus might be right, I still don't quite understand why, but… at the same time, obviously, Protos is much, much, much dependent. On the governance side, though, I think I disagree with you, Protos, because Yes. Obviously, it's not ideal to, like, basically, like, after accepting it, kind of changing, like. demanding, quote-unquote, to change… I don't think it's a demand, just, like, an ask to change the scope a bit. I think it's coming from this place that… I also went back, I read the justifications for all… from all the client teams that supported EPBS when we had this roundup of, like, who's in favor, who's not in favor for the headliner, and…

I have to look at the list again, but it's, like, out of the 10 clients, basically, it was, like, 6, 7 clients explicitly saying that this is… their motivation is coming from scaling, for scaling reasons, primarily, and then 2 clients just not specifying explicitly, so… It's very much basically the mandate for the headliner is using EPBS for scaling, and then unconditional payments, and the state builder and whatnot. Unless it's, again, necessary for the spec, which is your argument, but that's a separate argument from the governance process point of view. It's basically just, like, an additional, like, staking-related feature, like, an additional, like, build-up, like, basically, like, Ethereum improvement feature, but then it should just be a non-headliner EIP to express that. That's kind of… so, governance-wise, I think I disagree with you spec-wise. I think it's possible you're right.

Justin Traglia: Potus?

Potuz: Once more, two things. The trustless payments has Very little addition to the spec. from the… scaling EIP. The scaling EIP already has an in-protocol signer, which is the builder, it already has the separation, the payload, the four-choice changes, it already has essentially everything. The trustless payments addition originally actually was incredibly simple, it was just a balance change on the validators. It got slightly more complicated because Lido requested it. But that's it. So it's a min… the trustless payment part is a minor thing. What clients voted for, which was the scaling IP, already includes the in-protocol builder that is already acknowledged in the beacon state. This is regardless of trusted payment or not. This is what we need for the pipelining.

And this was already in the IP. The people that voted for this already knew that it was in the IP for this. Second. we are going to be… continue using this argument that, this EIP is more complicated, and we should delay it because… or even take it out of Glamsterdam, because it's going to be the one that is going to delay it. And yes, of course, it's going to delay it if we keep arguing and we keep discussing whether or not this EIP should even be included. I mean, after SFI in it, after all of what we've done, now we want to go back, put it back on the discussion, whether or not we're going to include it or not, and yes, of course, we're not going to merge anything, and we are going to delay, of course. Clearly, we are going to delay.

So it's… I find it fascinating that this thing… these kind of things are happening. And I find it fascinating by people that haven't even read the spec to not realize that trusted payments were already covered, that trustless payments have very little to do in this picture with the builder being staked or not. Trustless payments only adds, one of these, builders' withdrawals and one of these, pending payments. If we went with, balance transfers, we could just remove some of them, but that's it. It's just a minor thing compared to the actual EIP. And state builders, well, that's the way we have it specified. There's no other specification.

Justin Traglia: Terrence.

Terence Tsao: Right, so I guess I'll chime in a few points, just, like, from reading the situation from the last few months. I think, in general, we're looking at these two designs, right? We're comparing our EPBS with this base version of EPBS, which people claim to be simpler, but I think that's the wrong way to look at this. I think it's basically our EPBS and another version of EPBS, which is not like a base version of EPBS, Because when you remove, like, this, like, the trust's payment and pending queue and stuff, it becomes a totally different design, which… we frankly don't have the vetted authority yet, right? So I don't think we can definitely ship that in glamster then, like, within, like.

mid-year of 2026, just because of… it's just so early to switch the design. So I've… so I think I would encourage people to look at this, like. EPBS version 1 versus EPBS version 2, but not, like, the base version of EPBS, because it's completely different. I think the other thing that, like, our current design also supports both, like, trusted and trustless payments. Right? The only difference is that, like, the builders needs to be staked, which, surprisingly, we talked to builders over the years, and they all seem okay with it, so I would love to see more feedback from the builder side on, like. basically, I would like to see them come out and to hear them say, like, they're not okay with this, because, yeah, I'm surprised to hear this one.

Justin Traglia: Lorenta?

Lorenzo: Hey, just, I guess we don't want to comment necessarily on the spec, because I think that would be outside, kind of, my realm, but let's say specifically on the stake builders… I do think that it's quite a change. Doesn't necessarily mean that it's gonna be, you know, too disruptive, or it's gonna destroy the market, but I do think it's quite a change, so we wrote an article on this, and how that might affect… let's say, builder competition, relay competition, and in general, I think the… There is a large, let's say, off-protocol market currently that's responsible for some 95% of the blocks in Ethereum. And I think that sometimes maybe this Market, is not as, let's say,

Taken into account when, when making protocol changes, so… I think it's just, just, I guess, a point.

Potuz: Lorenzo, when you said, quite a change, I assume that this is what you guys wrote, explaining that, the capital efficiency and, like, keeping track of depositing and payments on the CL, that that would be, quite complicated, right?

Lorenzo: Yeah, for example, yeah.

Potuz: Okay, which has… and also, there's this issue of, like, the… the risk that a builder would be taking by, like, putting up a bid, a very large bid, and they paying it up front if they… if they… for some reason, the payload doesn't get included, right?

Lorenzo: Yeah, or for… or just having, you know, enough balance to beat the… for blocks on the… Perfect. So…

Potuz: So, again, all of this… It's gone with just… Pain of protocol. Which might even be the default. For example, for Lido validators. And again, I want to stress this, because it seems to me that people don't have this clear here. If I am a node operator, and I just whitelist and say, I want to take a bid from Titan. And I don't care if it doesn't pay me. This is already allowed today, and the builder… and the proposer would actually get the bid. Titan will sign it. We still need Titan to be staked. Will it sign it? And we're gonna get the payment in exactly the same way that we get it today, on the EL side, on the address that we're specifying in the same way on the Builder API, and no changes are going to be on the side from Titan, nor on the side of the proposer that is receiving this payment.

So… I… I don't see how this could be invasive, nor very… a big change from the point of view of Titan, except the fact that you need to be staked That's 32 ETH. There's not going to be balance changes, because you're only going to be beating off protocol, I mean, if you want to go that route. And… that's it! No changes on any of the logistics, no changes on the risks, no changes on anything. So, for someone that doesn't want to go on the protocol side, and doesn't want to be bidding on the protocol side, and only wants to be sending bids on the off-protocol side, again, I don't see what is the change.

Lorenzo: Yeah, I guess my point was related just to Terrence's comments that whether billions having to be staked would be an issue. Obviously, if a builder doesn't have to be staked, then that would not be an issue. Assuming there is some of protocol, you know, bidding.

Potuz: Well…

Lorenzo: I would just… maybe, sorry, I would just… Yeah, sorry, I just wanted to add that some of the, I think, points that we mentioned are not necessarily related about Titan itself. Obviously, you know, Titan is a large builder. But there are also a number of other builders, and potentially new builders coming in, too. And if you have, you know, some builders who have just, direct access, that would, that would also not be ideal for competition.

Justin Traglia: at the end.

Lin Oshitani: Who… yeah. Like, I think… I do see that, like, trustless… trustful payments, or, like, off-vertical payments can be supported, and… My expectation is that's probably gonna be, like, the dominant usage, and… Which is… kind of okay, as in… like, there's not much disruption. It might also mean that we are having some complexity that's… Not gonna be used, but maybe that's okay. But, like, this is all under the assumption that it's going to be very, very easy to have off-road payments, like, you don't need off-work. all the clients will have support for it. It's just out of the box, like, just some configuration change, and you can just have the exact flow that you have right now.

I think that kind of support will be needed if we're gonna have it, to have trustless payments, and minimize disruption, and also minimize, like, the arguments that we're gonna need in this kind of calls. Like, as long as we have that. I think it'll be… And I think there was some, like… I think, like, in the past, like, week or so, like, in Discord. I think Blackboard does you? be much more supportive. Well, you were always supportive, probably, but, like, I think a lot of us were kind of… misunderstanding your point around removing the MedBoost. We thought it was removing off-protocol payments, but not the case, so… But I think the question now then would be, like, how much support will we have? Like, how much out-of-the-box support that's standardized around the clients will we have?

Justin Traglia: Notice.

Potuz: the very first time that I pitched EPBS on ACD, Danny Ryan was still running the meeting, and… I mentioned this, and Danny repeated it, just to clarify that that was the situation, because everyone that was opposing EPBS back then, that was 2 years ago, was opposing it on the ground that it would be bypassed. And Danny made the point of saying, this is not about forcing people to go the trustless route, this is about giving them the option. And I think it was very clear back then, that, already back then, that this was a thing. It was not about forcing people using something, it was about giving them the option. That was always my, my way of thinking about this. And I think we will, we have to. All clients, we specify it so that, so that

node operators that want to take trusted payments, they have to, and it's… I don't know, you've already been in the discussions, and I think it's kind of universally agreed that the easiest way to do this would be to get enough protocol bid on the builder API, And that's it. I just have clients allowing, by default, those off-protocol bids to be counted on whitelisted builders that they trust. That's a very simple configuration that everyone should use. What I would oppose, and adamantly oppose, and I would definitely not want to include this in PRISM, is a way of removing the trustless payments route. Because it's just a matter of safety. One of the biggest things that EPBS gives us is a way of having a pair builder circuit breaker, for example. I would not want to lose that. I would not want to lose the ability of having the P2P layer bids winning the auction, so that,

So that we can have a fallback mechanism which is over P2P, even especially so whenever proposers can no longer propose themselves. So I would oppose, and I would adamantly oppose, a way, a configuration, that removes the trustless payments. I'm totally fine with defaulting to trusted payments. I am totally fine with allowing node operators to prefer them. I am against removing the trustless route.

Lin Oshitani: We're removing… The trustless route, an employer thinking about the case where the proposer just Alex himself as a builder, and then just offered courses, like, completely.

Potuz: No, that's… no, removing the trusted rub will be… I don't take any bids unless it is from this builder that it's going to be only off protocol. So that, I, I, I, I, I don't like.

Lin Oshitani: For example, like, in the… like, proposals that Terminus had, like, you'll have a configuration file that configures, like, this builder is trusted, you have a boost. But if you only have trusted in that list, wouldn't you be kind of… Bypassing the trustless.

Potuz: No, the P2P stack is always… the P2P stack is always taken. Like, you can… I would be very against validators being able to stop the P2P stack from happening. You can boost the non-P2P one, and you can boost it, like, very largely, that's fine. But the thing is that there should always be a fallback in that if you don't get a bid from the trusted payment side, and for some reason you cannot propose, you should be able to take a bid from the B2P layer.

Lin Oshitani: Yeah, in principle, I do agree, but, like, operationally, for example, some node operators, they might have no idea how to handle like, these deal-side payments. And… It might have to go through, like, different accounting and all that. In that case, maybe they'll need some time. To actually, you know, Disable the trustless payment until they got ready. I think… one of the concerns around, like, that Lido was raising was that, like, they have to Like, upgrade their software to actually, like, do the accounting for the payment route.

Justin Traglia: Potus or Terrence, do you respond to that? Okay.

Potuz: I guess Lido can always boost the… I mean, there is an effective way of disabling the P2P stack in a sense. By boosting, very largely, your whitelisted builders. The problem is what happens when those guys… you boost yourself as a local builder, and you boost the whitelisted builders a lot. And then… even if no builder is giving you a bid, you will just still choose your local payload instead of the P2P stack payload.

Lin Oshitani: Yeah, that makes sense. So, yeah, my personal… standpoint right now is that, like, if we… kind of had a time machine to go back, I think. It would have been better if we had, like, two different EIPs and two different discussions, but I do see your point that it's kind of… Already very tied together, and… Hard to see, like, where we can actually separate. And… as long as, like, we have very, very good support, and you're already agreeing, so I think… That's very nice that, like, we have very good out-of-the-box support to block local payments. I think so. A lot of the concerns that the community had will be mitigated. Wondering if, like, Lido, I think someone from Lido is here, like, if you guys had anything that you guys…

Wanted to be snow. Is it okay to have trustless payment, but having, like, very good supportive payments?

Justin Traglia: Greg?

Greg K | Lido: Yeah, so… from lighter side, the important thing that I think was discussed with POTUS is to… as he said before, it was the withdrawal part, so that the, you know, the MEV records are not, sent directly in the SEL, but they are given in this, the recipient address on the execution layer via the withdrawal queue. So, yeah, since this is now incorporated in the specs, this kind, kinda… you know, avoids having to update the… our on-chain kind of, infrastructure, so that's a big thing, and I think this was discussed with, Bottus before I joined Light, and it's already settled, so that's fine. Yeah, then… I also talked in the algorithms last week. I do have the opinion that, you know, it could be two separate eaves for reasons that I already said, like, no, I think it's two quite different

conceptual topics, like the scalability part of the pipelining and the proposal builder separation. So, for me, it seems to me that it's kinda… many sorts at once, but, you know, I think it all boils down to what discussed also in the chat, and the claim of what was before. So, the main thing that is not 100% clear, I think, to everyone is that, this lack of stake builders is necessary either way, so… what's the main point of Portos that I think it's… it was not clear to me. It's not 100% clear to me until now, but I think, yeah, 2K is… well, I was not… Definitely so that this takes builder is necessary for the pipelining part, so this was not clear to me.

So, but yeah, so looking at the high level, it seems to me that those are kind of independent things. But, you know, yeah, as I said, like, so it seems to me more normal to separate, but, yeah, if there is another solution, then for, like, since we have these withdrawals. set, in the specification for Lido, yeah, that would be… Okay.

Justin Traglia: Thank you. Any response from POTUS or Lynn about that? Photos?

Potuz: Actually, yeah, so… This whole discussion is kind of very, very unfortunate, in a sense, because if… I mean, we had a system that was incredibly simple. to… to transfer, payments on the CL side. The system was… the builder pays, its balance is decreased, and the balance of the proposer is increased. And, yes, it needs to be churned, it will… definitely would look like, exactly like it is today, except that it won't hit the exit queue, and it won't hit the deposit churn. Now, this was changed by the explicit request of Lido, because they didn't want to change the… they didn't want to change their contracts, and this would make them change the contracts anyways, but…

But it would make their life easier. But if… had we known that Lido anyways would take only trusted payments, then I think we would have gone with the other system anyways, which is actually safer. Well, I don't know safer, but it is better from the UX perspective that it doesn't affect the churn. So now it's this very unfortunate situation in which we might actually want to go back to that system. The change doesn't seem to be too large. It's actually very minor, as far as I can see. We now have these builder payments that are put in the state in the case that the payload is not available, and we are going to check for those and epoch transition, and then we put a withdrawal

We just churned. And it's processed with process withdrawals later on. I think the only change that we need to do is to put, instead of a withdrawal, we need to put a transfer to be churned. It has to be churned, because we don't want to be in transfers fast. And, we would put a… instead of a withdrawal, a builder transfer, on a pa… on a… again, on a… on a slice, exactly as it is today, but instead of being process in process withdrawals, it would be processing… process builder transfers, and it would take its own churn. I think it's a very minor change to the current spec. So if… and it's something that people might want to, like, look into if we want to go that route.

So that we don't affect actual withdrawals and deposits and exits, and we just go back to the drawing board on this, because it's useless to have a system that was requested by Lido, but that Lido would not use it.

Greg K | Lido: Sorry, sorry about this, but I think it's kind of… there is some confusion here. I never said that Light is not gonna use it, so there's perhaps some confusion here. I never said that Light is not gonna use it. So, Leido requested this in order to have the option to use it, of course, right? So, perhaps there is here some misconception.

Potuz: No, so Lido will use trust… will use in-protocol payments, would support this.

Greg K | Lido: Yeah, I mean, we will be examining this, so it's not, lido never decided to not use it, yeah. So this is why the, kind of, the way receiving the payment is something important for later, right? If LATO didn't care about receiving a payment, then that wouldn't have been important for later, right? Wouldn't make sense, of course. So I guess there is some confusion here. So does it… is it clear now, or is there any more question on that?

Potuz: Not clear to me, because it's… if you're going to use this, then you are going to need to change your contracts anyways. If you go the trusted payments. mechanism, then there's no change on the contracts at all, as far as I can see, because it's exactly the same as what you have today now.

Greg K | Lido: Yeah, but also, in the… in the trustless way, it's important for, like, logos to receive the payments on the EL, like in this execution layer, what to have, and not have the consensus layer,

Potuz: Yeah, yeah, in the trustless… in the trustless side, right?

Greg K | Lido: Exactly, exactly. So this is settled. So, no, like, I think this should be clear, right?

Lin Oshitani: Yeah, I think it's clear. I think the point here is that if Lido is to use Trust Sustain, that's the requirement. But they haven't… still haven't decided whether to use it. Like, they need some more further investigation for that. Does that make sense? Yeah, put this, like, I think many people are kind of asking the same question, so maybe, you know, we don't have much time, it's still worth going over, like, why are staked builders required for pipelining. You mentioned that it's actually for protecting the builders.

Potuz: Well, I don't know, I don't have a specification, a full specification of how does it go. With, the proposer self-signing. And the original… yes, so that's it. Like, there's no full specification of how the proposal self-signs. It requires a bunch of backs and forths. And even to… to actually, like, broadcast the payload later. The… there's… it requires another back and forth. Like, the implementation actually is actually much more complicated, too, because you see that the payload itself It's again signed by the proposer, so there has to be a communication between the proposer and the builder. When you're about to propose, and then there has to be another communication between the proposer and the builder when you're about to submit the payload.

And,

Lin Oshitani: Isn't that what the relays do right now? Like, kind of? Like, they sit in the middle,

Potuz: Yeah, so… and Francesco is saying something, that the builder can sign it, but it doesn't need to be staked. Yeah, so… and then the problem with that, I think it's just a DOS, right? So, I don't under… we need to have a list of signatures. yeah. That's… that's right. It's not even clear what the signature… well, the signature is useful for… for validation. We're propagating an object that we need to know from with whom it's coming. On the P2P side, otherwise you can be DOSED. So that's why the signature comes in the payload. And now the question is whether or not we can have signatures from people that are not in the beacon state. That… yeah, I do not know about the safety of that. That's why we had them. Now, of course,

If we… since we're saying that the That most of the… most of the payments will be trusted anyways, and there's no reason for someone that is going to be providing trusted, trusted bids, there's no reason to be staked for 32 ETH, because anyways, most of your bids are going to be on the trusted side. So, in principle, we could have builders being staked by very little, so that it's just a deterrent from DOSing the… the beacon state, but but that will require more changes on the protocol side, so that… it's absolutely fine to have builders that are staked for very little. But I think that would require changes on the beacon state that are, that are worse.

For example, we could make them not validators, and being staked very little. And that's easy. But if we make them validators and being staked very little, so that their money is not sitting them just losing money, then it becomes much harder. So, I don't know. I mean, all of this… these are design decisions, it's just that it's… it's a specification that no one did. I'm going back on the drawboard now, to, like, go back and specify all of this again. That is a big change.

Lin Oshitani: Yeah, I guess, like, the BIM protocol part… imagine wouldn't be too much of a change, but, like, have support for the MEP boost, and… But maybe there's… Oh, I'm not sure, but yeah. I do agree that it's… it is, like… Don't have that much time.

Justin Traglia: Yeah, we don't really have that much time left in a call. 5 more minutes. I don't think that we should make a decision on this today. I think we should save the decision making for next week's ACDC call, which Stokes will be leading. Okay, let's continue talking about that, then. For the final agenda item, Mehdi, are you available to talk about the attestation container? Yeah, sure.

Mehdi Aouadi: Yeah, sure. So, yeah, I, I basically was working on the gossip rules, for Gloas, and, when I reached the attestation stage, I noticed that, the attestation data index is now used for, to signal the payload status. And, we used to force it and hardcode it to zero in Electra, but, it's not the case now. So yeah, I was a little bit worried about that, because in my understanding, that would require a new container. To basically be able to… to differentiate the attestations and interpret the index field accordingly. So yeah, and in my understanding, too, that would have some side effects, basically, on the attestation data creation API. well, the gossip rules and the attestation data creation. So, yeah, I wanted to raise this concern to have some feedback and see if other people have

I came across this, this issue, and yeah.

Potuz: I'm sorry, I missed the issue. What is the issue, Mary? That we're using the index to, like, signal the payload?

Mehdi Aouadi: Yeah, I mean that the index in Electra, we were sure that the index was set to zero, and we was, for example, in TECO implementation, we were using that to check if it's an Elektra attestation, for example.

Potuz: And now, now we're gonna have index different than zero, and…

Mehdi Aouadi: Yeah, yeah, that's the issue. And I was even thinking about the fork boundaries, when we move from Electra to GLAS, we could still have… we'll be still receiving some electra… a mix of Electra and the GLOAS attestations, and we need to differentiate, them, so yeah, that could be tricky, and I'm a little bit worried about that, so yeah.

Potuz: Yeah, we'll need to look at this, too. I think we don't distinguish because of this. But I'm not sure.

Mehdi Aouadi: I mean, we could add some workarounds and try to do some hacky workarounds, but… in my opinion, it would be really better if we add the spec change to that. Otherwise, we already introduced some… a lot of workarounds with the EIP attestation, and I really don't want to see some other hacky ways to handle that. For the next fork, so, yeah.

Justin Traglia: What would the spec change look like exactly? Would there just be a new container?

Mehdi Aouadi: Yeah, I think it would be a new container, even though it would be exactly the same data structure. The only difference would be, like, a conceptual difference, basically how we interpret the index field. Because we, in Elektra. We set, explicitly in the spec that the index field would be set to zero, And, yeah.

Justin Traglia: Yeah, we should consider how difficult this will be for other clients as well. Like Terrence said, that adding a new access station container in Prism is… Pain in the butt.

Mehdi Aouadi: When tech would go back.

Justin Traglia: Yeah, I understand your concern, though. Let's discuss this more on Discord, and…

Mehdi Aouadi: Yeah, sure.

Justin Traglia: Maybe if you could make a PR, just as, like, a proposal that we could discuss, that would be great. Sure.

Mehdi Aouadi: Okay, sure, let's do it like that.

Justin Traglia: Okay. We're pretty much out of time. Is there anything anyone would like to discuss before we end the call? Okay, thank you everyone for joining. I'll be sure to post a recap soon. I'll see you all in 2 weeks.

Potuz: Thank you, thank you.

Mehdi Aouadi: Thank you, bye.

Justin Traglia: Yep.

Stefan Bratanov: Alright.

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