IBC connections typically use light clients. However, optimistic rollups, e.g. Base, Arbitrum, and many layer-1 blockchains such as Solana, currently don’t have a light client. Therefore, alternative methods must be leveraged to attest to the state of those domains to enable cross-chain communication. Fortunately, the IBC client layer is flexible enough to enable different verification methods for different blockchain architectures.
This post discusses multiple ways teams can build IBC connections other than via light clients. We are working on an attestation-based solution to connect to Base, Arbitrum, Solana, and beyond, and are seeking your feedback. This attestation-based solution will be released after the initial launch of IBC v2 in March. Get in touch with IBC Product Manager Susannah Evans to learn more about the attestations-based IBC solution.
TL;DR
- Attestations beyond light clients: the IBC client layer can also be used with multi-signature attestations and clients dependent on other light clients to verify a state transition on another domain.
- Conditional clients offer a flexible solution: when interoperating with an optimistic rollup, there is a trade-off between speed and security, as waiting for a 7-day challenge period is an unsuitable cross-chain user experience. Conditional clients retain data availability inclusion guarantees whilst shortening confirmation before the challenge window. Conditional clients more generally enable multiple verification methods to be used in a single client.
- A range of security models: IBC can also leverage aggregated clients or attestations from multiple sources offering users a robust and flexible solution for their needs.
High-Level Requirements for an IBC Client
To communicate with another chain, there needs to be a view of the counterparty’s state machine. From the perspective of IBC, a chain is defined by its consensus mechanism. IBC clients must provide three key elements:
- A means to update the
ConsensusStateof a counterparty chain and confirm at a givenHeight, a blockchain is representative of that chain's consensus mechanism through aValidityPredicate. - A means to enable state verification of a counterparty chain.
- A means to freeze operations through
Misbehaviour. This is the case where there has been aConsensusStateupdate at a givenHeightthat violates theValidityPredicate.
In the case of the Tendermint light client, misbehaviour is triggered when there are two block headers submitted at the same height that both would have been considered valid, i.e. validators double signed. Although IBC is considered to be a light client based protocol, there are many optionalities for holding a view of the counterparty you want to communicate with, not limited to light clients alone; these three requirements just need to be met.
Single or Multi-signature attestations: Solo Machine Clients
A solo machine client is the simplest client type. With the solo machine, a single or multi-signature public key is used to sign arbitrary data which is used to attest to the consensus state of a blockchain at a given timestamp. Signers are expected to run a full node to track the consensus state of a given blockchain to attest to. The public key is used to verify that IBC packets were sent by a counterparty to be received on the chain the solo machine client is on. To progress the IBC packet lifecycle, the solo machine proof will verify that the public key signed over the data confirming an IBC packet was sent by the counterparty.
1
2
3
4
5
6
7
8
9
// the struct a solo machine public key signs over
interface SignBytes {
sequence: uint64
timestamp: uint64
diversifier: string
path: []byte
data: []byte
}For mishbehaviour, a solo machine client is frozen if the public key signs over data with the same sequence number but conflicting bytes.
Solo machine clients are great candidates for attesting to the state of optimistic rollups or blockchains that don’t have a light client such as Solana. They have a security model similar to existing bridging solutions, such as Hyperlane that leverages m of n multi-sigs or Wormhole that leverages a 13/19 guardian network.
Conditional Clients for Rollup Attestations
Conditional clients are IBC clients that depend on another to provide verification for an IBC packet commitment, relevant for use with rollups. More generally, they can be used to stack multiple verification methods into a single client, where all verification methods must pass for the IBC packet life. A rollup using Ethereum for data availability requires:
- Verification that there was a valid state transition that included an IBC packet commitment
- Verification that the rollup transaction data containing the IBC packet commitment was posted to Ethereum.
You can split these two verification needs into a client representing Ethereum and a client representing the rollups state transitions. Full verification of the IBC packet commitment is dependent on verification of both of these clients.
ZK rollups directly prove the validity of the rollup state transition, whereas optimistic rollups assume during normal operation that a sequencer is acting honestly, with a fraud prover observing and computing the state transition of the rollup independently. This presents a challenge for trust-minimized cross-rollup interoperability, because the challenge window to prove a fraudulent state transition submitted to Ethereum is typically 7 days. A client would need to wait 7 days before it could verify the rollup had no invalid state transitions, but this bridging experience would be untenable.
However, once a single honest fraud prover has verified correct computation, and the transactions are posted to the DA layer on Ethereum, an actor in the system is certain fraud was not committed - waiting the additional 7 days adds no additional security guarantees. This principle can be leveraged to form the basis of IBC clients that are solo machines, requiring attesters to run fraud proving infrastructure.
Ultimately, there is a trade-off between speed and security for optimistic rollup interoperability. The diagram indicates different levels of security that could be built into an IBC client that facilitates interoperability. The frequency a given rollup sequencer posts a blob containing rollup transaction data to Ethereum depends on utilisation. For example, Base frequently posts blobs to Ethereum, typically every couple of minutes or less, whereas other rollups will post less frequently. Verifying that a blob was posted to the DA layer guarantees that the sequencer is not censoring transactions, and hence provides additional guarantees than simply trusting attestations to the rollup at a certain height.
Conditional Clients for Attestation Aggregation
Conditional clients can be used for attestation aggregation. A user may want to check attestations for a certain state transition or IBC packet commitment across multiple security providers. They may have their own attestation from a chain validator set, and also trust another bridging provider, or alternative client to attest to the same state transition. This enables building a more robust and flexible security solution.
A constraint of aggregating attestation providers is that one provider could censor transactions by withholding an attestation. Additionally, one attestation mechanism may provide stronger security guarantees than a committee-based attestation, e.g. if a light client and multi-sig based solo machine client are used in combination. This implies there may be an element of redundancy in this design, but redundancy may be desirable for certain use-cases.
A Broad Range of Available Security Models
IBC is adaptive and flexible enough to use a broad range of security models, meaning the protocol can connect to a large range of blockchain architectures if the chain has a deployment of the IBC protocol. IBC v2 launches in March with a connection to Ethereum, and we are developing an attestation-based system to onboard other major chains and rollups as a next step after the v2 launch. If you are interested in day 1 access to domains beyond Ethereum such as Base, Arbitrum and Solana, please get in touch with IBC Product Manager Susannah Evans.
About Interchain Labs
Interchain Labs (formerly Skip Protocol) is building the development platform for world-scale multichain application builders: people with a giant vision who need a tech stack that gives them that expressivity and scale. Labs is building the tools essential for the next generation – enabling new, fairer ways of organizing our communities, our lives, and the world.
