Cross-Chain

When blockchains were first being built, they were envisioned as being able to provide a ‘one size fits all’ solution, meaning that all transactions, smart contracts, or anything else is performed on a single chain. However, it’s clear now that such a system isn’t so practical, especially when there are scalability limits and innovation constraints.

A cross-chain is the interoperability between two relatively independent blockchains. In other words, it allows blockchains to speak to one another because they’re built in a standardized way. Cross-chain implementation is mainly represented by asset swap and asset transfer, which is both an important part of the blockchain world and a key research direction of PPIO. With cross-chains, the limitations of a single chain can be avoided. Today we will explore the logical structure of the Cosmos cross-chain protocol, one of the most promising cross-chain platforms.

Cross-chain interaction can be divided into isomorphic cross-chains and heterogeneous cross-chains according to the different underlying technology. For isomorphic chains, the security mechanism, consensus algorithm, network topology, and block generation verification logic are consistent and the cross-chain interaction between them is relatively simple.

On the other hand, the cross-chain interaction of heterogeneous chains is relatively complex and includes technology such as the PoW algorithm for Bitcoin and PBFT consensus algorithm for Tendermint. The block composition and the deterministic guarantee mechanism are quite different, therefore a direct cross-chain interaction mechanism is not easy to design. Cross-chain interaction between heterogeneous chains generally requires third-party ancillary services.

How to Realize Isomorphism Across Chains?

Chains developed based on Tendermint can adopt isomorphic cross-chains. The principle of asset transfer between isomorphic chains in Cosmos is as follows.

Since Tendermint uses the PBFT+POS consensus algorithm, a block is only submitted to the network when 2⁄3 certifiers agree. The Validator information can be verified by checking the block header to verify whether the block header is legal in a certain chain. As an example, Tendermint is developing two chains: Chain A and Chain B. Now assume that assets need to be transferred across the chain. Firstly, the two chains, A and B, will register with each other. In the process of registration, A and B recognize their separateness. The chain will then send the respective genesis blocks and ChainID (used to represent different chains) to each other. Since the genesis block contains the Validator information, after registration, A and B chains will have the Validator information of the other chain, as well as block header information.

Now the assets in A need to be transferred to B. First, the user can send a cross-chain transaction packageTx to A. A executes the packageTx, destroys or locks the related assets, and then writes packageTx to the egress. The egress can be regarded as a mailbox where all externally notified cross-chain transactions are placed.

In order to notify chain B of events occurring in chain A, a relayer is needed. The relayer is responsible for forwarding cross-chain messages from the egress in chain A to chain B’s egress. In this situation, the relayer queries the packageTx in chain A’s egress and obtains the Merkle Proof of packageTx. The information is packaged into IBC Package PostTx transaction and sent to chain B, which queries block header information as to where packageTx is located. It also packs the block header information into IBCUpdate Chain Tx and sends it to chain B. Note that the relayer pays the transaction cost of both IBC Package PostTx and IBCUpdate Chain Tx.

After chain B receives the IBCPacketPostTx transaction, it first checks whether the block header in the IBCUpdateChainTx is part of chain A through the Validator in that chain, and then verifies whether the Merkle proof of the cross-chain transaction in IBCPacketPostTx is equal to the block header hash in IBCUpdateChainTx. When all the checks pass, the B chain starts to perform related operations (for chain B, this means generating related assets, etc).

Multichain Networks

At the heart of it, a multichain blockchain refers to a project using multiple chains that are designed to communicate with one another. For this to work, the project needs to be based on at least two blockchains at the same time. By existing across multiple blockchains, it allows easy communication and interaction between the blockchains so that users can utilize the project across different networks.

How does multichain technology work?

The multichain approach creates a sort of internet of blockchains that allows users to transact across multiple chains at the same time without needing to move their assets from one network to the other.

It achieves this by splitting its underlying blockchain into different layers: the consensus layer – which is what keeps the system secure – is the base layer for the entire network. This common strand keeps all of the different blockchains within the multichain system secure.

By contrast, the network’s application layer, which sits on top, is programmable – this enables different individual blockchains to co-exist and communicate freely, despite each one being a unique ecosystem. Cosmos is a great example of this dynamic in action, ushering in a new era of interoperability between blockchains without compromising on security.