This article focuses mainly on interoperability between two exogenous blockchains that are live on their Mainnet now. It is assumed that subchains sharing same blockchain infrastructure or consensus algorithm constitute intra-blockchain communication (like Intranet) and are not considered to be cases of interoperability. First, we will delve briefly into cryptocurrency history. Next, we will explore the ideal interoperability solution, outline existing approaches and finally, the applicability of MavenBridge.

History

Crypto-savvy readers may want to skip to this section.

Out of the wreckage of the financial crisis in 2008, Bitcoin emerged as a potential disruptor for the established banking system. Soon after, other cloned cryptocurrencies utilizing Proof-of-Work consensus followed suit.

Vitalik Buterin, a leading cryptography researcher, elevated the concept of chaining blocks together by proposing Ethereum which established an Ethereum Virtual Machine (EVM) to store the state in a smart contract. This second generation network, in fact, opened the doors of killer applications like ICOs to raise billions of dollars by preserving the complete state of the smart contract and their associated accounts. Further usage of similar networks started showing issues of scalability, privacy, security, congestion. Thus, more networks were proposed and implemented to address the aforementioned issues. The diversity of networks was well received in the community as there may not be “one size fits all” solution. Rather these networks have gone far in their implementations to use different cryptographic signatures, consensus protocols, block headers and confirmations, languages, tools, etc. These varied implementations have led to bigger challenges for interoperability and seamless integration required to create a new level of applications. Before we go into details about how Mavennet is approaching these issues, let’s understand the opportunity at hands.

The Internet — the Biggest Opportunity

Computers have evolved a lot since the middle of the last century and so has the communication between them. Early computers were only capable of communicating using a packet-switched network through ARPANET[1]. As computers evolved, they were required to communicate with each other at longer distances using different architectures and Operating Systems, all the while being fast, reliable and efficient. As a result, we saw the birth of TCP/IP four-layer and Open Systems Interconnection (OSI) seven-layer stacks.

TCP/IP has seemingly prevailed in modern times and is the primary communication protocol allowing computers to share data of different sizes and shapes. Transfer of data or information between the computers has become so easy and transparent that it is essentially akin to magic. One can drag and drop a digital document in a browser and it is directly stored on a computer situated in the data center across the world. Later the same document can be shared with various parties using applications like email, messaging applications, file transfer, etc.

The blockchain Interoperability — Another Opportunity

Similarly, blockchain technology has evolved all the way from first-generation payment processors like Bitcoin and Litecoin, to second-generation systems like the Ethereum network which has added smart contract capability. Now third-generation decentralized networks have emerged, seeking to address storage, scalability, sustainability, and governance issues.

It’s hard to ignore that the benefits of blockchain and applications developed on them have created real value in addressing payment processing, secured transactions, fungible and non-fungible tokens for the digital marketplace, etc. By connecting computers, we are reaping the multifold benefits of the Internet. By connecting these blockchains we can unlock a new paradigm, not only of value but also the transfer of trust, data and immutability records. We now need to create a fabric to join them and build new meaningful and interoperable applications.

Ingredients for a good Interoperability

While working on interoperability specifications, we recognized that any blockchain interoperability solution should have the following important characteristics

a) Decentralized: The decentralized interoperable solution removes intermediaries from the setup and so the centralized failure of the system. Any node on a blockchain should be able to communicate and transact with all nodes existing on different blockchains.

b) Open participation: The digital asset issuers should be able to decide whether to allow cross blockchain transfers and take sole responsibility in case of failure. The platform that connects to other blockchains should be an open marketplace for anyone to build it and provide competitive rates for asset transfers.

c) Secured: The system must be secured through cryptographic operations, and failure-proof from hacker-attacks, collusion of participating parties, network shutdowns, and asset manipulation. The smart contract logic for mint and burn or freeze and thaw operations must be open source (including any software components interacting with the smart contract, if any). The smart contracts must also be audited by external parties.

d) Incentivized: The interoperability should create incentives for the bridge operators and validators to operate the infrastructure reliably. In the situation when this cannot be achieved, such a solution should allow creating cross-chain applications which can offset the cost.

e) Value, data and logic transfer: Though crypto asset movement is a primary use case, the interoperability solution should not be limited to just crypto assets or assets which are backed by crypto; it should support transferring data and logic across blockchains efficiently i.e invoking a smart contract in another chain for actions taken on the source chain (assuming that the source chain does not have smart contract capabilities).

f) Usability: The dev tooling of the interoperability solution should be easy to use by application developers and help them create cross-blockchain applications.

The Existing Interoperability Approaches

Let’s see some of the existing approaches taken by various projects to address blockchain interoperability. Some projects allow direct conversion of one type of cryptocurrency to another whereas some have tried to map (or proxy) one type of cryptocurrency or token to another. The details have been exhaustively covered by respective projects, so we will briefly investigate these approaches and recognize their trade-offs.

Exchanges

In order to convert one cryptocurrency to another, the exchange user must first send the crypto funds to the user wallet on the exchange. The user initiates a trade and the exchange helps to find the opposite trade from its centralized book. After finding the best-paired trade, the exchange makes the trade and charges a fee on the transaction. The user can then withdraw the funds from the exchange in the new cryptocurrency.

Limitation: This approach leaves the end users with no control over the private keys and the funds that are stored on these exchanges, neglecting the first two important characteristics of interoperability. Many of us are aware of the recent example of QuadrigaCX where users collectively lost control of around $200 million. This was a direct consequence of the aforementioned limitation breaking first three characteristics.

2. Atomic Swap

An atomic swap is a peer-to-peer exchange of cryptocurrencies from one party to another, without going through an exchange or an institution. This can be achieved online (direct execution of transaction between different blockchains) or executed through off-chain channels of the main blockchain.

A payment channel is created among agreed participants using a Hashed-TimeLock Contract (HTLC) [2]. This channel remains open until all participants come to an agreed total amount of transaction value or time lapses to close the channel. An HTLC is a multi-lock safe contract which allows transferring cryptocurrency in a secured and trust-less manner.

The primary benefit of atomic swap is that users have full control of their private keys throughout the entire process and avoids centralized exchanges (which may levy additional fees and charges).

Limitation: Decred and Litecoin have achieved on-chain atomic swap [3]. To support on-chain atomic swap here, both chains need to support HTLC functionality and run on the same hashing algorithm. This on-chain interoperability scores high, but it cannot be extended to an incompatible network and cannot support data/logic transfer.

Bitcoin Lightning Network [4] is an example of a Layer 2 off chain atomic swap solution. It allows tiny payments and privacy of those transactions but cannot support large payments.

3. Wanchain

Wanchain utilizes the combination of smart contract, Multiparty Combination (MPC) and Shamir’s Secret Sharing (SSS) and threshold key sharing. It works by locking the real ETH or BTC on Home chain and releases corresponding wrapped 1:1 WETH or WBTC on Wanchain [5]. The end user receiving these mapped ETH or BTC can transfer to another user on Wanchain or redeem by locking them back on Wanchain to receive the original ETH or BTC back.

Limitation: The Wanchain interoperability addresses decentralization, security and incentive characteristics, however, it mostly focuses on mapping BTC or ETH (with some ERC-20 tokens) on their network. Their current approach is more focused on unbanked users and creating a proxy representation of digital assets which can be exchanged or transacted on Wanchain. However, this solution has yet to realize data and logic transfer.

4. Cosmos

Cosmos[6] is a network of independent blockchains, called zones. The zones use the Tendermint core — a PBFT-like consensus — to arrive at block agreement. The first zone at Cosmos is called Cosmos Hub and acts as a central connector. The hub and zones talk to each other using Interchain Blockchain Protocol (IBC) and the hub keeps track of a total amount of tokens held by each zone. To connect to a live blockchain like Ethereum, Cosmos uses Peg zones.

Ethereum EVM is not designed to be compatible with IBC protocol, so Peggy (peg zone) was created, to allow communication with the Ethereum network. Peg zone is a translator blockchain developed on top of Tendermint.

Limitation: Cosmos interoperability supports security and incentive characteristics with BFT consensus (but relies on validators/relays to publish IBC packets). Every connecting chain needs to implement Cosmos IBC protocol and be compatible using the Cosmos SDK to have cross-chain communication with the Cosmos network. If a chain does not provide IBC implementation (platform dependency), any digital asset issuers on that chain cannot benefit from this interoperability — not supporting open participation.

5. Parity Bridge

Parity Bridge[7] is an ERC-20 token contract to map Mainnet Ether with the corresponding mapped token on another blockchain (side) chain. It allows the transfer of arbitrary messages between two Ethereum-based blockchains.

Currently, the bridge allows converting Ether on one chain to ERC-20 token on the other chain. The other chain can be deployed as a POA (Proof of Authority) network which offers reduced transfer cost and high throughput based on network configuration.

Limitation: This solution seems not under active development according to their Github activities and does not address incentives characteristic for bridge operators and validators and relies on trusted parties model. Also, unexpected events like a hard fork or chain reorganization have yet to be considered.

6. Substrate & Polkadot Bridge

Substrate[8] is a generic framework to create an upgradeable blockchain by combining three different technologies like Rust, WebAssembly, and Libp2p. Multiple blockchains capable of their own blockchain state transitions (functions) can be deployed by interested parties, however, they end up isolated as they cannot share its value with another chain.

Polkadot network[9,10] has been proposed to enable these blockchains to communicate with each other using Relay chain. Parachains (chains connecting to Relay chain) with different characteristics can use pooled security.

Limitation: An independent chain like Ethereum will not lose its sovereignty of consensus mechanism, thus, it needs to be connected with Relay chain using a Parachain bridge. This relay chain governance (not open participation) decides whether such a chain can be part of (through an auction or staking process) or be abandoned if the slot expires in the worst case.

MavenBridge

The Aion Foundation moved more than 100 million Aion ERC-20 tokens to the Aion network through the token bridge in late 2018. Concurrently Mavennet was defining and creating the world’s first bi-directional interoperable bridge to connect exogenous blockchains like Ethereum and Aion so that the value can flow from one network to the another and vice versa. The Blockchain Interoperability Application Framework is well captured in the Aion Foundation’s whitepaper, Transwarp-Conduit[11]. Our approach is more in line with the Notary Scheme of Byzantine fault tolerance with trusted validators/signatories, staking reputation rather than value (within PoS).

In our implementation of the interoperability between live blockchains, we allow bi-directional movements of ERC-20 tokens between Aion and Ethereum using MavenBridge. Following the cross-chain standard specification of a fungible token called Aion Token Standard (ATS) [12], We have implemented a smart contract for ATS on Aion network to correspond to the smart contract active on Ethereum network. The ATS checks and ensures that the total supply of the chain does not change in any case irrespective of how many times you move tokens around.

Aion Token Standard

Mavennet has defined a bi-directional bridge standard[13] that illustrates how a bridge smart contract behaves with a relay component that sits in between the two chains to support the movement of tokens. The relay listens and responds to the transfer operations by requesting signatories to confirm whether those transactions have been finalized on the source chain. When the number of confirmations from all validators reaches two-thirds or more, the bridge allows thawing tokens on the destination chain.

The below diagram shows a bridge architecture between Aion and Ethereum for existing ERC-20 tokens. A controller is required only on the Ethereum blockchain to enable freeze and thaw functions on the existing token contract.

Bi-directional MavenBridge Architecture

There are some interesting things that can be achieved using this Notary approach. Firstly and importantly, it’s possible to free the ERC20 tokens from the ecosystem where they were created. In its widespread usage, the lifecycle of a token starts and ends in the same network where they have been issued in and could not experience the benefits of different networks. For example, if a network is congested (or gets hacked in the worst case), with our approach, the tokens on the other network are still accessible (despite the unlikelihood of both networks going down). Secondly, now it’s possible to avoid having all eggs in one basket; to elaborate, distributing the funds by holding 80% in a treasury on a secured blockchain and operating account with the remaining 20% in a nimble blockchain.

This architecture has some important benefits.

The ATS or the controller has full control of freeze or thaw operations making sure the total supply never changes. This helps asset issuers manage accounts and book-keep while providing transparency to the stakeholders. Users have full control over their private keys as they are directly executing the transfer on the network they have tokens on. The bridge does not need an extensive infrastructure of decentralized elements and consensus among them, so there are lower costs and fewer attack vectors for the secured light-weight network elements running between the chain. The smart contracts are self-sufficient to recover from potential compromising activities of bridge operators or validators and imposing order. It cuts down the exchange related expenses and incentivizes interested parties to run the bridge as a token transfer service. The bridge contract and relay are self-correcting (not to allow repeated minting of assets) when chains reorganize or unexpected hard forks occur or in case of long-range attacks.

That being said, this approach has its limitations too since it needs to rely on the probabilistic guarantees of finality gadget for a Proof-of-Work blockchain. If the blockchains on both sides are using PoW consensus, the time to complete the transfer of tokens increases. Secondly, a proper selection of trusted signatories or validators is important too because the whole model cannot function if the relay and signatories collude for two-third voting. It requires governance model (not decentralized) to appoint an entity as a bridge operator or signatory. Additionally, such a bridge infrastructure needs to be DDoS protected as it is open to the outside world.

The MavenBridge acts as a token super highway to allow any ATS compliant tokens to move in both directions. Mavennet went ahead by choosing trusted participants model with an onboarding process. The participants’ main objective is not to earn rewards here but to facilitate interoperability. The signatories can share the cost with bridge operators. Lastly, this solution only addresses crypto asset transfer but this design can be extended to support the transfer of data and logic. Mavennet can help you with any specific functionalities.

Conclusion

Some of the open challenges for connecting blockchains are that more than five-hundred public blockchains exist in this space (according to Coinmarketcap). A few of them are mentioned below.

The technical challenges are of primary concern here as these projects differ significantly in their implementations — different consensus algorithms, virtual machines, data structures, cryptographic signatures, serialization formats, etc. There is no straightforward way to connect them using generic integration.

Secondly, blockchain applications should go beyond utility and security tokens to advanced cross-chain use cases of data and logic.

Lastly, blockchain projects should build beyond their value island emphasizing the creation of external interfaces /integrations to communicate to the external blockchains.

It is our belief that these problems will be nullified by the industry by the mid-twenties. Once this is achieved, cross-blockchain communication will be as seamless as TCP/IP.

References

[1] https://en.wikipedia.org/wiki/ARPANET

[2] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf

[3] https://blog.decred.org/2017/09/20/On-Chain-Atomic-Swaps/

[4] https://lightning.network/

[5] https://medium.com/wanchain-foundation/the-importance-of-blockchain-interoperability-b6a0bbd06d11

[6] Cosmos https://cosmos.network/resources/whitepaper https://blog.cosmos.network/the-internet-of-blockchains-how-cosmos-does-interoperability-starting-with-the-ethereum-peg-zone-8744d4d2bc3f

[7] https://github.com/paritytech/parity-bridge

[8] https://www.parity.io/substrate/

[9] https://polkadot.network/Polkadot-lightpaper.pdf

[10] https://github.com/w3f/polkadot-white-paper/blob/master/PolkaDotPaper.pdf

[11] https://aion.network/media/TWC_Paper_Final.pdf

[12] Aion Token Standard https://github.com/aionnetwork/AIP/blob/master/AIP-004/AIP%23004.md

[13] Bridge Operator Standard https://github.com/aionnetwork/AIP/issues/6