Justin Traglia:All right, let's kick it off, I guess. Hello everyone, welcome to EPBS Breakout Room Call 25.
Transcript
Justin Traglia: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.
Justin Traglia:I'll quickly go over some of the… or just, like, mention that there are some open PRs that we should probably
Justin Traglia:Try to get merged soon.
Justin Traglia:a couple of testing PRs and a PR from NC.
Justin Traglia:I can discuss that with POTUS and NC later.
Justin Traglia:And then there are two to-do items, for anyone who wants to pick those up.
Justin Traglia:So just removing some tests which were no longer relevant in GOS, and adding some asserts that were missing, that Terrence pointed out.
Justin Traglia:There haven't really been that much spec work this week, just one small PR merged.
Justin Traglia:I'm guessing client teams are very busy working on their implementations.
Justin Traglia:And then let's talk on that. Anyone from PRISM available to give us a status update on their implementation for DevNet Zero?
terence: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.
terence: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
terence: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.
terence:And they are all passing spec tests, so that's good. Basically, the existing SPAC test that we have.
terence:And, I guess maybe, like, that's the update, but I would like to hear from other client teams, like.
terence: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.
terence: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.
Stefan Bratanov:Yeah, all the operations, like block cursing, exhibition sailor Pursing.
Stefan Bratanov:The bid processing.
Stefan Bratanov:Yeah, I think that's pretty much everything there's linked.
Stefan Bratanov:Okay.
terence:Why would you feel so strong?
terence:That's true.
Stefan Bratanov:Yeah, there are no touches.
terence:Thank you.
terence: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: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:Yeah.
Justin Traglia:Yeah, I guess we have a few more weeks.
Justin Traglia:Alright, let's move on to the next client. Is there anyone here from Lighthouse who can give an update?
Justin Traglia:I'm scanning the member list, I don't see anyone.
Justin Traglia: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.
Stefan Bratanov:Just a little bit of plumbing here and there.
Stefan Bratanov:Yeah, not that much money.
Stefan Bratanov:But, yeah, I think over the next few weeks, we'll…
Stefan Bratanov: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.
Stefan Bratanov:But, yeah, let's say again in a couple of weeks. I…
Stefan Bratanov:I'm not very confident in the order.
Justin Traglia:Thank you.
Justin Traglia:Onskir says end of October might be nice to not get into DeafConnect-related rush.
Justin Traglia:Not sure how many people here will be attending TEF Connect. Yeah, that's fair.
Justin Traglia:Yeah.
Justin Traglia:Potus, what's up?
potuz:I think it's… it's kind of hard to…
potuz: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.
potuz: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.
potuz: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.
potuz:Which is already going to be about, like, 17th of October.
Justin Traglia:Yeah, that's fair.
Justin Traglia:Okay, we can discuss that more, I guess, after the trusted… trustless payments discussion.
Justin Traglia:Is there anyone here from Nimbus that's willing to give an update?
Justin Traglia:I don't think I see Ignis or Terzak.
Justin Traglia:Lodestar? Nico?
nflaig:We have some work in progress on the state transition code. I don't think it's passing reference tests yet.
nflaig:But we are at least passing SSC static tests, but that's about it.
Justin Traglia:Okay.
Justin Traglia:Thank you. And, lastly, Grandean, Salius, can you give us a status update?
Saulius Grigaitis | Grandine:Yeah, so we started to work on that, however, I think we are…
Saulius Grigaitis | Grandine:Still far from, from the…
Saulius Grigaitis | Grandine: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,
Saulius Grigaitis | Grandine: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,
Subhasish | Grandine(EPF):The blocker production code is, sort of ready, but it's, not yet…
Subhasish | Grandine(EPF):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.
Justin Traglia: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…
Shane Moore: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.
Shane Moore: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.
Justin Traglia:Anything else that clients would like to discuss regarding implementations for DevNet Zero before we move on to the next topic?
Justin Traglia:Such as blockers, concerns… Anything like that?
Justin Traglia: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.
potuz:Which is about, adding the slot to the sidecars.
potuz: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.
potuz: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.
Justin Traglia:Stefan, do you have any updates on this? Or, like, have you determined whether or not it's…
Justin Traglia:Necessary to have.
Stefan Bratanov:Everyone.
Saulius Grigaitis | Grandine:Goodbye.
Stefan Bratanov:Yeah, I saw the comment from Brandy, and yeah, it's exactly the same thing that we have in our code.
Stefan Bratanov:So… Yeah, if we don't have that, then…
Stefan Bratanov:Any data falling sidecars wouldn't be…
Stefan Bratanov: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 | Grandine: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.
Saulius Grigaitis | Grandine:this,
Saulius Grigaitis | Grandine:So, we would save a huge, factoring, huge changes in the client by bringing, back this,
Saulius Grigaitis | Grandine:It's a lot better.
Justin Traglia:Would you argue that we should do this sort of, like, retroactively, so that this would be,
Justin Traglia:the spec for DevNet Zero.
Saulius Grigaitis | Grandine:We are not sure that we will be able to participate in DevNet Zero,
Saulius Grigaitis | Grandine:But, I mean, for us, it would be better if we do that as soon as possible.
Saulius Grigaitis | Grandine: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.
potuz: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.
potuz:And, a way of, like, making safe is that we are any ways going to,
potuz: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.
potuz:It's going to be the same, the same because we are targeting not having any blobs for the DevNet, in any case.
potuz: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.
potuz: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.
potuz: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
potuz: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.
Justin Traglia:We make a PR…
Justin Traglia:with the add slot to Datacom sidecar, and then we would do that for, like, DevNet 1 or something.
Justin Traglia:Right.
Justin Traglia:Yep.
Justin Traglia:Okay, sounds good. So yeah, let's make a PR for that, and we'll get it merged.
Justin Traglia:Anything else? Any other concerns?
Justin Traglia: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 | Nethermind:Yeah, yeah, sure. So, I already talked to my points.
Lin Oshitani | Nethermind:not ACTC, but I think there's, like, 3 things that…
Lin Oshitani | Nethermind:we should kind of decide upon. Like, one is, like, should we have process payments in the current EAP in the first place?
Lin Oshitani | Nethermind:Can we split?
Lin Oshitani | Nethermind:And…
Lin Oshitani | Nethermind:Yeah, I've asked some people in the ecosystem to join this call, too, if they have any wishes they want to raise.
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind:like, what's the exact… if we're gonna have it, like, what does it look like? And the third point is…
Lin Oshitani | Nethermind:Like.
Lin Oshitani | Nethermind:I think we all agree that we should have off-protocol bids to be supported, like, what does that look like?
Lin Oshitani | Nethermind:How should it be standardized? I think Terrence, you already started some write-ups, thanks for that, I think…
Lin Oshitani | Nethermind:That kind of things.
Lin Oshitani | Nethermind: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?
Lin Oshitani | Nethermind:Especially if we're, like, having doubts around the design at this point.
Lin Oshitani | Nethermind: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…
Lin Oshitani | Nethermind: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…
Lin Oshitani | Nethermind:That kind of coordination, and… is required, and I think it's kind of underestimated so far.
Lin Oshitani | Nethermind:But yeah, if we're gonna do it, we should do it right, so, like, we need to.
Lin Oshitani | Nethermind:Be sure that everyone's happy.
Lin Oshitani | Nethermind:So, that's my only point that I wanted to add there. If anyone wants to…
Lin Oshitani | Nethermind:talk about their point on any of these points, I'm… We'll just… Yeah, feel free to.
Lin Oshitani | Nethermind:Peak up, or… yeah.
Justin Traglia:Potus or Terrence, or anyone that…
Justin Traglia: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.
potuz:Which the IP already considers. The IP already allows for this, and we have very good designs for this.
potuz: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.
potuz:Now, Removing trustless payments, that's a very different story, and I haven't seen a single argument for it.
potuz:Now, if we are going to go that route of removing trustless payments.
potuz:I think we need to analyze practically what are our options, to remove trustless payments.
potuz:We, well…
potuz:We need to… we need to decide how we're gonna do this, because it's still not trivial.
potuz:By removing trustless payments, how the sign-in is going to happen, the builders will still need to be staked.
potuz: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.
potuz:So, I think people are just… separating
potuz: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.
potuz:So if we keep stake builders, then it's very simple.
potuz: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.
potuz: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…
Ansgar Dietrichs: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
Ansgar Dietrichs:state builders, but again, put us as raising concerns that that might not actually be so easy to facilitate, so…
Ansgar Dietrichs:that point taken. The reason why I personally would like to see, in a way, base EPBS in just that raw form is that
Ansgar Dietrichs: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
Ansgar Dietrichs:extra implementation complexity, just compared to today, right? Like, just this entire CL side.
Ansgar Dietrichs:builder balance, build a staking mechanism is just… it's just pretty novel, and so… so there's significant extra overhead, and I…
Ansgar Dietrichs: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
Ansgar Dietrichs:stake builders unconditional payments, but at least the point… point being is I feel like that kind of conversation, even if we end up
Ansgar Dietrichs: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
Ansgar Dietrichs: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…
potuz:Now, after…
potuz: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.
potuz: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…
potuz: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 | Nethermind:So… Yeah, like, I do see that it's, like, really…
Lin Oshitani | Nethermind:Late in the process, all that, but my impression is that, like, the whole SFI was more around
Lin Oshitani | Nethermind: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 | Nethermind: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 | Nethermind:But, like, in principle.
potuz:In principle, no, I haven't seen a single design.
potuz:This CIP was specified 2 years ago.
Lin Oshitani | Nethermind: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!
potuz:And after we've specified an EIP, people are trying to come up with yet another design. We've already debunked many of them.
potuz:Since Berlin, I had to analyze a new one every week.
potuz:At some point, this has to stop people.
Lin Oshitani | Nethermind:Yeah,
Lin Oshitani | Nethermind:bleep.
Lin Oshitani | Nethermind:Let's see your, like… Yeah, concerns around that, but…
Lin Oshitani | Nethermind:Like, is it not as simple as just… Unlimited to a header.
Lin Oshitani | Nethermind:At, like, the attestation time, and…
Lin Oshitani | Nethermind: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,
potuz: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.
potuz: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 | Nethermind: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 | Nethermind: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 | Nethermind:Okay, I see.
Lin Oshitani | Nethermind:Yeah, that's probably the part that I'm getting, but yes, it's not.
Lin Oshitani | Nethermind:be… Let's go separately.
Lin Oshitani | Nethermind:Yeah, Score, you have your hand up?
Ansgar Dietrichs:Yeah, I mean, I just… Why don't say we should…
Ansgar Dietrichs: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…
Ansgar Dietrichs:at the same time, obviously, Protos is much, much, much dependent.
Ansgar Dietrichs:On the governance side, though, I think I disagree with you, Protos, because
Ansgar Dietrichs:Yes. Obviously, it's not ideal to, like, basically, like, after accepting it, kind of changing, like.
Ansgar Dietrichs: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…
Ansgar Dietrichs: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…
Ansgar Dietrichs: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.
Ansgar Dietrichs: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.
potuz:The trustless payments has Very little addition to the spec.
potuz:from the… scaling EIP. The scaling EIP already has
potuz:an in-protocol signer, which is the builder, it already has the separation, the payload, the four-choice changes, it already has essentially everything.
potuz:The trustless payments addition originally actually was incredibly simple, it was just a balance change on the validators.
potuz:It got slightly more complicated because Lido requested it.
potuz:But that's it. So it's a min… the trustless payment part is a minor thing.
potuz: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.
potuz:And this was already in the IP. The people that voted for this already knew that it was in the IP for this.
potuz:Second.
potuz: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.
potuz: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.
potuz: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.
potuz: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.
potuz:And state builders, well, that's the way we have it specified. There's no other specification.
Justin Traglia:Terrence.
terence: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
terence: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,
terence:Because when you remove, like, this, like, the trust's payment and pending queue and stuff, it becomes a totally different design, which…
terence: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.
terence: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.
terence: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.
terence: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.
terence: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…
Lorenzo: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…
Lorenzo:let's say, builder competition, relay competition, and in general, I think the…
Lorenzo:There is a large, let's say, off-protocol market currently that's responsible for some 95% of the blocks in Ethereum.
Lorenzo:And I think that sometimes maybe this
Lorenzo:Market, is not as, let's say,
Lorenzo:Taken into account when, when making protocol changes, so…
Lorenzo: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.
potuz:Which might even be the default.
potuz:For example, for Lido validators.
potuz:And again, I want to stress this, because it seems to me that people don't have this clear here.
potuz:If I am a node operator, and I just whitelist and say, I want to take a bid from Titan.
potuz:And I don't care if it doesn't pay me.
potuz: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.
potuz:Will it sign it?
potuz: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.
potuz:So…
potuz: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
potuz: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.
potuz:And… that's it!
potuz:No changes on any of the logistics, no changes on the risks, no changes on anything.
potuz: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.
Lorenzo:Obviously, if a builder doesn't have to be staked, then that would not be an issue.
Lorenzo:Assuming there is some of protocol, you know, bidding.
potuz:Well…
Lorenzo:I would just… maybe, sorry, I would just…
Lorenzo:Yeah, sorry, I just wanted to add that some of the, I think, points that we mentioned are not necessarily related about Titan itself.
Lorenzo:Obviously, you know, Titan is a large builder.
Lorenzo: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 | Nethermind:Who… yeah.
Lin Oshitani | Nethermind:Like, I think… I do see that, like, trustless… trustful payments, or, like, off-vertical payments can be supported, and…
Lin Oshitani | Nethermind:My expectation is that's probably gonna be, like, the dominant usage, and…
Lin Oshitani | Nethermind:Which is… kind of okay, as in…
Lin Oshitani | Nethermind:like, there's not much disruption. It might also mean that we are having some complexity that's…
Lin Oshitani | Nethermind:Not gonna be used, but maybe that's okay.
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind: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.
Lin Oshitani | Nethermind:Like, as long as we have that.
Lin Oshitani | Nethermind:I think it'll be…
Lin Oshitani | Nethermind:And I think there was some, like… I think, like, in the past, like, week or so, like, in Discord.
Lin Oshitani | Nethermind:I think Blackboard does you?
Lin Oshitani | Nethermind:be much more supportive. Well, you were always supportive, probably, but, like, I think a lot of us were kind of…
Lin Oshitani | Nethermind:misunderstanding your point around removing the MedBoost. We thought it was removing off-protocol payments, but not the case, so…
Lin Oshitani | Nethermind: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…
potuz: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.
potuz: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.
potuz: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
potuz: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,
potuz: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.
potuz: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.
potuz: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,
potuz: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.
potuz: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 | Nethermind:We're removing… The trustless route, an employer thinking about the case where the proposer just
Lin Oshitani | Nethermind: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.
potuz:So that, I, I, I, I, I don't like.
Lin Oshitani | Nethermind:For example, like, in the…
Lin Oshitani | Nethermind:like, proposals that Terminus had, like, you'll have a configuration file that configures, like, this builder is trusted, you have a boost.
Lin Oshitani | Nethermind: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.
potuz: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 | Nethermind:Yeah, in principle, I do agree, but, like, operationally, for example, some node operators, they might have no idea how to handle
Lin Oshitani | Nethermind:like, these deal-side payments.
Lin Oshitani | Nethermind:And… It might have to go through, like, different accounting and all that.
Lin Oshitani | Nethermind:In that case, maybe they'll need some time.
Lin Oshitani | Nethermind:To actually, you know, Disable the trustless payment until they got ready.
Lin Oshitani | Nethermind:I think… one of the concerns around, like, that Lido was raising was that, like, they have to
Lin Oshitani | Nethermind:Like, upgrade their software to actually, like, do the accounting for the payment route.
Justin Traglia:Potus or Terrence, do you respond to that?
Justin Traglia:Okay.
potuz:I guess Lido can always boost the… I mean, there is an effective way of disabling the P2P stack in a sense.
potuz:By boosting, very largely, your whitelisted builders.
potuz:The problem is what happens when those guys… you boost yourself as a local builder, and you boost the whitelisted builders a lot.
potuz:And then…
potuz: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 | Nethermind:Yeah, that makes sense.
Lin Oshitani | Nethermind:So, yeah, my personal… standpoint right now is that, like, if we…
Lin Oshitani | Nethermind:kind of had a time machine to go back, I think. It would have been better if we had, like, two different
Lin Oshitani | Nethermind:EIPs and two different discussions, but I do see your point that it's kind of…
Lin Oshitani | Nethermind:Already very tied together, and… Hard to see, like, where we can actually separate.
Lin Oshitani | Nethermind:And… as long as, like, we have very, very good support, and you're already agreeing, so I think…
Lin Oshitani | Nethermind:That's very nice that, like, we have very good out-of-the-box support to block local payments.
Lin Oshitani | Nethermind:I think so.
Lin Oshitani | Nethermind:A lot of the concerns that the community had will be mitigated.
Lin Oshitani | Nethermind:Wondering if, like, Lido, I think someone from Lido is here, like, if you guys had anything that you guys…
Lin Oshitani | Nethermind:Wanted to be snow.
Lin Oshitani | Nethermind: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,
Greg K | Lido:sent directly in the SEL, but they are given in this, the recipient address on the execution layer via the withdrawal queue.
Greg K | Lido:So, yeah, since this is now incorporated in the specs, this kind, kinda…
Greg K | Lido: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…
Greg K | Lido: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
Greg K | Lido: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…
Greg K | Lido:many sorts at once, but, you know, I think it all boils down
Greg K | Lido: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…
Greg K | Lido: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…
Greg K | Lido:Definitely so that this takes builder is necessary for the pipelining part, so this was not clear to me.
Greg K | Lido: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.
Greg K | Lido:set, in the specification for Lido, yeah, that would be… Okay.
Justin Traglia:Thank you. Any response from POTUS or Lynn about that?
Justin Traglia:Photos?
potuz:Actually, yeah, so… This whole discussion is kind of very, very unfortunate, in a sense, because
potuz:if… I mean, we had a system that was incredibly simple.
potuz: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.
potuz: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.
potuz: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…
potuz: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.
potuz:So now it's this very unfortunate situation in which we might actually want to go back to that system.
potuz: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
potuz:payload is not available, and we are going to check for those and epoch transition, and then we put a withdrawal
potuz:We just churned.
potuz: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.
potuz: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.
potuz:I think it's a very minor change to the current spec.
potuz:So if… and it's something that people might want to, like, look into if we want to go that route.
potuz: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.
Greg K | Lido: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.
Greg K | Lido: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?
Greg K | Lido:Wouldn't make sense, of course.
Greg K | Lido:So I guess there is some confusion here.
Greg K | Lido: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.
potuz: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.
Greg K | Lido:So, no, like, I think this should be clear, right?
Lin Oshitani | Nethermind:Yeah, I think it's clear. I think the point here is that if Lido is to use Trust Sustain, that's the requirement.
Lin Oshitani | Nethermind:But they haven't… still haven't decided whether to use it. Like, they need some more further investigation for that.
Lin Oshitani | Nethermind:Does that make sense?
Lin Oshitani | Nethermind: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
Lin Oshitani | Nethermind: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.
potuz:With, the proposer self-signing.
potuz:And the original… yes, so that's it. Like, there's no full specification of how the proposal self-signs.
potuz:It requires a bunch of backs and forths.
potuz:And even to… to actually, like, broadcast the payload later.
potuz:The… there's… it requires another back and forth.
potuz:Like, the implementation actually is actually much more complicated, too, because you see that the payload itself
potuz:It's again signed by the proposer, so there has to be a communication between the proposer and the builder.
potuz: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.
potuz:And,
Lin Oshitani | Nethermind: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.
potuz:yeah.
potuz: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.
potuz:On the P2P side, otherwise you can be DOSED. So that's why the signature comes in the payload.
potuz:And now the question is whether or not we can have signatures from people that are not in the beacon state.
potuz:That… yeah, I do not know about the safety of that. That's why we had them. Now, of course,
potuz:If we… since we're saying that the That most of the…
potuz: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.
potuz:So, in principle, we could have builders being staked by very little, so that it's just a deterrent from DOSing the…
potuz: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.
potuz:But I think that would require changes on the beacon state that are, that are worse.
potuz:For example, we could make them not validators, and being staked very little.
potuz: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.
potuz:I'm going back on the drawboard now, to, like, go back and specify all of this again.
potuz:That is a big change.
Lin Oshitani | Nethermind:Yeah, I guess, like, the BIM protocol part…
Lin Oshitani | Nethermind:imagine wouldn't be too much of a change, but, like, have support for the MEP boost, and…
Lin Oshitani | Nethermind:But maybe there's… Oh, I'm not sure, but yeah.
Lin Oshitani | Nethermind: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.
Justin Traglia: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.
Justin Traglia:Okay, let's continue talking about that, then. For the final agenda item, Mehdi, are you available to talk about the attestation container?
Justin Traglia: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.
Mehdi Aouadi:And, we used to force it and hardcode it to zero in Electra, but, it's not the case now.
Mehdi Aouadi:So yeah, I was a little bit worried about that, because in my understanding, that would require a new container.
Mehdi Aouadi:To basically be able to…
Mehdi Aouadi: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.
Mehdi Aouadi: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
Mehdi Aouadi: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,
Mehdi Aouadi: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.
potuz:But I'm not sure.
Mehdi Aouadi:I mean, we could add some workarounds and try to do some hacky workarounds, but…
Mehdi Aouadi: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.
Mehdi Aouadi: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.
Mehdi Aouadi:We set, explicitly in the spec that the index field would be set to zero, And, yeah.
Justin Traglia:Yeah,
Justin Traglia: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…
Justin Traglia: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.
Justin Traglia:We're pretty much out of time. Is there anything anyone would like to discuss before we end the call?
Justin Traglia:Okay, thank you everyone for joining. I'll be sure to post a recap soon.
Justin Traglia:I'll see you all in 2 weeks.
potuz:Thank you, thank you.
Mehdi Aouadi:Thank you, bye.
Justin Traglia:Yep.
Stefan Bratanov:Alright.
Chat Logs
00:06:10
Pooja Ranjan:We are live !
00:08:00
Justin Traglia:agenda: https://github.com/ethereum/pm/issues/1744
00:10:18
potuz:The only one from LH I see here in Shane I think
00:10:37
Ansgar Dietrichs:end of october might be nice to not get into devconnect related rush? not sure how many people here will attend devconnect ofc, seems many are skipping this year
00:11:19
Stefan Bratanov:We can try devnet without any execution payload processing, all empty blocks
00:12:24
Ansgar Dietrichs:Replying to "end of october might..."
but yes agree, not sure it’s a realistic target
00:12:34
potuz:@Stefan Bratanov In my experience adding payload processing doesn't add complexity to the devnet, the problem is payload propagation that gave us a huge headache in our previous interop with you
00:13:12
Justin Traglia:@Shane Moore would you like to give a lighthouse update?
00:13:31
Shane Moore:Hi, yep, can go next
00:13:49
potuz:Ahh you meant no execution requests @Stefan Bratanov ? yeah that I agree
00:15:00
Stefan Bratanov:Replying to "Ahh you meant no exe..."
Ah no I meant just no payload propagation, just fake local bids, but can't see too much benefit for that
00:16:03
potuz:Replying to "Ahh you meant no exe..."
we will do only local bids, but you still need to propagate the payload envelope
00:16:06
Ansgar Dietrichs:already related to the unconditional payments topic - even in case we decide it should be split into a separate EIP, are clients closer to having devnet-0 with or without unconditional payments in that case?
could decide to keep it in for devnet-0 either way, if that would make getting to devnet ready quicker for clients
00:16:38
nflaig:same pattern in Lodestar, having slot in container would be good to have
00:16:39
potuz:the EIP only exists with unconditional payments, there's no EIP without it, it needs to be fully specified
00:17:02
terence:i can open a pr after the call, should be easy
00:17:10
terence:we should do it for devnet0
00:17:15
Stefan Bratanov:We can just have no blobs for devnet0
00:18:19
terence:it's very easy to add it, the sooner we do it the better
00:18:57
potuz:Replying to "We can just have no ..."
yeah exactly I think this iis a noop anyway
00:21:05
Stefan Bratanov:Replying to "Ahh you meant no exe..."
That's the most difficult portion of code in my opinion which needs good design (having two states for the same block root), so realistically would be hard to achieve that end of October, let's see in two weeks what is the progress
00:25:38
potuz:Are you trying to highjack the full SFI process and go back to remove it and puit the highliner process to trash?
00:27:03
Ansgar Dietrichs:to be clear, my motivation is (mostly) unrelated to trusted payments
00:33:23
Ansgar Dietrichs:you mean ePBS as a whole? that will definitely be in Glamsterdam :-)
00:34:21
stokes:i do think we are just analyzing the different design decisions before finalizing the spec
00:34:29
potuz:Replying to "you mean ePBS as a w..."
ePBS ONLY exists the way it's specified now
00:34:42
stokes:i don’t think anyone is trying to sabotage the ACD process
00:34:44
Ansgar Dietrichs:apologies for coming in without much context, I also only heard about this proposal on acd last week, and was ooo this week, so couldn’t prepare for the call. I think one week is very short for making this decision
00:35:30
potuz:Replying to "i do think we are ju..."
what ae the other design decisions? there is NO OTHER design except handwavy versions of people that actually haven't even read this one to not realize the problems of trying to remove the compromises of this design
00:36:29
Trent:What’s the article Lorenzo?
00:36:44
Ansgar Dietrichs:so my understanding is there is two elements:
staked builders
unconditional payments
the two questions I see:
is staked builders really necessary for the scaling / slot restructuring part of ePBS?
what extra complexity do these two elements each bring? both in specs, but crucially also for the overall building pipeline
00:36:48
Chris Haug:Replying to "What’s the article L..."
https://titanbuilder.substack.com/p/builders-and-relays-in-epbs
00:36:53
Lin Oshitani | Nethermind:Probably this one: https://titanbuilder.substack.com/p/builders-and-relays-in-epbs
00:37:08
stokes:ability to have trusted payments
should builders be staked or not
placement of deadlines to mitigate free option problems
are some design decisions that i see
00:37:24
terence:in the trusted scheme, off protocol payment, what's the captital efficiency argument?
00:37:29
Ansgar Dietrichs:Replying to "so my understanding ..."
my understanding of potuz’ view:
staked builders is necesarry either way
unconditional payments is very little specs complexity
00:37:38
terence:same as today, the only diff is 32 eth deposit to be a validator
00:38:24
stokes:Replying to "i do think we are ju…"
i hear you there may be subtleties that imply we need the current spec but then we all need time to get up to speed
00:40:30
terence:smaller builder (dont want to stake) can still use the relayer which is staked for 32eth
00:44:03
Ansgar Dietrichs:it feels like we don’t really have an informed basis for a decision today - or rather, no one in favor of a change (including me) has put in the work necessary yet.
I don’t think it’s clear yet that the proposal is a bad idea though, so I would prefer for us to wait for the decision until next acdc at least. with the understanding that default outcome is no change to ePBS, trustless payments (and staked builders) stay in.
00:44:04
Shane Moore:“If trusted routes fail or are blacklisted, ePBS’s trustless path remains: take a regular on-protocol bid from a staked builder and get paid via pending-payments/withdrawals. That’s exactly the “keep options open” argument for not removing trustless payments from the spec.”
- https://hackmd.io/@blockshane/BJJL43T2le
00:44:45
stokes:Replying to "it feels like we don…"
i don’t think we were going to make a decision on this today
00:45:01
Ansgar Dietrichs:Replying to "it feels like we don..."
I saw people express a preference for doing so
00:45:11
Ansgar Dietrichs:Replying to "it feels like we don..."
but if that’s not on the table, great
00:45:14
Sophia Gold:Replying to "so my understandin..."
Sorry, I missed why staked builder are necessary for the pipelining benefits
00:45:31
potuz:Replying to "so my understanding ..."
you need a signature
00:45:54
Sophia Gold:Replying to "so my understandin..."
Wouldn't it be the same as today with the proposer blind signing a header?
00:46:10
Lorenzo:In terms of having a fallback, what is the advantage of p2p bids vs local building?
00:46:10
potuz:Replying to "so my understanding ..."
that requires dealing with unbundling in a safe way
00:46:46
Francesco:Replying to "it feels like we don..."
Having trustless payments in protocol seems quite different from not allowing operators to decide which builders they want to get bids from. Feels like it would make everyone's life easier if operators could just choose? Why would they need to do it with some weird boost?
00:47:02
Sophia Gold:Replying to "so my understandin..."
That would be more of a problem than it is today?
00:48:13
Ansgar Dietrichs:Replying to "it feels like we don..."
@Francesco was this meant to be a top level comment?
00:48:33
Francesco:Replying to "[Full message cannot be displayed on this version]"
Yes I am from phone
00:48:45
stokes:Replying to "In terms of having a…"
you allow easier entry for builders into the market
00:49:04
stokes:Replying to "In terms of having a…"
it’s far more permissionless than any configuration with a relay
00:49:07
terence:p2p allows anyone with 32 eth to be a builder without opening up rpc end points and advertising to proposers to use it
00:49:40
Justin Traglia:Replying to "it feels like we don..."
@Francesco would you like to talk about this?
00:50:36
Barnabé Monnot:strawman pipelining: there is only the validator releasing a beacon block committing to an exec payload, and the payload later on, both signed by them. what is wrong with this?
00:50:46
potuz:@Francesco so you don't disagree with "I blacklist every builder except these ones"
00:52:38
Sophia Gold:Replying to "strawman pipelinin..."
Yes, I still don't understand the argument why this is unsafe
00:56:46
Francesco:Doesn't have to be proposer self signing, could still be signed by the builder but it just isn't staked
00:56:58
Ansgar Dietrichs:right, without staked builders you need to keep the current relay architecture
00:57:07
Francesco:(though it's not super clear what the signature is useful for at that point)
00:57:41
terence:Replying to "strawman pipelining:..."
i think one argument here is "this is a change" and the change here is "not easy" either
00:58:36
Ansgar Dietrichs:DOSing with which message? the payload would come with proposer signature, no?
00:58:49
Justin Traglia:Yeah not sure about smaller stakes for builders
00:58:49
Ansgar Dietrichs:and the bid would just be builder <> relay <> proposer like today
00:59:11
terence:questions to builders, do you not like the stake part? or not like the running the validator infra part? or both
00:59:31
Barnabé Monnot:Replying to "strawman pipelining:..."
Well it removes trustless payments, staked builders, all the builder-related infra (e.g, p2p exec bids etc) so agree it could be complex but hard for me to say how big the delta is, seems quite significant. no builder entity in code too
00:59:49
potuz:Replying to "DOSing with which me..."
yes this was a reply to Francesco, if we go with the proposer's signature
00:59:50
DA | Flashbots:Replying to "questions to builder..."
We’re fine with it.
00:59:52
potuz:Replying to "DOSing with which me..."
then we n
01:00:00
potuz:Replying to "DOSing with which me..."
then we have to do a back and forth again
01:00:03
potuz:Replying to "DOSing with which me..."
for unbundling
01:00:27
Ansgar Dietrichs:so wait, was the confusion here that potuz was talking about a version where bids would still travel on the p2p? I think everyone else was talking about just sticking with today’s relay architecture as-is, no new bid p2p at all
01:00:54
Barnabé Monnot:Replying to "DOSing with which me..."
that back and forth unbundling is on the proposer though, and in fact proposer could even blind sign early so the relay can release asap
01:01:20
stokes:Replying to "so wait, was the con…"
i think potuz feels the p2p option is worth having
01:01:32
Lorenzo:Replying to "questions to build..."
I would say that if most payments are trusted on the EL, then the builder is only nominally staked don't think would be an issue. Main issue would be if builders were required to keep the balance for payments on the CL since can be a large amount of capital
01:01:32
Barnabé Monnot:Replying to "so wait, was the con..."
this, this is what we should be comparing against, a completely PBS-free version, not a half-free version
01:01:35
stokes:Replying to "so wait, was the con…"
but maybe i shouldn’t speak for him
01:01:53
Ansgar Dietrichs:Replying to "so wait, was the con..."
that’s what I am thinking about with the “scalining-only part of ePBS”.
and then a separate EIP for:
bid p2p
staked builders
trustless payments
01:02:19
terence:Replying to "strawman pipelining:..."
ah, but some of us are viewing p2p exec bids as a "feature", and worth the tradeoff, maybe that's the disagreement
01:02:25
Ansgar Dietrichs:Replying to "so wait, was the con..."
to me that’s the only sensible way to split ePBS into two
01:02:45
Barnabé Monnot:Replying to "strawman pipelining:..."
well it’s a feature but a market change feature, that people disagree with, wrt benefits and costs
01:02:50
Barnabé Monnot:Replying to "strawman pipelining:..."
not a pipelining feature
01:03:03
potuz:Replying to "so wait, was the con..."
no Ansgar, the p2p side is kinda irrelevant to me
01:03:20
terence:ouch, adding an new attestation container is a pain in #$#$ for prysm
01:03:30
Lin Oshitani | Nethermind:Replying to "questions to builder..."
If anyone won't like it, I imagine it will be small builders that won't be in this call.
01:03:55
potuz:Replying to "so wait, was the con..."
and as I said a gazillion times, staked builders (as lorenzo is putting here too) specially if they don't churn, it's not a problem. The complication of the EIP along those sides are minimal
01:04:01
potuz:Replying to "so wait, was the con..."
compared to the sheer change of separating
01:04:06
terence:Replying to "questions to builder..."
smaller builders can still use relayer, assuming there's a staked relayer
01:04:19
Lin Oshitani | Nethermind:Replying to "questions to builder..."
True, good point
01:04:22
Ansgar Dietrichs:Replying to "so wait, was the con..."
ah hm, then I still come out of this with confusion around staked builders
Summary
11 highlights
· 3 action itemsExperimental
Summary
11 highlights · 3 action itemsExperimentaldevnet zero progress
- Prism: all Beacon chain.md implemented, passing spec tests; awaiting Fusaka stable release00:07:32
- Teku: passing all reference tests except Fork Choice00:08:41
- End of October DevNet Zero timeline considered rushed by most teams00:09:19
- ACD decision on CIP split scheduled for ~October 17th blocks PR merges00:10:59
spec changes
trustless payments debate
- Core question: Should trustless payments be separate EIP or stay in 7732?00:21:29
- Potuz: Staked builders required for pipelining; removing them requires full redesign00:25:38
- Trustless payments add minimal complexity; main work is staked builder infrastructure00:31:59
- Consensus: Strong out-of-box support for off-protocol bids needed regardless00:44:29
attestation container concern
- GLOS reuses index field for payload status; may require new attestation container01:00:20