EDIT 1 (05/15/2020) @ansermino has provided further content in the comments section 
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
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 https://github.com/ansermino
Polina: Project Manager https://github.com/Polycarpik
Greg: Research https://github.com/gregthegreek
Elizabeth: Research https://github.com/noot
Steph: Developer https://github.com/steviezhang
Wyatt: Developer https://github.com/spacesailor24
Ryan: Developer https://github.com/RyRy79261
Anthony: Developer https://github.com/anthonychernyak
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
- Transfer of tokens from one chain to another
- Conversion of a token to a native fuel
- NFT transfers
- 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:
- 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.
- A user moves a token (such as DAI) from Ethereum to Nervos to be interacted with.
- 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.
Timeline
Based on the current status of the bridge, a conservative estimate for the completion of an integration would most likely take around two months.