🙌🧐1/n cBridge 2.0 is the first and only cross-chain architecture that allows Liquidity Providers to freely choose between the "self-managed" and the "pooled-together" liquidity models. Today, we talk about some fun design challenges. We will unveil solutions in the coming days! Image
2/n Under the self-managed, a.k.a "non-custodial", model, LPs hold full control of their liquidity 100% of the time. To make this possible, each LP also needs to run a cBridge node "program" in a server so that they can respond to users' asset cross-chain requests. Image
3/n Self-managed model has the very obvious benefits of not needing to trust any centralized or decentralized third parties. However, this is also a double-edged sword. Image
4/n First, for LPs, the barrier of entry of operating a bridging node is quite high: the LP needs to: 1. maintain a safe "hot wallet" env for the private key; 2. ensure operational reliability; 3. manage external RPCs for chains; 4. manage liquidity; 5. tune fee profile; etc. Image
5/n Second, from the perspective of the entire bridging network, when a user request comes in, how does the system decide which cBridge nodes to use? Do users have to "talk" to potentially different nodes and have back-and-forth complex interactions? Image
6/n Then third, there is the "Griefing Problem". Where the selected bridge nodes just "vanish" and refuse to serve users' requests. Users then have to wait for a very long timeout while having funds locked up and there is no promise he won't be griefed again. Image
7/n Or the same thing can happen for users, but the problem is that, due to the isolation of information between two different chains, there is no way to tell who is the actual bad guy from any single-chain state. Image
8/n cBridge 2.0 makes LP's life much easier for problem #1 and solves #2 with simplicity and provides the world's first solution to #3 with high efficiency, all with a construct called State Guardian Network. Wanna know more details? Stay tuned for tmr's thread! Image
9/n Now, remember cBridge 2.0 architecture also supports a pooled together liquidity model? It is designed for LPs who want to pool together their funds to provide liquidity for the network without running bridging nodes but with high efficiency, security, and simplicity. Image
10/n cBridge 2.0 architecture integrates these TWO models seamlessly to provide users with the best service and LPs with the utmost flexibility. The pooled-together model surely comes with tradeoffs and we will dive into that soon. For now, gn/gm! Image
11/n For more details, you can always refer to blog.celer.network/2021/09/22/cbr…

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with CelerNetwork

CelerNetwork Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @CelerNetwork

29 Oct
In locally verified bridges, since liquidity is also self-managed by the relayers themselves, there is additional complexity in node scheduling and handling griefing as mentioned below (malicious relayer locks user fund). Celer cBridge 2.0 is the first to solve these challenges.
Read 5 tweets
15 Oct
🎉🥳#TGIF and it is ELI-5 time! Today, we talk about the last topic for the self-managed model for cBridge 2.0: how cBridge 2.0's design provides the first-ever solution to the "griefing problem" in the non-custodial bridging system using the Celer State Guardian Network. Image
1/n So what is “griefing”? In the self-managed bridging model of cBridge 2.0’s two models, two steps are always needed for the cross-chain transaction to happen for both the bridge nodes and the user in the following sequence.
2/n Step 1 for the user: make a “time-locked” transfer to the bridge node on the source chain, where only she has the key to unlocking this transfer.
Step 1 for the bridge node: make a locked transfer to the user on the destination chain, using the exact same lock as the user. Image
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(