🙌🙌 #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.
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!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Tl;dr 🧵 on how Celer's Brevis @brevis_zk works.
💪1/ Brevis is a powerful system for omnichain data access in dApps with key components: zkFabric, zkQueryNet, and zkAggregatorRollup. Benefits include trust-free access, low-cost, and modularity. blog.celer.network/2023/03/21/bre…
🌉2/ zkFabric collects block headers from connected blockchains and generates ZK Consensus Proofs for validity using zk light client circuits. A decentralized network of relayers and provers ensures trust-free access to block headers.
🚀 3/ zkQueryNet is an open marketplace of ZK Query Engines for dApp developers. Write queries via high-level APIs and query languages directly in smart contracts & select the engine that fits your needs. Flexible, powerful, and trust-free.
🤔When building a next-gen ZK infrastructure, one must select a suitable ZK dev framework from the many available options
🏦To make this easier, we're launching the Pantheon of ZKP to help build a ZKP dev framework testbed with a diverse set of benchmarks blog.celer.network/2023/03/01/the…
🧪Today we take the first step by providing a comprehensive benchmark using a SHA-256 workload for low-level circuit frameworks including gnark, Arkworks, Circom+snarkjs/rapidsnark, Halo2 (KZG), Plonky2 and Starky
🤗We invite the community to share reproducible benchmarking results and work together towards a universally recognized evaluation testbed that covers the full set of low-level circuit development frameworks, high-level zkVMs and compilers, and hardware acceleration providers
📢(1/n)A DNS cache poisoning attack on cBridge’s frontend UI appprox. during 08/17 07:45pm to 10:00 pm UTC caused some users to be redirected to malicious smart contracts that can drain all approved token amount. FIRST, PLEASE check&revoke any approval to the followings:
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.
🎉🥳#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.
🙌🧐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!
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.
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.