I… preliminarily like this.
Proposers taking on orphanage risk seems a bit iffy but it does seem necessary for the scheme to work.
I see a few weird effects:
- Once a proposal is made, the proposer has a 1:1 griefing attack against the validator by not publishing the proposal. That said, in a simple blockchain, the validator of a child block has a 1:2 griefing attack against the validator of the parent by building on top of the grandparent instead, so this isn’t that much worse.
- If all transactions in a proposed collation have been broadcasted, then it may be possible to reconstruct the collation from just the header. This would allow validators to piggyback off of proposers’ state computation and transaction selection efforts for free and claim the fee revenue for themselves. However, this could easily be mitigated by allowing the full collation body to contain even one secret parameter (eg. coinbase) that is not visible from the header.
- A new censorship vector appears: a censoring attacker could dominate proposing in a particular shard and subsidize their proposed collations that exclude transactions from some account; the validators would have no idea that this is happening. However, this still has the property that censors would have to outbid the transactions they want to exclude for every block that the transactions are being excluded, so it’s not much worse than simple transaction spam.