Cross Layer Transfer — CELR cBridge
Note: This article is part of our cross-layer transfer series, and I have prepared the list below, which helps the reader navigate easily through the articles.
- An Introduction to Cross Layer Transfer
- Fast Withdrawals In Optimistic Rollups — Part 1
- Fast Withdrawals In Optimistic Rollups — Part 2
- Standardising Cross-Domain Asset Transfer
- Cross Layer Transfer — Hop Protocol
- Cross Layer Transfer — CELR cBridge
Introduction
Similar to Hop Protocol, CELR cBridge is also a Liquidity Provider assisted Bridge that helps in Cross-Layer Transfer. But unlike Hop Protocol, cBridge doesn’t need to mint “synthetic tokens” (such as Hop tokens in Hop Protocol). Both Hop protocol and cBridge ensure L1↔L1 transfer and L2↔L2 transfer immediately(assuming the bonder/Liquidity Provider is willing to serve the request) from the user’s Point of view.
- cBridge at its core consists of multiple Relay nodes and cBridge contracts.
- The relay nodes provide liquidity for cross-layer transfer by charging a fee. The list of available nodes is updated here.
- cBridge contract helps the user and the relay node to interact with each other trustlessly. It is made possible with the help of HTLC (Hashed TimeLock contract) based implementation of cBridge contract.
HTLC Contracts
Let’s begin with understanding the HTLC contract using the below example.
Suppose Bob has a token “Token A” in Ethereum, and he wants to swap it with Alice for “Token B” in the Binance Smart chain.
The following steps are performed by both Bob and Alice in order to successfully complete the atomic swap.
- Bob picks a secret and finds the hash of the secret using a suitable hashing algorithm.
2. Bob deploys a HTLC contract on Ethereum. He then sends Token A to this contract which is locked with Alice’s Address and the hash of the secret.
3. Alice deploys a HTLC contract on Binance smart chain. She then sends Token B to this contract which is locked with Bob’s address and the secret hash (same as what Bob used).
4. Bob withdraws Token B from the contract deployed by Alice by unlocking it with the secret he created. During this process, Bob reveals the secret which is then publicly available.
5. Alice then uses the secret revealed by Bob to withdraw Tokens from the HTLC contract deployed in Ethereum.
Transfer Flow
Let’s see how a user transfers 1000 USDC from Ethereum to Optimism. The following steps are performed during this process.
- The user sends a transferOut request of 1000 USDC to the cBridge contract on the Ethereum side. This action emits an event LogNewTransferOut. The user also specifies the duration of the timelock(UI default is 12h)
- Multiple relay nodes or cBridge nodes are waiting to serve the liquidity requests. The Gateway server picks a relay node based on specific parameters.
- The bridge node sends a transferIn request to the Optimism part of the bridge(destination chain) using the same hashlock set by the sender. In this example, assume the bridge node sends 990 USDC to the contract after deducting the fees.
- When the user sees that the 990 USDC is waiting for them on Optimism, they release 1000 USDC from the Ethereum part of the bridge to the Relayer.
- Finally, the Relayer releases 990 USDC from the Optimism part of the bridge to the user.
If any party is not cooperative during the process, others can use the confirm and refund methods to finish or cancel the transfer forcefully.
The below GIF will help you understand the transfer flow.
cBridge v1- Scope for Improvement
What happens if there is no relayer on Optimism to help the user with transfer?
The user can withdraw the funds stuck on the ETH part of the bridge back to the wallet after the timelock (12h). It is not a problem if the user transfers 1000 USDC, but what if the user wants to transfer 10,000,000 USDC? Everybody is farming for yields, but here the user funds can be stuck for 12h. Also, can the user know in advance that the relayer is happy to help and has enough liquidity? At present, it requires additional trust assumptions.
What happens if the relayer does not release funds in the last step of the transfer?
If the relayer does not do it, the user needs to interact with the cBridge contract on the Optimism side and perform the step themselves. At present, there is no bonding and slashing mechanism to punish the relay nodes for any bad behaviour.
Also, as of now there is no way for a user to look at an on-chain contract and see much liquidity is available.The fee and relay node status can be queried here.
In Hop Protocol, a user can see how much liquidity is available using the on-chain contracts.
cBridge v2
Keyword : State Guardian Network (SGN)
SGN is currently the “watch tower” component of Celer’s State Channel architecture. The current purpose of SGN is to monitor “miss behaving” State Channel Nodes when users are offline and punish them.
They have plan to enhance SGN in the following two ways for cBridge use cases:
- Bonding/Slashing Mechanism for Relay nodes to Behave
SGN is used as a cBridge node selector module with success rate monitoring functionality and node “availability bond” slashing capability, replacing the centralised part of the system. The high-level idea here is that cBridge nodes will register in the SGN side chain when they are up and will put up an “availability bond” . When a user request comes, it comes to SGN and through consensus, SGN, instead of a centralised service, monitors and selects which cBridge nodes (can be multiple) to use based on a set of rules (how much bonded liquidity they have, past success rate, etc). If selected cBridge nodes respond, great, if they do not, oops, availability bond is slashed to the user. So the “opportunity cost” of money being stuck can be quite well covered. Users can ask for specific liquidity coverage too, just different kinds of pricing
2. Hybrid Model where LP can keep the custody of funds or delegate the liquidity to an on-chain contract.
SGN itself can act as a “cBridge Node”. For LPs who do not want to run a node, but can explicitly trust the level of security offered by SGN (a CELR staking-based PoS network), they can delegate the liquidity to SGN. And SGN can directly respond to users’ transfer requests with this delegated liquidity. In this mode, LPs are trusting their money to the decentralised PoS security level provided by SGN which is really an individual choice. This gives the benefits for a shared liquidity pool to bootstrap liquidity blazing fast.
