Fantastic idea. Here is my personal tl;dr in case that’s useful to anyone:
- We are assuming a functioning proposer/block builder separation-friendly market.
- Block builders signal a payment that is shared between block proposer and committee members of that slot, if their block is proposed. The highest of of all such signaled payments is called the maximal-payment p
- Block proposer should propose a block with a payment that offers at least p
- Committee members will only attest to the block if the proposed block’s payment is greater or equal to the maximal-payment, i.e. p_i \geq p (in addition to the usual fork choice rules).
- This payment p_i is shared equally between the block proposer and all committee members of a given slot. This is the crucial idea. Instead of smoothing MEV across slots (as often discussed), here it is proposed to share it with committee members of the same slot.
- The intuition is simple: As a committee member I only attest to a block that is proposing to share at least the maximal-payment that is known to me locally.
- This requires (block, slot)-voting, because attestors need a way of expressing an opinion: whether the proposed block is good enough or if the proposed block’s payment is not maximal (read: “screw you, you’re not sharing enough payment with us, so we are not attesting to your block”).
- Simply voting for the last head of the chain does not work, because the to-be-rejected-proposed-block is built on that block and would inherit all its weight and thus become canonical…
- (block, slot)-voting is problematic, because it introduces latency constraints of
SECONDS_PER_SLOT / 3, which is the amount of time after which an honest validator is supposed to attest even if it hasn’t heard about a block for the current slot. So if within 4 seconds a validator does not hear a block it will vote for an empty slot. As a consequence honest, but slightly late block proposals will be orphaned. - There are ideas for replicating (block, slot)-voting functionality without introducing latency constraints. Read more in the long form note.
- tl;dr: Attestations in slot n not only vote for a source, target and head, but also attach their local view of the max-value p_{i,n}. This helps because blocks publish a payment value p_{n} (to be shared across committee and proposer), and so we can compare the attestation’s p_{i,n} value to the block’s p_{n} value. But then there are new, different issues…
- imho finding a workaround for (block, slot)-voting is the heart of the matter to solve.