Cross-chain solutions have been the most talked about topic for the past year. With the rise of public chain infrastructures, there have been huge interests in how different chains talk and communicate with each other. Solutions have been proposed and implemented, but without drastic trade offs, none of them really solves the fundamental problems. Now we examine the different cross-chain approaches and divulge into 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.
What is Cross-chain technology?
Cross chain refers to the technology that enables the interoperability between two relatively independent blockchains. Cross-chain technology seeks to eliminate the need for intermediaries or third parties in connecting two blockchain networks, thereby improving interoperability and aiding in the maintenance of blockchain technology’s decentralization.
“The reason for cross-chain usage: chains are heterogeneous and require developers significant time to keep track of the differences and challenges when moving assets across.”
By this time, cross-chain interoperability used to be regarded as cross-chain bridges. However, cross-chain 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.
Reason for usage: chains are heterogeneous and require developers significant time to keep track of the differences and challenges when moving assets across.
What are some different types of cross-chain solution?
In order to understand the cross-chain solutions and compare their differences and attributes, the history of cross-chain mechanisms must be laid out and compared.
1st generation of cross-chain solution: 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 on Excel. Then after a finite amount of time (usually for monitoring purpose), the entity credits assets onto chain B upon verification. The advantage of this approach is the ease of implementation but is prone to human errors and has very low security guarantee. There is also no decentralization among 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 is set to automatically send 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 (CEX)
When the simple cross-chain solutions just 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 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. This 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 it, 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.
What are some different types of ‘decentralized’ cross-chain solution?
- Decentralized Bridge with MPC
As opposed to a centralized bridge, the next iteration is by decentralizing the verification model. An MPC (Multi-Party Computation) bridge starts by having users transfer assets into it, and then using the bridge’s transfer feature, initiate 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 from MPC. Also the nodes can be compromised or colluded. The security is medium while the decentralization is also medium.
- Atomic Swap Bridge with HTLC
There arises another class of bridges depending on atomic swap (Lightning Network) technology. It works by: user transfers assets into an atomic swap bridge, and then using the bridge’s transfer feature, initiate transferring assets X on chain A into assets Y on chain B:
- Create 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 contract on chain A with the encrypted secret
The major advantage is that there is no centralized node/process controlling the bridge transfer. And the disadvantage is rather common – a high cost from deploying HTLC and running HTLC calls. Due to trustlessness, maintaining high security and audit trail is also a hard task. The security of this approach is high and the decentralization is also high, given the above drawbacks.
Cross-chain solution with Light client / Oracle / Relay chain
- 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 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 protocol’s contract on chain B
- Block header (light client) updates are handled by Oracle network to ensure delivery and validity
- User withdraws assets Y from protocol’s contract on chain B upon validation
The pro of this approach is that no intermediary token or chain is needed for transferring to complete. 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 audit trail is a hard task. 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:
- 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
- Block updates are handled by underlying relay chain validators to ensure delivery and validity
- Upon validation, relayer nodes forward transfer message to protocol’s contract on chain B
- User withdraws assets Y from protocol’s contract on chain B
The advantage of this approach over the simple Oracle solution is the cheaper fees from relay chains which consumes 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 relay chain to incorporate all chains:
- 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
- User withdraws assets Y from interoperability contract on chain B
This solution ensures interoperability with very cheap fees due to a relay chain implementation. And it gives instant confirmation after block headers are updated. The biggest challenge is the high complexity in optimizing light clients on the relay chain. By giving enough research and engineering, these optimizations should work out in supporting the benefits the others cannot solve. The security is very high and the decentralization is obviously high.
Next Cross-chain generation: Omnichain is coming – 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 hard research and development, MAP Protocol has finally achieved the omnichain Infrastructure layer with light Client + relay chain technology without compromise. MAP has implemented the omnichain principles with the follow properties:
- Application Ready
- All-Chain Coverage
- Cost Efficient
- 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 – 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 multi-chain and more modularization and incentivization is the way to go.
