Suppose you know that you want to go cross-chain to enable global accessibility, liquidity and distribution for your decentralized application. How should you go about designing the cross-chain architecture?

On a high level, there are two models of cross-chain architecture:

• Peer-to-peer architecture.
• “Homebase-and-satellite” architecture.

Let’s take a look at examples of these architectures and examine their trade-offs.

Peer-to-peer cross-chain architecture

In a peer-to-peer cross-chain architecture model, you can deploy an identical “symmetric” version of your smart contracts across multiple chains to run the same functionality. A good example of this is an omnichain token, such as an ERC-20 token, which can run on any chain that is compatible with the Ethereum Virtual Machine (EVM).

Your peer-to-peer contract can encode the following semantics:

• It can receive a message from any one of its siblings.
• The message will say, "User X is sending their token of amount Z from chain A to chain B."
• The contract on chain B will verify that it trusts the messages from chain A and the contract address that sent the message. If so, it will authorize a “mint” operation on chain B to the user’s wallet (the token is burnt on chain A prior to this by the associated contract).

All contracts perform identical functions. Messages can be sent asynchronously and even executed out of order. Tools like the contract address deploy services allow dApps to scale to new chains without much friction. (Every contract has a contract address C across all chains, and messages are verified if they come from C and the underlying interoperability protocol approves them.)

The main advantage of using this cross-chain architecture is simplicity and ease of scale across multiple networks. However, it doesn’t work well when an operation cannot be executed without “global” visibility into the state of the application.

Homebase-and-satellite cross-chain architecture

This is where “homebase-and-satellite” comes in. It is essentially a hub-and-spoke cross-chain architecture model, where most of your contract logic lives on a single chain. The developer can pick the best chain for their use case and build in an environment that optimizes for high security, latency, fees or any requirement. The satellite contracts on the connected chains are then responsible for sending messages to the homebase to perform state transitions.

For example, suppose you want to build an NFT marketplace on chain A. You might want to enable users to buy/sell the NFTs from any wallet, on any chain, in any currency. Then, a user from chain B would send their asset to a satellite contract that will communicate with the homebase contract on chain A and issue the NFT to the user’s wallet. The NFT issuance, order table and prices are all determined on chain A. As a result, the user’s transaction may not be finalized until the message from chain A to chain B is finalized and delivered.

Users can manipulate shared application state across multiple chains. Some applications would need “atomicity” of their requests. You can build a layer of application-level protocols to deliver these properties. For instance:

• You can add nonces to your messages to make sure they're always executed in order, using nonced execution.
• You can implement a send-ack (acknowledge-receipt) pattern to synchronize states across contracts (example dApp).

Conclusion

On the one hand, secure cross-chain communication allows existing dApps to connect with assets, users and functions cross-chain. Looked at another way, it enables new kinds of applications.

Axelar provides a universal overlay network that links any asset, any dApp, any user, on any connected chain, with the entire decentralized web. Developers can bridge assets, or compose functionality over this network using General Message Passing to call any function on any connected chain.

The cross-chain architecture choices discussed in this article are some of the decisions that come with building applications that take advantage of those capabilities natively.

To learn more: - Read Axelar's documentation.

• Watch coding tutorial videos (we're always adding new ones).
• Clone a GitHub repo of example dApps

Cover image public domain: Source.