Thread by @CelerNetwork

🙌🙌 #ELI5 continues 1/n We talked about TWO models of cBridge 2.0 yesterday and also dived into the design challenges for the self-managed liquidity model.

🧑‍🔧 Today is we start to break down the solutions. First, we start with the node coordination and operation issues.

2/n Previously, on cBridge 2.0 ELI-5

3/n cBridge 2.0 solves the coordination problem in the self-managed model with State Guardian Network (SGN). SGN, an essential component in Celer, is a specialized and decentralized PoS chain with CELR staking. Its general purpose is to relay information from L2 to L1.

4/n In Celer’s State Channel construct, it acts as a watchtower to ensure the security of channel states when users are offline. In the Celer layer2.finance rollup chain, the SGN extends as a decentralized block producer network.

5/n In cBridge 2.0’s self-managed model, SGN is extended as a decentralized gateway. When a user tries to bridge funds, her request hits SGN first and then SGN will “assign” this request to cBridge nodes with the goal to minimize the user’s fee for this transfer.

6/n This design makes the coordination between multiple independent self-custodial nodes very simple: there is no need to have a multi-round communication protocol (e.g. some kind of auction) with significant communication overhead and complex synchronization assumptions.

7/n This also offers great operation security benefits: there is no direct network connection into cBridge nodes nor any direct connection between users and nodes: the information rendezvous point is now SGN and other L1 chains through state query RPC.

8/n It means one can run a cBridge node without even having a public IP (on your home laptop or Raspberry Pi!) or behind a no-port-open network configuration.

9/n But wait, what happens if the SGN-assigned cBridge nodes act maliciously and refuses to serve the requests, i.e. griefing the user? Don’t worry! SGN continues to solve this issue and we will talk about how that works in the next ELI-5 thread!