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.

🤔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

📢(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: Ethereum: 0x2A2aA50450811Ae589847D670cB913dF763318E8
BSC: 0x5895da888Cbf3656D8f51E5Df9FD26E8E131e7CF
Fantom: 0x458f4d7ef4fb1a0e56b36bf7a403df830cfdf972
Polygon: 0x9c8b72f0d43ba23b96b878f1c1f75edc2beec9f9
Avalanche: 0x9c8B72f0D43BA23B96B878F1c1F75EdC2Beec9F9

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.

https://twitter.com/0xangelfish/status/1454120116862414854

For griefing challenge:

https://twitter.com/CelerNetwork/status/1449146677558857731

🎉🥳#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.

🙌🙌 #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

https://twitter.com/CelerNetwork/status/1447415169328451585

🙌🧐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.