Interchain Messaging with SKALE

Published in

SKALE

5 min readMar 22, 2019

Hello, Everyone!

Today, we’re going to be reviewing SKALE’s Interchain Messaging — a system serving as the communication layer between independent SKALE Chains which allows users to call smart contracts on other SKALE Chains and facilitates the transfer of digital assets. This functionality is made possible through the combination of smart contracts (MessageProxy, TokenManager, and DepositBox), transfer agents, BLS signatures, and fork-less consensus.

Connecting SKALE Chains

Before we can send messages between SKALE Chains, we must first connect them using the MessageProxy smart contract that comes packaged and deployed with each chain — we can think of this in a similar way to opening a TCP connection between two servers.

Linking chains is done in a one-way fashion whereby the chain’s owner (or any owner-approved party) can approve what chains they listen to messages from. This approval is facilitated by adding the target SKALE Chain’s ID and public group key (stored in SKALE Manager on mainnet) to the MessageProxy smart contract on the SKALE Chain. At this point, the owner’s chain will begin listening and relaying any messages from the target SKALE Chain. In this way, the owner of a SKALE Chain can specify which chains they listen to but cannot force another chain to listen to them — so as to prevent spamming / DoS attacks.

Message Transfer Agents

Each validator in a SKALE Chain ships with a Message Transfer Agent responsible for listening to events emitted from each connected chain’s MessageProxy smart contract and executing them. This means that a chain of 16 validators has 16 agents — all of which are assigned to short (~15 seconds) deterministic time slots during which they must monitor all incoming messages from other chains.

To send a message to another chain, a user will send a transaction specifying the target chain’s ID as well as the address of the target user / smart contract of the transaction to their originating chain’s MessageProxy. Once this transaction has been executed and committed to the chain, it will emit an event including the transaction data, the number of the block that the transaction was included in, and a nonce for the transaction representing the message counter between the sending and receiving chains.

Once the transaction has been committed, all of the receiving chain’s agents will receive the emitted event and cache it until it has been executed on their respective chain. The currently selected agent will provide each of their transactions as well as their signed blocks to the validator to execute them on the respective chain’s MessageProxy.

Before forwarding transactions to their respective destination smart contracts, the MessageProxy will verify that the chain has been connected, that the transactions are included in each of the signed blocks, and that the signers of the transaction are the current validators for the sending chain; transactions not meeting these criteria will be discarded. After the transaction has been executed on the receiving chain it will be removed from the caches of the agents in that chain. Just because a transaction has been forwarded does not mean that it will succeed — it is still subject to the same checks as any normal transaction on a SKALE Chain.

Note: It should be noted that SKALE Chains have no fees, allowing for these transactions to be freely executed without incurring monetary cost to each validator / transfer agent.

Presently, there is no acknowledgement for the success / failure of an interchain transaction — this is by design to allow users to implement their own protocols on top of the messaging system. As popular design patterns emerge for handling this, users will be provided with sample implementations for their respective SKALE Chains.

Fork-less Consensus

The default consensus protocol for each SKALE Chain is finality-guaranteeing and does not fork. This is crucial for interchain messaging to provide receiving chains with assurance that the transactions which were received will not be orphaned. Below is an illustration of this issue.

In a forking protocol, the transaction we wish to include may be included in block 4b, which will be eventually orphaned due to it not being included in the longest chain. This would lead to invalid transactions being relayed across chains — allowing for things like double spending.

Transferring ETH

Participants of a SKALE Chain wishing to transfer ETH into their account can deposit ETH into a pool in the DepositBox smart contract on the mainnet at any time. Before relaying the transaction, the transfer agents will wait a finalization period (~5 minutes) to mitigate possibility that the deposit transaction is orphaned. After the transaction has been finalized, the currently selected agent will transfer a message to TokenManager through MessageProxy, for send the respective amount of deposited ETH to the desired account on the respective SKALE Chain.

To transfer ETH from one chain to another, a user will send a transaction to another chain which will transfer the ETH being sent to the TokenManager on their chain and send ETH to the counterparty from the TokenManager on the receiving chain. In this implementation, the transfers are serving as a way to withdraw the pooled funds in the DepositBox on the mainnet. In the event that the sender specifies an invalid address to send the ETH to, the ETH will not be refunded and still be stuck in that account until its respective private key has been determined.

To withdraw ETH from a SKALE Chain to the Ethereum mainnet, a user will submit a withdrawal transaction their respective chain’s TokenManager. This transaction will emit an event to the agents who will relay it and related metadata to the MessageProxy located on the mainnet. The MessageProxy will verify that the transaction is included in the signed block and that the signers of the transaction are the current validators for the sending chain. Once this has been verified, the transaction is forwarded to the DepositBox and the specified amount is transferred to the user’s account on the mainnet.

Learn More

If you’d like to learn more about SKALE’s Interchain Messaging or are interested in trying SKALE out, make sure to join the SKALE community on Discord and check out the Developer Documentation!

Also, feel free to also check out SKALE’s Technical Overview and Consensus Overview for a deeper dive into how SKALE works and is able to provide 20,000 TPS.

SKALE’s mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. We aim to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization.