Main goal: enable IBC for any chain where you can’t/don’t have a light client you can trust/use.
For optimistic rollups, and many other chains, IBC is problematic because of the lack of light clients or consensus protocols you can verify on-chain.
Interchain Attestation enables IBC for any chain that can implement IBC, and let another chain safely validate it (for instance by running a full node). This then includes optimistic rollups, Ethereum, Solana, and more.
Solution
Interchain Attestation enables IBC connectivity (with no intermediary chains) with any chain where you can’t/don’t have a light client.
To dive deeper into the architecture, see https://interchain-attestation.io
Interchain Attestation solves the problem where you can’t, for whatever reason, trust the counterparty with a “normal” light client. Instead, it allows a chain’s validators to attest to the state of the counterparty – moving the security to someone you already trust.
This solution enables any chain to connect with IBC, as long as it can implement the IBC protocol (e.g. smart contracts), and the validators using Interchain Attestation are attesting to the state of the counterparty IBC implementation.
Interchain Attestion is based on using validators with existing economic security to attest to the state of the counterparty chain. We move the security assumption over to the receiving validator set (e.g. Cosmos Hub/Osmosis/whatever), away from the one we can’t trust (like a single sequencer).
In addition, the Attestation light client is based on attesting to IBC packets, rather than full state. This makes it much easier to implement new chains and support consensus algorithms that don’t (yet?) have a light client implementation.
The Attestation light client verifies the signatures of the attestors (validators) and stores the packet commitments to be able to verify the packet later.
Not all scenarios warrant all validators running a full node and attesting to every chain it connects to, so Interchain Attestation also has a config module that allows for configurable security requirements.
The architecture uses a combination of a sidecar process, ABCI++ Vote Extensions, and a light client to enable the attestation process.
Economic model
The goal is that this should be economically feasible to run from day 1 without running at a loss. So there should be incentives to run this validation. And the cost should probably be reflected in the required security.
There will also be native slashing to incentivize validators to run the nodes (and not just take updates from others).
