ChainBridge Integration: Multi-Chain Arbitrary Message Passing

EDIT 1 (05/15/2020) @ansermino has provided further content in the comments section :slight_smile:

Hello all,

My name is Greg, I’m the CTO at ChainSafe and researcher for our project ChainBridge. For the last few months we’ve been working on ChainBridge, which is an effort to bridge as many different blockchains together. Since the beginnings of ChainSafe we have believed in a multi-chain collaborative effort, and we believe ChainBridge is a step in that direction.

We’re excited to begin discussing a potential collaboration :slight_smile:

About ChainSafe
ChainSafe Systems is a 35 person blockchain research & development firm, with a focus on building infrastructure for Web3. We are actively contributing to the Ethereum, Ethereum Classic, Cosmos, Polkadot, Filecoin & Celo ecosystems and are open to contributing to other Web3 ecosystems where we see merit.

Proposed Team
David: Team Lead
Polina: Project Manager
Greg: Research
Elizabeth: Research
Steph: Developer
Wyatt: Developer
Ryan: Developer
Anthony: Developer

About ChainBridge
ChainBridge is a modular multi-directional blockchain bridge to allow data and value transfer between any number of blockchains. We believe that the future of blockchain technology is to allow all major networks to interact with one another and to be able to share value and information. We are building ChainBridge to make this vision a reality. Furthermore, we believe it is not enough to simply facilitate transfers between many different networks.

The first rendition of ChainBridge relies on relayers who are trusted but will feature mechanisms that will make it impossible for any one validator to abuse their power by stealing or otherwise misdirecting funds. At genesis, a specific voting threshold will be established. In order for a transfer to be accepted and sent across the bridge, it must receive enough votes from the relayers to surpass this threshold. After genesis, the relayers may vote to change the threshold if they see fit. Relayers can create a proposal for a transfer and vote on such a proposal, but they may not execute a transfer until the specified threshold has been reached. This means that although the relayers are currently trusted, users can be sure that their transactions are verified by multiple parties.

The design of ChainBridge is modular to enable the seamless addition of any blockchains that seeks support. Additionally, the design is set up so that the on-chain verification logic can be custom per blockchain. This means that any connected blockchain need not conform to the same rules of how data enters the chain as another connected blockchain. For example, the realyer threshold vote can be substituted for a proof based approach. A blockchain is only required to follow the rules defined by a type of transfer (i.e. such as token, arbitrary data or NFT transfers). Another unique benefit is that ChainBridge is set up to connect to as many blockchains as possible (upper threshold is in the 10’s - 100’s and based on computation power of the host machine). This means that by adding support for a blockchain, one immediately gains support for every other blockchain that has been integrated into ChainBridge. Currently this includes Ethereum, Ethereum Classic, Substrate based chains, Cosmos based chains and Celo.

At a high level, the following diagrams explain how ChainBridge is able to perform this logic.

As you can see, a common message format is standardized across the different blockchains, allowing ChainBridge to seamlessly move data between them. A blockchain’s writer handles all the logic of ensuring that the inbound message is correctly formatted to meet the needs of the destination chain.

The following explains how ChainBridge contracts function on Ethereum.

As seen in the diagram, all inbound interactions are with what we call the “Bridge” contract. Deposits and new proposals occur on the bridge contract. An interaction deeper occurs at a contract named “ERC20 Handler”, a handler is a concept we have to denote a modular component that handles a set of data, and performs actions accordingly. The handler process was implemented to mimic a plugin based system, thus providing extensive modularity. Based on the needs of a specific type of transfer, a new handler can be created to facilitate the needs without causing a disruption to the overall system.

Currently Supported Use Cases

  1. Transfer of tokens from one chain to another
  2. Conversion of a token to a native fuel
  3. NFT transfers
  4. Generic data and checkpointing via proofs (WIP)

ChainBridge + Nervos
With the existing infrastructure, a bridge between Nervos and any of the existing connected blockchains can be made seamlessly. Once the Nervos listener and writer are implemented, a user could perform any of the below transfers and many more:

  1. A user transfers ETH to Nervos, redeeming a token resembling ETH on the Nervos chain. Vice versa, a user could send CKByte to interact on the ETH chain.
  2. A user moves a token (such as DAI) from Ethereum to Nervos to be interacted with.
  3. A user of a substrate based chain could bridge over NFTs to be used on the Nervos Chain.

Security Assumptions
The security model of ChainBridge is agnostic to the chains with which the bridge interacts. This means the bridge does not need to understand a single security model but knows how to correctly assemble data based on the on-chain interaction. This can be done because the bridge has a unified messaging system that passes “just enough” information between chains (from the Listener to the Writer) for them to construct the necessary security.

Currently there exist two types of security models: threshold voting and spv style proofs. These models can be used interchangeably between blockchains, for instance, Ethereum could use threshold voting while the Nervos chain uses Ethereum merkle proofs to prove the integrity of the data.

This adds a tremendous benefit integrating new blockchains looking to use ChainBridge. It means that non-intrusive, upstream PR’s will not break existing implementations, and every chain benefits as it becomes a new destination option. In other words, by adding Nervos, you will also get access to the existing implementations as well as any future ones. Secondly, you are in control of your security. You do not need to be held hostage to a specific security model. If you have the ability to perform more complex logic, or have access to light clients, you can add that functionality whenever you would like.

Take the following scenario as an example: a user wants to have a very specific type of root built from the Ethereum chain to prove some data on Nervos. Using the Ethereum listener, a user can add a method to query whatever data they wish, pass that along to the accompanying Nervos writer and use that data to aid in the construction of the SPV style proof. Doing so does not break the existing Ethereum implementation, nor does it add bloat.

Based on the current status of the bridge, a conservative estimate for the completion of an integration would most likely take around two months.



Greg, myself, and our team have been working on a more concrete proposal to bring Nervos into the ChainBridge ecosystem.

We propose that the Nervos ChainBridge integration begin with a threshold signature design to enable bridging between CKB and any EVM or Substrate chain (and more in the near future). Multiple relayers will be required to vote on proposed transfers to allow for distribution of responsibility. Only once a threshold of votes has been met will a transfer be executed. This will then enable the ability to map native CKB tokens to ERC20 tokens, and it will also allow for arbitrary data payloads to be passed between chains. For this initial phase, we propose the following two milestones:

Milestone 1 - CKB ChainBridge Integration (CKB only)

  • ChainBridge Listener component to observe transfers out of CKB

    By indexing cells we can identify transfers as they occur. Transfers are then serialized into the internal message format and forwarded to the destination chain.

  • ChainBridge Writer component to propose and vote on transfers into CKB

    As transfers are received via the internal messaging system that interacts with the chain to create and execute the proposal. A threshold of relayers must vote in favour before the proposed transfer is executed.

  • Nervos Script to manage deposits on-chain

    This allows bridge to take possession of tokens. We will need to observe the outputs within the Listener.

  • Nervos Script to manage proposals and votes on-chain

    The writer component uses this to interact with the chain. The primary responsibility of this is to track the votes for a proposed transfer. Once a proposal is successful this also allows the release of tokens to the recipient

Milestone 2 - UI & Testnet Deployment

  • Web UI to:

    • Enable users to submit transactions to CKB to initiate transfers
    • Enable users to submit transactions to Ethereum to initiate transfers
    • Display voting process and confirmation of transfer
  • Deploy bridge to both the CKB and Ethereum testnets to provide bridging of native assets

    We will provide public access to allow CKB testnet tokens to be exchanged with Goerli ETH via an instance of the bridge. This will give the community an opportunity to evaluate the project and provide feedback.

  • Provide documentation for developers to deploy, configure, and understand the Nervos components of ChainBridge

    Our hope is that members of the community will want to deploy and modify the bridge in their own environment and for their own use cases. To help facilitate this we will provide in-depth developer documentation.

  • Provide documentation for users to interact with the UI and directly with the Nervos components of ChainBridge

    Step-by-step guides and high-level explanations will be integrated with the UI to help users understand what is happening.

Once this is completed we plan to propose adding support for ERC20 and ERC721 compatible tokens as well. Along with this we can look at mainnet deployment. As part of the ChainBridge project we are already exploring the best way to move to a more trustless approach and aim to iterate on this initial implementation to bring those features to Nervos in the near future.