CBridge 2.0: Generic cross-chain platform based on the Celer state Guardian network

Source: Celer

Since the launch of cBridge version 1.0, the total amount of our cross-chain funds has been increasing exponentially every week. In the first month of the launch, we only handled $10M of cross-chain transfers, but in the following month, the total amount of cBridge cross-chain funds increased to $170M, and the daily cross-chain funds also steadily exceeded $10M. Liquidity providers at cBridge nodes, with no additional incentive, earn 45% annualised returns from cross-chain fees alone. It's exciting, but it's just the beginning.

Today we are pleased to announce the planned cBridge 2.0 upgrade and give a brief overview of this innovative upgrade.

CBridge 2.0's technology architecture will deliver the best cross-chain trading experience on the market today, based on providing better liquidity depth to users, the most efficient and easy-to-use liquidity management to cBridge nodes and liquidity providers (LP) who don't want to run nodes, and broad cross-chain messaging capabilities to developers. To support cross-chain NFT, cross-chain DEX and more applications. All cBridge 2.0 features are based on an upgrade to the CELR pledge driven State Guardian Network (SGN) to further enhance value capture in the SGN Network.

Summary: What optimization does cBridge 2.0 implement?

For those who don't want to focus too much on technical implementation details, here's a quick look at the upgrades and benefits of cBridge 2.0.

For users:

-  Better depth of liquidity: support for larger single cross-chain transactions.

-  Easier to use process: provide one-click transfer function.

-  Support transfer to native fee token (GAS token) : for example, WETH on BSC can be directly transferred to native ETH on Arbitrum, which is used to pay the fee on Arbitrum.

-  Extension and support for multi-chain and token.

-  Bridge node service quality guarantee mechanism: For users who choose to use bridge nodes, we introduce a new service quality insurance mechanism, which will punish the offline nodes and compensate users.

For liquidity provider (LP) and cBridge node:

-  You don't have to run a node to provide liquidity: in cBridge 1.0, the only way to provide liquidity was to run a cBridge node. In 2.0, we added a new schema in which SGN itself will exist as a cBridge node. Liquidity providers can broker liquidity to the co-managed node run by SGN, so they do not need to run additional cBridge nodes while obtaining cross-chain handling fees.

-  Optimal liquidity management experience: Compared to other cross-chain solutions, cBridge 2.0 LP does not require the casting of synthetic tokens, the forced entry of a highly volatile AMM liquidity pool, and the exposure to high volatile losses. You only need to simply provide single currency liquidity, and you can flexibly master your liquidity distribution to carry out arbitrage.

-  High liquidity efficiency: Compared to other cross-chain solutions, cBridge 2.0 does not require additional double liquidity lock-in, thus increasing the unit value and efficiency of liquidity and maximizing LP returns.

-  Reasonable liquidity rebalancing design: cBridge 2.0 manages liquidity uniformly through SGN, supports and generates optimal asymmetric AMM curves according to supply and demand, so as to motivate arbitragers and LP to maintain liquidity adequacy and symmetric stability of the overall network.

-  Optimal self-managed Mode cBridge node scheduling: SGN will conduct unified optimized user experience scheduling for those liquidity providers who choose to self-run and manage cBridge nodes.

For user and verifier nodes that pledge CELR in SGN:

-  Value capture: As SGN pledgers and verifiers provide an integral service to cBridge 2.0, CELR pledgers in SGN will capture network value directly through cBridge cross-chain fees and liquidity mining incentives.

-  Protocol governance: System parameters such as price curves, cost ratios, and so on are governed by a distributed protocol based on CELR pledges.

For developers:

-  The white label of the front-end SDK: allows various multi-chain DApps to integrate cBridge functions locally, allowing users to cross chains directly within their DApps.

-  Provides cross-chain messaging capabilities to support other applications such as NFT cross-chain: enables developers to develop applications that are more complex than simple asset cross-chains, such as cross-chain NFT and cross-chain DEX.

So how did we implement all these new features and features in cBridge 2.0?

Answer: Celer's state guardian network -SGN.

In cBridge 2.0, we extended the functionality of SGN to support two different bridging modes to meet the preferences of different types of users and LP. In this paper, we will introduce the overall architecture of the system.

Status Guardian Network Review

State Guardian Network (SGN) is a core component of Celer's overall architecture. In Celer's overall system architecture, SGN is a special PoS chain that monitors L1 events related to L2 state and faithfully passes layer 2 information back to Layer 1 as needed.

inCeler status channel, SGN helps store channel state and responds to malicious clearing on L1 when needed. In CelerLayer2. Finance rollup chain, SGN expands into a decentralized block-out network, passing Call Data and State Roots back to L1. In Rollup mode, even if the entire PoS consensus fails, any SGN node can still chain Fraud-proof to ensure system security.

CELR holders can pledge CELR to SGN by becoming SGN verifiers or by proxy and actively provide the above services. CELR pledger will receive pledge reward and corresponding service fee by providing the above services.

SGN acts as the cBridge node gateway and service Level agreement (SLA) arbiter

cBridge  Node design choices and limitations for 1.0

In cBridge 1.0, when a cBridge node joins the network, it registers various information, such as expense tables and liquidity status, with a gateway service. The gateway continuously monitors the status and performance of cBridge nodes. When a user request is made, it is directed to the gateway. Gateways evaluate registered nodes based on liquidity availability, historical bridging success rates, cost, and so on. It then suggests the most appropriate bridge node for the request. In 1.0, we chose to use a centralized gateway to quickly learn how to operate various scheduling policies.

What the 1.0 gateway provides users with is essentially "for reference only" advice to use certain cBridge nodes. Although cBridge 1.0 is built with an unmanaged architecture and users never need to trust nodes for the security of their funds, there are user experience issues related to "node availability". For example, if a user sends a conditional transfer (the first part of HTLC) to a node, but the node goes offline before the two-step HTLC transfer is complete, the user will have to wait for the conditional transfer timeout, and there will be no penalty for the dropped cBridge node, nor will the user receive any compensation for the waiting time.

We addressed both of these limitations in 2.0 with SGN.

Decentralized and efficient cBridge node scheduling via SGN

In 2.0, we first migrated all of our centralized gateway logic as distributed services to distributed SGNS. CBridge nodes will register with SGN, not with a centralized gateway service, based on their fee preference, liquidity availability, and so on.

When a user makes a request, the normal system flow is as follows:

-  Users query the current status of SGN for estimated transaction costs and liquidity availability.

-  If the estimated fee is acceptable, the user sends the first half of the HTLC transfer and specifies the maximum fee tolerance.

-  SGN monitors and receives transactions. It assigns one or more cBridge registered nodes to transactions based on node scheduling rules. This transaction assignment is written on the SGN chain and is also marked in the user's HTLC transfer.

-  The allocated node accepts the allocation and responds by completing the remaining conditional transfer.

-  SGN continues to monitor and track transactions, and once a transaction is successfully completed, the status associated with that transaction is removed from the SGN chain.

Based on this, more scalable cBridge node growth will be implemented to support the selection process of consensus and unbiased nodes. But the benefits of migrating cBridge nodes to SGN go beyond that.

Bridge node SLA margin and forfeiture mechanism

Unlike gateway 1.0, SGN monitors the entire process of cross-chain transactions under the architecture of SGN as a scheduling layer (gateway). As a decentralized PoS chain, SGN can now offer more than just "fSO advice", it can also impose penalties on cBridge nodes that fail to complete allocated cross-chain transfers "as promised".

When a cBridge node registers with SGN, it can place a "SLA margin" (i.e., a pile of valuable tokens) in the pool contract associated with certain service level agreement (SLA) commitments, such as availability, fee levels, and liquidity reserves. If SGN determines that a node has violated an SLA, such as a node going offline without completing a transfer, SGN can forfeit its margin as compensation for the reduced user experience and liquidity opportunity cost. (Note that there is never a possibility of losing a user's money; this compensation is only for the opportunity cost of "stuck money.")

During node selection, the available value of SLA margin is a key consideration for prioritization during node scheduling and allocation. Honest cBridge nodes have a strong willingness to pledge deposits to increase their chances of being selected during the bridge process. Less reliable nodes, on the other hand, will be kicked out of the system or as the lowest-priority option.

CBridge nodes can run high quality SLA through the SLA margin function supported by the distributed SGN Gateway. This aims to provide a healthy, rapidly growing and decentralized network of cBridge node operators for liquidity providers who wish to maintain "self-managed liquidity".

Some might argue that SLA margins can be wrongly forfeited due to the possibility of PoS consensus failure, so setting SLA margins cannot be called 100% self-managed.

We would like to emphasize that SLA margins need only be a small percentage of total liquidity to effectively ensure a smooth user experience and a self-healing cBridge node operator ecosystem. This is a worthwhile trade-off, and most importantly, the entire cross-chain process is always "unmanaged" from the user's perspective, with no financial risk issues.

Node scheduling rules

The principle of designing node scheduling rules is to optimize user experience. We built an empirical formula for "node quality score" to combine multiple factors, such as parameters in the node SLA (cost, response time) and historical performance (such as success rate, average response time). When selecting nodes for user requests, we prioritize the nodes based on this score. We want this formula to be iterated and optimized over time through protocol governance, through empirical operational experience.

Compared with the NXTP protocol newly launched by Connext, which is also self-hosted architecture, cBridge has simpler user interaction, less delay, lower cost, no complex multi-node auction process, and can effectively guarantee the node service level and protect the interests of users.

SGN acts as the shared liquidity pool manager

No need to run cBridge  Nodes provide liquidity

The improvements described above are designed more for self-managed LPS that can run cBridge nodes themselves. However, we recognize that there are plenty of LPS and users who want to provide liquidity but don't want to run cBridge nodes themselves, and who are comfortable with the level of security that SGN and CELR staking's PoS consensus provides. In addition, by sharing the liquidity pool model, it is easy to jump-start liquidity across the network, enabling a better user experience more quickly.  

Therefore, in cBridge 2.0, we introduced a new mode of operation: SGN as a whole manages shared liquidity pool contracts across multiple chains. This is to regard SGN, which is itself a distributed PoS chain, and the liquidity pool it manages as a single "node", and provide an option for LP, so that it can easily entrust liquidity to SGN and obtain cross-chain fee income without running any nodes.

So what security guarantees does this model provide?

PoS level security and decentralized governance

In this model of cBridge 2.0, shared liquidity pool contracts are managed through SGN's PoS consensus. Funds in transfer pool contracts require CELR pledge weighted multiple signatures.

A pool of funds is at risk only if a node that exceeds an APEST is malicious. We would like to emphasize that as the number of cBridge cross-chain transactions increases and the total value of cBridge network capture increases, it naturally becomes more difficult and costly for any node to attempt malicious behavior. This is fundamentally different from other solutions that utilize TSS multiple signings in terms of security, because TSS itself does not bind to any token pledge, so its security does not grow as the value of the network increases.

The validator governance model in SGN is open and decentralized: SGN allows new validators to be elected and joined to the collection of validators through a governance process, without any special reconciliation process.

Concise liquidity provider (LP) experience and high liquidity efficiency

So how do LP's manage their liquidity in this model? Existing solutions such as Hop Protocol and Thorchain require LP to place token liquidity into an on-chain AMM pool along with another protocol-controlled settlement token. But this model has some drawbacks:

-  For example, Thorchain requires LP to use Rune, a highly unstable settlement token, which is bound to cause LP to suffer significant impermanence losses.

-  Even in the case of synthetic tokens minted through native liquidity tokens, LP still faces complex operational overhead in adding, removing, and rebalancing liquidity across multiple chains.

-  For example, the Hop Protocol is less efficient in liquidity situations where a bonder is required to provide liquidity, because the actual demand for liquidity for any cross-chain transfer is twice as much as its necessary liquidity.

CBridge 2.0 solves the "liquidity attribution problem" with a new design that provides a simple LP experience and high liquidity efficiency. To better understand our system design, we will first explain what "liquidity attribution" means. In any multi-chain bridge system, when a user sends funds from the source chain to the target chain, the LP (or aggregation pool) essentially pays funds to the users on the target chain and receives funds from the users on the source chain. Now, suppose you have an LP that provides liquidity to the system on chain A. When users send money from chain B to chain A, the liquidity of LP is essentially "redistributed" : they have less liquidity in chain A, and they have more liquidity in chain B. The liquidity attribution problem is defined as "how the system lets each LP know where all their liquidity is" and "how to effectively manage liquidity to optimize transaction fee returns".

AMM pool-based solutions implicitly track LP liquidity by allocating settlement tokens and native tokens in the AMM pool. Bridging structures (such as TSS validators or L2 to L1 messaging protocols) only manage the minting and destruction of cross-chain settlement tokens. Users will always have to pay for AMM exchanges from settlement tokens to native tokens on the target chain; Sometimes even on the source chain. When liquidity imbalances occur in the network, it makes sense to move liquidity from chains with abundant liquidity to chains with scarce liquidity in order to arbitrage the slip points. Arbitragarists would have an incentive to rebalance liquidity by sending money from the liquidity scarcity chain to the liquidity abundance chain.

LP also has a stronger incentive to balance liquidity because they do not have to pay additional bridge tolls to reap arbitrage gains. However, the rebalancing process of LP is very complicated. For example, if we represent the liquidity scarcity chain as S and the liquidity adequacy chain as A, LP will need to take the following steps:

-  Remove liquidity from S's AMM pool.

-  Move the settlement token from S to A.

-  The settlement token is sold to the AMM pool on A at A premium for the native token.

-  Move the native token back to S.

-  Purchase settlement tokens on S.

-  Add liquidity back to S's AMM pool.

The above steps not only incur operational costs, but also significant transaction and time costs.

In cBridge 2.0, we believe that the bridge structure (in our case SGN) can be highly optimized to radically reduce costs compared to on-chain smart contract operations. Therefore, in cBridge 2.0, the liquidity of each LP in the system is explicitly tracked. Adding liquidity is super simple: Simply add native tokens to a liquidity pool contract with a single transaction, and SGN records the amount of liquidity for each LP in SGN's chain state. In essence, SGN maintains a table (chain_id, LP_address, Token_type, balance) in its chain state.

When processing a cross-chain transfer request, SGN will use the liquidity of the entire pool to calculate slippage and pricing (more on that in the next section), then SGN will treat LP as a "virtual cBridge node" and transfer the request based on LP's liquidity allocation. A simplified conceptual understanding is that for each transfer request, the LP liquidity balance of each target chain will decrease proportionately to its available liquidity, while their liquidity balance on the source chain will increase. Of course, in practical engineering implementation, random sampling and approximation algorithms are used to minimize state changes and costs, while maintaining statistical fairness between LP. This part is reflected in more detail in our technical documentation.

Such a structure is also suitable for arbitrager-based liquidity balances, and this design also provides LP with maximum flexibility in managing its liquidity. Each LP can clearly see how their liquidity is allocated at any given time. This allows them to fully understand what is going on when they choose to remove or increase the fluidity of any chain. This simplifies the liquidity rebalancing process from six steps to three, with no AMM exchange costs:

-  LP removes the liquidity of native tokens directly in A. In this first step, LP has locked in the slip arbitrage returns due to the slip points in the system.

-  LP moves native tokens from A to S.

-  Add native tokens to S's pool.

LP can still remove all fluidity from a single chain or any combination of a particular chain. In cBridge 2.0, this is done by triggering an internal cross-chain transfer and treating THE LP as a user, transferring its liquidity to the desired chain, and then removing the liquidity. Note that in this case, LP will bear the system slip point of cross-chain transfer. However, this is no different from directly exchanging settlement tokens for amM-based on-chain solutions, and actually costs less.

More importantly, in cBridge 2.0, LP uses native token liquidity directly and therefore does not suffer from high volatility losses. In particular, compared to Hop Protocol, cBridge does not require any additional Bonder liquidity locking requirements, thus achieving the highest liquidity efficiency and the best liquidity rate returns.

Cross-chain bridging pricing to incentivise balanced liquidity

In a cross-chain bridging system, the liquidity of the same native token exists on multiple chains. As the demand for the same native token changes across different chains, the inherent pricing between the same token on different chains also changes dynamically. This is based on the potential cost of using native Bridges to transfer between different chains and the supply-demand balance of liquidity across these different chains.

It is important for any bridging solution to be able to capture this inherent price change by designing the proper bonding curve. This creates significant incentives for LP to leverage "economies of scale" to rebalance liquidity across multiple chains to maintain a network with sufficient and balanced liquidity to handle all user requests.

Continuing with our "smart architecture" design principles, we built a joint Curve pricing mechanism within SGN inspired by Curve Staboin AMM. When a user transfers tokens from one chain to another, SGN calculates the tokens received based on the liquidity available on the source and destination chains. In addition to the pricing itself, a fixed fee is deducted from the transaction as a fee paid to LP.  

Specifically, for any pair of chains. And J, let  And & have spentThe balance on the chain. And chain j  These are given tokens. Then the following invariants should always hold when we calculate the slip point of token transfer between chains. And chain j:

-  A  Is the constant of each pair. For the same chain pair, all the tokens of A are the same.

-  D  Phi is a variable. Initial D.   D  can be obtained by solving the cubic equation. Given the initial flow along both chains, then, D.   Should be updated iteratively according to liquidity status.

-    And & have spentIs the relative weight of the two chains, used to control the slip point asymmetry of the transfer. Note that the weights are configured for each chain pair and should satisfy  .

The reason why we use these weight parameters in bonding curve is to capture the inherent asymmetry of some chains. For example, switching to rollups such as Arbitrum and Optimism is much simpler and less costly than a seven-day delay in switching out. Therefore, we can control the weights in the joint curve to reflect the inherent differences produced by each chain.

In the red asymmetric curve with a blue symmetric reference line above, we can see that the curve is from the chain i&NBsp when the imbalance occurs; Transfer to chain J creates more slip points. If & have spent, can be simplified as the Curve used in Curve Finance.

Universal cross-chain messaging

CBridge 2.0 creates an INTELLIGENT cross-chain architecture based on SGN. This structure can do more than cross-chain asset transfer, in fact, it is a general cross-chain messaging framework, in which SGN monitors any events on the source chain, and publishes consensus notarization of these events on the target chain to complete the information cross-chain process.

We will gradually open up this underlying functionality to developers as an SDK to build use cases, not only for on-chain bridging, but also for other use cases such as cross-chain NFT, cross-chain DeFi aggregation, and so on.

Network value capture

Unlike many governance tokens, where protocol token-holders do not assume day-to-day functions of the protocol, it is clear that a network of CELR holders and state guards is essential to the good operation of cBridge.

As a result, users and LP in cBridge 2.0 need to pay SGN for its services. These fees are prorated among CELR pledgers in SGN. To be specific:

-  In a model where SGN acts as a bridge gateway and SLA arbiter, a portion of cross-chain transaction fees and forfeitures are transferred to SGN for its scheduling node and SLA mediation work.

-  In SGN's model as a shared liquidity manager, a portion of cross-chain transaction fees are paid to SGN to help handle all cross-chain liquidity transfers.

There are also some system parameters and configurations that need to be updated and adjusted based on governance to ensure the stability and continuity of the system. CELR will also act as a governance token for this new component in the Celer ecosystem.

Conclusion of cBridge multi-chain bridge design

The last part is about our views on the technical trade-offs in cross-chain bridge design. We believe that the most important choice in the design of cross-chain bridge is the ownership of system liquidity control.

Some might argue that a self-regulated bridge solution is the "purest" and "safest" bridge design. While we recognize the principle of this argument, we want to emphasize that not everyone can actually run cBridge full nodes. Of course, we are confident in the potential of this model, which is why we designed the self-hosted model of SGN as cBridge node Gateway and Service Level Agreement (SLA) arbiter.

At the same time, we believe that our design philosophy is to cater to different user and LP preferences and present all available options in an unbiased manner so that both users and LP can choose according to their own preferences. This is why cBridge 2.0 also comes with the "SGN as shared liquidity pool manager" model, which is also intended to guide liquidity more quickly to achieve wider adoption of cBridge.

After all, it doesn't matter if a cat is white or black; A good cat is one who can catch mice.

Start the plan

Blockchain interoperability is the new frontier, as evidenced by the frequent hacking incidents in this area. We always hold system security to the highest standards and strive to keep our network security startup records unbroken.

So cBridge 2.0 will be rolled out in phases.

We plan to launch the "SGN as Shared Liquidity Pool Manager" model as the cBridge 2.0 Phase 1 test network in October, with at least two security audits of the system and smart contracts.

After testing the network and auditing, we will launch a $1 million bug bounty program and phase out the cBridge 2.0 mainnet.

After that, we will enter the "SGN as cBridge node gateway and Service Level Agreement (SLA) arbiter" mode as the second phase.

This article is submitted and does not represent the opinion of BlockBeats.  

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia