The main objective of this proposal (as I see it) is precisely that it avoids any trust assumption about validators. As soon as the design allows validators to steal MEV (i.e. we take away the blind signing), small stakers are imho unlikely to be able to receive the very best MEV opportunities, because they can’t be trusted with them. The fact that cheating is detectable (and still, this is not easy at all, so you’d rather trust and police few reputable entities like the escrows) helps very little, because for a small staker stealing once can be worth more than a year of expected rewards (or even several years). Also, small stakers can hardly build a reputation worth anything, because they propose so few blocks (20-40 a year I think?), most of which might not have very high MEV.
For example, would a searcher who has found a 100 ETH extraction opportunity (assuming it’s not very time-sensitive) trust an unknown proposer with it, or just wait one block and give it to a staking pool?
Even if it’s just a small percentage of MEV opportunities, it matters because the distribution of MEV is very much long-tailed, so this small percentage amounts to a disproportionate fraction of the total MEV. Making the long-tail much less accessible for small stakers can result in them earning significantly less, and is therefore a centralizing force
Validators trusting relays is a completely different game than the opposite, because the relay “plays” all the time, so it has a much higher incentive not to do anything bad. Moreover, from the perspective of a validator, I don’t think the relay can do any bad thing which isn’t easily detectable (from the perspective of a searcher it can, i.e. stealing MEV, but that’s irrelevant to validators):
- It can lie about how much the proposer will be rewarded for signing the block, but that’s obvious once the full block is published
- It can withhold the full block or publish something invalid
- It can publish the full block too late for it to be considered. There can be disagreement here about whether the block was actually sent too late, but not about whether it becomes canonical, and that’s something measurable about a relay’s performance
Not only all these faults are detectable and contribute to a relay’s performance/reputation score, they are also greatly mitigated by the presence of multiple reputable escrows. Before signing a payload header, a proposer can simply ask a variety of escrows which it trusts to certify the availability and validity of the full payload, and only sign if it gets at least one positive response (or however many the proposer wants). The trust model for validators becomes then 1/N, and think most small validators would be quite ok with this tradeoff (no trust required versus this trust model) considering it gives them full access to MEV.