Things are happening quickly in the blockchain space. And while we already know the many benefits of the technology, there is one key challenge that comes to mind, namely blockchains’ lack of interoperability.
To put this dilemma into context, if a developer wants to build a dApp on any particular blockchain network, they’re generally locked into that platform and are unable to leverage the benefits of other blockchains.
Individual blockchain networks are often unable to effectively communicate with one another. This makes it difficult, and at times impossible, for users to transact across different blockchain networks.
To resolve this issue of non-interoperability, a cornerstone technology of blockchain has been developed — the blockchain bridge.
Put simply, a blockchain bridge can be thought of exactly like its real-world counterpart, as a structure that connects two or more disconnected and completely separate points to provide easy passage over a pre-existing ‘obstacle’.
In the blockchain world, a bridge can be defined as an interconnected link that enables the communication and interaction between two different blockchain networks.
By design, a blockchain bridge is the key enabler for users to leverage the benefits of both blockchains. Blockchain bridges are generally regulated by a
protocol to keep a constant token supply across all platforms.
For instance, when a token moves from one blockchain, it is locked on that chain, and the equivalent token is minted on the opposite blockchain. Conversely, when the token moves back to its original network, the minted token is burned and the corresponding token on the origin chain is unlocked.
Most blockchain networks are based on different core technologies for consensus, smart contract functionality, and runtime. For an ecosystem that strongly positions itself as a distributed and decentralized system for transacting, a lack of blockchain interoperability hinders the development of the ecosystem.
The first known attempt exploring blockchain interoperability was back in 2012 by Joseph Chow, who created the BTC-Relay system to obtain information from the Bitcoin network to use on Ethereum.
Fast forward a few years, and with no satisfactory mechanism in place, users continued to note the necessity for a breakthrough solution in cross-chain interactions. By using a bridge, users are able to connect multiple isolated blockchains to one another, allowing for the simplified flow of digital assets.
To put this into perspective, let’s imagine two blockchain networks: Ethereum and Avalanche. Today’s Ethereum users experience slow transaction speed and expensive gas fees during times of high traffic and congestion.
With a bridge, the user can send their token (ERC-20 or ERC-721) to Avalanche to take advantage of its rapid transaction times, higher throughput, and lower fees.
In this situation, both blockchains benefit from users leveraging the bridge. On one hand, it reduces network traffic on Ethereum by distributing it to other less congested blockchains, thus solving some of Ethereum’s scalability issues.
On the other hand, the corresponding blockchain gains exposure to the Ethereum community. Ultimately, once a bridge unites separate blockchain ecosystems, it allows users to reap the benefits of each.
“Bridges play a vital role in enabling DeFi to grow beyond the borders of one network to complementary ecosystems.” — Emin Gün Sirer, Founder and CEO of Ava Labs
ChainSafe is focused on building the infrastructure for Web3 by contributing open-source software to the ecosystem.
Back in 2018, the ChainSafe team began building ChainBridge: a modular multi-directional blockchain bridge to allow data and value transfer between EVM-compatible blockchains and Substrate-based chains.
The company considers itself to be chain agnostic and is actively contributing to the Ethereum, Ethereum Classic, Cosmos, Polkadot, and Filecoin ecosystems.
At a high level, the ConsenSys-audited ChainBridge is a message-passing protocol. Events on a source chain are used to create a message that is then delivered to the destination chain.
“ChainBridge has been our response to the imperative for open-source protocol objectivity, sustainability, and collaboration. Our goal is to allow projects to interact with one another using a lightweight and simple integration. Collaboration is good for the whole garden, and it gets competitors to see value beyond zero-sum thinking.” — ChainSafe founder and CEO Aidan Hyman.
The bridge offers the ability to transfer arbitrary data from one blockchain to another, signalling another win for protocol interoperability and tooling.
With the team at ChainBridge providing the necessary toolkit to share blockchain infrastructure, they are heavily focused on improving three main features of bridge functionality.
1. Easy transfer: No restrictions on backward compatibility. A greater focus will be placed on streamlining transfers between multiple chains so that each bridge doesn’t have to be built 1:1. In the future, one relayer set could be created across different chains for additional support and transactions amongst everyone.
2. Simple integration: Easy integration for future chains. It should always be able to interact with all of the chains that were previously added to it.
3. Modular security: Network security should be multilayered, with different techniques used to protect the network.
There is an immense amount of value in sharing infrastructure across specific use cases — the costs get lower and the sustainability of the software increases.
Going forward, the ChainSafe team hopes to encourage members of the community to deploy and modify the bridge in their own environment for greater applications of use.
ChainBridge functionality is two-way, which enables its users to transfer assets from one chain to another, and back again (if they so desire).
To illustrate the functionality of the bridge, we’ll take a look at the following: bridge characteristics, bridge components, and bridge roles.
A decentralised bridge should be accessible at any time, with no single point of failure. A bridge should easily integrate with new chains. Cross-chain transactions should be secure and provable.
The relevant bridge components are listed below with their respective abilities.
🔐 Bridge Admins
➕ Can add or remove relayers.
➕ Can change the number of votes for a proposal to pass.
➕ Can pause/unpause the bridge.
➕ Can transfer funds in the contract to any account (EVM-specific).
➕ Whitelist resource and chain IDs.
➕ Can vote or create new proposals.
➕ Can execute passed proposals.
➕ Can vote against proposals (Substrate-specific).
➕ Can transfer tokens between blockchains by locking tokens in bridges.
Relayers play three main roles. ChainBridge currently relies on trusted relayers to perform these roles.
Under the ChainBridge model, the general workflow of data and value transfer from Chain A to Chain B is as follows:
To better understand the above diagram in more detail, each step numbered
is explained below.
The user initiates a transaction in the bridge contract of Chain A. The user will need to input the target chain (where they want the data/ message/funds to go). After a few checks, the deposit function of the handler contract is called, which validates the parameters provided by the user, creating a deposit/execution record on the corresponding call of the target contract.
After the function of the target contract in Chain A is executed, a Deposit Event is emitted by the bridge contract, which contains all of the necessary information to execute the transaction on Chain B. This is known as a Proposal and gets sent to relayers.
Each Proposal can have five status (inactive, active, passed, executed, and cancelled). Relayers are always listening on both sides of the chain. The relayer plays various roles during this process (listener, router, and writer). The listener extracts events from Chain A and constructs a message which passes through the router to the writer. The writer interprets the message and submits the transaction to the destination chain.
At this point, the relayer initiates a vote on the Proposal, which takes place on the bridge contract on Chain B. This sets the state of the Proposal from inactive to active.
In the current model, relayers have a trusted setup with the admin of each chain bridged. Depending on the bridge, you can set up as many relayers as needed. The Proposal Event is broadcast to the relayers of the target chain, who must vote on the Proposal. Each time a relayer votes, an event is emitted by the bridge contract that updates its status.
Once a predefined threshold is met (how many votes must pass to execute the transaction), the status changes from active to passed. This mechanism guarantees that multiple parties verify each transaction.
A relayer then executes the proposal on Chain B via the bridge contract.
The bridge then executes the Proposal in the target contract via the handler contract on Chain B. Another event is emitted, which updates the proposal status from passed to executed and concludes with the transfer of value from Chain A to Chain B, and the user receives their minted tokens.
Without learning the history of open-source software, it’s easy to think that good intention is what fuelled this movement when in reality the fuel is economic cooperation.
The ChainSafe team is continuing to enter new partnerships and onboard new integrations, paving the way for cross-functional collaboration for a (near) future multi-chain world. ChainBridge has already seen a number of exciting partners successfully test and integrate their bridge contracts, with more on the way.
Currently, the system is not entirely trustless; admin key holders have complete control of all components reviewed. For example, they could mint an infinite amount of tokens or withdraw all the tokens from the bridge contract on the original chain.
While ChainBridge v1.0 was solely focused on building the necessary message-passing functionality, v2.0 and v3.0 are focused on implementing higher degrees of ‘trustless’ features and improving overall bridge security and functionality.
While the company is looking to make improvements, they are more concerned with building a ‘ solid system that works rather than expanding to non-EVM-supported frameworks at this point.
Create your free account to unlock your custom reading experience.