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:
- User initiates an asset transfer from
dapp_A
todapp_B
. dapp_A
signals the asset transfer by initiating a transaction and embedding a message indicator in its block header.dapp_B
actively polls for new messages with the specified message indicator representing a topic.- Once the
dapp_B
finds the new message on the chain ofdapp_A
, it retrieves the message, initiates the validation process, and records the asset transfer on its blockchain.
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:
- Suppose a client(ICCF) wants to transfer an NFT from the
dapp_chain_#1
todapp_chain_#2
. - The client invokes an operation to destroy the NFT asset on the
dapp_chain_#1
. - 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. - Then the System Chain reads the data from the Cluster Anchoring Chain, validating the corresponding block containing the transaction hash of the destroy operation.
- The client sends a transaction to the
dapp_chain_#2
that contains the proof of the successful destroy operation to reconstruct the NFT on thedapp_chain_#2
. - The
dapp_chain_#2
verifies the proof by referring to the records stored on the System Chain. - Once the proof authenticity is verified, the
dapp_chain_#2
reconstructs the NFT for the client.
To see practical usage examples, visit the Confirm events across blockchains course.