Future improvements to basic bridge censorship resistance

[musnit]

The current plan for the Basic Polkadot to Ethereum Message Channel is to use an ordered queue for replay protection. This is somewhat censorship resistant, but an attacker can still flood the queue to create an expensive blockage in the queue, effectively creating some economic censorship. This is not an issue for the Incentivized Bridge, as it will have incentives to cover the blockage.

The intention behind using the same ordered design for the basic and incentivized bridge is a pragmatic one, to get to production quickly with an acceptable level of censorship resistance and with support for both bridges, but it can be optimized in future to increase censorship resistance.

This could be done by:

• For replay protection, instead of using an ordered queue with increasing nonces being enforced, use an unordered queue with a replay protection mechanism like an on-chain list/commitment to the set of nonces that have already been processed that can be checked against for replay protection.
• For commitment/verification, use a scheme that is cheaper for partial verification of a single message, like a merkle tree rather than a single of all messages together

[philipstanislaus]

For replay protection, we could also go the standard way and save an incrementing nonce per (sending?) account instead of storing every single used nonce. The big question here is whether we can have unique sending accounts.