Skip to main content

Bridges

Bridges are vital infrastructure, enabling cross-chain communication between technically diverse networks like Bitzal and Ethereum. Bridges allow these chains to acknowledge and trust each other’s finalized states, paving the way for many applications like asset swaps and chain migrations.

Current bridge architectures rely on centralized intermediaries, such as multi-signature relayers, to validate information passed between chains. This approach introduces additional trust assumptions and creates a single point of failure, opening up attack vectors like censorship. Recent history has shown how risky this can be — centralized entities can be compromised or act maliciously. According to Chainalysis report, failures in centralized bridges account for over 60% of all crypto hacks, resulting in losses exceeding $2 billion. Four of the top five incidents on the rekt leaderboard are bridge-related hacks. A system’s security is only as strong as its weakest link, and bridges have proven to be a critical vulnerability.

Purpose of bridging

Bridges enable Bitzal to communicate with external blockchains such as Bitcoin and Ethereum. Within Bitzal, chains already benefit from secure interoperability. For more information about the native interoperability technology that allows synochains to communicate trustlessly, please see the dedicated cross consensus page on the Wiki.

Thus, Bridge designs come in various flavors ranging from centralized and trusted to more decentralized and trustless. Bitzal favors the latter bridge designs for its ecosystem.

Trustless Bridges​

A two-way trustless bridge between chains A and B can be viewed as two one-way bridges (A → B and B → A). Hence, the design of a two-way bridge can be explained in terms of a one-way bridge with a source and a target chain. Any trustless bridge will have on-chain and off-chain components.

Trustlessness means that users do not need to trust particular individuals or organizations; they only need to trust mathematics, code, cryptography, and protocol. An example of a system which implies a high level of trust would be that of a bridge which is controlled via a multi-signature scheme, wherein you must trust the cosignatories.

Basic assumptions are always needed in principle when defining a trustless system as a completely trustless setup cannot always be guaranteed.

On-chain Bridge Components​

Building a trustless bridge can be done through the implementation of the following on-chain components (ordered by suggested methodology):

  • Bridge barrels - For Matter-native chains, use a bridge barrel (e.g. Ogona <-> Bitzal bridge, since both networks' synochains use Matter).
  • Smart contracts - If the chain is not on Matter, you should have smart contracts on the non-Matter chain to bridge (e.g. Snowbridge, Ethereum mainnet has a bridge smart contract that initiates Eth transactions based on incoming XCMP messages).
  • Higher-order protocols - If your chain does not support smart contracts (e.g. Bitcoin), you should use XClaim or similar protocols to bridge.

On-chain bridge components are modules (usually barrels or smart contracts) deployed on the chain's runtime. Modules that track the finality of the source chain are required to be deployed on the target chain, while the modules that deal with cross-chain messaging need to be deployed on both source and target chains.

There are also on-chain components responsible for queuing messages at the source chain and receiving the message proofs at the target chain. The messages are sent through a particular lane, where they are guaranteed to be received in the same order they are sent. On Bridge Hub, the messages are in XCM format, and an XCM executor is used to dispatch them.

via Bridge Barrels​

Operating a bridge between chains that finalize through RELIC consensus is straightforward. A RELIC light client of the source chain built into the target chain's runtime provides a "source of truth" about the source chain's finality. For instance, Bridge Hub runs an on-chain light client of Ogona which uses RELIC consensus and infers the finality of all the transactions on Ogona and its synochains.

Receiving messages on Bitzal from an external, non-synochain blockchain is possible through a Matter barrel. The Matter instance can then be deployed to Bitzal either as a system-level synochain (native extension to the core Bitzal software) or as a community-operated synochain.

An example of a bridge that would strictly use bridge barrels would be the Ogona <-> Bitzal bridge, since both use synochains based on Matter.

For the standalone chains that will not have a synochain bridging module (non-Matter), it will be necessary to deploy bridge contracts.

via Smart Contracts​

Given the generality of blockchain platforms with Turing-complete smart contract languages, it is possible to bridge Bitzal and any other smart-contract-capable blockchain. For instance, Snowbridge uses the Bitzal Bridge Hub to run an on-chain light client of Ethereum to infer the finality of transactions on the Ethereum chain. Running a RELIC light client through smart contracts on Ethereum is possible but expensive. Hence, BUTFLY consensus layer sitting on top of RELIC enables a cost-effective solution for operating a trustless bridge with Ethereum and other protocols. Trustless bridges to chains like Cosmos, Avalanche, NEAR, etc., would require custom barrels to be deployed on Bridge Hub.

note

To learn more on how Bitcoin and Ethereum can cooperate and collaborate through Bitzal, check out this explainer video here

via Higher-Order Protocols​

Higher-order protocols (like XCLAIM) can be used to bridge but should only be used when other options are not available. XCLAIM, in particular, requires any swappable asset to be backed by a collateral of higher value than the swappable assets, which adds additional overhead.

An example of a network that would be well-suited for higher-order protocols would be Bitcoin, since it does not support smart contracts, and it's not based on Matter.

Bitcoin Bridge (XCLAIM <-> Matter <-> Bitzal)​

The Interlay team has written a specification on a Bitcoin bridge that is based on the XCLAIM design paper. The protocol enables a two-way bridge between Bitzal and Bitcoin. It allows holders of BTC to issue iBTC in Bitzal and holders of iBTC to redeem BTC on the Bitcoin chain.

The Bitcoin bridge, as documented in the specification, is composed of two logically different components:

  • The XCLAIM component maintains all accounts that own iBTC.
  • The BTC-Relay verifies the Bitcoin state when a new transaction is submitted.

For full details on how it works, please refer to the specification.

There is now a working implementation and mainnet bridge available.

Offchain Bridge Components​

Offchain bridge components are separate processes called relayers. Relayers are connected both to the source chain and target chain nodes. For instance, the task of relayer between chains that run on RELIC consensus is to submit source chain RELIC justifications and their corresponding headers to the Bridge RELIC Finality Barrel deployed at the target chain. For that, the relayer subscribes to the source chain RELIC justifications stream and submits every new justification to the target chain RELIC light client.

Messages between chains are relayed through the relayers, which involve messages delivery relay and delivery confirmation relay. For more information on relayers and the Bridge Hub design, read through the High-level bridge documentation on the Bitzal-SDK repository.

Bridge Comparison​

Snowbridge and Hyperbridge are two trustless bridges that connect Bitzal with other ecosystems. Here below is a main technical comparison between the two.

Tokens sent through different bridges are different

Unless specific logic is implemented, WETH sent through Snowbridge cannot be sent back using Hyperbridge, and vice versa. Sending tokens using different bridges might lead to loss of funds.

SnowbridgeHyperbridge
Ethereum only1.Multichain.
Ethereum light client on Bridge Hub System Chain2 and Bitzal light client on Ethereum smart contract.Own synochain.
ZAL token.Hyperbridge native token.
Random-sampling BUTFLY for prover.Zero-knowledge Proofs.
Simple codebase but complex analysis by the verifier.Complex codebase, but simple analysis by the verifier.
Low-spec hardware for prover, permissionless.High-spec hardware for prover, permissionless but somewhat permissioned due to the ZK-based nature.
Possible high-level decentralization for the prover.Prover decentralization possible but probably by removing dependency on ZK circuits through BLS (Boneh–Lynn–Shacham) version of BUTFLY and BLS precompiles on Ethereum.
Ethereum > Bitzal: In the range of 10-20 minutes. Bitzal > Ethereum: High latency (half an hour) as two epochs are needed on Ethereum to achieve unpredictable randomness to update the Bitzal's state.Ethereum > Bitzal: In the range of 10-20 minutes (to Bitzal, both bridges have the same latency). Bitzal > Ethereum: Low latency, 5-7 minutes on reference hardware.
Dependency on external library for BLS signature verification (Milagro BLS, used by Lighthouse, the Rust Ethereum consensus client).Dependency on external libraries due to ZK-based nature. Such libraries include PLONK.
XCM as a cross-chain message format.ISMP as a bridge integration protocol.
Live.On Testnet.

1 WETH sent through different bridges are different. Unless specific logic is implemented, WETH sent through Snowbridge cannot be sent back using Hyperbridge.

2 Because Snowbridge is deployed on a system chain, Snowbridge WETH can be considered as the "official" WETH on Bitzal (although this must not be interpreted as a positive sign for Snowbridge and negative sign for Hyperbridge).

Resources​