Skip to main content

Build an event-driven multi-blockchain dapp

In this course, we will build a dapp consisting of three blockchains: Order, Factory, and Delivery. They will interact with each other using ICMF.

The dapp we will build is an ordering system consisting of three blockchains:

  1. Ordering chain: Users can order products using this chain
  2. Factory chain: Produces products and keeps statistics of how many products have been created
  3. Delivery chain: Handles delivery of orders to customers

The main idea for this system is to separate concerns for different actors. Products are made available on the order chain and can be ordered (bought) by a user. Factory workers only need to interact with the factory chain. Delivery companies only need to interact with the delivery chain. There are other ways to slice a dapp into several blockchains, for example, in terms of sharding (having several factories for different product types) to either parallelize the workload or to achieve different time scales (a factory may produce big batches, but the order and deliver chain need to handle separate orders), but this serves as an excellent example on how to use the ICMF.

The system we will build can be modeled like this:

ICMF can be compared to a message queue, where a chain can emit events on a specific topic or subscribe to several topics. This is an integral part of the architecture of Chromia, where blockchains need to communicate without user interaction.

Sending a message using ICMF is easy in Rell, but what actually happens under the hood?

  1. The sender dapp calls the function send_message, a part of the ICMF Rell library. This could be user-triggered via an operation or by the dapp itself.
  2. This emits an event on the node, which is sent to the cluster's anchoring chain.
  3. The receiver node polls for messages on the subscribed topics before each block gets built.
  4. When a message is found, the node calls the __icmf_message special operation on the dapp.
  5. The ICMF library calls the function receive_icmf_message, which triggers any logic defined by the dapp.

Based on this, the ideal type of dapp for this type of messaging is when you want chains to broadcast a message to indicate that it has completed an action. Then, it's up to the other chains to subscribe to this action and perform an action based on the information in the message. This way, you can add more chains to your solution with new responsibilities, and they must subscribe to their topics of interest. No logic needs to be changed in the sender chain.

In our scenario, the factory workers don't care who created an order and when it was created. They only care about that an order is created and start their manufacturing process, similarly, for the Delivery chain. The delivery company only cares about what box or products they should deliver and where, not what's in the box.