Pessimistic Validation – Round 4

This grant was approved through the Quadratic Funding (QF) program. The Atom Accelerator DAO contributes $20,000 USDC to the matching pool for each round of the QF program, and this page states the amount a project received from our allocation. Any amount contributed from the matching pool to this particular project is based on public voting and contributions. As such, AADAO is neither endorsing nor otherwise indicating support for this project. Learn more about the Quadratic Funding program. Some projects might have also been funded through another of our funding programs. View our FAQs on how we deal with potential double-funding.

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.

Problem - IBC connectivity with any chain

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).