IBC launch risk mitigation strategies

[cwgoes]

Notable risks:

• Design mistake / implementation bug in Tendermint light client verification algorithm (could lead to double-spending or state fraud)
• Design mistake / implementation bug in connection or channel handshakes (could lead to man-in-the-middle attacks)

Possible mitigation strategies:

• Throughput limit on token transfers. This would contain possible loss from double-spending, but it is tricky to implement, since it has to be across all channels - and once there exists such a throughput limit, it opens up a denial-of-service vector (sending tokens back-and-forth to fill the quota). A quota could be implemented per-address, which would remove the DoS vector, but would then protect against vulnerabilities less effectively.
• Require an additional signature on received packets by the sender (the IBC packet nonce & port/channel identifier can be used for replay prevention). This prevents state fraud; however, it requires that the destination chain understand the sending address format (so it can verify a signature), and the UX will be a bit annoying. Possibly this could be implemented for packets over a certain token amount.
• Instead of immediately releasing funds on packet receive, hold them in escrow for a certain number of blocks (allowing potential proof-of-misbehaviour to be submitted). This would limit damage from Byzantine behaviour, and possibly some kinds of light client bugs.
• No mitigation at all, users assume all the risk by transferring tokens.

Edits & comments welcome.

[cwgoes]

Another, related, question: do we want to implement a mechanism for client recovery? In particular, it seems to me like we could add something like a param-change proposal to allow Hub governance
(ref #418) to:

• Override an expired client with a new trusted header if the client hasn't been updated recently
• Unfreeze a frozen client & submit a new trusted header

This doesn't seem too risky to me, since:

• 2/3 of Hub validators could sign arbitrary state anyways
• These changes would still be delayed by the governance period (presently two weeks)

Thoughts? Is this sufficient for avoiding accidentally frozen funds or unusable clients?

One restriction is that the governance period must not be longer than the trusting period.

[cwgoes]

(it could be an option when a client is created to allow governance to override or not)

[fedekunze]

Note, we should also consider the client's trust level and the governance quorum. Ideally, we want quorum ≥ trust-level.

Override an expired client with a new trusted header if the client hasn't been updated recently

It could be the case that when the proposal passes, the submitted header would already be expired (eg. when trust period < 2 weeks)

[cwgoes]

@dtribble notes that the governance vote can be simple (a height) to just deal with timeouts only.

[cwgoes]

Note that unexpected upgrades which require other chains to change their light clients are irregular state changes anyways, so they might as well switch verification algorithms for different light clients as a part of it.

[ebuchman]

In order to reduce the risk of certain light client attacks we might also want to increase the trust-threshold initially beyond +1/3, maybe to +1/2 (+2/3 might be too high). Higher levels require a greater set of past validator sets to collude, but also have the potential to increase ClientUpdate costs by requiring more intermediate bisection headers. That said in practice, since the validator set changes minimally, this might not matter. I wonder if anyone has stats on validator set turnover

[cwgoes]

Split into #445, cosmos/cosmos-sdk#6488, cosmos/cosmos-sdk#6591.