Game theoretically sound bridging

[seunlanlege]

Currently writing a more detailed article about securing cryptographically sound bridges with game theory.

But the gist of this issue is that currently our bridge is vulnerable to eclipse attacks (todo: references) where the validators for a blockchain might collude and sign a single malicious header which they don't gossip in the p2p swarm, but instead update the light client running on our chain.

This attack is absolutely devastating and is capable of destroying the peg of an existing bridged asset, where the validators essentially sign a forged header which in turn contains a forged ibc commitment trie that makes a huge transfer of existing bridged assets in the forged header.

In order to mitigate this attack we need a new game theory protocol:

First a challenge window for newly updated headers in our light client, could be 5-10 mins. This will give enough time for a new participant of the bridge system (colloquially called fishermen, todo: references) to challenge the header by presenting another header that would have been valid at the same height. Allowing us to leverage IBC semantics and freeze the light client immediately.

Secondly all bridged chains will need to have an equivocation protocol:

An equivocation protocol is a property of Proof of stake systems where staked validators can be slashed if they are found to have signed 2 headers that would've been valid at the same height. The reason we need this equivocation protocol is so that fishermen, in parallel to freezing the light client on our chain, can claim the rewards for securing our bridge by reporting this misbehavior to the counterparty chain, where the malicious validators will be slashed and their stake ideally is split between the network and the fishermen. Without an equivocation protocol, there's no way to incentivize fishermen and disincentivize eclipse attack attempts.

Action Items:

• Implement fishing mode #75
• Research equivocation protocol for cosmos & Near

[seunlanlege]

OK seems like we might not need the challenge window as ibc natively has the idea of a connection_delay in between header updates and packet relays.

informalsystems/hermes#640