Interchain messaging

Messaging concepts

The foundation of bridges and the ability to move tokens from one network to another relies on the concept of messaging. Messaging is a fundemental primitive in IT - the ability to send a message from one discrete system to another is a key part of many applications we use in our daily lives.

Asynchronous versus synchronous messaging

Synchronous messaging

The first concept is understanding the difference between synchronous and asynchronous messaging. Synchronous messaging is characterised as a conversation, where both the sender and recipient must be available and capabable of sending and receiving messages in real-time. With a synchronous approach, when a sender sends a message, they will wait until a response is recieved from the recipient. The recipient must be available to process the message and then send a response back to the sender, which also must still be available to receive it. Typical manifestations of synchronous messaging involve remote procedure calls (RPC) where a sender invokes a function on the recipients machine via sending it a message and then waits for the a resposne which is the return value of the remote function.

Asynchronous messaging

With asynchronous messaging, there is no assumption that the sender or recipient must to be online to effectively participate in a messaging workflow. This is made possible by a piece of infrastructure called a message queue. Message queues receive messages from producers into a queue which can then be accessed by consumers at some point in the future. If the consumer is not available when the message is enqueued, then that's OK, they'll just receive the message when they are next available and check the queue. The broker handles persistence of the message for the time between when it is produced and consumed. We say this is durable messaging, that is, the broker ensures that the message is not "lost" for whatever reason at any point during its journey from producer to consumer. Lastly, using queues allows a producer process to continue execution after a message is sent, rather than blocking and waiting for a response as with a synchronous workflow.

Inter-blockchain messaging relies upon asynchronmous messaging. A standard messaging protocol listens for messages on a source blockchain, sends the message to an off-chain queue, which then forwards on the messages to the destination blockchain.

Delivery semantics

An effective messaging protocol must define a set of rules for how it operates:

1. For example, some messaging protocols are "Fire and forget". You can send a message to another system but you've no idea if it will be received or not. This is usually called "at-most-once" delivery.

2. You might want to retry sending the message but what if that message is to debit your account by 1000 GBP - you don't want to do that twice. This has an advantage over the prior system in that the message will always arrive but there might be duplicates. This is usually called "at-least-once" delivery.

3. Finally, we can improve the messaging protocol by filtering out duplicate messages if we tag each message with a number the senders and receivers keep track of. This means we can retry sending and not worry about duplicates. This is called "exactly-once" delivery and is exactly what we need to send messages from one block chain to another.

Messaging protocols

We currently use two inter-chain messaging protocols

• Layer Zero

• Hyperlane

We can extend Hyperlane's support for more networks by running validators and relayers.

d2o teleporting

d2o teleporting works by using message protocols as described above.

One of the key differences with d2o is that we have integrated the minting and burning of d2o with the ability to move it from one blockchain to another. This means that there's no need to wrap d2o when it's moved from one blockchain to another. The advantage is that d2o is always a native token whatever network its on.

When teleporting d2o, it is first burnt by the d2o contract. In the same transaction an event is emited to signal that d2o should be minted on another blockchain. This event is created if and only if the transaction which burns d2o succeeds.

Next, an off-chain process, monitoring these particular type of events sees the event that we wish to mint d2o on another blockchain. The off-chain process checks the validity of the message and forwards it on to the other blockchain network.

It does this by sending a transaction to a particular contract on the other network. This contract is essentially a mailbox. It unpacks the message and routes it to the right place, in this case, our d2o contract, specifically to call the mint function for the smae amount of d2o which was burnt on the other blockchain network.

You may note that the fees to teleport are higher than you might imagine. This is because you also have to pay the gas for the transaction on the desintation network as well as the source network.