Teleport Extensible Inter-Blockchain Communication Protocol.
XIBC is an extension of IBC (opens new window). It is an interoperability protocol for communicating arbitrary data between arbitrary state machines, which can be used to build a wide range of cross-chain applications, including but not limited to token transfers, non-fungible token transfers and contract invocations. XIBC allows communications between any two chains via a third chain (e.g. Teleport Chain) trusted by both as a relay chain.
# Advantages compared to IBC
- Source and destination chains only need to be connected to the relay chain
- Asset aggregation across different chains
- Better support for non-BFT consensus chains, e.g. Bitcoin and Ethereum
- Cross-chain interoperability for Smart Contracts
- Alternative cross-chain approaches such as
Multi-Party Threshold Signature
- Clean-up data packets at the end of life cycle
- Secure, reliable cross-chain interoperability protocol based on cryptography
- Support seamless integration, arbitrary data cross-chain communication, atomic cross-chain contract invocation among homogeneous and heterogeneous chains
- Composable state verifications and applications
- Efficient and verifiable relay chain
XIBC clients are verification programs that are identified by a unique client id. XIBC clients track the consensus states of other blockchains and the proof specs of blockchains that are required to properly verify proofs against the client's consensus state. XIBC defines several basic client types: light client, TSS client, and ZK client, which can be combined with each other to verify any chain. The first batch of blockchains supported include:
# Proof and Path
In XIBC, blockchains do not directly pass messages to each other over the network.
To communicate, a blockchain commits some state to a precisely defined path reserved for a specific message type and a specific counterparty. For example, a blockchain that stores a specific endpoint as part of a packet intended to be relayed to a contract on the counterparty chain.
A relayer process monitors updates to these paths and relays messages by submitting the data stored under the path along with a proof of the data to the counterparty chain.
Contracts communicate with each other by sending packets over XIBC ports. All XIBC packets contain:
A sequence to optionally enforce ordering
If the relay chain is specified, it means the relay chain mode is used.
A set of sub-packets. each packet contains:
- PortID This port allows the contracts to know the receiver contract of a given packet.
Contracts send custom application data to each other inside the
Data byte field of the XIBC sub-packet. Sub-packet data is completely opaque to XIBC handlers. The sender contract must encode their application-specific packet information into the Data field of packets; the receiver contract must decode that Data back to the original application data.
XIBC writes a packet receipt for each sequence it has received. This receipt contains no information and is simply a marker intended to signify that the destination chain has received a packet at the specified sequence. This avoids the double spending issue.
Contracts also write application-specific acknowledgements when processing a packet. Acknowledgements can be done:
OnRecvPacketif the contract processes packets as soon as they are received from XIBC contract.
Asynchronously if the contract processes packets at some later point after receiving the packet.
This acknowledgement data is opaque to XIBC much like the packet Data and is treated by XIBC as a simple byte string
byte. The receiver contracts must encode their acknowledgement so that the sender contact can decode it correctly.
The acknowledgement can encode whether the packet processing succeeded or failed, along with additional information that allows the sender contract to take appropriate action.
After the acknowledgement has been written by the receiving chain, a relayer relays the acknowledgement back to the original sender contract which then executes application-specific acknowledgment logic using the contents of the acknowledgement. This acknowledgement can involve rolling back packet-send changes in the case of a failed acknowledgement (refunding senders).
After an acknowledgement is received successfully on the original sender the chain, the XIBC contact deletes the corresponding packet commitment as it is no longer needed.
Routing contract maintains the mapping between ports and basic applications, and routes each sub-packet(or sub-acknowledgement) to each basic application to execute their own logic.
An XIBC basic application contract can bind to any number of ports. Each port must be identified by a unique portID. Since XIBC is designed to be secure with mutually-distrusted contracts that operate on the same ledger, binding a port returns the dynamic object capability. To take action on a particular port, for example, to send a packet with its portID, An XIBC basic application contract must provide the dynamic object capability to the XIBC handler.
XIBC contracts are for claiming the capability that is returned on
# Basic applications
The cornerstone of application development based on the XIBC protocol. The module contains token-transfer, remote-contract-call and multi-contract-call, which can be directly adopted for cross-chain transactions or cross-chain dApps development
# Participating chain <--> relay chain
# Participating chain <--> participating chain
# Client updating
When the relayer observes that the dest chain client state is obsolete for cross-chain packet verification, it will fetch the appropriate client state from the source chain and send a transaction on dest chain to update the state.
# Packet execution
Users can use XIBC basic contracts for cross-chain interoperability, such as cross-chain transfer and governance, or implement their own cross-chain operation contracts based on XIBC basic contracts.
# Receive packet
# Receive acknowledgement
# Relayer Incentivisation
The relay process must have the access to accounts on both chains with sufficient balance to pay for transaction fees, in order to ensure the forward flow of cross-chain data packets, incentivisation is necessary.
A user can specify a cross-chain fee for the packet. Once the acknowledgement is sent back to the source chain, the relayer will get the fee.
# Exception Handling
It can be considered that sufficient cross-chain transaction fees paid to relayers will positively motivate cross-chain operations to be actively executed. When a user finds his cross-chain transaction has not been executed in time, he may increase transaction fees to accelerate. However, XIBC allows users to specify other packet sequences without adding extra transaction fees.
# Technical Specification
# Client inteface
# Application interface
# Core pseudocode
# Packet handler
# XIBC basic contracts
# Usage Scenarios
XIBC protocol supports multiple status verifications and composable applications, which can be used for any interoperability between chains. You can check some practices here.