Ibc-sync is an evolution in the IBC packet relaying process that aims to solve these issues. It does this by moving the responsibility of IBC relaying to the validators of the network by making use of ABCI++ vote extensions. **

Problem

Relaying IBC packets is a vulnerable process often conducted by validators as a side and incentivised by community pools. When viewed in the light of Atom's interchain security this fault-prone process can lead to chain halts, exemplified by the halting of the Neutron testnet (pion-1) caused by a defect relayer.

Additionally some chains are hesitant to integrate IBC into their blockchain because of censorship concerns. It's well known that Thorchain, a native DEX with a TVL of $310M, chose not to integrate with IBC because the relaying process can easily be DDOSed.

These concerns should be addressed as IBC matures. We believe ibc-sync is a major step in that direction.

Solution

Ibc-sync revolutionizes the IBC packet relaying by moving the relaying responsibility into the CosmosSDK. It does this by introducing a voting process where validators can gossip any IBC client updates and packets that they believe should be included in the next block. The proposer of the block then uses these votes to construct the IBC messages and proposes the block to the other validators. If the proposal is approved (after validation) then the client updates and packet commitments will be included in the block, essentially performing the relaying of the packet.

The channels over which relaying is performed is configurable through governance approval. Regular relaying can still be performed for channels that the chain's community does not deem valuable to subsidise.