Skip to main content

Overview

Interchain Messaging Facility (ICMF)​

ICMF enables cross-chain communication between blockchains within the dapp cluster. By default, communication between two or more dapps is not allowed; hence, to overcome this limitation, you must extend your dapp's functionality by implementing ICMF. It ensures secure and reliable notification of transactions between chains while validating blocks.

ICMF operates as an event-based service, where dapp_#1 subscribes to specific topics and waits for dapp_#2 to emit events. Events are encoded using the GTV protocol and transmitted via special transactions. These messages are hashed and included in the block headers at a specific block height for dapp_#2, which emitted the event. Once dapp_#1 receives these events, it verifies the authenticity of the block headers and validates the messages by comparing their bodies to associated hashes in the block header.

The communication mechanism is simple yet reliable. Here's a breakdown of the process:

  1. User initiates an asset transfer from dapp_A to dapp_B.
  2. dapp_A signals the asset transfer by initiating a transaction and embedding a message indicator in its block header.
  3. dapp_B actively polls for new messages with the specified message indicator representing a topic.
  4. Once the dapp_B finds the new message on the chain of dapp_A, it retrieves the message, initiates the validation process, and records the asset transfer on its blockchain.
tip

For an in-depth course on using ICMF in a real dapp, visit the Build an event-driven multi-blockchain dapp course.

Interchain Confirmation Facility (ICCF)​

ICCF allows communication between dapps in different dapp clusters. Typically, dapps can communicate with each other only within the same cluster where they are deployed. The ICCF represents the client application that establishes the communication between dapps in the source_chain and the destination_chain. It is important to emphasize that communication is not established directly between dapps. Instead, the client application conducts an action on the source_chain and presents the proof of the action to the destination_chain. Then this proof of action is used to reconstruct an asset on the destination_chain. Find the detailed example of this process below:

  1. Suppose a client(ICCF) wants to transfer an NFT from the dapp_chain_#1 to dapp_chain_#2.
  2. The client invokes an operation to destroy the NFT asset on the dapp_chain_#1.
  3. Once the destroy operation is complete on the dapp_chain_#1, the subsequent block header containing the transaction hash gets recorded on the Cluster Anchoring Chain.
  4. Then the System Chain reads the data from the Cluster Anchoring Chain, validating the corresponding block containing the transaction hash of the destroy operation.
  5. The client sends a transaction to the dapp_chain_#2 that contains the proof of the successful destroy operation to reconstruct the NFT on the dapp_chain_#2.
  6. The dapp_chain_#2 verifies the proof by referring to the records stored on the System Chain.
  7. Once the proof authenticity is verified, the dapp_chain_#2 reconstructs the NFT for the client.
tip

To see practical usage examples, visit the Confirm events across blockchains course.