In previous stories, we have been covering various bridging solutions. We have not assumed any prior knowledge of this subject, but we might have to spend a bit more time on the basics. Hence welcome to the first post in the series about bridging basics, where we aim to bring up the common knowledge and understanding about bridging in general.

What is cross-chain message passing?

We are starting with cross-chain message passing as it is the core utility needed for creating any bridging solution. And it is a tool for delivering a message from one chain to another. Let us start with a straightforward example that depicts how cross-chain message passing would work if it were a parcel delivery service.

Parcel passing

1. First, the sender hands her parcel to the nearest Drop Point, where a delivery fee and the parcel are collected.
2. The delivery order is recorded into the Database, and a tracking number is given to the sender.
3. Parcels from multiple senders are collected and transported to the corresponding Distribution Point, which depends on the recipient’s address.
4. The parcel delivering system keeps track of the parcel delivery process in its Tracking System.
5. The sender and recipient can periodically check for delivery status by querying the tracking system using the tracking number.
6. The parcel arrives at the distribution point.
7. Parcels are organized into batches which then are transported to corresponding recipients.
8. Before delivering a parcel to the recipient, the system sends the Expected Delivery Notification to the recipient to check and notify him about an incoming package.
9. The parcel is delivered, and the tracking system changes its status to “delivered.” Once the sender checks the tracking status, he acknowledges that the recipient has received the parcel.

Now let us look at how it would be done in a blockchain world.

Cross-chain message passing

1. The user calls a function in a smart contract on the Source Chain.
2. That smart contract forwards the message to the Source Gateway Contract on the Source Chain, and the message is receipted, and the sender pays a fee.
3. The Source Gateway Contract generates a unique ID and emits an event containing the unique ID, message, recipient, and fee data. The transaction hash is often used as a unique ID. The Bridge registers this event.
4. The Bridge Validators pick the event emitted by the Source Gateway Contract, validate and sign the transaction.
5. The Explorer tracks events emitted by the Source Gateway Contract, Validators, and the Destination Gateway Contract.
6. Everyone can use a unique transaction ID to query the message status in Explorer. This unique ID represents the tracking number.
7. Signed transactions are organized into batches and sent to the Destination Gateway Contract on the Destination Chain.
8. The Destination Gateway Contract executes its logic and approves these transactions, and then they land on the ledger of the Destination Chain.
9. Please note that these batched transactions are not yet executed. This means that they are in the state of being on the delivery truck but not yet delivered. The relayer (a truck driver) will need to execute these transactions on the Destination Gateway Contract to deliver them. And we trust that it will eventually happen.
10. When the message is executed on the Destination Chain, an acknowledgment is sent to the contract on the Source Chain as an attestation that the message is finally delivered.

We can see similarities and differences between shipping a package and passing a message cross-chain. We hope you find it interesting and stay tuned for more Bridging Basics soon.