The last two weeks, I focused on the slashing mechanism for the rollup-relay, as well as reconsidering an availability committee for the off-chain commitment.
As mentioned in my last post, there are 3 slashing conditions:
Although, for all of them, there is a problem - if the bid is greater than the staked ETH of the builder, the proposer losses out on some reward. In addition the builder has an incentive to just take the "slash" instead of paying the promised bid amount in case of 3. if bid > stake.
Optionally, there could be a Merkle proof that is sent when the builder sends the bids, so the proposer could check if the needed transactions are included. But this should only be used as a quick sortout method, not as proof that these transactions are actually in the block. That's due to the fact that the builder could include those transactions, for example, the bid sent to the proposer and forge a proof, but they could include another transaction with the same nonce as the first one and therefore make the first one revert. Maybe there could be a proof to prove that such a second transaction does not exist in that block, but that might be too complex.
First, before the proposer's slot, the builder and proposer register on-chain via a smart contract. The builder must also deposit some amount of stake, which can later be used to slash the builder if they misbehave. Next, all the builders send their block headers and bids either to the proposer directly or they get sent to the availability committee. The proposer collects all the offers and selects the best bid. The proposer then signs the block header. The proposer sends the signed header, encrypted with the builder's public key, to the availability committee. The availability committee attests to this message. The builder whose bid was selected by the proposer can now retrieve the signed header and release the block to the network. If something slashable happened, the proposer sends the message with the attestation, which needs to be at least m out of n to the slashing contract as proof, the rest of the slashing is the same as in the rollup-relay.
The only thing that is still open is how to incentivize honest participation in this availability committee. EigenLayer could be a solution, and the builder also needs to pay some fee to the committee, but this is not 100% clear yet. As a benefit of this approach, assuming incentives are there, that now large trust assumptions like with the current approach or the rollup-relay, like the proposer and the sequencer do not collude with one another, don't exist anymore. As a downside, it has no spamming protection by default, but I believe this is implementable.
Overall, the approach with the availability committee might be the better solution in the long term, but it is more complex and there are still some open questions like the incentive layer and spam-protection.