Discussion on this topic has been rigorous and we've appreciated the input from devs, researchers, builders, and relays, all of whom have provided valuable insights. After long internal debates, we've consolidated around the two points of view presented here.
Majority Opinion: Keep It In
Ethereum's block production status quo is not viable long-term and we should push to change it in the short term. The major reliance on a limited set of out-of-protocol actors for liveness is a major risk to the protocol. Trustless payments give us an avenue to ensure the liveness risk is mitigated, while remaining pragmatic about the market forces involved. It is possible the usage of this feature is low and is not disruptive to existing market forces in practice, but ensuring there is an enshrined path to block building in the protocol long term is essential.
Recognizing a new class of validators at the protocol level effectively enshrines a decentralized set of block builders for the long term. Many validators opt out of local block building today, while many others want to do it altruistically. The current trustless payments design allows actors within the protocol to altruistically build blocks for any other validator in a trustless way. A pragmatic view of the status quo is that not adding trustless payments is artificially limiting our ability to scale. The risk of low upload speeds causing missed proposals is currently a major bottleneck to scale. Enshrining this set of builder-validators allows us to ensure there is a large decentralized set of block publishers before making it infeasible to produce a block on lower-resourced nodes.
This feature is not only core to the ethos of Ethereum, but also a critical step on the roadmap to enable scaling. This is the best existing design, and although it does carry complexity with it, it is very well thought out and fully specified, with some clients already implementing it. It is also not clear that a delay of this feature to the next fork will yield a better design.
Minority Opinion: Not Ready Yet
We should pursue trustless payments as a feature generally. It's possible this is the best design. However, the prudent thing to do is to separate this feature, continue to research it, accept that it will not go into Glamsterdam, and we should strongly consider its inclusion in the next fork. Trustless payments aren't strictly necessary on the roadmap until local block building is infeasible. Although it's difficult to predict its actual impact, inclusion now does not appear to provide enough practical benefit to warrant the complexity.
We're fundamentally weighing complexity vs. impact on every change. There is real complexity to the current design. A new class of validator is introduced to the protocol. Stake is reused for builder payments. This is an important design decision because validator balances are used for calculations throughout the protocol and this introduces a new path to modifying them. Critical bugs have previously been found in code paths that we will change to enable trustless payments.
In a normal process, it is our opinion this change would not have been included in the fork had it been evaluated independently of the pipelining portion of ePBS from the start. We believe a lack of common understanding that it was reasonably separable may have contributed to this.