Skip to main content

Synopsis

This document describes a standard for multi-hop IBC channels. Multi-hop channels specify a way to route messages across a path of IBC enabled blockchains utilizing multiple pre-existing IBC connections.

Motivation

The current IBC protocol defines messaging in a point-to-point paradigm which allows message passing between two directly connected IBC chains, but as more IBC enabled chains come into existence there becomes a need to relay IBC packets across chains because IBC connections may not exist between the two chains wishing to exchange messages. IBC connections may not exist for a variety of reasons which could include economic inviability since connections require client state to be continuously exchanged between connection ends which carries a cost.

Definitions

Associated definitions are as defined in referenced prior standards (where the functions are defined), where appropriate. Connection is as defined in ICS 3. Channel is as defined in ICS 4. Channel Path is defined as the path of connection IDs along which a channel is defined. Connection Hop is defined as the connection ID of the connection between two chains along a channel path.

Desired Properties

  • IBC channel handshake and message packets should be able to utilize pre-existing connections to form a logical proof chain to relay messages between unconnected chains.
  • Relaying for a multi-hop IBC channel should NOT require writing additional channel, packet, or timeout state to intermediate hops.
  • The design should strive to minimize the number of required client updates to generate and query multi-hop proofs.
  • Minimal additional required state and changes to core and app IBC specs.
  • Retain desired properties of connection, channel and packet definitions.
  • Retain backwards compatibility for messaging over a single connection hop.

Technical Specification

The bulk of the spec describes multi-hop proof generation and verification. IBC connections remain unchanged. Additionally, channel handshake and packet message types as well as general round trip messaging semantics and flow will remain the same. There is additional work on the verifier side on the receiving chain as well as the relayers who need to query for proofs. Messages passed over multiple hops require proof of the connection path from source chain to receiving chain as well as the packet commitment on the source chain. The connection path is proven by verifying the connection state and consensus state of each connection in the path to the receiving chain. On a high level, this can be thought of as a chained proof over a channel path which enables the receiving chain to prove a key/value on the source chain by iteratively proving each connection and consensus state in the channel path starting with the consensus state associated with the final client on the receiving chain. Each subsequent consensus state and connection is proven until the source chain’s consensus state is proven which can then be used to prove the desired key/value on the source chain.

Assumptions

This multi-hop spec assumes that all proof specs for membership verification for each chain are equal.

Channel Handshake and Packet Messages

For both channel handshake and packet messages, additional connection hops are defined in the pre-existing connectionHops field. The connections along the channel path must exist in the OPEN state to guarantee delivery to the correct recipient. See Path Forgery Protection for more information. See ICS 4 for multi-hop related spec changes. Multi-hop does not change existing spec behavior for channel handshakes, packet delivery, and timeout handling. However, multi-hop channels require special handling for frozen clients (see chanCloseFrozen). In terms of connection topology, a user would be able to determine a viable channel path from sender -> receiver using information from the chain registry. They can also independently verify this information via network queries.

Multihop Relaying

Relayers deliver channel handshake and IBC packets as they currently do except that they are required to provide proof of the channel path. Relayers scan packet events for the connectionHops field and determine if the packet is multi-hop by checking the number of hops in the field. If the number of hops is greater than one then the packet is a multi-hop packet and will need extra proof data. For each multi-hop channel (detailed proof logic below):
  1. Scan source chain for IBC messages to relay.
  2. Read the connectionHops field in from the scanned message to determine the channel path.
  3. Using connection endpoints via chain registry configuration, query for required multi-hop proof heights and update client states along the channel path as necessary (see pseudocode implementation).
  4. Query proof of packet or handshake message commitments on source chain at the proof height used in step 3.
  5. Query for proof of connection, and consensus state for each intermediate connection in the channel path using proof heights determined in step 3.
  6. Submit proofs and data to RPC endpoint on receiving chain.
Relayers are connection topology aware with configurations sourced from the chain registry.

Proof Generation & Verification

proof_generation.png Graphical depiction of proof generation. relayer_calc_update_heights.png During the first phase of querying a multi-hop proof the relayer searches for the minimum consensus height that can prove the previous chain state and is also provable by the next chain in the channel path. relayer_query_proof_and_submit.png In the second phase of querying a multi-hop proof, the relayer queries proofs of the client and connection states as well as the key/value on the source chain at the heights determined in the first phase. proof_query_algorithm.png Multi-hop proof query algorithm. proof_verification.png Multi-hop proof verification logic. Proof generation pseudocode proof generation for a channel path with N chains: C[0] --> C[i] --> C[N]

Multi-hop Proof Verification Steps

The following outlines the general proof verification steps specific to a multi-hop IBC message.
  1. Unpack the multihop proof bytes into consensus states, connection states and channel/commitment proof data.
  2. Check the counterparty client on the receiving end is active and the client height is greater than or equal to the proof height.
  3. Iterate through the connections states to determine the maximum delayPeriod for the channel path and verify that the counterparty consensus state on the receiving chain satisfies the delay requirement.
  4. Iterate through connection state proofs and verify each connectionEnd is in the OPEN state and check that the connection ids match the channel connectionHops.
  5. Verify the intermediate state proofs. Starting with known ConsensusState[0] at the given proofHeight on Chain[1] prove the prior chain’s consensus and connection state.
  6. Verify that the client id in each consensus state proof key matches the client id in the ConnectionEnd in the previous connection state proof.
  7. Repeat step 5, proving ConsensusState[i], and Conn[i,i-1] where i is the proof index starting with the consensus state on Chain[2]. ConsensusState[1] is already known on Chain[0]. Note that chains are indexed from executing (verifying) chain to and proofs are indexed in the opposite direction to match the connectionHops ordering.
    • Verify ParseClientID(ConsensusProofs[i].Key) == ConnectionEnd.ClientID
    • ConsensusProofs[i].Proof.VerifyMembership(ConsensusState.GetRoot(), ConsensusProofs[i].Key, ConsensusProofs[i].Value)
    • ConnectionProofs[i].Proof.VerifyMembership(ConsensusState.GetRoot(), ConnectionProofs[i].Key, ConnectionProofs[i].Value)
    • ConsensusState = ConsensusProofs[i].Value
    • i++
  8. Finally, prove the expected channel or packet commitment in ConsensusState[N-2] (sending chain consensus state) on Chain[1]
For more details see ICS4.

Multi-hop Proof Verification Pseudo Code

Pseudocode proof generation for a channel between N chains C[N] --> C[i] --> C[0]

Path Forgery Protection

From the view of a single network, a list of connection IDs describes an unforgeable path of pre-existing connections to a receiving chain. This is ensured by atomically incrementing connection IDs. We must verify a proof that the connection ID of each hop matches the proven connection state provided to the verifier. Additionally we must link the connection state to the consensus state for that hop as well. We are essentially proving out the connection path of the channel.

Backwards Compatibility

The existing IBC message sending should not be affected. Minor changes to the verification logic would be required to identify a multi-hop packet and apply the proper proof verification logic. Multi-hop packets should be easily identified by the existence of more than one connection ID in the connectionHops field.

Forwards Compatibility

If a decentralized chain name service is developed for the data currently in the chain registry on github, it may be possible for a calling app to specify only a unique chain name rather than an explicit set of connectionHops. The chain name service would maintain a mapping of chain names to channel paths. The name service could push routing table updates to subscribed chains. This should require fewer writes since routing table updates should be fewer than packets.

Example Implementation

Coming soon.

Other Implementations

Coming soon.

History

Dec 16, 2022 - Revisions to channel spec and proof verification Nov 11, 2022 - Initial draft All content herein is licensed under Apache 2.0.