Dialogue with Dr. Dong Mo from Celer: How to Build a Better Cross-Chain Bridge

Source: Rhythm Research Institute

With the gradual rise of various new public chain ecosystems this year, the demand for cross-chain interaction between public chains has suddenly exploded. However, the current user experience of various official bridges is far from satisfactory, as many users are still troubled by issues such as a limited number of supported cross-chain objects, complex cross-chain processes, and slow transfer times.

Rhythm BlockBeats interviewed Dr. Dong Mo, the head of Celer cBridge, one of the most mainstream third-party cross-chain platforms, to hear his views on the current cross-chain market and the latest features brought to users after the cBridge 2.0 upgrade.

How cBridge 2.0 Ensures Fund Security

Rhythm BlockBeats: We see that the newly launched cBridge 2.0 has opened a liquidity provision interface for ordinary users. For an ordinary user who wants to become a liquidity provider (LP), the most concerning issue is still fund security. What mechanisms are in place in cBridge 2.0 to ensure the safety of liquidity pool funds?

Dr. Dong Mo: We need to discuss this issue from two dimensions. The first dimension is from the overall system architecture, which is about who manages these funds and how they are managed. The second dimension is more about the engineering details, specifically what measures we have taken to ensure overall security.

Let me start with the first point. From the current overall architecture of cBridge 2.0, the shared liquidity pool is controlled by the State Guardian Network (SGN). This State Guardian Network itself is a special PoS chain, and its security is determined by CELR staking. This is no different in essence from Polygon or any other PoS chain; it relies on economic security to ensure the safety of assets and the system within the entire network.

For example, in the entire PoS chain, as long as more than 2/3 of the nodes are not malicious, the entire system can operate normally; if between 1/3 and 2/3, the system will experience a halt; if more than 2/3 of the nodes are malicious, the entire system will face risks. This is the overall system security. This type of security is conceptually similar to ensuring fund security through an n-of-x multi-signature wallet, with the main difference being somewhat analogous to the distinction between PoA and PoS in blockchain.

Compared to some cross-chain bridges that use simple multi-signature solutions (where each node has a private key, and controlling enough nodes can lead to significant security issues), our cBridge system has higher economic stability and economic security. Even if there are some minor malicious nodes, the system will immediately exclude these problematic nodes and confiscate their staked CELR. In this process, through CELR staking and penalty mechanisms, problematic nodes will be quickly eliminated.

Therefore, from an architectural perspective, one significant difference between cBridge and other solutions is that we are very close to the security of a public chain, which gives us a substantial security advantage over other PoA or simple multi-signature solutions.

The second point, regarding engineering details, is that we have done a lot of work on security overall. Our entire contract layer has undergone three independent audits, and no vulnerabilities that could lead to fund loss were found.

Before going live, we conducted cross-reviews of the entire engineering team, ensuring that each core piece of critical code was reviewed by at least two different teams. During the cross-review process, no significant issues that could lead to fund loss were discovered.

More importantly, we adopted a phased rollout plan in our launch mechanism. Although we launched cBridge 2.0 on November 18, liquidity mainly came from some LPs migrating from 1.0. We did not directly initiate liquidity mining or other activities. We hope to give the system one to two weeks to have a period of adjustment. Only after confirming that no unexpected issues arise during the adjustment period will we start liquidity mining and other user incentive activities.

In addition, we have implemented some innovative solutions throughout the system to ensure fund security. For example, during the initial gradual rollout, we will have some traffic control, such as limiting cross-chain funds every half hour. At the same time, we have a completely independent monitoring system to monitor the entire system's traffic in real-time and check whether any "invariants" are violated in the system.

The so-called "invariants" refer to the fact that if a fund is to be sent from the chain, it must first come from somewhere. By monitoring the overall on-chain state, we can keep track of the entire system's situation in real-time. Once we detect any issues, our system will quickly pause all on-chain contracts through a governance model to ensure the safety of the entire system.

Finally, we believe that the entire cross-chain space is a relatively high-risk area, as there have been too many cross-chain projects attacked in the past, with some cross-chain bridges being attacked more than once, often 2-3 times.

However, you will find that none of these solutions had vulnerability reward programs beforehand. This is actually very problematic because many blockchain researchers or white hats are willing to help you assess the security of the entire system but would hope for some additional rewards.

This is also why we launched a $2 million vulnerability reward program in partnership with Immunefi when cBridge 2.0 went live. If a hacker can steal money from our system, we will reward them with $2 million. We hope to address this issue beforehand rather than negotiating with hackers after the fact to get our money back.

Rhythm BlockBeats: We have seen many security incidents with cross-chain bridges this year. What essential differences does cBridge have compared to these cross-chain solutions that have already experienced security issues? For example, is the reliance on a PoS public chain for security a significant advantage of cBridge 2.0?

Dr. Dong Mo: Yes, you are correct. Our economic security is built-in, which is a significant advantage.

The second advantage is that we have simplified the logic on-chain. Unlike many cross-chain solutions that rely on AMM pools, creating a so-called settlement token and converting between cross-chain tokens, these complex combinations do not exist.

In cBridge 2.0, there is a PoS chain similar to a public chain (SGN). Unlike other projects that purely rely on simple signatures or multi-signatures, we run most of the complex logic on this PoS chain, minimizing the need to design complex smart contracts on both public chains, thereby reducing system complexity as much as possible. In fact, the design of our entire system is simpler than that of other systems, and simplicity often leads to higher security.

Rhythm BlockBeats: We know that cBridge can not only facilitate cross-chain transactions but also help users migrate assets across layers, such as between Arbitrum and the Ethereum mainnet. Previously, if users used the official Arbitrum bridge to withdraw funds to the mainnet, they would need to lock their funds for about 7 days for the system to complete fraud proofing. However, with cBridge, funds can be withdrawn instantly. If these funds are later proven to be fraudulent after 7 days, will the related risks be borne by the LPs in cBridge?

Dr. Dong Mo: This is a very good question. For OP-Rollups like Arbitrum, the characteristic is that anyone can observe whether what happens above is correct; we do not blindly trust the results.

Our entire SGN acts as a monitoring system in the form of a chain, observing the data (calldata) written on the main chain by OP-Rollup, and running the OP-Rollup light client through the SGN nodes to re-verify these transactions to ensure no security issues occur before we process the transaction.

Rhythm BlockBeats: So, when we accept this fund, we have already confirmed in advance that this fund is definitely fine, which is why we accept the cross-chain application?

Dr. Dong Mo: You are correct. When we accept this fund, it must be that a state root of Arbitrum has already appeared on the Ethereum mainnet, and that state root itself is error-free. Only then will we accept the cross-chain application. Of course, this does not take 7 days; it generally only takes one to two minutes.

cBridge's Cross-Chain Solutions

Rhythm BlockBeats: Currently, various cross-chain solutions on the market can be roughly divided into three types: hash time lock, notary cross-chain, and light nodes. cBridge should be based on the first type, hash time lock. What do you think about the future development trends of these three solutions? Will these three models of cross-chain bridges coexist and develop, each with its strengths, or will there be an evolution towards one particular solution?

Dr. Dong Mo: First, I need to correct you a bit. cBridge did indeed use the hash time lock solution in 1.0, but in cBridge 2.0, although we have not yet launched all the features, the currently launched shared liquidity model is more similar to a notary and light node side-chain type of cross-chain solution.

In cBridge 2.0, we will verify the validity of transactions in Arbitrum, and then the entire PoS chain (SGN) will perform a weighted signature. After obtaining the weighted signature, we will control the shared liquidity pool to cross from one chain to another. This means that the shared liquidity pool is controlled by the PoS chain, so the PoS chain itself is similar to a notary.

Regarding the hash time lock and notary models, both are included in the overall architecture of cBridge 2.0. The latter operates in scenarios where if you do not want to run a node and only want to be a liquidity provider (LP), you can lock liquidity in the liquidity pool, which is managed by SGN as a notary.

However, some LPs may say they do not want others to control their liquidity and want to run their own nodes. In this case, SGN will not control their liquidity but will assign cross-chain tasks, which is based on a completely trustless model of hash time lock without adding any third parties.

Our entire 2.0 architecture design supports both modes simultaneously, but which mode will have more advantages in the future and in which environments may become more popular will require some time to test. From cBridge's perspective, we support all cross-chain models.

Rhythm BlockBeats: We see that cBridge 1.0 supported about 8 types of tokens, while 2.0 currently only supports 3 types. Will cBridge continue to increase the number of supported assets in the future? Is there a specific process for adding new assets, or will it eventually support all ERC20 tokens without restrictions?

Dr. Dong Mo: When the product is first launched, we will prioritize stability to avoid issues, but the number of supported assets will definitely increase in the future.

The process of increasing asset support does not conflict with unrestricted access. Specifically, when everyone wants to add new asset types, they can vote through Celer's governance mechanism. After the vote passes, liquidity will be opened for provision, and only after a period will the cross-chain functionality be officially launched.

Rhythm BlockBeats: After reviewing the official documentation of cBridge 2.0, I have a question. I previously thought that the cBridge cross-chain architecture did not include an AMM mechanism. However, in the introduction of cBridge 2.0, we found that as a liquidity provider, there might be some impermanent loss risks. So, has cBridge introduced an AMM mechanism in 2.0?

Dr. Dong Mo: In fact, the concept of AMM has been overused. The so-called AMM mechanism actually refers more to a price curve. We indeed used a price curve model in 2.0, but we did not implement this price curve on the two chains bridged by cBridge; instead, we implemented it within SGN, allowing for easy adjustments and optimizations.

Rhythm BlockBeats: Can you reveal which market-making function we are using?

Dr. Dong Mo: It is similar to the stablecoin market-making function used by Curve, not the constant product function like x*y=k, but a relatively more complex stablecoin market-making function.

Rhythm BlockBeats: This means that if the liquidity on both sides is roughly equal, users will not bear high slippage when crossing chains?

Dr. Dong Mo: That is correct. Even if the liquidity on both sides is not roughly equal, as long as the difference is not too large, such as 1:10 or 1:20, there will not be significant slippage.

For liquidity providers, since it is a swap of homogeneous tokens, there will indeed be impermanent loss in this process, but the magnitude of this impermanent loss is similar to that of LPs on stablecoin exchange platforms.

Rhythm BlockBeats: So, while there will be some risk, in most cases, LPs still do not need to worry too much about impermanent loss?

Dr. Dong Mo: Yes, the losses will be quickly recouped through transaction fees.

Rhythm BlockBeats: Previously, when using the cBridge 1.0 product, users sometimes encountered situations where one side's liquidity was exhausted, preventing cross-chain transactions. So, in 2.0, theoretically, will there be no liquidity exhaustion? It might pull the price higher to automatically balance the liquidity on both sides; can we understand it this way?

Dr. Dong Mo: You are absolutely right. The issue of liquidity exhaustion was indeed a flaw in cBridge 1.0. However, I believe a more critical point in cBridge 1.0 was that you had to run a cross-chain node yourself to provide liquidity, which was a relatively high barrier.

In cBridge 2.0, we will launch liquidity mining activities in the future, and when liquidity is sufficient, such problems will naturally not exist.

Rhythm BlockBeats: Can we understand that the current cBridge 2.0 product is very much like a cross-chain version of Curve?

Dr. Dong Mo: Very correct.

Rhythm BlockBeats: Will cBridge potentially add stablecoin exchange functionality during the cross-chain process in the future? For example, if I cross USDC here, will it directly convert to USDT after crossing?

Dr. Dong Mo: This is not limited to stablecoin exchanges; any asset exchange is possible. We do not need to perform the swap ourselves but can directly integrate existing swaps on both sides.

For example, if I want to cross USBC from Avalanche to BNB on BSC, I would first cross USDC to BSC and then send a message during the cross-chain payment to inform the recipient that they need to exchange USDC for BNB. The user will receive BNB directly on BSC.

In our entire system architecture, we can not only perform simple asset cross-chain transactions but, more importantly, expand into richer use cases. Our overall SGN architecture is not limited to communicating how much you should send to the other side; SGN is actually a very generalized messaging layer that can carry messages from one chain to another and can be bound to the corresponding payments to execute relevant operations. This will be a very useful feature in the future and will be a major advantage for us.

Rhythm BlockBeats: We see that cBridge currently only supports cross-chain transactions for EVM-compatible chains. Are there plans to support non-EVM blockchains like Solana in the future or establish cross-chain connections with their EVM-compatible layers?

Dr. Dong Mo: Establishing cross-chain connections with EVM layers is relatively straightforward. As for non-EVM-compatible chains, we are already planning to integrate Solana and Terra. Technically, this is not an issue, and as our product upgrades, we will support more non-EVM-compatible chains.

Development Trends in Cross-Chain Technology

Rhythm BlockBeats: With the increasing number of cross-chain bridges in the current market, some cross-chain projects focusing on aggregation have recently emerged. Do you think aggregation will be a development trend in the entire cross-chain market in the future?

Dr. Dong Mo: I believe aggregation is definitely needed, whether it is done by aggregators or by the cross-chain bridges themselves. In fact, aggregation is relatively simple, but I think aggregators should not create their own APPs; that won't work. They should be developed in an SDK model, which can be integrated into every DApp with cross-chain needs. Such an SDK is very valuable.

This model will also bring more benefits to the entire cross-chain bridge ecosystem. We have been laying out in this area and are even participating in investing in or incubating some cross-chain bridge aggregator projects.

Rhythm BlockBeats: Do you think these projects will be in competition with cBridge in the future, or will cBridge potentially engage in aggregation cross-chain work itself?

Dr. Dong Mo: We will still focus more on the underlying aspects. Aggregation cross-chain is more of an upper-layer application concept. Whether it is asset aggregation or aggregating some DEXs, the underlying can use Celer's SDK, so we hope to integrate various aggregation cross-chain applications as much as possible.

Rhythm BlockBeats: So you believe different aggregation cross-chain projects may bring some synergies to cBridge rather than direct competition?

Dr. Dong Mo: Yes, these will bring some traffic to cBridge.

Rhythm BlockBeats: Have you considered the team's profitability issue, or can CELR currently capture the commercial value brought by cBridge?

Dr. Dong Mo: This is a very good question. First of all, CELR is designed to directly capture the value of the entire cross-chain bridge. The economic security of cBridge is actually guaranteed through CELR staking in the PoS chain (SGN). During the staking process, because it provides security services to the entire network, a portion of the fees will be charged for cBridge, layer2.finance, and other products we will launch in the future, which is quite similar to the security models of various public chains.

Rhythm BlockBeats: We are seeing more and more applications, especially gaming applications, gradually starting to build their own application chains due to the performance and transaction costs of public chain platforms. Do you think this will be a significant development trend?

Dr. Dong Mo: This is possible, but the application chain itself needs to be looked at in terms of what model it is. I still have a relatively positive outlook on the entire Rollup track. Rollups, whether OP-Rollups or ZK-Rollups, will have their place in the future. It is not the case that ZK-Rollups will necessarily dominate because ZK-Rollups have proof costs. If you want to develop some so-called application-specific chains, you can completely use Rollup solutions to gain Ethereum's security while greatly improving application efficiency. I believe this is an inevitable path for the future.