ePBS Breakout #28

Transcript

Pooja Ranjan: Alright, I am ready to go whenever you are.

Justin Traglia: Okay, let's do it.

Pooja Ranjan: We are live.

Justin Traglia: Hello, everyone. Welcome to EPBS Breakout Call 28. 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. Version 1.6.1. We can and will publish a new release soon, if plants want it. I've shared the list of PRs. Since the last breakout call. The ones that have been merged have been checked. So, for the unmerged ones, please take a moment to review them. If you haven't already. And, one final note, The… sorry, the final breakout call will be on December 19th, 2025. After that, all of the, The last discussions will move to ACDT.

Which will be dedicated to Glamsterdam. 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 Tsao: We haven't made much progress last week because of Fusaka. Yeah.

Justin Traglia: That makes sense. Lighthouse? Okay, no one here from my house. Taku, please?

Enrico Del Fante: Yeah, not as much progress, as well. We are… we are currently working on… Gossip validation rules, mostly. Yeah, not yet fully ready.

Justin Traglia: Okay. Nimbus. Oh, hey Dustin. I just asked for an update on… from Nimbus on, glass implementations.

Dustin Brody: And was one provided? I obviously don't have context.

Justin Traglia: Nope. Asked right as he joined.

Dustin Brody: Right, okay. 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 Into truck? In an ongoing way. I don't know if there's a specific, set of specs or aspect of EPBS that you're… Asking about in this context? But yeah, we're continuing.

Justin Traglia: Okay. That's good enough. Lodestar? How is your work going?

Nico Flaig: 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. So, from last meet, we have the… we have, closed the PRs on, Sync Manager, and, 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, On the gossips of handling for, envelopes and bits. I think for, attestation, it was, recently merged. There's an open PR for, local blog building. 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. Okay.

Dustin Brody: Alright, sorry, can I…

Justin Traglia: Fuck.

Dustin Brody: 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 Brody: So, so I would like to actually hand this over to him, who has a lot more context on this than I do. Alright. Thanks As far as the EPPS and Nimbus?

Justin Traglia: Yep. Caleb, do you have any updates other than what Dustin said?

Caleb: None, none.

Justin Traglia: No worries. Let's move on to the agenda items, I suppose. Thanks for the updates from clients. I don't know what your first name is, but JCS Legal? Could you, talk about the dynamic penalty proposal that you brought up?

Christoph Schlegel: Right, yeah, I'm Christoph. J is for Jan. But you can call me Christopher. Okay, I can have some slides. Which I'm not able to share. You can also do it without slides, Or if somebody gives me the rights to…

Potuz: Booja?

Christoph Schlegel: 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: Yeah, maybe you have to start stop sharing, and then try again.

Justin Traglia: Alright, please try again.

Christoph Schlegel: Oh, that's Wix.

Justin Traglia: Sorry.

Christoph Schlegel: No worries. Okay, does this work?

Enrico Del Fante: Yep.

Christoph Schlegel: Okay, so this is how Nana Banana… Imagines EPPS to look like, and this is a free option problem on the right-hand side. That's what I wanted to talk about. So, Bruno and I have been, investigating this free auction problem. To remind you, so that the problem is that… you have commitment to a payload, but you don't reveal it when you make your bid. And then you have time to reel payload and blobs, and there's a time window between 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… 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.

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. We were looking into different mitigations, and, Have looked in particular into penalties and reward schemes, so we penalize, if you miss a payload or a blob. And… or we… we reward you for doing that, if you deliver it. 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, basically the… we introduce correlation, in… so we punish correlated failures, more severely than isolated failures. So the idea is if you… fail from time to time to deliver a payload. That's basically a very small penalty, but if we observe a lot of those,

Fair payloads, then we increase penalties, to… basically punish people for which something that looks like a free option exploitation. And the rationale behind that is that, first of all, it's a robust metric, a robust statistic to base penalties on, and the other idea behind it is that you usually observe this clustering, volatility clustering. So you observe that exercising, The pre-option, is… lucrative… in time intervals where you, basically have a correlation of, where you have clustering of opportunities. So you want to punish there. Right, so… 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, Can, can game them by basically increasing rewards for themselves, so penalties are less gameable.

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, Have a concrete rule of setting the size of those penalties. 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, payload failures, as I have been, recently. And then we use those, penalties, we keep track of them, and we use… we propose to use the payments 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.

So let me tell you briefly what is this rule. So, the idea is very simple, so you, have a penalty, which is this another, new state variable that we introduced, missed payload penalty. We would propose to introduce. 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. So that's the dynamic aspect of it. 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 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.

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… Online learning, kind of, standard results. 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. how aggressively you move it up and down, okay? So those are the two, two… Parameters that we introduced. Going up was a penalty, going down was a penalty. Then we did a bunch of backtesting, 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…

Free option, available, but at historical blocks, we looked into how that, changes, the effect, how effective it is to… To exercise this free option, and how much does it mitigate, and basically theoretical guarantees that you have from this online learning results are… 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 Mmm… Profitable to exercise, even with a penalty. 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. Are very much close to that theoretical. Guarantees that you want to achieve. You can also see, so those numbers are in east, the, sort of size of those,

Those penalties that he would need to… levy in order to, to, to, to achieve these, rates, so it would be… 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, In very volatile times. But on average, they stay sort of low, so that's… that's the point. So that's, the idea behind it. There are also graphs where you see, sort of, the fluctuation of Profitability, over time. With different, different parameterizations, and then you see, how, how large, penalties would be, if you would set them accordingly. And you see that, I mean, in these where volatility spikes, you would have

Also, spike of, the… Penalties. Okay, I think that's… Big picture… the… the… 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, According to… 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. 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 Missed, missed, payloads rates.

So, yeah, one can debate about it. What we can say is you can… Achieve, because there's also a sort of theoretical worst-case guarantees, you can achieve very robust, guarantees on these. 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… Sets the penalties, and then you have to… 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, 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

Of penalties at the same time, so you keep track of them together. And then you would, basically, deduct those penalties at the end of the subsequent epoch. From the, the builder, balances. 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. What I think is important as Twilight is that you should also, Put penalties on self-builders, and so you basically also need to keep track of those,

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… Yeah. going, through, I don't know, a relay or something like this, to, to, to, exercise the free option without… getting a penalty. So that's the idea. We've looked in possible issues that we thought about, probably other ones. 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. What we think is, sort of. It might be a problem, but what would you think is… is, 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,

miss, basically, the deadline for the payload timeliness Committee, if they do that. So, the risk is very limited. External builders, there's risk for them. Right? But then we… 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… the end of the world. It's a small amount, on average. 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? 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

Omit maybe sending blobs, if that is… introduces more errors in… to the, more failures in expectation for margin of safety. That might be downsides. It could be that, if there is… 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. In a client, that could cause correlated penalties without us actually, you know. 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.

But of course, that is true in general. I mean, also in… if you… 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. So, that's the high-level idea, and… What else are rewards? If you don't like that penalties are there. And then you can make that on expectation. Basically, you can… make it zero by introducing rewards, right? So we cannot do dynamic rewards, so in extreme cases, we have to punish. But on average, we can make you break even if you wanted to do that. That comes at the cost of additional issuance, potentially. Or we have to reduce…

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. Okay. 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 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 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,

About the builder payments in protocol, so I think, with or without these trustless payments. 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, No in-protocol payments, but that's the only difference.

Justin Traglia: Thank you so much for the presentation, that was really good. Does anyone here have feedback and or questions?

Potuz: I have a question, how… I mean, the proposal to remove Trustless payments. 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?

Christoph Schlegel: Well, then you have just, normal proposers, proposing, and then you keep track of, whether they… Deliver the payload, and you… can process them as… 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. 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. So it doesn't seem to me…

Christoph Schlegel: 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.

Christoph Schlegel: I mean… he can always build his own payloads, I mean, if he outsources it to shady actors, then… his problem. But, yeah.

Enrico Del Fante: We're moving the risk from the builder to the proposer, essentially.

Christoph Schlegel: Right, and then out of protocol, people have to find ways of, you know, doing this risk sharing among themselves. I guess if I propose blocks, 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 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. 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 Is that today. 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. Validators are not heavily penalized. 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…

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… to validators. this thing might actually cause it, because if you do have a bargain on the EL, 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. 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.

I'm not sure how to weight that.

Christoph Schlegel: It's true. I guess. Yes. Only thing that I can say. Don't introduce bugs. and your clients.

Justin Traglia: Okay, let's move on to the next topic. We don't have all that much time. Barath would like to speak about the Builder API with ePBS. Barath, would you like to share your screen?

Bharath Vedartham: Yeah, I'll just share my screen. Let me know if you guys can see. Yep. Can… can see it. It's visible, right?

Justin Traglia: Yep.

Bharath Vedartham: 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. 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. 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

Actual, like, payload and the commitments to the blobs and execution requests. 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. So… 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. 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.

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… 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. 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.

Now I just want to, like, quickly discuss on… 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. 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. 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.

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. Right? And both the proposer and the builder can, like, broadcast the beacon block to the beacon committees. The builder at this point, now that we have the beacon block, you can actually construct the execution payload envelope. And once the builder has the execution payload envelope, the builder is, like, responsible, solely responsible for, broadcasting the envelope to the PTC committee. 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.

So this is, like, how I think it would look like with stake builders. Things get a little trickier with off-protocol builders, so… Technically, like, in this case, proposals will have to act as of the self-build, because the protocol has no idea about the builders. The proposers, like, and the proposer have to… has to sign the payload envelope. 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. 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.

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. 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. So… 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.

The proposer constructs a blinded execution payload envelope with the payload route and execution request root. 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. Both the relay and the proposal broadcast the beacon block. 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. 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.

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. 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, 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. So, yeah, so this is, in my opinion, like, how it could look like.

And that's pretty much it. Like, I just wanted to, like, take the time to, like, just kickstart, like. 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. 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. Or, they,

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? 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. And of course, like, we can always make the design better and stuff. 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?

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. So, I suggest we take these offline. Would that be okay?

Bharath Vedartham: Excellent. Sounds like a blood.

Justin Traglia: Okay. Thank you. Let's get into trustless payments. We only have 23 minutes to discuss this. Alex?

alex: Yeah, thank you, Justin. 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… I would summarize it as… 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. 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.

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. 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, 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.

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

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: I can have a little comment, just to start up, so… as… as… from the core dev perspective, seems like trustless payment is… is… is… 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… 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. 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 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.

I feel like the biggest downside that is seen, but again, talk to people, you hear it's one of many, is that the… Introducing this new path? 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 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. 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.

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

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. Yeah, I'll leave it there. Maybe there's still a builder that could, add in. 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, A few angles here as to why we think there's a cost to the outer protocol blog building market. So, like, to continue on Alex's point on centralization, we think… That, having direct connections is potentially quite… centralizing for the general builder market. If there's an advantage to connecting directly to validators. 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. Our concern there is that… Payment is not the only thing that validators need. Validators have other preferences, for example, OFAC. And that requires something else other than a trustless bit. That requires, like, a personal relationship, some kind of…

agreements, SLAs, etc. And so then that requires new builders to go in BD with all the big staking pools, which is just impossible. And then, would add the other part to… 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. 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. Currently, if there's some bug in our block, you know, things happen.

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. 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… 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. A lot of people I've spoken to will say that 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? Should continue to be here. 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 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. 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.

But since it's, like, a trustless payment, this becomes, like, a lot harder to see. It's direct to proposer. 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.

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 auction. 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 Busa: I don't think we should… I don't think we should pay for a middleware that Ethereum doesn't actually need, unless we essentially need them. So, like, why do we even need relays at all if every block, every bit, would just end up publicly?

alex: Yeah.

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

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. 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? From the builder perspectives, that means any builder can access every single validator. 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. That, I think, is very centralizing for the building market.

Enrico Del Fante: I don't get that much the, oh fuck, Argument, because if… if… 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. If you are in certain jurisdictions, and this is.

Enrico Del Fante: The surveys that I'm.

Potuz: Currently, we want to actually… this is an argument pro. 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. 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.

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: So it's a plus 1 for me.

george: Is there a plus one to enshrined builders?

Enrico Del Fante: 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 Busa: 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. 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? 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. 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. This means that they need to trust people that they may not know. 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… 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. 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.

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 Feels like we're working against each other.

Max: Oh, hi everyone, Max from the Asus Relay. I've recently joined the Sigma Prime team, to help them work with their builder. 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 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 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.

It will not be profitable to run a relay. Public goods-funded relays will disappear. We certainly don't intend to put our capital on the line to, to keep the market 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 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

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. 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 The protocolization of removing some of the external actors and their influence over the process. 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. 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. 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

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. 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 really looking at a very big picture, splitting the EIP into the two fundamental pieces, is the slot restructuring. And then a lot of the builder flow stuff. I think is just at least worth looking at from a… 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.

In order to make sure it really is gonna be not only effective, but efficient.

Enrico Del Fante: 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… that… big. So, that's why we are actually okay to have it in, because they are already in. And I think we did a lot of things in the past that… We can adjust and remove additional forks, there's no that much complexity. That we have to deal with if we want to… go in a different path, and I also think that From another perspective, if the number of relays goes down, I think it's a sign of It's a good thing. 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. 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. 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 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. More than just… feelings about it. We want to have an actual argument to why we should remove this feature. 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. It removes this, property of, validators that want to trust builders, to honor OFAC transactions, Yeah, that's… Perhaps. I mean, that's certainly true. Do we want to use this in the protocol? Certainly not. And there's also this ill-founded statement about Doing this will enshrine builders. Yeah, we are definitely enshrining builders, but doing this will centralize the builder market, which is not only is…

like… 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. 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. Removing trustless payment also removes the option for someone to bill, to bid bids for someone else. 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 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 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. 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 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. 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.

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, 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… sense? But then, of course, yeah, I still, like, to my best estimation, I think it would make sense to not have trustless, and I… 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.

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. 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. Otherwise, they can exercise the free option for free. So that, either way, will happen. So if it happens, why just not happen on chain? So it's not a good… for me, it's not a very good argument against… Build decentralization, because, again, this will happen off-chain.

Justin Traglia: Lorenzo?

Lorenzo: I just wanted… Oh, one second.

george: Great. 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 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. So… they can, 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 Deciding that you are gonna be a builder, and potentially a lot of builders bid for just a few number of slots. Now, if you do want to bid off-chain. 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.

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 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… To be an off-chain builder, so to speak. 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. Bruno, could you clarify the trustless payments? 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. I would rather say I would prefer to have a permissionless set than a trust-me-bro relationship, so…

alex: But, yeah. 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. 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.

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. 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 so for, like, for small builders, you have to make them accountable, right? If they don't have reputation, you either make the mistake. or… Or you trust them, but to trust them, they must be sufficiently big. To statistically infer if they are exercising the free option or not. Therefore, they will stake. My point is, small builders, they will have to stake the release, either way. 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. 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. 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… 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… 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. 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. I think he's listening. He is messaging. Okay. Obviously, no decision will be made at this call, but yeah, temp check. Enrico?

Enrico Del Fante: Yeah, just one final thing, so… Very, very simple. Trust-trust payment does not prevent the status quo to continue. And I think we all agree about this. So, we are all talking about, we don't know where the equilibrium will be, After… 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. So, let's provide the options. Everything really remains on the table. 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. 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.

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. Like, trustless payments.

Justin Traglia: Alex Tobes, We are going to talk about this at ACDC. Next week, correct? Okay, I guess no, Mike, he said yes. And a decision will be made then and there, and I guess clients clients in the community should, I guess, review this call. 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, What people are bringing in, even if maybe some of these perspectives they find unconvincing. 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.

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