What Is A Blockchain Bridge?

Blockchain bridges serve as crucial connectors in the decentralized landscape, fostering interoperability among diverse blockchain networks. Unlike physical bridges linking geographical locations, these digital connectors facilitate the seamless transfer of assets and data between blockchain ecosystems.

Key Strategies for Enhancing Cross-Chain Asset Transfers -

• Lock & Mint -

  • In the "Lock & Mint" strategy, assets are locked on the source chain and simultaneously minted on the destination chain.

  • This process ensures a controlled transfer of value between two blockchains.

  • Examples - Polygon’s PoS bridge, Avalanche Bridge (AB), along with assets like wrapped BTC, wMonero.

• Burn & Mint -

  • The "Burn & Mint" approach involves burning assets on the source chain, rendering them unusable, while new assets are minted on the destination chain.

  • Examples - Circle's CCTP, LayerZero's OFTs, Wormhole's xAssets.

• Atomic Swaps -

  • These bridges swap assets on the source chain for assets on the destination chain. Generally, they are more trustless because they rely on self-executing smart contracts for asset swaps and remove the requirement for a trusted third party necessary in lock & mint or burn & mint mechanisms.

  • Examples - cBridge, Connext, Across.

Bridge Types

• Native bridges -

  • These bridges are typically built to bootstrap liquidity on a particular blockchain, making it easier for users to move funds to the ecosystem. For example, the Arbitrum Bridge is built to make it convenient for users to bridge from Ethereum Mainnet to Arbitrum. Other such bridges include the Polygon PoS Bridge, Optimism Gateway, etc.

• Validator or oracle based bridges -

  • These bridges rely on an external validator set or oracles to validate cross-chain transfers.

  • Examples - Multichain and Across.

• Generalized message passing bridges -

  • These bridges can transfer assets, along with messages and arbitrary data across chains.

  • Examples - Nomad and LayerZero.

• Liquidity networks -

  • These bridges primarily focus on transferring assets from one chain to another via atomic swaps. Generally, they don’t support cross-chain message passing.

  • Examples - Connext and Hop.

Read more on bridges and their classification in blockchain networks.

Top 10 Bridges on Optimism Blockchain (as of February 2nd, 2024, 3:00 PM, sourced from DeFi Lama) -

Among these, I have chosen to delve deeper into the functionality and features of the Optimism Gateway, Hop, Across, and Stargate.

Optimism Gateway

• OP Mainnet is a “Layer 2” blockchain and is fundamentally connected to Ethereum.

• OP Mainnet has a system called the Standard Bridge, which facilitates easy movement of tokens in both directions, from OP Mainnet to Ethereum and from Ethereum to OP Mainnet.

The Standard Bridge -

The Standard Bridge is composed of two contracts, the L1StandardBridge (on Ethereum) and the L2StandardBridge (on OP Mainnet). These two contracts interact with one another via the CrossDomainMessenger system for sending messages between Ethereum and OP Mainnet.

• Bridged Tokens:

  • Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side.

  • A bridged representation of a token is an ERC-20 token that implements the IOptimismMintableERC20 interface.

  • This interface includes a few functions that the StandardBridge contracts use to manage the bridging process.

  • The standard bridge contracts can be used to bridge ETH and ERC20 tokens from Ethereum to OP Mainnet, and vice versa.

• Bridging ERC20 Tokens

  • Bridging Native Tokens

    • The Standard Bridge uses a "lock-and-mint" mechanism to convert native tokens into their bridged representations.

    • Message relaying is automatic when sending from Ethereum to OP Mainnet but requires additional user transactions when sending from OP Mainnet to Ethereum.

    • The process of bridging a native token involves a few steps.

• This completes the process of bridging native tokens. This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions.

  • Bridging Non-Native Tokens -

    • The Standard Bridge uses a "burn-and-unlock" mechanism to convert bridged representations of tokens back into their native tokens.

    • The process of bridging a non-native, bridged representation of a token involves a few steps.

• This completes the process of bridging non-native tokens.

  • Bridging ETH -

    • The ETH bridging process is generally less complex than the ERC-20 bridging process. Users simply need to trigger and send ETH to the bridgeETH or bridgeETHTo functions on either blockchain.

Control Flows -

• Deposit (from L1 to L2)

• Withdrawal (from L2 to L1)

• In Optimisim bridge terminology deposit means a transfer from L1 to L2, and withdrawal means a transfer from L2 to L1.

Deposit Flow

Layer 1

• If depositing an ERC-20, the depositor gives the bridge an allowance to spend the amount being deposited

• The depositor calls the L1 bridge (depositERC20, depositERC20To, depositETH, or depositETHTo)

• The L1 bridge takes possession of the bridged asset

  • ETH: The asset is transferred by the depositor as part of the call

  • ERC-20: The asset is transferred by the bridge to itself using the allowance provided by the depositor

• The L1 bridge uses the cross-domain message mechanism to call finalizeDeposit on the L2 bridge

Layer 2

• The L2 bridge verifies the call to finalizeDeposit is legitimate:

  • Came from the cross-domain message contract

  • Was originally from the bridge on L1

• The L2 bridge checks if the ERC-20 token contract on L2 is the correct one:

  • The L2 contract reports that its L1 counterpart is the same as the one the tokens came from on L1

  • The L2 contract reports that it supports the correct interface (using ERC-165(which opens in a new tab)).

• If the L2 contract is the correct one, call it to mint the appropriate number of tokens to the appropriate address. If not, start a withdrawal process to allow the user to claim the tokens on L1.

• Transactions sent from L1 to L2 take approximately 1-3 minutes to get from Ethereum to OP Mainnet.

• This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions.

Fees For L1 to L2 Transactions

• Costs for L1 to L2 transactions primarily arise from smart contract execution on L1.

• When initiating an L1 to L2 transaction, you send it to L1CrossDomainMessenger, incurring gas fees for the execution on L1.

• Additionally, the OptimismPortal contract charges for L2 execution by burning L1 gas based on your specified gas limit on L2.

Withdrawal Flow

Layer 2

• The withdrawer calls the L2 bridge (withdraw or withdrawTo)

• The L2 bridge burns the appropriate number of tokens belonging to msg.sender

• The L2 bridge uses the cross-domain message mechanism to call finalizeETHWithdrawal or finalizeERC20Withdrawal on the L1 bridge

Layer 1

• The L1 bridge verifies the call to finalizeETHWithdrawal or finalizeERC20Withdrawal is legitimate:

  • Came from the cross-domain message mechanism

  • Was originally from the bridge on L2

• The L1 bridge transfers the appropriate asset (ETH or ERC-20) to the appropriate address

Transactions sent from L2 to L1 take approximately 7 days to get from OP Mainnet to Ethereum.

This is because the bridge contract on L1 must wait for the L2 state to be proven to the L1 chain before it can relay the message.

Below is a step-by-step breakdown of the L2 to L1 transaction timeline -

• The L2 transaction is sent to the Sequencer, similar to any other L2 transaction. It is swiftly confirmed by the Sequencer within a few seconds.

• The block containing the L2 transaction is proposed to the L1. This typically takes approximately 20 minutes.

• A proof of the transaction is submitted to the OptimismPortal contract on L1. This can be done any time after step 2 is complete.

• The transaction is finalized on L1. This can only be done after the fault challenge period has elapsed. This period is 7 days on Ethereum and a few seconds on Sepolia. This waiting period is a core part of the security model of the OP Stack and cannot be circumvented.

Challenge Period -

• In L1 ⇔ L2 interaction, messages sent from Layer 2 to Layer 1 have a 7-day challenge period, during which transactions can be challenged for faults.

• Optimistic Rollups are named for their optimistic approach of publishing transaction results on Ethereum without executing them, reducing complexity and cost.

• However, to prevent incorrect results, a "fault-proof" mechanism exists. Whenever a transaction result is published, it's considered "pending" for a period known as the challenge period.

• During this period, anyone may re-execute the transaction on Ethereum in an attempt to demonstrate that the published result was incorrect.

• If someone can prove that a transaction result is faulty, then the result is scrubbed from existence and anyone can publish another result in its place.

• Only after this period can Layer 2⇒ Layer 1 messages be relayed, ensuring decisions on Layer 1 are based on valid results.

Fees For L2 to L1 Transactions -

• The overall cost encompasses the L2 initiation and two L1 transactions: one for proof and another for finalization.

• Notably, the L1 proving and finalizing transactions are typically pricier compared to the L2 initiation.

Hop  Protocol

Hop is an advanced token bridge designed for quick and efficient transfers of tokens between different blockchains, known as rollups or sidechains. Unlike traditional methods that require waiting for network challenge periods, Hop enables almost instant transfers.

Here's how it works -

• Hop involves market makers called "Bonders," who provide liquidity on the destination chain in exchange for a small fee. This fee compensates the Bonder for their service. The liquidity is provided in the form of hTokens, a special type of token created by the protocol.

• These hTokens serve a dual purpose. First, they facilitate the seamless movement of tokens across chains programmatically by being minted and burned as needed. Second, they play a role in reducing the time it takes to exit a scaling solution's native network, making the entire process more efficient.

• To understand it better, think of it this way: when users want to transfer tokens from one network to another, the Bonder on the destination chain provides liquidity using hTokens. These hTokens are then exchanged for the native tokens through an automated market maker (AMM) on the destination chain, completing the transfer.

• A unique feature of Hop is that Bonders can unlock their fronted capital every 24 hours, making them more capital-efficient. This flexibility allows for better management of resources.

Trustless Design -

• Hop is designed to be trustless, ensuring users that they can always access their funds, even if the Bonders (the entities facilitating the cross-chain transactions) are temporarily offline. In the unlikely event of such a situation, users simply need to wait until there is on-chain proof that the transaction has occurred, and then they can manually withdraw their tokens on the destination chain. While this might result in a slower experience for users, their funds are secure, and there's no risk of them being taken by the Hop Bridge.

• Bonders run local nodes to verify if the state transitions on the source chain are accurate and decide to "bond" the transfer by locking up 110% of the TransferSum as collateral. This allows them to mint hTokens at the destination chain which are sent to the user to provide instant liquidity. The Bonder unlocks the capital after a 24-hour challenge period during which anyone can challenge the Bonder. If a challenge is successful the Bonder capital is slashed.

How Hop is Different -

• Hop stands out by prioritizing maximum security in its design. Unlike other systems, it eliminates single points of failure and doesn't rely on trusted off-chain entities. Instead, it ensures 100% security through on-chain mechanisms.

• Here's how it works: Hop consolidates original messages, like transfers, into Bundles. These Bundles are then moved between chains using native message bridges. Think of it as a "Hub-and-Spoke" model, where Ethereum serves as the central hub, and each scaling solution acts as a spoke. For instance, if you want to send data between Optimism and Arbitrum, Hop routes the Bundle through Ethereum, utilizing the native bridges of Optimism and Arbitrum. The key point is that the validity of transfers can be proven directly on-chain.

• While this approach is highly secure, it might seem slower because it depends on the exit times of native message bridges (40 minutes for Polygon PoS and Gnosis Chain, and up to 7 days for ORUs).

• To address this, Hop introduces Bonders. They play a crucial role by verifying transactions off-chain and providing liquidity for users on the destination chain. By doing this, Bonders take on the responsibility of liquidity lock-up until the on-chain proof (the Bundle) reaches its destination. Once the proof is confirmed on-chain, the Bonders' liquidity is unlocked. This setup helps to expedite transactions and improve overall efficiency.

How long does a transfer take?

• L1 to L2 transfers take the same amount of time as sending via the native bridge. For example, depositing from Ethereum to Polygon takes approximately 22 minutes via the Polygon bridge and the same amount of time with the Hop bridge. This is because Hop itself uses the native bridges for L1 -> L2 deposits.

• The advantages of Hop come about when you transfer the other way around from L2 to L1 or from one L2 to another L2.

• L2 to Any

  Optimism: ~25 minutes (finality)

  Arbitrum: ~12 minutes (finality)

  Nova: ~12 minutes (finality)

  Polygon: ~60 minutes (1600 blocks) (due to ongoing chain reorg issues)

  Gnosis: ~4 minutes (L2 finality)

  Base: ~25 minutes (finality)

• Ethereum to Any

  Optimism: ~2 minutes (optimistic finality)

  Arbitrum: ~10 minutes (finality)

  Nova: ~10 minutes (finality)

  Polygon: ~20 min (finality)

  Gnosis: ~30 min (light client finality)

  Base: ~2 minutes (optimistic finality)

Fees -

• When using the Hop Bridge, there are a few fees to keep in mind. If you're swapping assets between blockchains, you might encounter AMM swap fees, usually between 0.01% and 0.04%. However, Hop Bridge is unique as it doesn't charge these AMM fees. There are also fees for moving your assets within the same layer (L2 to L2) or between layers (L2 to L1 or vice versa).

• The fees range from 0.01% to 0.08%, depending on how many swaps are involved. Keep in mind that the conversion rates between tokens can fluctuate a bit (slippage), but this is less of an issue with more liquidity in the Hop protocol.

• Bonder fees, ranging from 0.05% to 0.30%, cover the cost of providing liquidity and taking on risk. Additionally, there are gas fees for moving your funds from the Bonder to your wallet on the destination chain, and these are included in the overall fee.

• Lastly, to prevent misuse, there's a minimum fee of $0.25 for Hop transfers.

Across Bridge -

• Across is a cross-chain bridge for faster transactions, secured by UMA's oracle. It optimizes capital efficiency with a single liquidity pool, competitive relayers, and a no-slippage fee model.

• Across utilizes a single liquidity pool design and an interest rate fee model, resulting in lower costs for users and increased yields for liquidity providers.

• The majority of LP assets are securely stored on the mainnet, and bots operate to rebalance between destinations through the canonical bridge.

• Across employs third-party relayers who take on the risk of bridging assets with their own funds. These relayers have the flexibility to move funds more quickly than the finality times of the origin or destination chains, enabling 'fast fills'.

• Across uses UMA’s optimistic oracle to confirm that transactions on all the chains are correct. If there is an incorrect transaction, it will be disputed and resolved by UMA tokenholders. It only requires a single honest actor to detect fraud.

How it works?

• When a user wants to transfer funds from one blockchain (Chain A) to another (Chain B), they deposit the funds into a Spoke Pool on Chain A. They provide instructions on where they want the funds to go and specify the fee they're willing to pay.

• Relayers, who monitor these deposits, verify the details and promptly provide the user with funds on Chain B. Once the relay is done, proof of the relay and the validity of the original deposit is sent to the optimistic oracle (OO). The relayer is reimbursed after the OO verifies this information.

• The reimbursement for relayers comes from a single liquidity pool on Ethereum Mainnet held in a contract known as the Hub Pool. Liquidity providers (LPs) to this pool also earn a fee for each transfer made, which is deducted from the user's deposited amount.

Key roles in Across' system -

User -

• In Across, a user is someone who moves their assets between Layer 2 (L2) and Layer 1 (L1).

• Users pay relayers and liquidity providers to send their tokens instantly across networks that support their tokens.

Relayer -

• Relayers give out short-term token loans to Users in exchange for fees. Relayers fulfil deposit requests by sending the depositor their desired token on their requested “destination chain”.

• Relayers will send the recipient the full deposit amount minus a relayer fee, meaning that they will keep the relayer fee as an incentive for crediting the depositor funds.

Liquidity Provider -

• A liquidity provider or LP is an actor who deposits assets into one of the pools on Across. Liquidity Providers provide the capital that enables relayers to have flexibility about where they want to take a refund in exchange for fees.

• Moreover, liquidity providers provide capital that can be used to fulfil deposits in the unlikely but possible case that no relayers can fast-fill the deposit.

Dataworker -

• Dataworkers maintain system stability by managing refunds, transferring assets, and proposing bundles for optimistic validation.

• Whitelisted dataworkers post a bond when suggesting bundles, and anyone can dispute an invalid bundle to earn a dispute bond, including a part of the proposer's bond.

How Across Guarantees Transfers -

Fast Fills -

• When users request a bridge transfer, they can include a 'relayer fee' percentage to encourage relayers to process it quickly on the destination chain. Generally, users can expect their funds in 1–4 minutes.

• If relayers have enough capital and the fee is sufficient, the deposit is quickly processed, termed a 'Fast' fill. If not, Across uses liquidity pool funds for a 'Slow' fill. Relayers endure a 2-hour challenge period, taking on liveness risk before receiving their refund from the liquidity pool.

Slow Fills -

• If relayers fail to complete a deposit, a process is called "slow fill". This means that an Across Dataworker has flagged the deposit as being unfilled and wants the system to use its funds to fill the depositor. The depositor gets refunded the relayer fee in this case because the fill will take a longer time to complete.

• Relayers notify dataworkers of unfilled deposits by sending partial fills, often appearing as "1 wei" fills, indicating a tiny fraction of the total deposited amount. While these partial fills may seem unusual to users, they play a crucial role by informing the dataworker about the presence of a slow-fill payment in progress for that specific deposit.

High-level overview of smart contracts -

• The Hub contract resides on Ethereum Layer 1, holding all the liquidity. It communicates with Spoke pools situated on Layer 2. There's also a Spoke pool on Ethereum Layer 1.

• Relay actions, deposits, and fills are executed via Spoke pools. Administrative tasks like pool rebalancing and managing relay funds are handled by the Hub pool.

• Adapters act as intermediaries between the Hub pool and Spoke pools. Additionally, the Hub pool interfaces with the optimistic oracle for action validation.

Contract breakdown: Hub Pool

• The Hub Pool, exclusively deployed on Ethereum Layer 1, serves as the central hub for managing liquidity in our cross-chain ecosystem. Depositors interact with the Hub Pool for both deposits and withdrawals, making it the go-to destination for liquidity actions.

• It  also tracks the fees earned by liquidity providers and serves as the primary point of contact for a key player known as the "data worker."

• The data worker plays a pivotal role in overseeing the system's operations. They manage tasks like rebalancing pools, ensuring relayer refunds, and addressing slow relay issues.

• The Hub Pool serves as the central authority for managing disputes within the system. Additionally, it acts as the cross-chain administrator, overseeing the operation of Spoke Pools. In this capacity, the Hub Pool has the authority to direct Spoke Pools to return funds to Layer 1, a process known as "pull rebalancing."

• It is owned by a cross down mutlisig.

Contract breakdown: Spoke Pool

• The Spoke Pool is deployed across all destination chains, including Ethereum Layer 1.

• Users deposit funds into the Spoke Pool, and relayers play a crucial role in filling these deposits in corresponding Spoke Pools on other chains.

• The Spoke Pool operates under the guidance of the Hub Pool. The Hub Pool, acting as the central authority, can send specific instructions to the Spoke Pool for various actions.

• The Hub Pool can instruct the Spoke Pool to execute specific actions, including sending funds back to Ethereum Layer 1. This process, known as a "pull rebalance," ensures efficient cross-chain fund management.

• In cases where a relay runs out of funds and a slow relay occurs, the Hub Pool instructs the Spoke Pool to fill the gaps.

• In essence, the Spoke Pool serves as a decentralized bridge, connecting users and relayers across different chains, all orchestrated under the guidance of the central Hub Pool.

Contract breakdown: Chain Adapters

• Chain Adapters, strategically deployed on Ethereum Layer 1. With one dedicated contract per destination Spoke Pool.

• Serving as an abstraction layer, Chain Adapters streamline communication between the Hub Pool and diverse Layer 2 solutions.

• It can primarily do two things -

  • Send tokens to the destination chain

    • Used for sending funds to refund relayers and fill slow relays.

  • Send messages to the destination chain

    • This is used for executing governance actions and instructing the spoke pools on what to do.

Example of Simple fill -

• The user calls the deposit method on the Optimism spoke pool to send money to Arbitrum.

• The deposit method triggers an event indicating the successful initiation of the deposit.

• On the Arbitrum chain, a relayer monitors events and detects the deposit initiation event. The relayer verifies the legitimacy of the deposit by checking the event details and confirming that the funds are in the Optimism spoke pool.

• Upon verifying the deposit, the relayer proceeds to fill the deposit on the Arbitrum chain. The relayer calls the fillRelay method on the Arbitrum chain to complete the transfer of funds.

• This is the simplest flow in the case of a full relay.

Example of Partial Fill + Slow relay + relayer refund -

• The user starts the process by initiating a deposit and specifying parameters. This triggers the emission of an event.

• On the destination chain, the relay fills the deposit. However, there might be a case where the relay partially fills the requested amount.

• In the scenario of partial filling, a data worker assembles a bundle of instructions. This bundle contains three types of information, guiding the spoke pool on the necessary actions.

• The bundle is sent across the canonical bridge as a message from the hub pool. This message includes the actual funds required to cover the shortfall.

• Upon receiving the message, the spoke pool follows the instructions and utilizes the provided funds to fulfil the remaining component of the relay.

• After completing the relay, the spoke pool executes either the relay leave or relay refund leave, repaying the relayer for their efforts.

• Finally, the slow relay leave is executed, ensuring that the recipient is duly compensated for the relay's partial filling.

Fees -

• Relayer fees, ranging from 0% to 50%, cover gas costs and capital opportunities for the relayer. Destination gas fees account for the gas costs of transferring tokens on the destination chain.

• LP fees, currently 0.06% to 0.12%, are based on utilization, but an upcoming V3 launch aims to introduce a more dynamic fee model for lower user fees. Challenges arise when LP capital is overutilized, prompting ongoing research for an optimal fee system that minimizes user costs.

Stargate -

• Stargate is a fully composable cross-chain bridge protocol that removes the need to rely on intermediate tokens and instead preserves the native tokens being sent between chains.

• For example, users can swap USDC on Ethereum for USDT on BNB.

• It is built on LayerZero which enables native asset transfers between different blockchain networks.

• A major shortcoming of most current bridges is that they are unable to send native assets from one chain to another. Instead, they rely on the use of a wrapped or "intermediate" token to complete the bridging process.

• The problem with this approach is that it is extremely inefficient and makes the user experience onerous.

• Stargate is designed specifically to remove the need for wrapped tokens and lets users send native tokens directly to non-native chains.

• The protocol is built around unified liquidity pools shared between chains that ensure instant guaranteed finality. Stargate's goal is to make cross-chain bridging a seamless and single transaction process.

Bridging Trilemma

• Stargate is the first bridge to solve the bridging trilemma.

• Designing a bridge for blockchain transactions presents a challenge known as the Bridging Trilemma, where developers must navigate a trade-off between native asset transaction requirements, instant guaranteed finality, and unified liquidity. To address this, many bridge designs opt for a compromise, often involving the use of wrapped tokens instead of native assets. This is typically done through mechanisms like Lock-and-Mint or Burn-and-Unlock. In simple terms, users deposit their native assets into the bridge's smart contract, and in return, the bridge mints a wrapped version of the asset on the destination chain (e.g., converting $ETH to $WETH). This approach ensures instant guaranteed finality and eliminates liquidity risks. However, a drawback is that users need to manually convert the wrapped token back into a native asset on the destination chain for practical use; otherwise, it serves merely as a bridge vessel.

• Another issue is around liquidity and scaling. Bridges can only function properly if both the source chain and the destination chain have sufficient liquidity. So each time a new blockchain is integrated into a bridge protocol, the bridge must also bootstrap liquidity between each existing blockchain currently integrated. This places significant limitations on a bridge infrastructure's ability to quickly scale and adopt new networks.

• To solve the Bridging Trilemma, Stargate has developed a novel cross-chain bridge mechanism, ∆Bridge, and balancing algorithm, the Delta (∆) algorithm.

  They enable cross-chain liquidity and purely native token transfers.

• ∆Bridges let users send native assets directly and seamlessly between different blockchains, without the need for an intermediate token and without any deprecation of interoperability or composability.

• ∆Bridges are powered by a unified liquidity pool shared amongst chains to ensure that each side of the bridge has sufficient liquidity, prevents transaction reversion, and achieves instantly guaranteed finality.

• All of this is in part achievable because of LayerZero's infrastructure, which is an omnichain communication protocol that provides robust inter-chain communication between large blockchain networks.

• This foundation enables Stargate to effectively communicate bidirectionally between source and destination chains.

Fees

• You can also use Transfer to move STG tokens cross-chain. There is no protocol transfer fee associated with these swaps. The user will only pay gas fees associated with these transactions.

• Each non-STG token transfer has a .06% fee. Additionally, Stargate transfers may incur a pool rebalance fee depending on how imbalanced the source & destination transfer pools are with respect to pool equilibrium weights. STG token transfers do not incur a pool rebalancing fee.