We are thrilled to introduce Celer cBridge, a multi-chain network that enables instant, low-cost and ANY-to-ANY value transfers within and across Ethereum’s layer-2 chains, Ethereum main chain and in the future, other layer-1s, and layer-2 on top of those other layer-1 chains.
A summary of some immediate use cases of Celer cBridge are：
- Instant and low-cost multi-hop value transfer between multiple different layer-2 networks on Ethereum, including Optimistic Rollups, such as Optimism, Arbitrum and Celer Rollups, and PoS Sidechains such as Matic and SKALE, without going through underlying layer-1 blockchain.
- Instant entering and existing layer2 from/to Ethereum layer-1 without long delay.
- Two-way bridging between layer-2 on one blockchain and a completely different layer-1 blockchains without going through the corresponding root layer-1 at all.
- Seamless connection to Celer State Channel Network in any single chain with full cross-chain routing support.
Why is cBridge important?
We are moving towards a multi-chain world as dApps and token assets are distributed over more and more loosely joined systems with different tradeoffs on security, throughput, latency, developer friendliness and modularity. These systems include different layer-1 blockchains, such as Ethereum, Cosmos and Polkadot, shards on those chains, and then different layer-2 scaling solutions on top, such as Optimistic Rollup, ZK Rollup and sidechains.
While transactions within each system are relatively smooth, value transfers across these chains are usually expensive and slow. For example, moving funds out of an optimistic rollup chain may require many days of delay. Transferring tokens from one rollup to another rollup system is even more expensive and time-consuming.
To keep liquidity flow efficiently between these loosely coupled systems without long delay and trust-based custodian, a universal value network that connects parallel chains and flattens different layers becomes increasingly needed.
cBridge is such a universal value transfer network. As illustrated in Figure 1, utilizing cBridge along with Celer State Channel, a client on Arbitrum rollup on top of Ethereum can transfer to a client on Polkadot via multiple cBridges that first relay liquidity from Arbitrum to Optimism Rollup, then to layer-1 Ethereum, then several hops across Celer State Channel Network on top of layer-1 Ethereum, and then to Polkadot. This can all happen within milliseconds that are spent in speed-of-light message passing and with minimal costs.
To take a closer look at the speed improvement: performing the above series of operations without cBridge will take approximately half a month, which is approximately 1,000,000X slower than doing it via cBridge. On the cost side, cBridge provides the same cost profile as state channel and instead of incurring costs on a per transaction basis, the cost can be associated with the amount of value transferred and liquidity used across the network. This drastically reduces costs for smaller-sized liquidity movements in the order of $100s to $1000s. It is clear that constructs like cBridge is crucial to enable a unified active liquidity across these systems and allow mass audiences to use applications in different tradeoff universes.
How does cBridge work?
As illustrated in Figure 1, we build cBridge by extending Celer Network’s state channel network’s functionality. To bridge liquidity instantly across multiple chains, we modified the off-chain communication protocol to enable “multi-homing”. For example, node A in Figure 1 simultaneously has presence on Optimism rollup, Arbitrum rollup, Celer rollup and Ethereum layer-1. Node A essentially connects to users who wants to bridge liquidity on all of the four chains and provides the bridging liquidity to bridge between layer-2 and layer-2 to layer-1. It is also important to note that multi-homing nodes (e.g. Node B) also can connect to state channel “subnets” on each chain individually and the connection between these multi-homing nodes essentially formed a “backbone” network across different chains.
Figure 2 shows a simplified example of the cross-chain state channel network where A from chain-1 transfers funds to D at chain-3 through a cross-chain multi-hop payment. The different chains can be a mix of Arbitrum/Optimsim rollup chain, eth2 shard, or any EVM compatible chain. Intermediate nodes (B and C) act as off-chain service providers (OSPs) that offer liquidity and payment routing service to the end users (A and D). In this example, B hosts service in chain-1 and chain2, C hosts service in chain-2 and chain-3.
If all nodes are cooperative, the cross-chain payment can be settled end-to-end instantly. If any node along the path is uncooperative or malicious, other nodes can force settle the payment on the chain through the CelerPay contracts. Our online architecture documentation has detailed descriptions on the single-chain CelerPay contracts and payment protocol. To extend them to support cross-chain payment, we need to deploy the contracts on each chain, add chain-id as a higher layer of address space, and add protocol to convert payments across different chains. Back to the example above, payAD, payAD*, and payAD** share the same src/dst addresses, payment value, and hash lock condition, but have different local token addresses and resolver contract addresses. These conversions are done at the ingress service node (B and C).
How is cBridge different?
cBridge extends our existing production-ready state channel core code that has been battle-tested in gaming applications with one million users. Alternative solutions to cBridge include various cross-layer-1 non-custodial bridge contracts and other layer-2 bridges such as Vector built by our friends from Connext. See below table for a quick comparison.
| Feature Support | Non-custodial Bridge Contract | Vector from Connext | cBridge from Celer |
| Generalized conditional transfer | No, mostly simple hash lock | Yes, no built-in condition | Yes, with optimized built-in conditions |
| Cost of repeated payment | High | Low | Low |
| Multi-hop value routing | No | No | Yes |
| Full duplex concurrency | N/A | No | Yes |
| Non-EVM chain support | N/A | Plug-in needed | Polkadot substrate supported. Plug-in needed for others |
| State backup | N/A | No | Yes, via Celer SGN |
| Challenge watchtower | N/A | No | Yes, via Celer SGN |
| Software Scaling | N/A | Single node | Easy clustering |
How to use cBridge?
The implementation is added as a part of our Celer State Channel Network. To add a new chain to Celer Bridge Network, one can simply deploy CelerPay contracts on any EVM-compatible chain or deploy corresponding plug-in in non-EVM compatible chains (e.g. Celer substrate module on Polkadot). After that, a cBridge node operator then starts Celer Node servers on each chain, and uses the CLI tool to populate the multi-homing config (example) into each OSP database. Here is an end-to-end example for configuring and setting up a cBridge node across three networks/chains.
Celer cBridge is production-ready and the on-chain component is not changed from Celer State Channel Network’s CelerPay contracts. As the layer-2 system rolls up, we will release a user-friendly web interface for mass audiences to use cBridge Network shortly.
Have questions?
Ask us in our Discord channel!
