Justin Traglia:Hello, everyone. Welcome to EPBS Breakout Call 28.
Transcript
Justin Traglia:There's a lot to go over today, so I'll probably jump right in. I'd like to quickly state that since the previous breakout room call, there has been a new consensus specs release.
Justin Traglia:Version 1.6.1.
Justin Traglia:We can and will publish a new release soon, if plants want it.
Justin Traglia:I've shared the list of PRs.
Justin Traglia:Since the last breakout call.
Justin Traglia:The ones that have been merged have been checked.
Justin Traglia:So, for the unmerged ones, please take a moment to review them.
Justin Traglia:If you haven't already.
Justin Traglia:And, one final note,
Justin Traglia:The… sorry, the final breakout call will be on December 19th, 2025.
Justin Traglia:After that, all of the,
Justin Traglia:The last discussions will move to ACDT.
Justin Traglia:Which will be dedicated to Glamsterdam.
Justin Traglia:Let's start with… or sorry, let's… let's do, updates from client teams. Is there anyone here from Prism that can give us an update on their implementation?
terence:We haven't made much progress last week because of Fusaka. Yeah.
Justin Traglia:That makes sense.
Justin Traglia:Lighthouse?
Justin Traglia:Okay, no one here from my house. Taku, please?
Enrico Del Fante (tbenr):Yeah, not as much progress, as well. We are… we are currently working on…
Enrico Del Fante (tbenr):Gossip validation rules, mostly.
Enrico Del Fante (tbenr):Yeah, not yet fully ready.
Justin Traglia:Okay.
Justin Traglia:Nimbus.
Justin Traglia:Oh, hey Dustin. I just asked for an update on… from Nimbus on, glass implementations.
Dustin:And was one provided? I obviously don't have context.
Justin Traglia:Nope.
Justin Traglia:Asked right as he joined.
Dustin:Right, okay.
Dustin:So, this is something that both of, I guess, Caleb, my understanding, has been showing up here? I don't know, he tells me. And yeah, we've merged, more EPBS support into
Dustin:Into truck?
Dustin:In an ongoing way. I don't know if there's a specific, set of specs or aspect of EPBS that you're…
Dustin:Asking about in this context?
Dustin:But yeah, we're continuing.
Justin Traglia:Okay. That's good enough.
Justin Traglia:Lodestar? How is your work going?
nflaig:So yesterday, we merged a pretty big PR for the state transition, and we passed all the spec tests from 161. And there's work in progress for P2P and block building.
Justin Traglia:Nice. And last but not least, Grandine.
Subhasish:Yeah, I can take this one.
Subhasish:So, from last meet, we have the… we have, closed the PRs on, Sync Manager, and,
Subhasish:Sync Manager changes for envelopes, plus, request response, changes for envelopes, and, the support for payload, timeless committee assignment, and, its integration into Blog Producer. We have some, open PRs on,
Subhasish:On the gossips of handling for,
Subhasish:envelopes and bits. I think for, attestation, it was, recently merged. There's an open PR for, local blog building.
Subhasish:And on the fork choice, side, we have, initial implementation that's, passing, the initial, gloss tests, which are added, and, yeah, we're, looking into that, that aspect mostly.
Justin Traglia:Thank you.
Justin Traglia:Okay.
Dustin:Alright, sorry, can I…
Justin Traglia:Fuck.
Dustin:So, I'm… I'm told, I don't know, is Caleb on this call yet? Like, is he, is he… I hadn't see if he… Yeah, he is, hi. Okay, so…
Caleb:He'll be fairly…
Dustin:So, so I would like to actually hand this over to him, who has a lot more context on this than I do. Alright.
Dustin:Thanks
Dustin:As far as the EPPS and Nimbus?
Justin Traglia:Yep.
Justin Traglia:Caleb, do you have any updates other than what Dustin said?
Caleb:None, none.
Justin Traglia:No worries.
Justin Traglia:Let's move on to the agenda items, I suppose. Thanks for the updates from clients.
Justin Traglia:I don't know what your first name is, but JCS Legal?
Justin Traglia:Could you, talk about the dynamic penalty proposal that you brought up?
christophschlegel:Right, yeah, I'm Christoph. J is for Jan.
christophschlegel:But you can call me Christopher. Okay, I can have some slides.
christophschlegel:Which I'm not able to share.
christophschlegel:You can also do it without slides,
christophschlegel:Or if somebody gives me the rights to…
Potuz:Booja?
christophschlegel:Too shit.
Potuz:You might have the rights to make you a co-host, or something like that?
Justin Traglia:I could also stop sharing, I don't know if that's the reason.
Enrico Del Fante (tbenr):Yeah, maybe you have to start stop sharing, and then try again.
Justin Traglia:Alright, please try again.
christophschlegel:Oh, that's Wix.
Justin Traglia:Sorry.
christophschlegel:No worries.
christophschlegel:Okay, does this work?
Enrico Del Fante (tbenr):Yep.
christophschlegel:Okay, so this is how Nana Banana…
christophschlegel:Imagines EPPS to look like, and this is a free option problem on the right-hand side.
christophschlegel:That's what I wanted to talk about. So, Bruno and I have been, investigating this free auction problem.
christophschlegel:To remind you, so that the problem is that…
christophschlegel:you have commitment to a payload, but you don't reveal it when you make your bid.
christophschlegel:And then you have time to reel payload and blobs, and there's a time window between
christophschlegel:Commitment and revelation, and people might change their mind in between whether the block that they want to publish is actually a reasonable block, and the way to exploit it is to…
christophschlegel:Put usually a bunch of trades in your blog, and if they go against you, the market goes against you, you basically don't publish.
christophschlegel:publish a block. And the gadget that you would use for that would be, you fail to… usually you fail to deliver a block, so that's a free option problem.
christophschlegel:We were looking into different mitigations, and,
christophschlegel:Have looked in particular into penalties and reward schemes, so we penalize, if you miss a payload or a blob.
christophschlegel:And… or we… we reward you for doing that, if you deliver it.
christophschlegel:And, we've gone through a bunch of things, and the most promising to us is dynamic penalties, where we, put the… where we use,
christophschlegel:basically the… we introduce correlation, in… so we punish correlated failures, more severely than isolated failures. So the idea is if you…
christophschlegel:fail from time to time to deliver a payload. That's basically a very small penalty, but if we observe a lot of those,
christophschlegel:Fair payloads, then we increase penalties, to…
christophschlegel:basically punish people for which something that looks like a free option exploitation.
christophschlegel:And the rationale behind that is that, first of all, it's a robust metric, a robust statistic to base
christophschlegel:penalties on, and the other idea behind it is that you usually observe this clustering, volatility clustering. So you observe that exercising,
christophschlegel:The pre-option, is… lucrative…
christophschlegel:in time intervals where you, basically have a correlation of, where you have clustering of opportunities. So you want to punish there.
christophschlegel:Right, so…
christophschlegel:That is irrational. You could also do it with, rewards, so you reward people, but the problem is if you do dynamic rewards, people can basically,
christophschlegel:Can, can game them by basically increasing rewards for themselves, so penalties are less gameable.
christophschlegel:So proposals that we have, and we have an implementation that we put on EASH Research, or a SPAC, a spec on EASH Research, is that we,
christophschlegel:Have a concrete rule of setting the size of those penalties.
christophschlegel:Which, is dynamically adjusted, so you would need to introduce another state variable, to the protocol that keeps track of the penalty, and that takes in this information how many failed,
christophschlegel:payload failures, as I have been, recently.
christophschlegel:And then we use those, penalties, we keep track of them, and we use… we propose to use the payments
christophschlegel:that are pending payments that are already part of the spec, to also keep track of penalties. So, effectively, what we propose is that you, you would add, another, field to this pending, pending, builder payments, container that would also keep track of penalties.
christophschlegel:So let me tell you briefly what is this rule.
christophschlegel:So, the idea is very simple, so you,
christophschlegel:have a penalty, which is this another, new state variable that we introduced, missed payload penalty.
christophschlegel:We would propose to introduce.
christophschlegel:We go up with a penalty if the block on top of which you build has no payload, and we go down with a penalty if it has one.
christophschlegel:So that's the dynamic aspect of it.
christophschlegel:We have written also some theoretical paper on this, which gives you a bunch of guarantees. So the object of interest for the theoretical guarantees is a failure rate, so you have a
christophschlegel:failure rate that you target, so you say, I don't know, 1% failed payloads is acceptable, or 0.5% is an acceptable failure rate.
christophschlegel:And then you, look, and then you can design those, or you can set those, parameters in such a way that you achieve those, rates on average. So those are theoretical guarantees that you can get, in terms of, yeah, in terms of…
christophschlegel:Online learning, kind of, standard results.
christophschlegel:And so, the other interesting parameter is how long of a time window you want to sustain this failure rates over. That gives you, basically.
christophschlegel:how aggressively you move it up and down, okay? So those are the two, two…
christophschlegel:Parameters that we introduced.
christophschlegel:Going up was a penalty, going down was a penalty. Then we did a bunch of backtesting,
christophschlegel:of this policy, so we've looked at realized… we have a data set of realized blocks, so of course, I mean, if forward-looking, people might build different kind of blocks if they have a…
christophschlegel:Free option, available, but at historical blocks, we looked into how that, changes, the effect, how effective it is to…
christophschlegel:To exercise this free option, and how much does it mitigate, and basically theoretical guarantees that you have from this online learning results are…
christophschlegel:replicated, quite well in the data. So you can set a target acceptable rate of failures, so failures would be, things where the option would be
christophschlegel:Mmm… Profitable to exercise, even with a penalty.
christophschlegel:For example, you set it to 0.5%, and then you observed that actually in our dataset, this very closely matches, the realized profitable exercise rates.
christophschlegel:Are very much close to that theoretical.
christophschlegel:Guarantees that you want to achieve.
christophschlegel:You can also see, so those numbers are in east, the, sort of size of those,
christophschlegel:Those penalties that he would need to…
christophschlegel:levy in order to, to, to, to achieve these, rates, so it would be…
christophschlegel:ballpark 0.02 to 0.04 ETH, to achieve this, half a percent of acceptable failure rate, in the worst case, and, well, they escalate in… in times of high volatility, so they can go up to… to 1 ETH in,
christophschlegel:In very volatile times. But on average, they stay sort of low, so that's… that's the point.
christophschlegel:So that's, the idea behind it.
christophschlegel:There are also graphs where you see, sort of, the fluctuation of Profitability, over time.
christophschlegel:With different, different parameterizations, and then you see, how, how large,
christophschlegel:penalties would be, if you would set them accordingly. And you see that, I mean, in these where volatility spikes, you would have
christophschlegel:Also, spike of, the… Penalties.
christophschlegel:Okay, I think that's… Big picture… the… the…
christophschlegel:the idea behind it. Yeah, you can set them in many different ways. We've given, as I said, an example spec where we set it, these, these, parameters,
christophschlegel:According to…
christophschlegel:These values here, so as you say, it goes more aggressively up as it goes down, because you, yes, you need to escalate very rapidly if you want to.
christophschlegel:to the policy to be effective, but this targets, basically, for example, a failure rate of half percent. And then it's a question of what do you find acceptable, right? So what do you find acceptable in average penalties, and what you find acceptable in
christophschlegel:Missed, missed, payloads rates.
christophschlegel:So, yeah, one can debate about it. What we can say is you can…
christophschlegel:Achieve, because there's also a sort of theoretical worst-case guarantees, you can achieve very robust, guarantees on these.
christophschlegel:I probably shouldn't go too much… I rather wanted to hear opinion on, or elicit feedback on the general idea, but we have a spec, so you have this new, new, new parameter where you…
christophschlegel:Sets the penalties, and then you have to…
christophschlegel:account for the penalties, and so what we propose to do there is we track them together with pending payments, right? So we have this object of a pending payment in ERP7732,
christophschlegel:You, have, payment… pending payment, so a pending payment, is in the queue if it's, is basically for an unconditional payment where a payload was not, delivered, so you can use it as a gadget to also keep track
christophschlegel:Of penalties at the same time, so you keep track of them together.
christophschlegel:And then you would, basically, deduct those penalties at the end of the subsequent epoch.
christophschlegel:From the, the builder, balances.
christophschlegel:And then you also have to make sure that the builders are able to pay those balances and the pending payments, so what you would also need to add is basically a condition on the bids that says, if you bid, we have to make sure that you are able to pay those penalties as well as all pending payments and all pending penalties.
christophschlegel:What I think is important as Twilight is that you should also,
christophschlegel:Put penalties on self-builders, and so you basically also need to keep track of those,
christophschlegel:So, self-building penalties, so… but you can use the same kind of gadget in principle. Why is it important? Because otherwise people would circumvent, maybe, penalties by…
christophschlegel:Yeah.
christophschlegel:going, through, I don't know, a relay or something like this, to, to, to, exercise the free option without…
christophschlegel:getting a penalty. So that's the idea. We've looked in possible issues that we thought about, probably other ones.
christophschlegel:So, it could be a problem that you penalize not only people who want to exercise a free option, but also honest builders that have a bad day. So they don't do it on purpose.
christophschlegel:What we think is, sort of.
christophschlegel:It might be a problem, but what would you think is… is,
christophschlegel:still argue… we would argue for the penalties. For example, self-builders, they can always release a payload together with a commitment, so at the point in time where they commit, they can also release a payload into blobs. So, I mean, they have to be highly unlucky to miss,
christophschlegel:miss, basically, the deadline for the payload timeliness Committee, if they do that.
christophschlegel:So, the risk is very limited. External builders, there's risk for them.
christophschlegel:Right? But then we…
christophschlegel:as we have shown in the graph, so on average, those penalties are low. So even if somebody is unlucky and gets a penalty, then, well, it's not…
christophschlegel:the end of the world. It's a small amount, on average.
christophschlegel:And if they're unlucky to miss a… get a penalty in times of high volatility and high penalties, of course, that could be substantial, up to one ease, or above that. I don't know, what is the most extreme scenario?
christophschlegel:might have a bearing on how people behave, then, in these times of high penalties. So, one thing that we imagine could be that they are more conservative in what they're doing. For example, they
christophschlegel:Omit maybe sending blobs, if that is… introduces more errors in… to the, more failures in expectation for margin of safety.
christophschlegel:That might be downsides. It could be that, if there is…
christophschlegel:Right? We do penalties that are based very much on the idea that correlated failures are much more… punished much more than isolated failures, so if there's a bug in a builder software, or, like, in the default builder.
christophschlegel:In a client, that could cause correlated penalties without us actually, you know.
christophschlegel:wanting to do them, so it has nothing to do with malicious behavior, but it's sort of… that could be an problem. And in principle, people could maliciously try to, you know, make you not sending your payload, because they want you to be punished. A malicious actor could do that.
christophschlegel:But of course, that is true in general. I mean, also in… if you…
christophschlegel:missed, to send… if you missed to send a payload in time, then you also forego profits. I think this problem is already there to some degree.
christophschlegel:So, that's the high-level idea, and…
christophschlegel:What else are rewards? If you don't like that penalties are there.
christophschlegel:And then you can make that on expectation. Basically, you can…
christophschlegel:make it zero by introducing rewards, right? So we cannot do dynamic rewards, so in extreme cases, we have to punish.
christophschlegel:But on average, we can make you break even if you wanted to do that. That comes
christophschlegel:at the cost of additional issuance, potentially. Or we have to reduce…
christophschlegel:you know, rewards for other, duties. But in principle, that's one way of achieving, basically, a zero on average, for, on, for… because you combine rewards, with penalties.
christophschlegel:Okay.
christophschlegel:We have written, it's research post, we would be very happy about feedback on it. We've tried to come up with a spec, probably
christophschlegel:you will… I mean, it would be highly appreciated if people could look into the spec, see whether there are any… any problems in the spec, and give us feedback on, whether that is something that we could introduce to
christophschlegel:help us with the free option problem. Final thing that I wanted to say is, so, there will be, I guess, some discussion later on about these,
christophschlegel:About the builder payments in protocol, so I think, with or without these trustless payments.
christophschlegel:it's reasonable to mitigate the free option problem. The solution should work in either case. SPAC would be slightly simpler if we would have,
christophschlegel:No in-protocol payments, but that's the only difference.
Justin Traglia:Thank you so much for the presentation, that was really good.
Justin Traglia:Does anyone here have feedback and or questions?
Potuz:I have a question, how…
Potuz:I mean, the proposal to remove Trustless payments.
Potuz:also removes staked builders. I mean, the easiest way of doing this would be to remove also staked builders. How do you implement this penalty mechanism in that case?
christophschlegel:Well, then you have just, normal proposers, proposing, and then you keep track
christophschlegel:of, whether they… Deliver the payload, and you… can process them as…
christophschlegel:penalties together with other penalties. With the penalty to the… so you mean…
Potuz:The proposal is to… but the proposal would be to have the payload signed by an off-protocol builder that is not state.
Potuz:So, you could keep track of these payloads not being delivered, but the only state object that you can actually penalize is the proposer, not the builder.
Potuz:So it doesn't seem to me…
christophschlegel:Also, of course, you would penalize a proposal, yes.
Potuz:Yeah, so you only penalize the prop… so you would penalize the proposer for payloads that are not delivered by builders.
christophschlegel:I mean… he can always build his own payloads, I mean, if he outsources it to shady actors, then…
christophschlegel:his problem. But, yeah.
Enrico Del Fante (tbenr):We're moving the risk from the builder to the proposer, essentially.
christophschlegel:Right, and then out of protocol, people have to find ways of, you know, doing this risk sharing among themselves.
christophschlegel:I guess if I propose blocks,
christophschlegel:if I'm a proposer and I elicit blocks through an external service, then I would want that service to make sure that payloads are delivered, and otherwise there's some
christophschlegel:I don't know, some stake, right, outside of protocol, right, on the relay level, or so on. Otherwise, it would self-build.
Justin Traglia:Alex, I saw that your hand was up. Do you want to say anything?
alex:No, I think Christopher covered it well, and I hesitate to, like, draw in the next discussion already. I think Christoph covered it well.
Justin Traglia:Okay, anything else from anyone before moving on?
Potuz:Yeah, I had a comment. The proposal is actually sound. I've checked the spec, it seems complete.
Potuz:It is complicated, and it's… it's an issue of whether or not it's enough of a problem that we want or not implement this, but that's a different discussion. The only, like, new philosophical change that I see
Potuz:Is that today.
Potuz:the spec doesn't have this… this issue of a common bug in a client. The spec is designed in such a way that if you have downtime… downtime, which is the kind of things that common bugs cause, like what Prism cost yesterday.
Potuz:Validators are not heavily penalized.
Potuz:And that's… you can't really be someone lucky to be heavily penalized. Being very unlucky on a bug is… you hit a bug that just…
Potuz:doesn't prevent your slash in DB, for example, and then you get slashed. That would be a bad bug. But the common bugs of, like, liveness that we have on clients don't cause capital loss to… to…
Potuz:to validators.
Potuz:this thing might actually cause it, because if you do have a bargain on the EL,
Potuz:that causes some blocks to be missed, then builders will not start, will not start providing bids. And if you have… if you are in a situation where you don't provide bids, then you self-build.
Potuz:And if you self-build it with that client, then suddenly you're heavily penalized in that situation. So I think this is new. I think this is the first time that we see a liveness bug creating, a liveness bug in a minority, not in a majority client creating these things.
Potuz:I'm not sure how to weight that.
christophschlegel:It's true. I guess. Yes.
christophschlegel:Only thing that I can say.
christophschlegel:Don't introduce bugs.
christophschlegel:and your clients.
Justin Traglia:Okay, let's move on to the next topic. We don't have all that much time.
Justin Traglia:Barath would like to speak about the Builder API with ePBS. Barath, would you like to share your screen?
Bharath:Yeah, I'll just share my screen.
Bharath:Let me know if you guys can see.
Bharath:Yep. Can… can see it.
Bharath:It's visible, right?
Justin Traglia:Yep.
Bharath:Oh, yeah, sounds good. Yeah, so hey guys, thank you for letting me speak. The, the agenda for this talk, like, my intent is to kickstart, like, discussions on how the Builder API could look with EPBS.
Bharath:again, everything, like, assumes we have, like, trustless payments and all that. So, just, like, I'm just gonna, like, run over, like, some background, like, which I don't have to do in this call, but PBS has, like, stake builders and trustless payments. The main thing is we restructure the beacon block by removing the full execution payload out of it, and only embedding, like, the bid to it.
Bharath:Right, so these are, like, the major data structures. You have the execution payload bid, the execution payload bid, which just contains a commitment to the full, like, payload. And you have the actual envelope, which has the
Bharath:Actual, like, payload and the commitments to the blobs and execution requests.
Bharath:So, and then, you know, we see that in the beacon block body, like, at this point, like, we remove, like, the blob commitments, execution requests, and the entire payload, and we just replace it with a bit.
Bharath:So…
Bharath:So, having that, just, like, establishing some ground, right, so how do builders communicate their bids with proposers, right? Like, and that's what the builder API, like, essentially does today, is, like, it's basically an interface between the proposer and builder to, like, exchange, like, block bids and commit to a block.
Bharath:So today, EPBS has… one of the things, we have a P2P gossip topic, which allows, like, stakeholders to, like, propagate their execution payload bits. It'd also be nice if proposals were able to directly connect to the builders, and to gain, like, a much lower latency connection.
Bharath:So, so the… so I'm, like… so the work that I'm trying to do is, like, try to think about how the builder API could look like when the proposal talks to, like, stake builders from the proposal… and also when the proposer talks to, like, unstake builders, or off-protocol builders. At this point, like, I want to stop, like, I think that is…
Bharath:I know there is, like, contention, Portis, I've been discussing with you, you… you know, you mentioned that, you know, we… we don't want, like, we won't support, like.
Bharath:talking to builders out of the protocol, but then I've also heard, like, people saying opt-protocol builders will still exist. I understand, like, there's some contention there. I'll leave that to, like, the end of this discussion, to end of this… end of my topic. I have that as an open question.
Bharath:Now I just want to, like, quickly discuss on…
Bharath:on the high-level, like, flow of the Builder API, how it could look like with EPBS. Again, this is, like, early work, and I'm sure there's a lot of, like, refinement we can do.
Bharath:With stake builders, the builder API will kind of look very similar to how we have it today. So these are builders in protocol, they're staked.
Bharath:With them, the builder API will probably look, like, pretty similar, like, if you… the flow would be, like, the proposal queries the builder, like, hey, I want a bid, give me your best bid. The builder sends back the best bid, and if the proposal, like, likes it, the proposal will commit that bid in its beacon block.
Bharath:once it commits the bid in the beacon block, it returns it back to the builder. So these are two, like, API calls. We can talk about names later. But, like, you get the execution payload bid, then you build the beacon block, and you send it to the builder.
Bharath:Right? And both the proposer and the builder can, like, broadcast the beacon block to the beacon committees.
Bharath:The builder at this point, now that we have the beacon block, you can actually construct the execution payload envelope.
Bharath:And once the builder has the execution payload envelope, the builder is, like, responsible, solely responsible for,
Bharath:broadcasting the envelope to the PTC committee.
Bharath:So, it's pretty simple, it doesn't involve… it's kind of similar to the get header and get payload, interface we have, like, today.
Bharath:So this is, like, how I think it would look like with stake builders.
Bharath:Things get a little trickier with off-protocol builders, so…
Bharath:Technically, like, in this case, proposals will have to act as of the self-build, because the protocol has no idea about the builders.
Bharath:The proposers, like, and the proposer have to… has to sign the payload envelope.
Bharath:Right? The bid, it doesn't have to sign the bid, because I forgot, like, it's because the spec doesn't enforce that the proposer signs the bid.
Bharath:But it has to sign the envelope, which is usually with the relay, which is, like, since it has the entire payload, right? But to sign the envelope, they require, like, a full payload, the execution request, and the commitments from the relay to sign it.
Bharath:So, we can introduce… so, I'm just introducing this notion of a blinded execution payload envelope. I'll get to the flow of how the builder APEC would look like, and maybe that… it makes sense.
Bharath:So I'll just introduce a blinded execution payload envelope. This is basically the execution payload envelope, but then we just have the roots of the payload execution request and the blob KCG commitments. Everything else, like, is the same.
Bharath:So…
Bharath:The interface, the flow would look like this. The proposer asks for the execution payload bid. It receives the execution payload bid back from the relay. The relay also sends the payload route and execution request route, because that data is not included in the execution payload bid.
Bharath:The proposer constructs a blinded execution payload envelope with the payload route and execution request root.
Bharath:If it likes the bid, it also embeds it in its beacon block, sends the beacon block and the blinded execution payload envelope to the relay.
Bharath:Both the relay and the proposal broadcast the beacon block.
Bharath:And then, and then once the beacon block is broadcasted, the relay can construct the full execution payload envelope from the blinded execution payload envelope, because it's essentially the same, it's just the hash tree roots of the data.
Bharath:And then once the relay has that, it's able to, like, broadcast the execution payload envelope, the signed one, to the PTC committee. Again, these are, like, off-protocol builders who are not staked in protocol.
Bharath:Right? You just, like, by sending the payload route and execution request route here, which, in my, in my opinion, like, just helps, helps in, like, not having, like, a third API call, where now the beacon block has been sent. Since you can only construct the envelope with the beacon block.
Bharath:when the beacon block is, like, set, like, it doesn't involve another API call where the proposer asks the relay, hey, now that the beacon block is set,
Bharath:I need to sign the envelope, like, can you get me the envelope that requires another set of, like, API calls? I believe, like, sending the payload route and execution request route, like, like, lets us, like, avoid that.
Bharath:So, yeah, so this is, in my opinion, like, how it could look like.
Bharath:And that's pretty much it. Like, I just wanted to, like, take the time to, like, just kickstart, like.
Bharath:discussions on how the builder API could look like. There are some open questions. One is, like, how will the builders get the free recipient of the proposal? Today, we have the off protocol, like, validator registrations. Like, clients send validator registrations to the relays every epoch.
Bharath:In some discussions, like, I think Porto suggested that, we could send the fee recipient along with the request for the execution payload bit, then the relay or the builder just, like, at that point, they have to, like, seal the block with the payment transaction if they're doing, like, off-protocol payments.
Bharath:Or, they,
Bharath:Or if they're just doing a trustless payments, then that's fine. Today, like, Justin suggested, like, adding a gossip topic to communicate all this. So I think this is kind of, like, open to discussion. Of course, like, the other question that I raised, will we support, like, off-protocol relays, or will clients only support talking with stake builders?
Bharath:One thing I want to get out of the way is, like, I feel like, irrespective of whether we support off-protocol delays or not, it's generally useful to have a specification for how the builder API could look like.
Bharath:And of course, like, we can always make the design better and stuff.
Bharath:So, yeah, that's just more information. I have a couple of design docs, and I've started just writing the builder specs for this. So, yeah, I think that's… that's… that's all I have for now. Any questions?
Bharath:Happy to, like… Stop.
Justin Traglia:Thank you for the presentation, Brah. There are some questions in the chat, but I think we're a bit limited on time for this call.
Justin Traglia:So, I suggest we take these offline.
Justin Traglia:Would that be okay?
Bharath:Excellent.
Bharath:Sounds like a blood.
Justin Traglia:Okay.
Justin Traglia:Thank you. Let's get into trustless payments. We only have 23 minutes to discuss this. Alex?
alex:Yeah, thank you, Justin.
alex:Yeah, so I think the question is, for most of the people on the call, probably already pretty clear, but maybe for some of the listeners not, so…
alex:I would summarize it as…
alex:really, yeah, speaking personally, during DevConnect, perspectives came up of people feeling that it would make a lot of sense to split trustless payments and consider it apart, people saying that they weren't convinced that Trustless Payment was the change that should go into Ethereum.
alex:And I guess ever since, I've been trying to, like, understand that myself, bring together perspectives, and see if we can resolve contention, because I will say that in my exploring, it's very clear that there's people that feel strongly it should not be in Glamsterdam, and there's people who strongly feel that it should.
alex:So to keep things, like, realistic, I think the question that I'm posing here is, should trustless payments be removed from the Glamsterdam update? I also think, for purposes of a smooth discussion, it's good to keep staked builders in.
alex:there is actually perspectives that I've heard of people saying, no, no, like, Trustless could go out, but I think Stake Builders should stay in, so that is a branch. I want to note that, but yeah, I would just keep them together for now. I also really want to add still that,
alex:both sides seem to want a better Ethereum, right? Like, whatever your view is, even. It's like keeping sides out of it. Whatever your view is for what should go into Ethereum, everyone involved.
alex:thinks that whatever their perspective is of what should happen is gonna make Ethereum better. I think Ethereum will be fine either way. I'm definitely not assuming, like, the hostile intentions for anyone or anything like that. Also good, I think, to say that, as Alex, I'm one of the people running the ultrasound relay, and so we're for sure biased, right? Like, whether we're right, that we think
alex:not putting trustless payments into the protocol is good for us, yes, but also good for Ethereum is, I think, exactly the topic that people differ on, of opinion. So I'll, like, pause there. Yeah, I just want to make sure, like, is the question clear that I'm trying to ask?
alex:Yeah, I'll leave it there.
Justin Traglia:So yeah.
alex:That's the…
Justin Traglia:The question is clear. I mean, should we, remove… should we keep trustless payments or not, is essentially it. How are people feeling?
Enrico Del Fante (tbenr):I can have a little comment, just to start up, so…
Enrico Del Fante (tbenr):as… as… from the core dev perspective, seems like trustless payment is… is… is…
Enrico Del Fante (tbenr):is a complete solution, gives everything in protocol, which makes sense end-to-end. What is probably unclear from our perspective, what are the downs… downsides, what are the…
Enrico Del Fante (tbenr):effects on the… on the… on the builder side, where… where actually are the pain points for you guys, to us to understand better your point of view?
alex:Yeah, okay, like, I'm happy to get into those. I think also even we may have some builders on the call, which could be interesting.
alex:Okay, so that's, like, I do want to highlight, like, from a lot of people, I heard that actually their major gripe was, the benefit is too small, so we shouldn't do it, and I know that that's… it's not that simple, that's actually a very complex position to take also. But then the next thing I often heard is, like, yeah, even if I agree with you, or agree with the perspective that
alex:the benefit is small. I'm not sure what the downsides are. I wrote recently this ETH research post where I tried to get into it.
alex:I feel like the biggest downside that is seen, but again, talk to people, you hear it's one of many, is that
alex:the…
alex:Introducing this new path?
alex:may mean that the out-of-protocol block-building market starts looking very different, and starts centralizing more. Like, in a way, what people are saying is, we're not expecting this
alex:to help much in block building. We think it will be the same people building blocks, we think there will maybe be less people building blocks, you're actually reducing how many different people will be building blocks. And also, like, the barriers to doing it, the costs to doing it.
alex:may become higher. So what people will often say is, like, there doesn't seem to be a clear benefit, there does seem to be a clear cost.
alex:I'm trying to be mindful of the time. Like, in very, very short form, like, people feel that there's a kind of prisoner's dilemma, where if we introduce a trustless path, what will happen is people will use the trustless path. I will highlight there also that
alex:proposers that refuse to use relays, I think, are gonna be better for trustless payments. I think they would get paid more in the future with this change. The only problem that many see is that
alex:This may also mean that all builders become direct-to-proposer builders, and if all builders, or at least the dominant builders, become direct-to-proposer builders, there's really very little reason left for a relay to exist. So, if you felt like relays were doing anything of use, like, previously, then whatever you thought that the benefit was may go away, and like, you know, one of these obviously is to
alex:Make sure that all proposers have, like, access to the same payment through, like, making builder competition very easy on a very wide set of proposers.
alex:Yeah, I'll leave it there. Maybe there's still a builder that could, add in.
alex:But, yeah, I'm curious to hear if that covers it, or if somebody wants to add something there.
george:Yeah, sure, I can speak. So, from Titan Builder. So, there's,
george:A few angles here as to why we think there's a cost to the outer protocol blog building market.
george:So, like, to continue on Alex's point on centralization, we think…
george:That, having direct connections is potentially quite…
george:centralizing for the general builder market. If there's an advantage to connecting directly to validators.
george:You then need to speak to validators to get connected, and I know there's been some discussion on that validators could connect to any builder they want. You get trustless payments, there's no issue.
george:Our concern there is that…
george:Payment is not the only thing that validators need. Validators have other preferences, for example, OFAC.
george:And that requires something else other than a trustless bit. That requires, like, a personal relationship, some kind of…
george:agreements, SLAs, etc. And so then that requires new builders to go in BD with all the big staking pools, which is just impossible.
george:And then, would add the other part to…
george:I think on to also your point, Alex, you said that relatives using trusted payments will get higher bids. I think it's actually the opposite.
george:And I think the reason is that if we have an unconditional payment, there's now a risk to our bid. So, as a block builder, there's quite a significant amount of blocks where we as a builder take zero profit. We bid 100%, a lot of builders actually bid plus 100% on some blocks.
george:Currently, if there's some bug in our block, you know, things happen.
george:the, like, this gets validated early on in Optimistic Relaying, it gets pulled very quickly, and that normally is the bid that is not delivered. There's no… but, you know, if with direct connections and trustless payments, there's no verification, any bug we have in our code as a builder could potentially cause us to miss a slot, and if there's a, you know, 100 ETH block, we're gonna make zero profit on that.
george:There's a non-zero risk that we miss out, and we make zero profit, that's negative EV, and we're not going to bid that value. I think they're the two big ones.
alex:Yeah, maybe to clarify a little bit, so the… the… when I said…
alex:a higher bid, that's from the perspective of the, I would estimate, maybe 7% of proposers, but maybe even less, that refuse to use release today and local block build. I think if you're local block building, this might result in a slightly better bid for you, but that's already a very small group, and this pushes the Overton window a little bit on this discussion.
alex:A lot of people I've spoken to will say that
alex:if that small group is the only one that moves, then does this make sense at all as a change to put in? Isn't there other stuff that is higher priority?
Justin Traglia:Data always?
DA | Flashbots:So, there's kind of two parts to this argument that I don't understand. The first is that, like, if relays are adding a service, and that, like, if they're actually improving the experience, then it makes no sense to me that they would disappear. So, like, any relay who's actually a positive force in the space?
DA | Flashbots:Should continue to be here.
DA | Flashbots:And… I'm trying to remember the second point, I don't remember.
Justin Traglia:Alex?
alex:Yeah, just maybe on the point of, like, why would a relay disappear? Because I think the intuition there is quite sensible, it is that
alex:If you have public bids in relay auctions as you have them today, and I'm a builder, it becomes very natural for me to say, hey, what is the top bid in the network right now? I look at all the relays, and then I make a private bid directly to the proposer that, is, like, trustless.
alex:Right, and if I do so, I can have a lower value block than the builder, but still get it on-chain. Because if I were to submit this same bid to the relay in the open auctions, a builder with a higher value block could see this new bid and say, oh, but my block is more valuable, and immediately outbid this bid.
alex:But since it's, like, a trustless payment, this becomes, like, a lot harder to see. It's direct to proposer.
alex:And it makes a lot of sense then that builders would say, well, you know, if you're not gonna bid with me in the same auction, but you'll use my public information to privately outbid me, I'm gonna go private as well. It makes a lot of sense. I think there's also, like, this is possible today. I also think if you ask me, on a very long-term timeframe, I think it's very possible that Ethereum goes there anyway, but at least it's not where we are today, and the out-of-protocol actors will say that we're quite happy with the equilibrium we have today.
alex:But we think this undermines it, because the moment I, as a dominant builder, decide, shit, they're using my public information to privately outbid me directly to the proposer, like, I would do the same. I start no longer showing my bids, I start bidding directly to the proposer, and from there, like, there's small steps to where you would only be left with, at least the dominant builders bidding directly to the proposer, and then I can say just very concretely, us as a relay, our revenue comes from those dominant builders. If they bypass our
alex:auction.
alex:I'm not sure how I could pay for the server costs that we have today to run the ultrasound relays, so that seems kind of straightforward, at least that part to me.
DA | Flashbots:I mean, we've already been approached by Relays who want to offer us sealed bidding, so if this is actually, like, the equilibrium collapse, then, like, it'll happen whether trustless payments exist or not.
Barnabas:I don't think we should…
Barnabas:I don't think we should pay for a middleware that Ethereum doesn't actually need, unless we essentially need them.
Barnabas:So, like, why do we even need relays at all if every block, every bit, would just end up publicly?
alex:Yeah.
Barnabas:minimum.
alex:you know, like, I really like the sentiment, but I would also immediately say, like, I'm a little bit alarmed, because I feel like if you go to talk to a blog builder, they will explain to you very clearly why
alex:there is no expectation of the bids becoming higher towards the proposer. Like, I think the expectation is there would be fewer builders, those builders would have higher costs to do what they're doing, but it would be harder to compete with them.
alex:Like, I like the sentiment of, like, why would we pay the relay if we don't have to? But at least from myself talking to builders, it really doesn't sound like you're gonna get higher bids, by the end of this.
alex:So, and that's kind of my call to say, maybe we should explore this a little bit more, maybe, like, this part of the EIP hasn't been considered enough yet.
alex:But I want to be careful there. It is also, to me, a difficult trade-off, and I can't predict the future, of course.
george:Would that relays offer builders access to all of the stake?
george:From the builder perspectives, that means any builder can access every single validator.
george:And that, I don't think is true if you have, like, no relays. If you're having direct connections because of OFAC and other preferences, you are not going to have intermediate access to all the validator stake for any new builder that spins up.
george:That, I think, is very centralizing for the building market.
Enrico Del Fante (tbenr):I don't get that much the, oh fuck, Argument, because if… if…
Enrico Del Fante (tbenr):I am a proposer, I want to go only with… directly with builder, and there will be a public knowledge that a builder starts censoring somehow, and I'm immediately excluded in my selected builder.
Potuz:You're not understanding, Enrico. It's the other way around. The point is that the relay actually offers the fact that they are filtering OFAC transactions, and apparently proposers want this.
Potuz:If you are in certain jurisdictions, and this is.
Enrico Del Fante (tbenr):The surveys that I'm.
Potuz:Currently, we want to actually… this is an argument pro.
Potuz:Removing trustless payments. Oh, the other way around. It's surprising to see this on the record on a public call.
george:So, validators want this. This is, like, they are going to connect directly to builders. So, they're going to choose to… these validators that want this, and there are validators that want this, because we saw, historically, ultrasounds, which is the most performant relay, and historically was head and shoulders above other relays, delivering the best bids.
george:before they had OFAC centering for some validators, some validators were not connected to them, so some validators will not connect to the best bits. And so validators will want this. And so, to get this, validators are going to then connect directly to builders, and they're going to have an agreement with the top-end builders, and any new builder that wants to connect is not going to be able to connect to them.
george:This is, like, this is not a good thing for the network, of course, but this is just, like, a fact of reality, and it's gonna enshrine some builders.
Enrico Del Fante (tbenr):So it's a plus 1 for me.
george:Is there a plus one to enshrined builders?
Enrico Del Fante (tbenr):No, I mean, to not have this guarantee.
george:No, but it's gonna happen regardless, right? Like, whether we have trusted payments or not. What's the argument that validators won't do this?
Barnabas:But they can still use the relay, right? Like, we're not…
Potuz:I know that they're not going to use this. I mean, validators are going to go with… they do this now with a trusted player, which is the relay. And they were going to continue doing this with a trusted player, which are the builders.
Potuz:I mean, you might have been…
george:There's a key definition.
Potuz:we don't want to help them do this. We definitely do not want the problem to actually help them.
george:There's a… there's a key difference here between connecting to a relay that allows all builders, and connecting to specific builders. Like, it's economically rational for relays to have as many builders connected as possible, and to get the best bids. For a builder's perspective, it's not… I'm not gonna, like, send my bids to anyone else, right?
george:And so, there's… you are… if you connect to one relay or two relays, you then get access to all builders and any builder that wants to connect. But for… if you connect right to builders, you don't. I think there's, like, a clear distinction there of why one is worse than the other.
Potuz:I think you're making a point about, like, builders being… not… not having access to proposers, which is true today in the system in which you need to make a BD investment to access proposers, which is something that relays constantly are posing about.
Potuz:On APBS, this no longer exists. Validators are going to connect to whomever they… someone posts an address on-chain, they can connect to. And I agree with you.
Potuz:This means that they need to trust people that they may not know.
Potuz:And the relays are offering this service of saying, we will actually do the filtering of OFAC transactions. Now, if this is put forward as an argument to why we… the protocol needs to support this system, I think we would be absolutely crazy to use that argument and actually support that system.
alex:Right, like, and this part, I think I can see. What I guess I find more concerning is, like, if it's…
alex:does, there's a lot to explore there, but does reduce the number of builders that you will have available in the set, then wouldn't that be bad for the full proposer set? Right, there's a small group for which I think things improve, like, I can now get better bids, and it's good for this small group, but I imagine for the big group.
alex:that is already trusting relays, and therefore getting access to the full set of builders that want to send bids to them, their optionality reduces in a way. Like, they get fewer builders now that they can source these higher bids from, and again, maybe that's fine, this is a pretty nuanced future to imagine or explore or weigh.
alex:But it is something that I expect could very well happen. My second most likely scenario is that relays and builders will work very hard to make sure that most of the proposers don't use trustless payments, because then again, you can go back to having all builders compete through relays for all proposers. But again, that feels so, to me, like, counterproductive. We'd be investing to make sure that people don't use trustless, that
alex:Feels like we're working against each other.
Max:Oh, hi everyone, Max from the Asus Relay.
Max:I've recently joined the Sigma Prime team, to help them work with their builder.
Max:I wanted to just chip in and summarize the argument here. From our perspective, ASIS is a quietly running small public goods-funded project, and we agree with the sentiment from
Max:Titan and some ultrasound. We think the effect of EPBS in the long run is to… is to attract the builder market, and we think what you're going to find is that you'll have… Today, we have, you know, two dominant builders and a few others
Max:And a lot of experimental people, you know, trying their best to get into this market. What we worry about is that if the relay disappears, you remove open access to that market environment.
Max:It will not be profitable to run a relay. Public goods-funded relays will disappear.
Max:We certainly don't intend to put our capital on the line to, to keep the market
Max:open. I'm also kind of interested in the point which has been covered in the chat here, which is that, as far as I understand EPBS, it doesn't actually enforce any of this. You could build MevBoost again if the proposer is the builder. So, we're kind of having an argument about what the protocol should do, but it is not quite
Max:the protocol. And until we clear up the design of the builder APIs, it's really difficult to give you a complete view of how we think the market's going to evolve. But there is a lot of… there's a lot of complexity here, there's a lot of complexity in scaling. What we would urge is a bit of caution, a bit more time to analyze it. Ideally, we'd see the EIP
Max:split up, and so we can analyze this a bit more in the future. I'm not saying this isn't the direction we want to head in, I just think there needs to be a bit more time and thought put into it.
Max:Act.
Matthew Keil:And this is the sentiment that we've gathered from a number of people after talking at, at DevConnect, is, you know, from an ethos perspective, and from a sentiment perspective, we really appreciate
Matthew Keil:The protocolization of removing some of the external actors and their influence over the process.
Matthew Keil:But the complexity of the idea is gonna build a lot of tech debt in that is gonna be incredibly difficult to remove if we do decide to come up with, better solutions.
Matthew Keil:And really, this is the crux of the situation, is that while we agree in premise, and we really do want to see some action.
Matthew Keil:We don't necessarily think that, doing anything is better than doing the right thing, and that there just needs to be some more research on some of these, more nuanced perspectives, because it's going to be very difficult in order to actually indo the enforcement
Matthew Keil:of, this in-protocol flow, and we just have a feeling there's gonna be a ton of activity, in order to circumvent it, and we're gonna end up building a Ribs-Goldberg machine that is incredibly difficult to back back out.
Matthew Keil:And while we are extremely bullish and extremely, excited to see a lot of the slot restructuring and some of the timing, restructuring and the scaling, benefits, because there are a lot, like, POTUS has done an amazing job
Matthew Keil:really looking at a very big picture, splitting the EIP into the two fundamental pieces, is the slot restructuring.
Matthew Keil:And then a lot of the builder flow stuff.
Matthew Keil:I think is just at least worth looking at from a…
Matthew Keil:from a delivery perspective, and being able to do the DevNets, with a lot of the slot restructuring, which would give us time, or at least the first DevNets, which would give us time for some of the subsequent DevNets, to really hammer out the details of the trustless payment spec.
Matthew Keil:In order to make sure it really is gonna be not only effective, but efficient.
Enrico Del Fante (tbenr):I can bring the perspective of Stefan, who's working on it. I mean, his feeling is that it's the actual complexity implementing those things related to trust payment are not…
Enrico Del Fante (tbenr):that… big.
Enrico Del Fante (tbenr):So, that's why we are actually okay to have it in, because they are already in.
Enrico Del Fante (tbenr):And I think we did a lot of things in the past that…
Enrico Del Fante (tbenr):We can adjust and remove additional forks, there's no that much complexity.
Enrico Del Fante (tbenr):That we have to deal with if we want to…
Enrico Del Fante (tbenr):go in a different path, and I also think that
Enrico Del Fante (tbenr):From another perspective, if the number of relays goes down, I think it's a sign of
Enrico Del Fante (tbenr):It's a good thing.
Enrico Del Fante (tbenr):If some release goes out of business.
Matthew Keil:No, and I totally agree. I mean, we've actually already got the code built in order to do some of this trustless payment stuff.
Matthew Keil:As far as the state transitions, etc. But, and I will also say it does feel weird to be advocating on this side of the discussion. But I just want to take a pragmatic view of it.
Matthew Keil:So, yeah, I think we're, you know, as a team, and I think a lot of the other people from other teams also agree that if, you know, we're going with the consensus, and we do feel like that, but we'd like to at least just
Matthew Keil:Get it out in the world, to talk about it.
Justin Traglia:Notice.
Potuz:I want to be a little bit pragmatic and to the point. I would just want to collect arguments to removing something that is SFI.
Potuz:More than just…
Potuz:feelings about it. We want to have an actual argument to why we should remove this feature.
Potuz:And yes, I hear… I heard a couple of them that are… that seem to be valid to me. It adds protocol complexity, true. It adds implementation complexity, true.
Potuz:It removes this, property of,
Potuz:validators that want to trust builders, to honor OFAC transactions, Yeah, that's…
Potuz:Perhaps. I mean, that's certainly true. Do we want to use this in the protocol? Certainly not.
Potuz:And there's also this ill-founded statement about
Potuz:Doing this will enshrine builders. Yeah, we are definitely enshrining builders, but doing this will centralize the builder market, which is not only is…
Potuz:like…
Potuz:it's not really a founded statement, it's just a statement, but it's not… it's not explained how this is going to be the case. And it's also counterintuitive, given the fact that EPBS actually gives access to anyone to be a builder.
Potuz:Removing trustless payment is not about, like, removing the option for a proposer to get a payment and be paid. This is more about builders and actual proposers.
Potuz:Removing trustless payment also removes the option for someone to bill, to bid bids for someone else.
Potuz:So, this proposal of removing trusted payment is mostly about removing the access to the builder market to people. And at the same time, we're arguing that keeping them will remove
Potuz:access to the builder market to people. So I think this is very counterintuitive statement, and even if you don't agree with me, at least you should realize that this is not really proving the fact that we will centralize the builder market by allowing anyone to actually provide bids.
Max:It's certainly difficult to prove it, but there are a large number of variables changing here all at once, and anyone who says that they can understand
Max:how the equilibria are going to settle after this is, you know, it could not be telling the truth. So, you know, what I would propose is that we do things… we make changes in small chunks.
Max:And we keep analyzing the situation, because I don't know any proposers who are desperate for trustless payment features at the moment. I think that this is coming well-intentioned from the protocol side, because we want to get rid of the relays and we want to minimize sources of trust. But there just doesn't seem to be a need to rush this right now.
Potuz:it's not only about this, it provides… I mean, the number of benefits of trustless payments are large, and we've documented many of them. It's not only about even trust assumption, it's about, like, resilience, it's about liveness, it's about getting access, it's about being able to remove
Potuz:self-building as a requirement, it's about scaling itself. So the number of good four proposals are good, and I'm not even mentioning here, because this discussion today shouldn't be about why to include them, it should be about why to remove them.
Potuz:And that's why I want to point out that I want to hear arguments, strong arguments, as to why to remove something that we're all coding, and it's already specified, and it's already in spec tests.
Potuz:So, I mean, if we are going to go into a discussion as to why to include them, I can just provide a huge list of arguments. This discussion today should be scoped as to why to remove them, and we haven't seen many arguments. We've seen even this OFAC angle as an argument.
Justin Traglia:Agreed. Alex, and then Bruno?
alex:Sure. Yeah, I just wanted to quickly say that,
alex:I appreciate the point that you were making about, like, how can we somehow formalize these arguments more, and then you said something about having them included in the SFI? Like, if you could say more about that, I'd be, like, very interested, because I think, yeah, having some of these written down and somehow clearly noted, at least, if we aren't, removing trust, this makes…
alex:sense?
alex:But then, of course, yeah, I still, like, to my best estimation, I think it would make sense to not have trustless, and I…
alex:the way I would phrase it is, for example, something we can say is, if there's a bunch of protocol actors now that say, trustless will not be used, it is not worth it to put these changes into Ethereum, then at least, to me, that sounds like a pretty strong argument, and I think also one where it's going to be very clear after the fact, once the new equilibriums are very clear.
alex:clearer than today, whether people ended up using it and it was, like, a good use of our time, or whether, like, some of these things stay more speculative, and then you did give a list of, like, other benefits that you think there are.
alex:Yeah, on that, I can only say that some of these that you named, I think, are also, like, contentious. There are other perspectives of people who feel like liveliness will not improve through doing this, or, like, censorship resistance will not improve, or maybe, like, there won't be more builders. But, yeah, I'm looking at the time, and I'm like, yeah, how can we ever go through all of it?
Justin Traglia:Bruno?
brunoflashbots:Yeah, I wanted to make a short comment. Like, trustless payments will happen, either off-chain or on-chain due to a free option. That's no ways to surround that. Even for optimistic relays, they will implement trustless payments. If they don't trust the builder, they will have to make their mistake.
brunoflashbots:Otherwise, they can exercise the free option for free. So that, either way, will happen.
brunoflashbots:So if it happens, why just not happen on chain?
brunoflashbots:So it's not a good… for me, it's not a very good argument against…
brunoflashbots:Build decentralization, because, again, this will happen off-chain.
Justin Traglia:Lorenzo?
Lorenzo:I just wanted… Oh, one second.
george:Great.
george:Hey, sorry, I'm just gonna speak from George's mic. I think my point was to POTUS, where he was asking, like, for good reasons why the builder markets would be centralized, and I think there were a few that were discussed
george:One would be that, because builders are now staked, they have to stake in advance the balance to bid, and then if they don't have the capital to bid, they wouldn't be able to bid. If there is a big volatility event, they would decide whether to bid lower, because otherwise there are no capital.
Potuz:they need to stake only to be a validator. To bid, you don't need the stake. You can bid off protocol… we are… we agreed that we are going to implement.
george:I was about to make that point. I was about to get to that.
george:So… they can,
george:Sorry, I lost my train of thought. So yeah, so if they do want to bid on-chain, they do need balance, and I think we all agree that to stay capital, and with the deposit queue, you maybe need, you know, one week or two weeks of bids, which can be, like, quite substantial, and also you need to be in advance
george:Deciding that you are gonna be a builder, and potentially a lot of builders bid for just a few number of slots.
george:Now, if you do want to bid off-chain.
george:You basically either bid directly with the proposer or bid through a relay. Now, we… I think we agree on this call that they will be more expensive to be a relay, and potentially relays will cease to operate. I think there were a few good points on that as well on this call already.
george:And then the point is, okay, you can still bid with an off-chain bid to a direct connection with the proposer, and the point is that only a handful of builders would be able to do that, potentially, you know, 3 or 4 or 5 of the largest ones, but definitely not a random builder who can just decide to start up
george:Because you need to get adoption from proposers, and it doesn't make sense if you can build just for one proposer, and then if you cannot build for many, then it just doesn't make sense to…
george:To be an off-chain builder, so to speak.
george:I see Paulo shaking his head, so maybe there's a counter-argument.
Justin Traglia:Otis, do you want to respond really quick, and then Bruno? No, no, no, no, Bruno's… there's people we can't read. Yep. Bruno?
brunoflashbots:Sorry, sorry, it was, I did not want to raise a hand.
Justin Traglia:No worries. Lorenzo? Or I guess he didn't have his hands up, he was just talking.
Justin Traglia:Bruno, could you clarify the trustless payments?
Justin Traglia:Thank Alex asked about it in the chat.
brunoflashbots:Yeah, I think my point is mostly either the relay has trusted relationships with the builders, or they make them accountable by staking.
brunoflashbots:I would rather say I would prefer to have a permissionless set than a trust-me-bro relationship, so…
alex:But, yeah.
alex:Maybe, like, so this, again, it feels to me quite, like, maybe relays will be able to maintain the equilibrium of today, and they keep builders coordinated around doing what we do today, but it seems to me, like, if you do trustless payments and builders start doing direct payments to proposers, then there will only be a very small set of builders that is really good at this, the builders that pay the highest bids. So I think what you will see is that really only those small set of builders will be landing all of the slots.
alex:And then from there, it just becomes very natural for this builder to say, hey, proposer, right now it's a trustless payment I'm making, but if you trust me, then I can give you a higher bid, because there's all kinds of, like, cost involved with doing these, like.
alex:staked single bids that I can send per pub key over the P2P with, like, timing games that get more complex. Like, it makes a lot of sense to them become trusted. So what I predict will happen is that, yeah, for a small set of local block builders, they will go to Trustless and get those extra blocks, but for the massive set of proposers that we have.
alex:They will build trusted relationships with a smaller group of builders than we have today, which to me, that sounds like more trust me, bro, not less trust me, bro.
Justin Traglia:Bruno, would you like to respond before moving on?
brunoflashbots:I mean, my point is that we'll… for small builders, I mean, again, relays will have to either
brunoflashbots:so for, like, for small builders, you have to make them accountable, right? If they don't have reputation, you either make the mistake.
brunoflashbots:or… Or you trust them, but to trust them, they must be sufficiently big.
brunoflashbots:To statistically infer if they are exercising the free option or not.
brunoflashbots:Therefore, they will stake. My point is, small builders, they will have to stake the release, either way.
brunoflashbots:In either… if we implement it or if we don't, unless you will allow small builders to exercise the free option, which… that…
alex:simulate your bid. It's not 100% necessary, and again, gets a little bit into, like, how much is this used on the protocol today, but today you can just send a block to ultrasound. If you don't have any stake, we'll simulate it for you, and then any block of any size you can offer to the proposer, because we'll take responsibility for it. And also, like, this, again, will change tomorrow, because then if we need to be staked for this as a relay onto the protocol.
alex:then we have to do a risk calculation, right, and say, I don't know, I…
brunoflashbots:The point is, I don't know if you can do that with the blobs. You can do this with the payload, but I don't know, I'm not sure you can do this with the blobs.
alex:Yeah, we'd have to dem… well, we have to demand they send everything, right? And… I'm not sure.
alex:Yeah, I guess I'm not well-read on this topic, I don't know exactly how you could withhold something of a blob when you send it to release, but normally you're expected to send all the blobs as well.
george:If the argument on this is that…
george:Yeah, sorry, the argument on, like, you can't send blobs is that the data is too high. There's some work implementations to fix this. So, one of the co-examples that's live now, actually, and a lot of relays, is that you can send deltas of blobs, so you only send a blob once. Blobs usually don't change, and so…
george:You can stream the blobs in as the builder receives it to the relay, and then you don't have a networking latency cost as a builder.
george:Submitting to a ruler.
Justin Traglia:Okay, let's try to wrap this up pretty soon. Otis suggested that we do a temp check. I'm not exactly how that should be done. Stokes, do you have any recommendations here?
Potuz:I'm not sure Alex is even listening.
Justin Traglia:Oh.
Justin Traglia:I think he's listening.
Justin Traglia:He is messaging.
Justin Traglia:Okay. Obviously, no decision will be made at this call, but yeah, temp check. Enrico?
Enrico Del Fante (tbenr):Yeah, just one final thing, so… Very, very simple.
Enrico Del Fante (tbenr):Trust-trust payment does not prevent the status quo to continue.
Enrico Del Fante (tbenr):And I think we all agree about this.
Enrico Del Fante (tbenr):So, we are all talking about, we don't know where the equilibrium will be, After…
Enrico Del Fante (tbenr):Which means, you don't know, you want to find the equilibrium, which means, let's provide all the options, and the equilibrium will be found. If we don't provide the whole spectrum, we are faking, because we are not providing the options.
Enrico Del Fante (tbenr):So, let's provide the options. Everything really remains on the table.
Enrico Del Fante (tbenr):Options are more options, just more opportunity to find a new equilibrium, and let's… C.
Justin Traglia:Ouch.
alex:Yeah, maybe what I… I might sound a little harsh here, like, forgive me, but this is definitely, like, from the many people I've spoken to, this argument, I feel like I get a very harsh reaction from people that says, like, that is just not good enough for Ethereum.
alex:If you want to make a change to Ethereum, it can't be enough that you're saying, hey, this is a new option that wasn't there before, and we don't really know what it will do in the future, so therefore let's try it. I will acknowledge that there's always unknown unknowns and things that we can't know, but Ethereum as a protocol a lot of people that I talk to will say needs to make changes that very clearly, lots of people want, like, basically yesterday, right? And we cannot be spending time on anything that is of the sort.
alex:we don't really know what will happen. I guess we can't make a strong argument for why this would be used a lot of the time, so then we'll do it anyway. And I guess one more caveat is, but today this process is already really far. I've also heard that from a lot of people, and I think that's, like, a fair thing to bring up. But in general, for the process that we have for EIPs, I think a lot of people will have this strong visceral reaction of saying, like, there has to be a much stronger justification for doing something.
alex:Like, trustless payments.
Justin Traglia:Alex Tobes, We are going to talk about this at ACDC.
Justin Traglia:Next week, correct?
Justin Traglia:Okay, I guess no, Mike, he said yes. And a decision will be made then and there, and I guess clients
Justin Traglia:clients in the community should, I guess, review this call.
Justin Traglia:try to, like, listen to all the arguments, and maybe try to come to a decision themselves, and then speak up at ACDC.
alex:Yeah, I guess on that note, also, like, thank you. A lot of people have been listening, I think also a lot of these perspectives are coming in very late to the process, and I can respect that that is frustrating, especially if you've been working on this for a very long time. So, like, yeah, I really appreciate that people are even having this conversation, like, this late in the process, and listening to what,
alex:What people are bringing in, even if maybe some of these perspectives they find unconvincing.
alex:And again, like, yeah, maybe, that's also immediately a call for, like, please keep doing that, that Ethereum is a very large protocol now with many, many users. I'm sure all of us wanted to have many, many, many more still. And then, really, we should be listening to what, all of those users, like, including proposers, but also end users, I think, want.
alex:Yeah, so thanks.
Justin Traglia:Yep, thank you too.
Justin Traglia:Does anyone have any last thoughts before, ending the call?
Justin Traglia:Okay, thank everyone for attending. I will…
Justin Traglia:Talk to you in two weeks, and at ECDC. Alright, bye everyone.
Enrico Del Fante (tbenr):Bye.
Chat Logs
00:00:51
Barnabas:haven’t been to this many meetings with potuz as this week.
00:01:35
terence:Replying to "haven’t been to this..."
welcome to my life
00:02:00
Potuz:we haven't slept last week because of Fusaka
00:02:20
Barnabas:Replying to "we haven't slept las..."
excuses
00:03:29
stokes:there was some link confusion
00:03:35
stokes:i’ll try to ferry ppl over
00:03:48
Potuz:yeah that will delay people coming in for a while
00:06:47
stokes:maybe stop sharing?
00:06:52
stokes:yeah idk may help
00:06:55
alex:smart to put trustless last on the agenda 😅
00:09:49
stokes:correlation across slots?
00:09:55
Potuz:yes
00:10:20
stokes:Replying to "yes"
hmm my mental model is that the time window is more per-slot
00:10:42
Barnabas:This feels super complex to test.
00:10:45
stokes:Replying to "yes"
i think the jargon is that it is an ergodic process
00:11:03
terence:Replying to "This feels super com..."
why?
00:11:15
Potuz:https://ethresear.ch/t/dynamic-penalties-for-epbs/23472
00:11:16
alex:is it correlation per builder or across all?
00:11:26
Potuz:Replying to "is it per builder or..."
across all
00:11:30
stokes:Replying to "This feels super com…"
yeah i don’t think it’s that bad in isolation
the concern is more just putting more stuff into a single eip
00:11:33
Potuz:Replying to "is it correlation pe..."
otherwise you just shift addresses
00:11:48
Potuz:I checked the spec and it seems fully specified to me. It is a complex change though
00:11:51
alex:Replying to "is it correlation pe..."
makes sense. the stake would be a bit of a barrier i guess, but perhaps not enough 👍.
00:11:59
Dustin:Replying to "This feels super c..."
I guess the claim is that it'd be an integral part of 7732?
00:12:08
Potuz:but it is kudos to see a proposal that is fully specified and justified from research to full python code
00:12:21
Barnabas:Replying to "This feels super com..."
How would orphaned blocks be handled for penalties?
00:12:21
Potuz:liffe would be easier if all proposals are like this one :)
00:12:46
stokes:Replying to "This feels super com…"
i would imagine you ignore them
00:12:55
stokes:Replying to "This feels super com…"
but then a builder could try to influence fork choice
00:13:06
stokes:Replying to "This feels super com…"
to get around the penalty
00:13:17
Barnabas:Replying to "This feels super com..."
Penalty calculation would be part of forkchoice?
00:13:18
terence:Replying to "This feels super com..."
state transition function can tell if its an orphaned block vs a block with missing committed payload
00:13:24
Potuz:Replying to "This feels super com..."
how does the builder influence forkchoice?
00:14:14
Potuz:Replying to "This feels super com..."
and @Barnabas no, penalty is STF, not forkchoice
00:16:36
Barnabas:Would non finalization effect the penalty value at all?
00:16:45
Potuz:not
00:24:17
terence:wouldnt builder grief proposer then?
00:25:04
brunoflashbots:I think in that case the builder/relay should refund the block proposer.
00:27:45
Barnabas:I think we should aim to have liveness, and accept that fact that it might cost people money.
00:31:10
alex:interesting point actually. for us we have options to stake. but what about relays that proposers want to use that are not able or willing to stake the 32ETH?
00:31:19
terence:why do you need to send the block with bid back to builder vs just boradcast it over p2p?
00:31:36
Barnabas:Replying to "interesting point ac..."
they shouldn’t be a relay, if they not willing to put up 32ETH
00:31:51
Potuz:yeah it does not make sense
00:32:29
alex:Replying to "interesting point ac..."
based on? if that’s what the proposer wants, i’m not sure i follow why we’d block them from doing so. happy to just take a link to prior writing by someone.
00:32:56
Dustin:why have to sign the payload envelope? the builder should be signing
00:32:57
alex:Replying to "interesting point ac..."
this is less my argument for what we “should” do, more what may create an incentive to fork clients 😅
00:33:11
nflaig:Replying to "why do you need to s..."
we shouldn't, I don't think there are any major changes required to builder api `getHeader` is still fine as is, just need to change the type
and we can get rid of `submitBlindedBlock` as it's not strictly necessary
00:33:16
Dustin:I mean, sign something. but this is the proposer allowing its sig to be used
00:33:17
Potuz:It seems to me that the agenda should have been changed...
00:33:21
terence:thats for off protocol builder, i think he meant to sign the bid
00:33:25
Justin Traglia:Replying to "It seems to me that ..."
How so?
00:33:39
Dustin:Replying to "why have to sign t..."
I thought he specifically said the envelope, but ok, can be clarified
00:33:45
Justin Traglia:Replying to "It seems to me that ..."
Doing trustless payments talk first?
00:33:48
Potuz:Replying to "It seems to me that ..."
dealing with blinded objects does not make sense in the current spec, so this only makes sense to discuss if we move to unstaked builders
00:33:56
ethDreamer (Mark):Replying to "It seems to me that ..."
There are no need for blinded objects
00:34:11
ethDreamer (Mark):Replying to "It seems to me that ..."
That was a consequence of not having block payload separation
00:34:11
Lorenzo:Replying to "why do you need to..."
could be both? builder has an incentive to invest in p2p distribution similar reasoning as https://github.com/ethereum/builder-specs/issues/119#issuecomment-3199858239
00:34:18
Dustin:Replying to "It seems to me tha..."
yeah the unblinded one already goes out
00:34:24
ethDreamer (Mark):Replying to "It seems to me that ..."
Now that we have this, we can do relays without blinded objects
00:34:42
Potuz:Replying to "why do you need to s..."
yes it will be naturally both, but anyway the builder would want to wait for distribution
00:34:49
Potuz:Replying to "why do you need to s..."
before submitting the payload to p2p
00:35:12
Lorenzo:yep meant the builder could help with the inital gossip of the signed header as well
00:35:56
terence:Replying to "why do you need to s..."
keep in mind consensus block is very small comparing to execution payload so p2p distribution optimization may not be necessary, we can do more testing here though
00:36:31
nflaig:Replying to "why do you need to s..."
yes, could keep submitting beacon block api as well to allow builder to help propagation
00:38:35
Bharath:For off-protocol builder, the proposer acts as if they self-build. So the proposer is technically the builder. So the proposer needs to sign the payload envelope
00:39:08
Bharath:Replying to "why have to sign the..."
In the case where the proposer talks to the staked builder, the proposer doesn’t have to touch the payload envelope at all
00:39:21
Milos:What are the main objections to trustless payments?
00:39:28
Bharath:Replying to "why have to sign the..."
Off-protocol builders things get slightly trickier here
00:41:27
NC:Replying to "What are the main ob..."
The whole ePBS doesn’t prevent people from going off-protocol, and we sfi ePBS mostly because of scaling benefit it brings by restructuring slot, not because of trustless payment
00:42:14
Bharath:Replying to "It seems to me that ..."
I think we will have to blind the execution payload in the envelope when we talk to unstaked builders right? We don’t have to do payload blinding if we only talk to builders which are staked
00:42:32
Barnabas:The reason we use relays is because we can’t directly go to builders.
00:42:45
Potuz:Replying to "It seems to me that ..."
we hopefully never again need to talk to unstaked builders
00:43:02
Bharath:Replying to "It seems to me that ..."
Yup me too, but I m not sure if that will happen
00:43:05
Justin Traglia:It’s not really ePBS without trustless payments. The trustless payments isn’t really that complicated. Less trust in the system the better.
00:43:34
Potuz:Wow I was not expecting to see the OFAC angle on the record
00:43:47
Eitan:IMO Yesterday was a good example of why trustless payments is a good thing. When the circuit breaker triggered the network started producing local blocks. As local building becomes more expensive from a resource/bandwidth context this becomes dangerous. With trustless payments we’d never have to revert to local building
00:43:48
Bharath:Replying to "It seems to me that ..."
The builder-api with staked builders stays the same as the status quo today. But with off-protocol builders, blinding will be required IMO
00:43:58
NC:Replying to "It’s not really ePBS..."
But extra efforts required for implementing and testing it so we meet the 6 month fork cadence
00:44:23
Justin Traglia:Replying to "It’s not really ePBS..."
At this point, removing trustless payments will delay things more.
00:45:06
Lorenzo:Replying to "It’s not really e..."
would be good to understand this point better, according to some CL devs the complexity is low but havent heard from many / not sure if all have started implementing
00:46:20
Potuz:that's a feature not a bug
00:46:59
christophschlegel:If private bids are desired by builders, relays could offer them as well
00:47:19
Barnabas:Why do we need relays?
00:47:22
Bharath:Replying to "why do you need to s..."
Also the builder will require the beacon_block_root to build the execution payload envelope
00:47:48
Potuz:Replying to "Why do we need relay..."
apparently because validators want to censor OFAC transactions
00:48:02
Bharath:Replying to "why do you need to s..."
The builder could either listen to the gossip topic for the beacon block but getting it via the builder-api would be faster
00:48:26
Bharath:Replying to "why do you need to s..."
The builder could broadcast the ExecutionPayloadEnvelope faster and also aid in beacon block disemmination
00:48:47
nflaig:Replying to "IMO Yesterday was a ..."
but in case the network is unstable we might have less than 60% attestation quorum in which case payments cannot be guruanteed, so you would likely wanna local build anyways?
00:49:10
Potuz:Replying to "IMO Yesterday was a ..."
you are guaranteed payments if they are included
00:49:28
Lorenzo:Replying to "Why do we need rel..."
validators will censor whether there are relays or not
00:50:27
Dustin:well, it's something that's touted in lists of MEV relays today
00:50:35
nflaig:Replying to "IMO Yesterday was a ..."
but that's out of the control of the proposer, so it's no longer "trustless"
00:50:40
Dustin:it's not really a secret some people want OFAC compliance
00:51:01
Potuz:that's fine, but the protocol making protocol decisions to keep this service and favor it is absolutely crazy
00:52:58
Cayman Nava:The current design of trustless payments is not enforceable and folks have noted that the mechanism won't always be used. Doesn't sound like a robust design. The EIP should split out the entire staked-builder and trustless payment flow to allow for more research with better properties. This will derisk the scaling benefits of the slot restructuring / block/payload split.
00:53:00
Barnabas:We need to look at what is good for Ethereum. OFAC requirements is absolutely not a point of view Ethereum should ever consider. If it is, we have lost the battle.
00:53:59
Barnabas:If you are here because you trying to protect your “business”. Or afraid that you going to go out of business because a feature that Ethereum wants to introduce to make the protocol itself better, then its also not something that Ethereum should need to worry about imo.
00:54:00
Lorenzo:Replying to "We need to look at..."
I think this is missing the point, the point is that because (sadly) some validators are censoring, the effect will be a more centralized builder market
00:54:06
Potuz:Replying to "The current design o..."
how is it not enforceable?
00:54:19
christophschlegel:Replying to "The current design o..."
What is the problem of it not always being used? It’s already valuable to have the option to use it
00:55:22
Dustin:Replying to "The current design..."
Have never understood the "it won't always be used, don't provide it" argument
00:55:24
alex:Replying to "If you are here beca..."
yea that’s not the worry. the worry is that it is good for proposers to be able to source blocks from many builders. and this will likely result in fewer builders.
00:55:26
NC:Replying to "The current design o..."
The problem is we want the slot restructuring to pave road for 6s slot. This has nothing to do with trustless payment
00:55:33
Eitan:Replying to "The current design o…"
At the very least it is very valuable as a fallback mechanism
00:55:36
Dustin:Replying to "The current design..."
"we" want various things
00:55:46
Potuz:ePBS is completely open, the arguments being put forward is that removing gatekeepers actually makes for a closed system and this does not make sense
00:55:51
Dustin:Replying to "The current design..."
Speaking personally, scaling was secondary to me
00:55:59
george:Replying to "If you are here be..."
would note that as a builder it is net better for us to be enshrined... What im saying here is that there are some validators that require preferences other than pure bid value and if there are no relays there to offer this service they will connect directly to builders and potentially enshrine those builders
00:56:21
Dustin:Replying to "The current design..."
(caveat, in this particular way not speaking for Nimbus)
00:56:24
Justin Traglia:FYI I am okay with staying on the call to continue discussing this. Sorry, there wasn’t enough time allocated to this.
00:56:25
alex:Replying to "If you are here beca..."
(or both are true in this case, we think this may be bad for relays, and bad for 87% of proposers that seem to prefer trusting one relay to get blocks from many builders)
00:57:20
george:Replying to "ePBS is completely..."
In the past few years of relays have there been any examples of them gatekeeping?
00:57:38
Max:You can’t enforce it. Mike Neuder spent quite a bit of time going around in circles on the topic.
00:58:08
Dustin:Replying to "You can’t enforce..."
if people want to fake-self-build how is that ever "enforceable"?
00:58:13
Eitan:Replying to "ePBS is completely o…"
they definitely have the ability to gate keep regardless if they have or not in the past
00:58:15
Potuz:Replying to "You can’t enforce it..."
yes which is fantastic to see the same people that cosigned the paper of Mike about relays not dissapearing, not saying that ePBS will make them dissapear
00:58:29
Lorenzo:would trustless payments be SFI'd as its own EIP if it were not bundled with the slot restructuring?
00:58:32
Max:Replying to "You can’t enforce it..."
The question is whether there is an incentive to do this, now and in the future.
00:58:40
Dustin:Replying to "You can’t enforce..."
short of removing self-building entirely, which is even worse
00:59:09
ethDreamer (Mark):Replying to "You can’t enforce it..."
Self-building will likely go away in the future when L1 execution requires proofs
00:59:13
NC:Replying to "would trustless paym..."
Yea that’s a good angle to think about this
00:59:44
Dustin:Replying to "You can’t enforce..."
yeah, some years from now
01:00:10
george:Replying to "ePBS is completely..."
fair point. But there have been examples of proposers gatekeeping. So if we move the whitelist to proposers that I think worse
01:01:12
alex:i will say i think epbs does a pretty good job of supporting trusted payments right now. still some open questions but i see little reason to bypass today. not sure we’d ever have to remove it as specced. i’d be more worried we keep implementing things we don’t need (contested).
01:03:03
Justin Traglia:I am 🙂
01:03:06
Barnabas:I am
01:03:11
Stefan Starflinger:I am
01:05:17
Potuz:even if they aren't used in the default case, the mere existence of them is already good enough for liveness and resilience
01:06:08
Lorenzo:dont get this point tbh
01:07:00
terence:you can use execution payment
01:07:10
brunoflashbots:Sorry, small caveat. Trusteless payments either happens off-chain or the relay makes the builder set permisioned.
01:07:56
alex:@brunoflashbots can you clarify, trustless payments will happen off chain? today there seems to be a lot of trust involved actually.
01:08:23
alex:Replying to "Sorry, small caveat...."
ah, yea that is true. but you’re saying that is reason to build it into the protocol?
01:09:04
alex:Replying to "Sorry, small caveat...."
that seems a bit of a quick decision 😅 . there is a lot we could build.
01:09:20
alex:Replying to "Sorry, small caveat...."
if the cost was high i’d agree, but haven’t seen a clear argument why.
01:09:35
george:relays can receive the full block so will be the one responsible for delivering the full payload
01:09:42
terence:btw we are 10 mins over time, and we should have a next step before wrapping up this call
01:09:53
Justin Traglia:Replying to "btw we are 10 mins o..."
Yeah good idea.
01:09:56
Barnabas:I haven’t got a single argument why the protocol shouldn’t have trustless payments implemented as an option.
OFAC required validators are still going exist, and they can still use a relay, or they can go directly to a builder. This is fine. Ideally once FOCIL is around, all validators that require OFAC will just simply go away, as they actually are not a net benefit for the health of the network.
01:09:57
Justin Traglia:Replying to "btw we are 10 mins o..."
Let’s try to wrap up.
01:10:15
Potuz:it'd be nice to run a temp monitor so that Alex Stokes has something to go on on ACDC
01:10:47
NC:Replying to "I haven’t got a sing..."
But is this the design that everyone agree when we sfi'ed 7732?
01:11:17
Potuz:Replying to "I haven’t got a sing..."
not everyone, but this IS the design that was SFId
01:11:50
Justin Traglia:Replying to "it'd be nice to run ..."
I’m not exactly sure how to do the temp check. Any suggestions?
01:11:54
Justin Traglia:Replying to "it'd be nice to run ..."
Maybe a message here?
01:12:02
Justin Traglia:Replying to "it'd be nice to run ..."
In this thread.
01:12:03
Potuz:Replying to "it'd be nice to run ..."
ask @stokes
01:12:07
Potuz:Replying to "it'd be nice to run ..."
no clue
01:12:45
Potuz:Replying to "it'd be nice to run ..."
Prysm is for not removing trustless payments... (if some say they aren't they'll get yelled at)
01:12:50
nflaig:Replying to "I haven’t got a sing..."
the claim for a long time has been that trustless payments is required for pipelining which is not true, so we never had a honest discussion about trustless payments and whether it's good to include it or not. But we are having that discussion now :)
01:13:18
stokes:i am
01:13:18
terence:he probably left
01:13:20
terence:oh
01:13:23
stokes:one sec
01:14:13
stokes:for a temp check, i’d be curious for each client team to say if they think we should keep as-is or take out trustless payments
01:14:23
Potuz:happy someone is saying the obvious
01:14:46
stokes:i think all of the community voices here say take them out (except for some of
the flashbots voices?)
01:14:52
terence:is current status good enough for ethereum though?
01:15:02
Dustin:Replying to "i think all of the..."
community voices == relay voices?
01:15:14
brunoflashbots:Replying to "i think all of the c..."
XD
01:15:14
Potuz:Again the reasons to have them have been spelled out, the purpose of this meeting is to have a reason to remove them
01:15:14
Dustin:Replying to "i think all of the..."
they're part of the community, yes
01:15:22
Potuz:not to explain reasons to have them
01:15:27
DA | Flashbots:Replying to "i think all of the c..."
Flashbots has no set opinion.
01:15:30
Lorenzo:Replying to "i think all of the..."
builders, node operators (few of them that i spoke to)
01:15:32
stokes:Replying to "i think all of the c…"
relays, builders
01:15:44
Dustin:Replying to "i think all of the..."
oh I guess I counted Titan as both
01:15:50
stokes:yes
01:15:54
Caleb:the more options the better though, as long as secutiry can be guaranteed
01:16:05
alex:right, would love to have this conversation. it seems v contentious which benefits it brings. i will agree they’ve been explored and shared by many previously 👍.
01:16:44
stokes:Replying to "i think all of the c…"
yeah staking pools can also have a view on this
01:16:56
stokes:Replying to "i think all of the c…"
i think @Potuz has been talking to lido tho
01:17:01
stokes:Replying to "i think all of the c…"
as an example
01:17:19
Potuz:Replying to "i think all of the c..."
I have talked to a lot of community members
01:17:26
Potuz:Replying to "i think all of the c..."
didn't want to bring them here
01:17:34
Potuz:Replying to "i think all of the c..."
because it wasn't about keeping them
01:17:39
Potuz:Replying to "i think all of the c..."
but to find out why to remove them
Summary
11 highlights
· 3 action itemsExperimental
Summary
11 highlights · 3 action itemsExperimentalfork status and schedule
client updates
repricing updates
Action Items
Targets
- December 19th - Final EPBS breakout call before moving to ACDT00:01:05