After reading the Cosmos white paper I was wondering about zone forks, as the white paper discusses forks in the Cosmos blockchain, but (perhaps I missed that) does not discuss zone forks.
Suppose I would like to transfer (tx1) 1 BTC to the Ethereum Mainnet, and assume both networks are zones connected to the Cosmos hub. The (BTC)ABCI verifies that the BTC tokens are indeed locked, sends a message to the (Ethereum)ABCI that the tokens have been transferred. Additionally, Cosmos validators reach consensus on the the state of the Cosmos blockchain, taking into account the state of the BTC-blockchain as well as the state of the Ethereum blockchain.
What happens when the Cosmos validators reach consensus on the BTC transaction, and the BTC network (soft)forks, assuming that the initial transaction (tx1) is no longer present in the Bitcoin blockchain?
- The Cosmos network comes to a grinding halt, as it is immutable and currently presents an invalid state.
- The Cosmos validators wait _n-_seconds, where n is the assumed safe waiting time for the slowest consensus mechanism in the participating zones. Following the above scenario, validators must wait at least 60 minutes to be reasonably sure that no fork appears on the Bitcoin blockchain.
- Just though of a third option: accept the invalid state. However, this would result in creating tokens for free on the Ethereum blockhain.
Following point 2, if relevant: who determines this waiting time? And who manages the risk in case of a long fork (e.g. Bitcoin once had a 32 block fork due to sync issues; also consider Ethereum’s DAO incident).
In short, it seems that the speed at which Cosmos validators reach consensus, although they use Tendermint consensus, is throttled by the zone with the slowest consensus mechanism.