Links

Bridge Architecture

A Layer 2 blockchain bridge is a type of interoperability protocol that facilitates the transfer of assets or data between two different blockchains or between a main blockchain (Layer 1) and a secondary network (Layer 2) that operates on top of the main blockchain. Thus, Layer 2 blockchain bridges are critical in enhancing scalability and efficiency in blockchain ecosystems by allowing for faster and cheaper transactions and promoting interoperability between blockchains.
The LightLink bridge is a decentralised web application (dApp) designed to allow our community to transfer their assets to and from Ethereum and LightLink easily. The bridge was developed by the LightLink team and fully audited by the independent blockchain security auditors at BlockApex. The bridge implements the Proof-of-Authority (PoA) consensus algorithm, which provides high-performance and fault-tolerant consensus about the validity of cross-chain deposits and withdrawals.

Overview

The bridge architecture consists of three main components: the front-end dApp, validator nodes and a single keeper node. As well as the three main components mentioned, the bridge uses smart contracts on Ethereum and LightLink. These smart contracts are used to lock the asset being bridged on one network and mint an equal amount of the same asset on the corresponding network.
Bridge architecture diagram

Bridge Front End dApp

The primary role of the dApp is to provide the LightLink community with a modern, easy-to-use graphical user interface to transfer their assets cross-chain. Users can simply:
  1. 1.
    Connect their favourite wallet
  2. 2.
    Select the network that they want to transfer assets to and from
  3. 3.
    Enter the amount they want to transfer and initiate the transfer
The dApp seamlessly integrates the most popular web3 wallets such as MetaMask, Coinbase Wallet and Wallet Connect. Wallet Connect enables connections to a further 32 web3 wallets, allowing users to connect regardless of their wallet preference.
The dApp was developed using ReactJS and conforms to the latest industry code and security standards. Internally, the dApp utilises the ethers.js library to inject the provided wallet as the provider and allows users to interact with the BridgeRegistry.sol smart contract on the network where the deposit or withdrawal is being made.

Bridge Back End

Context

  • We have predicate contracts on Ethereum and LightLink
  • We are using multi-sig to setup, create/update/remove configs on-chain
  • We support token types: Native token, ERC20, ERC721 and ERC1155, each token type will be a predicate logic
  • We are using POA to validate deposit and withdraw transactions

Limitation

  • Each token (every type) requires a mapped token on Lightlink to deposit
  • With Native token and ERC20, we use multisig contract to map token zero_address <- this is a type of predicate
  • With ERC721 and ERC1155, it is open, any tokens can be mapped (from users)

Deposit Flow

  • Users call deposit to deposit token (any type) on Ethereum (fee here - gas for txn)
  • Ethereum node will store event Deposited
  • Validators will scan/get events data from a full node that is assigned (the RPC source of each validator will be different)
  • Validators will check if events data is finalized (not be reverted or changed due to chain-reorg issue) (we are setting 12 blocks) ~6 mins
  • Validators send proof including signature to the keeper server
  • Inside keeper, we have a job that checks proofs are reached the consensus threshold (70 for now)
  • The keeper will send a transaction to LightLink to mint the token to the user's wallet

Withdraw Flow

  • Users call withdraw to deposit a token (any type) on LightLink
  • LightLink node will store Withdrawn event
  • Validators will scan/get events data from a full node that is assigned (RPC source of each validator will be different)
  • Validators will check if events data is finalized (we are setting 0 blocks) ~realtime cause LightLink does not have a chain-reorg issue
  • Validators send proof including signature to the keeper server
  • Users will get proof including signature and send a transaction to Ethereum to claim assets (fee here - gas for txn)