A Brief History of Cross-Chain: Explaining Nine Different Cross-Chain Solutions

Cross-chain solutions have been the most talked about topic for the past year. With the rise of public chain infrastructures, there has been massive interest in how different chains talk and communicate. Solutions have been proposed and implemented, but none of them solves the fundamental problems without drastic trade-offs. Now we examine the different cross-chain approaches and divulge why and how they will shape the future of cross-chain infrastructure.

First, let’s discuss what cross-chain technology is and why it is needed. Reason for usage: chains are heterogeneous and require developers significant time to keep track of the differences and challenges when moving assets across. Bridges are less secure and cannot be 100% trusted because they are usually owned by the blockchain project teams and highly centralized (messy with no coordination from each team). The goal of layer-1 blockchain is to standardize, but the segmentation of layer-1 chains is leading to the need of a cross-chain infrastructure layer that’s even underneath the layer-1s.

The history of cross-chain mechanisms must be laid out and compared to understand the cross-chain solutions and compare their differences and attributes.

Manual Transfer

 
The very first cross-chain solution is a manual transfer of assets. The process starts by having the user transfer assets to a specific wallet on chain A, and a centralized entity monitors the wallet for transfers and records them in Excel. Then after a finite amount of time (usually for monitoring purposes), the entity credits assets onto chain B upon verification. The advantage of this approach is the ease of implementation, but it is prone to human errors and has a very low-security guarantee. There is also no decentralization in this approach.

Semi-automatic Transfer

The next iteration improves by having the user transfer assets to a specific wallet and/or smart contract on chain A. Then, a centralized program monitors the address for transfers. Such a program automatically sends assets onto chain B upon verification. The upside is still the ease of implementation without too much complexity or coding, and the records can be kept on-chain instead of locally. The downside is that the centralized program can be buggy or malfunction. The central credit account might run out of funds as well. The security guarantee is also low, and there is no decentralization.

Centralized Exchange

When the simple cross-chain solutions aren’t scalable, centralized exchanges thrive on the cross-chain needs. They work by having users transfer assets into their centralized exchange and then, using the exchange’s “internal” swap, turn “assets X” on chain A into “assets Y” on chain B through record accounting. The advantage is obvious – it’s the easiest solution to use – no coding is needed, and there is high reliability on tier-1 exchanges. But the problem exposes the opposite disadvantage – centralized control of when deposit/withdrawal is available. The centralized exchange gives high security with the downside of the least decentralization.

Centralized Bridge

The next advance improves by having a separate infrastructure on transferring assets across chains – a bridge. A centralized bridge works by having the user transfer assets, then using the bridge’s transfer feature, initiate transferring assets X on chain A into assets Y on chain B. A centralized (or a set of) relayer is responsible for the process:

Lock assets X on chain A
Verify
Mint assets Y on chain B
The advantage of this bridge is the fully automatic process without any manual interruption. And the disadvantage is still the centralized control of when deposit/withdrawal is available. Also, the bridge may be down or hacked, rendering it unfunctional from time to time. So the security is medium, and there is still no decentralization.

Decentralized Bridge with MPC

The next iteration is decentralizing the verification model instead of a centralized bridge. An MPC (Multi-Party Computation) bridge starts by having users transfer assets into it. Using the bridge’s transfer feature, it initiates transferring assets X on chain A into assets Y on chain B. There is usually a decentralized set of relayers is responsible for the process:

Lock assets X on chain A using MPC
Verify using MPC
Mint assets Y on chain B using MPC
The upside of MPC is the fully automatic process without any manual interruption, and the relay nodes do not need to be centralized. The downside is the high computational and communication cost of MPC. Also, the nodes can be compromised or colluded. Security is medium, while decentralization is also medium.

Atomic Swap Bridge with HTLC

Another class of bridges arises depending on atomic swap (Lightning Network) technology. It works by: the user transfers assets into an atomic swap bridge and then using the bridge’s transfer feature, initiates transferring assets X on chain A into assets Y on chain B:

Create a new HTLC – Hash Lock Timed Contract
Deposit assets X into contract on chain A
Generate hash lock key + encrypt a secret for final withdrawal within time T on chain B
Present encrypted secret to contract on chain B to withdraw assets Y
OR time T has passed, and recover assets X from the contract on chain A with the encrypted secret
The significant advantage is that there is no centralized node/process controlling the bridge transfer. And the disadvantage is relatively common – a high cost of deploying HTLC and running HTLC calls. Due to trustlessness, maintaining high security and the audit trail is challenging. The security of this approach is high, and the decentralization is also high, given the above drawbacks.

Cross-chain Interoperability with Light Client + Oracle

After the high-cost bridge approaches, more implementations are born to reduce this cost. Light client technology has become the latest norm to simplify cross-chain verifications. The process is as follows:

First, the user transfers assets X into a cross-chain interoperability protocol’s contract on chain A
A transfer message is set on contract and gets picked up by decentralized relayer nodes
Nodes send proofs across to the protocol’s contract on chain B
Block header (light client) updates are handled by the Oracle network to ensure delivery and validity
The user withdraws assets Y from the protocol’s contract on chain B upon validation
The pro of this approach is that no intermediary token or chain is needed from the transfer to completion. Instant confirmation is possible after block headers are updated. The cons are 1) collusion risks from Oracles, 2) due to trustlessness, maintaining high security, and the audit trail is challenging. The security of this approach is medium, while decentralization is high.

Cross-chain Interoperability with Relay Chain

Upon the lessons of the Oracle approach, a pure relay-chain solution is also present. The process is slightly different:

The user transfers assets X into a cross-chain interoperability protocol’s contract on chain A
A transfer message is set on contract and gets picked up by decentralized relayer nodes
Nodes send proofs to the relay chain’s contract
Underlying relay chain validators handle block updates to ensure delivery and validity
Upon validation, relayer nodes forward the transfer message to the protocol’s contract on chain B
The user withdraws assets Y from the protocol’s contract on chain B
The advantage of this approach over the simple Oracle solution is the cheaper fees from relay chains which consume most of the costs. Instant confirmation is possible after blocks are updated, which is crucial to solving longer delay times. The problem is that the protocol itself may not support an all-chain ecosystem. The security is high (within the ecosystem), and the decentralization is also high.

Cross-chain Infrastructure Layer with Light Client + Relay Chain

The next-generation solution is focused on the cross-chain infrastructure layer solving all the fundamental problems above. It combines the light client technology with a relay chain to incorporate all chains:

The user transfers assets X into a cross-chain infrastructure layer’s interoperability contract on chain A
A transfer message is set on contract and gets picked up by decentralized relayer nodes
Nodes send proofs to the relay chain’s interoperability contract
Block header (light client) updates are handled by decentralized maintainer nodes to ensure delivery and validity
Upon validation, relayer nodes forward transfer message to interoperability contract on chain B
The user withdraws assets Y from the interoperability contract on chain B
This solution ensures interoperability with very cheap fees due to a relay chain implementation. It also gives an instant confirmation after block headers are updated. The biggest challenge is the high complexity of optimizing light clients on the relay chain. By conducting enough research and engineering, these optimizations should support the benefits the others cannot solve. The security is very high, and the decentralization is high.

About MAP Protocol

Out of the cross-chain solutions, we have yet to see one that solves all the problems above. Until the MAP Protocol is implemented. After 3 years of complex research and development, MAP Protocol has finally achieved the Omnichain layer with light Client + relay chain technology without compromise. MAP has implemented the Omnichain principles with the following properties:

Developer Ready
All-Chain Coverage
Minimum Cost
Security Finality
Instant Confirmation

MAP Protocol is the infrastructure layer to support building bridges, DEXes, interoperability protocols, and more. It supports verification by light clients on the MAP relay chain directly – to reduce costs. And it provides Incentives built into each component for dapp developers to earn or present to end-users. MAP supports EVM and non-EVM chains – the protocol layer is isomorphic with all chains.

For the future, MAP is the infrastructure behind all chains that will be the new base layer. Developers are no longer restricted by their chain of choice and can focus on the dapp product itself. The future is Omnichain, and more modularization and incentivization are the way to go.