Why Is Cross-Chain Bridging So Technically Difficult?

Fundamentally, to make cross-chain bridging secure, one must either: 1) make the underlying blockchains censorship-resistant and sufficiently decentralized or 2) decentralize the bridge itself so the bridge validators can’t censor/steal/freeze/change transactions.

Source

In cross-chain scenarios, bridge contracts assume transactions executed on the other blockchain are valid based on that chain’s rules. Accordingly, users need to trust that another chain’s validators won’t collude, be corrupted/compromised and that they can execute transactions and withdrawals at any time. This consideration is also before evaluating any additional trust assumptions introduced from an external relayer bridge.

Additionally, networks connected by a bridge but that don't have a shared state (i.e., EVM-to-EVM chain) entertain additional risk, specifically around finality on each chain. For blockchains, a transaction is considered final when the block containing it can't be altered. However, the majority of blockchains’ finality (specifically, Ethereum, as it's involved in the majority of bridging activity) is probabilistic, not deterministic. That is, there's no set number of blocks after which the block becomes immutable. It merely becomes ever more expensive with each additional block built on top of it, and thus less economically rational/feasible for an attacker to alter the transaction. 

When a transaction is conducted on a source blockchain, an event is typically recorded and used to trigger a similar transaction on a destination blockchain. For a relayer to transfer an event on the source chain, the source chain transaction must be finalized. The destination chain must select the number of block confirmations required to feel comfortable that the block is final and that security on the Ethereum base layer can't be compromised. 

Assets that have been bridged from Chain A and “wrapped” on Chain B would suffer if chain A is 51% attacked and transactions are reverted. This would result in Chain B assets no longer being fully collateralized. In these scenarios, the bridge and bridged assets are only as safe as the weakest blockchain.

With L2 networks and rollups, bridge smart contracts don't make these same assumptions. They can verify that transactions executed on L2 are valid per the rules of Ethereum L1. Validation is executed by proving systems (fraud proofs and validity proofs) that can be checked on L1. Therefore, L2 users are far less exposed to the centralization risks presented by the validator sets of other chains or bridges. 

*Learn more about different bridge designs and overall bridge security here or clicking the image below.*

With an L1 rollup, a protocol only needs to deploy an asset once for default interoperability with all rollups. Rollups inherit the security of the L1 while featuring “escape hatches” that allow users to exit to L1 vs. being stuck on the destination chain if something goes wrong. Because of this, they need an exponentially cheaper security budget than creating an L1 or bridge with a validator set. Finally, rollups can store data on or off-chain depending on their need, creating flexibility in the design space and user experience.

However, interacting with any type of bridge carries risk (on both chains):

• Smart Contract Risk: A code bug that can cause user funds to be lost
• Technology Risk: Software failure, buggy code, human error, spam, and malicious attacks
• Speed: If adequate liquidity isn’t available, users must wait until there is. This can be hours, days, or even weeks while the crypto markets continue to trade and funds are tied up

Moreover since trusted bridges add trust assumptions, they carry additional risks, such as:

• Centralization/Censorship/Custodial Risk: Some bridges have a small set of operators that can censor and, in the worst cases, steal user funds
• Poor security practices: Trusted third parties are human and make mistakes. As in the Ronin hack (discussed later), the Sky Mavis team had poor multi-sig security practices, and one individual was the victim of a social engineering hack

THORChain’s Solution

Founded in 2018, THORChain’s primary mission is to enable crypto users to permissionlessly swap between different cryptocurrencies with the need for KYC, a centralized exchange, or counterparty.THORChain is a decentralized and autonomous cross-chain network that aims to decentralize the liquidity of cryptocurrency assets via a network of public THORNodes and ecosystem products, with the goal of replacing centralized exchanges (CEXs). The protocol currently supports the swapping of eight native assets, including BTC, ETH, DOGE, BNB, ATOM, LTC, BCH, and AVAX.

THORChain uses Tendermint and the Cosmos-SDK as inspiration for its protocol, and employs Threshold Signature Schemes (TSS) to determine how to move assets in response to user-submitted transactions. The protocol watches for user deposits to its vaults and executes business logic based on transaction requests, such as adding or removing liquidity or swapping assets.

The RUNE token is the native token used for governance and to secure the network. RUNE operates on a unique tokenomics design, where it is used to pair with native L1 assets, such as BTC or ETH, allowing the protocol to scale while making liquidity pools reliable. RUNE's inherent value-accrual system relies on the token being 3x the value of the combined native L1 assets in the pool, and it is expected to increase in value as long as the TVL of the protocol grows.

*Learn more about the mechanics and obstacles of sourcing cross-chain liquidity here or by clicking on the image below.* 

The THORChain network uses a series of technologies to achieve functionality. Overall, THORChain was built using the Cosmos SDK platform, a stack that lets developers build Proof of Stake (PoS) blockchains. SDK allows for extended interoperability within the Cosmos network. The stack has a number of necessary pre-built modules to assist developers that are relevant to THORChain, such as transaction authentication or staking solutions. THORChain facilitates cryptocurrency swaps using its own AMM model, using the RUNE token as the intermediary powering a peer-to-pool economic model. 

In addition to Cosmos SDK, THORChain also uses the following technologies:

• Tendermint
• Bifröst Protocol
• Yggdrasil Protocol
• Threshold Signature Schemes (TSS)

THORChain Key Players

There are four distinct stakeholders within the THORChain ecosystem:

1. Swappers – Use liquidity pools to swap assets.
2. Liquidity Providers – Add liquidity to pools and earn rewards, AKA liquidity fees.
3. Node Operators – Provide bonds (i.e., RUNE) and are economically incentivized to secure the network.
4. Traders – Monitor and rebalance pools with the intention of making profits.

Swappers in THORChain facilitate swaps between native assets by executing trades by sending the native asset into the network and receiving assets from one of THORChain’s vaults. Inbound gas is paid in native RUNE, and the outbound fee is paid in the asset being swapped to.

Pricing accuracy for swaps is maintained internally by the pools and arbitrageurs, avoiding the need for external resources such as oracles and weighted averages. The exchange rate between two external assets is determined using a specific formula that provides both instantaneous price and purchasing power.

THORChain's key selling points for users are its large selection of assets, transparent and permissionless access, and one-transaction access to external supported chains. All swaps are managed by THORChain’s State Machine, which confirms valid transactions and refuses invalid ones, with a typical confirmation time of 5-10 seconds.

Liquidity providers in THORChain must have assets that are supported by external chains and meet the minimum deposit requirement. However, new assets must also win a competition to be listed, and larger value deposits will likely be listed over smaller ones. In order to secure their assets, liquidity providers must hold RUNE as a redeemable insurance policy while their assets are in the pool. Holding RUNE allows liquidity providers to leverage nodes and ensure their assets remain secure. The only direct cost to liquidity providers is the network fee charged when assets are withdrawn, which allows node operators to pay for compute resources and transaction costs. Impermanent loss is an indirect cost to liquidity providers, but this is minimized with THORChain's slip-based fee.

THORNodes are essential for the functioning of the THORChain network, and they consist of multiple servers that operate as a cluster of nodes. These nodes must be run as anonymous, decentralized entities to facilitate the decentralization process. To achieve this, nodes bond their RUNE capital, which serves as a security guarantee for liquidity providers who deposit their assets in the THORChain network. In this way, each unit of pooled capital requires two units of bonded capital to operate optimally. This mechanism disincentivizes anonymous network validators from stealing assets from the network.

Security Model

THORChain's economic security model requires nodes to bond more value than they're securing in pools with a hard cap built into the codebase. When this cap is reached, new deposits to the pools are halted. The system maintains a dynamic equilibrium between liquidity and security through its Incentive Pendulum. 

The Incentive Pendulum distributes block rewards and fees between bonders and pools. When pools outgrow the bonds, the pendulum... subscribe to CrpytoEQ.io for more.