Blockchain bridges — interaction between different networks
Interoperability — is the ability of a product or system, the interfaces of which are completely open, to interact and function with other products or systems without any restrictions on access and implementation.
Blockchains are typically isolated environments with many users and high activity levels. Still, they cannot interact with other similar systems, which greatly limits them. To ensure interoperability, the crypto ecosystem requires blockchain bridges.
A blockchain bridge is a technology that allows different blockchain networks to interact with each other, exchanging assets, data, and information.
Bridges create a transport route (channel) between blockchains through which tokens, messages, arbitrary data, and even smart contract calls can be transferred from one chain to another. Different blockchains have unique strengths and weaknesses (such as speed, throughput, transaction costs, etc.), so bridges contribute to developing the entire cryptocurrency ecosystem, allowing blockchains to use each other’s innovations.
Basic architecture
First, let’s understand what happens at the top level when something is transferred from Blockchain A to Blockchain B. For example, Alice has 10 ETH in Ethereum. Still, she wants to use it in the ecosystem of another blockchain (e.g., Avalanche, Tron, Polygon, etc.) with lower fees or for use in some unique DeFi protocol. However, these are technically two blockchains, and they cannot interact directly due to differences in consensus, community rules, transaction processing, etc. This is where the bridge comes into play.
For Alice, it looks like this: she interacts with the bridge, sends it ETH, and then receives ETH on another blockchain (either they go to Alice’s account or they need to be stamped). On blockchain B (let’s say Avalanche), Alice will not receive the original ETH but a so-called “synthetic asset” that will only have value as long as the corresponding amount of ETH is stored on the bridge.
Now, Alice can use her ETH in another blockchain. The main idea is that the bridge here is a third party that ensures compatibility between two blockchains. In this scheme, even an ordinary user with funds in Avalanche can act as a third party.
Of course, one entity cannot process both transactions in different blockchains. Let’s introduce the term “application”. This means that blockchain A will have its application, and blockchain B will have its own. By the way, since a bridge can be between two blockchains and between two layers of one blockchain (Layer 1 and Layer 2), for example, between Ethereum and Arbitrum, any article about bridges will use the term “domain.”
Domain — in the context of bridges, this is the main entity that participates in the exchange of messages from the sender side or from the receiver side (e.g., blockchain or Layer 2).
Now, domains can be strikingly different (Bitcoin and Ethereum, Ethereum and Solana, Cardano, and Polkadot), so each domain needs its own application for their interaction. The main data transfer processes will lie in the cryptographic plane (signatures, Merkle trees, etc.). Of course, channels will be needed to connect two such applications.
Moving to a more abstract level, the process described above will look like this:
In this case, domain A cannot simply send a message over a channel to domain B and receive confirmation from domain B that the message was delivered. This is a one-way communication. Therefore, a third party is needed — verifiers.
Things get more complicated because the verifiers and how they interact with applications are usually the main differences between bridges. In the context of developing different bridge designs, there is a concept called the interoperability trilemma, which states that interoperability protocols or bridges can only have two of the following three properties:
Trustlessness — Provides security equivalent to the base domain.
Extensibility — Supports any domain.
Generalizability — Ability to handle arbitrary cross-domain data.
Classification of bridges
Globally, bridges are usually divided into two types: trusted and trustless.
Trusted bridges are verified externally, i.e., they use an external set of verifiers to transfer data between domains: federations with multi-signatures, multi-user computing (MPC) systems, and oracle networks. Such bridges usually demonstrate good performance in speed and cost-effectiveness, but they must sacrifice security.
Trustless—these bridges rely on the security of the domains they connect to transfer data. Since security must be at the level of the base domain, this system lacks trust. Such bridges are considered more secure. In this case, either the ability to support a large number of different domains or the ability to process arbitrary data is usually sacrificed.
We can describe these types as a spectrum.
Trusted system with no staked collateral — verifiers do not post collateral so that users will lose funds in case of a system failure or hack. You can only rely on the reputation of the bridge. Example: Binance Bridge.
Bounded systems — verifiers post collateral in the native token of the network, which gives them an economic benefit. Still, the collateral will most likely be burned in an unfavorable situation. Users will also lose their funds in an error or hack. Example: the infamous Ronin Bridge.
Insured system — also requires collateral, but unlike the previous options, user losses are covered by this collateral. Example: Axelar.
Optimistic bridge — a system similar to “Optimistic rollups”, where all transactions are considered valid until proven otherwise. Verifiers are observers with an economic incentive to find “bad” movements on the bridge. Example: Nomad.
Liquidity Networks — similar to a p2p network, where each node acts as a liquidity provider for a specific domain (they are called routers). Any user can act as a router. There are no minimum liquidity limits. The system has a sequencer that collects requests and can connect as many routers as needed to execute them. Security is provided by mechanisms for blocking funds and the ability to challenge the actions of routers. The advantage is that you do not receive a derivative synthetic asset in the destination network; funds are stored in this blockchain. This is similar to a cross-chain token exchange. An example is Everclear, previously called Connext.
Light clients and relayers — verifiers here are users who track events that have already been added to the source blockchain. Then, evidence is generated that the event occurred and sent to the destination domain along with block headers (i.e., the so-called “light client” is sent). A smart contract in the destination domain verifies the headers and executes the action in the destination domain if the event has indeed occurred. It requires the subject to “relay” the block headers and proofs. While users can relay transactions, relayers are expected to relay data continuously. This relatively secure bridge design guarantees trustless delivery, but verification in the destination domain is usually very expensive in terms of gas. An example is Cosmos IBC.
ZK Bridges — Bridges built on zero-knowledge proofs (ZKP) also use light clients and relayers to verify inter-chain transfers and are considered another option for a trustless implementation. An example is the ZKSync bridge (which only works between Ethereum and ZKSync).
Bridge types
In the basic model, bridges need to monitor events in the source domain, relay them to the destination domain, and verify the validity of the relayed information to function properly. As a result, most bridges are designed with several components:
Monitoring. There is typically an entity, either an “oracle,” “validator,” or “relay,” that monitors the state of the source domain.
Message relaying/forwarding. Once an entity detects an event, it must relay information from the source domain to the destination domain.
Consensus. Some models require consensus among the participants monitoring the source domain to relay information to the destination domain.
Signing. Participants need to cryptographically sign information sent to the destination domain individually or as part of a threshold signature scheme.
Based on this design, there are approximately four types of bridges, each with its advantages and disadvantages:
Asset-specific — the only task of such a bridge is to access a specific asset of one blockchain in another blockchain (here, it’s more likely blockchains, although they can also be called domains). Assets in the destination blockchain are often “wrapped”. The underlying asset fully backs them. Bitcoin is the most common asset that connects to other blockchains.
Chain-specific — a bridge between two domains, the same as “asset-specific” in mechanics but transfers multiple assets (example: Polygon PoS bridge).
Application-specific — used for a specific application when DApp supports multichain. It can transfer assets and data (for example, Thorchain).
Generalized — protocols for transferring information between multiple domains (example: Chainlink).
When discussing the transfer of assets, the most common models of their transfer are worth mentioning. We’ve already mentioned “wrapping” an asset from the source domain a few times — this is a fairly common method for bridges. It’s done as follows:
The source domain locks the underlying asset, and the destination domain mints a synthetic version at a 1:1 rate. For example, for BTC, this would be WBTC (Wrapped BTC).
During the reverse exchange process, the asset is burned in the domain that minted the wrapper and is unlocked in the base domain.
The second model of asset transfer is called atomic swaps. This is simply an exchange of tokens from the source domain for tokens from the destination domain. The HTLC (Hashed Timelock Contracts) scheme is often used for this. In short, HTLC allows two users to exchange cryptocurrency directly between different domains without the need to trust external intermediaries (p2p); for this purpose, a special secret is used, which is specially processed in smart contracts, allowing the transaction to be carried out safely for all participants.
Trade-offs to consider when designing a bridge
There is no perfect solution for bridges, and some trade-offs always need to be made to achieve a specific goal. Bridges can be evaluated based on the following factors:
Security—Who verifies the system? Bridges secured by external validators are usually less secure than those secured locally or natively by blockchain validators.
Usefulness — How long does it take to finalize a transaction, and how many transactions does the user need to sign? How long does it take for a developer to integrate the bridge, and how difficult is this process?
Connectivity — What different destination chains can the bridge connect to (e.g., rollups, sidechains, other Layer 1 blockchains, etc.), and how difficult is integrating a new blockchain?
Ability to transfer more complex data — Can the bridge support messaging and more complex arbitrary data across chains, or does it only support cross-chain asset transfers?
Cost-effectiveness — How much does transferring assets across chains via the bridge cost? Typically, bridges charge a fixed or variable fee depending on the cost of gas and the liquidity of specific routes. It is also important to evaluate the cost-effectiveness of a bridge based on the capital investment required to ensure its safety.
Conclusions
A bridge is not simple, and if it is simple, it is often unreliable. Therefore, the bridges you want to use must be carefully chosen, and the development must be approached responsibly.
A decentralized bridge with minimal trust can be as vulnerable as a centralized one if it has an error in the smart contract. This confirms that decentralization and reliable verifiers are not a panacea. However, decentralization, updates through DAO, and more transparent models are, of course, preferable. Bridges concentrate huge liquidity, and any error, even a small error, can be fatal. The largest teams in the world made mistakes and hacked the code that was audited by the top firms in the industry.
Also, if we touch on the more prosaic tasks of bridges, sometimes they are needed by one ecosystem to get liquidity from another ecosystem. This will not necessarily be useful for the “donor ecosystem,” but if the bridge works in both directions, then the chances are equalized. And in the case of Layer 2, this should not be considered stealing liquidity from L1; after all, L2 cannot exist without the basic L1.
In general, it looks like blockchain ecosystems cannot do without bridges now. More and more cross-chain protocols are appearing, and sometimes, it is simply more convenient to keep your liquidity in different places. Of course, for now, you have to pay a high price for this, literally, but there is hope that over time, these solutions will become more and more reliable.
Hey, professionals, let’s connect on LinkedIn! 🤝
https://www.linkedin.com/in/dmytronasyrov
Feel free to drop a “Hi” at Pharos Production, where we bring software to life! 👋✨
“Join our exciting journey with Ludo — the reputation system of the Web3 world! 🌍✨”
