🎉🥳#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.
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.
3/n Step 2 for the user: unlock the transfer on the destination chain to get the fund from the bridge node.
Step 2 for the bridge node: seeing the key to the lock on dst chain, she can then unlock the transfer on the source chain to get the fund from the user.
4/n Griefing happens when bridge node refuses to do step 1 after user did step 1, or the user refuses to do step 2 after the bridge node did step 1, either due to system fault or malicious intent.
5/n Griefing will not result in fund loss but will cause funds of users or bridge nodes to be stuck in the system and wait for a very long timeout. The challenge is that, in both scenarios, events are happening on different chains and it is impossible to tell who is at fault.
6/n We need some decentralized entity that can act as the “arbitrator” of this griefing challenge. Because SGN is allocating the requests for the users and it can track the entire lifecycle any cross-chain transfer, it is very easy for the SGN to tell who is actually at fault.
8/n In cBridge 2.0, after the arbitration, SGN can slash “SLA” bound from the faulty party to compensate the opportunity and time cost of the damaged party. SGN can only touch a pre-defined amount of bond at maximal, so there is no loss of non-custodial property.
9/n That concludes our walkthrough of the self-managed model of cBridge 2.0. What's coming next? We will talk about the detailed design in the pooled together model soon!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.