Exciting proposal for sure. Mo from Celer Network here. I would love to introduce Celer and also respond to the questions listed here.
A quick introduction to Celer:
Celer is a generalized blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, and more across multiple chains. Developers can build inter-chain-native dApps using the Celer Inter-chain Message (IM) SDK 1 to gain access to efficient liquidity utilization, coherent application logic, and shared states. There are 10+ cross-chain applications live today that are built with Celer IM on various use cases including governance and liquidity network protocols. cBridge, a cross-chain asset bridge solution, has processed $12.2b transaction volume across 31 chains for 200K users.
How to build Uniswap’s cross-chain governance (with a focus on security models)
Celer IM based cross-chain governance is already live in production with FutureSwap since the end of April 2022 and has been operating flawlessly since. The reference implementation of cross-chain governance is very straightforward and we describe the high level flow here based on the application design pattern.
When a governance decision is made on Ethereum, the governance contract will call sendMessage of a “send box” contract which takes in the destination chain ids, message to be passed and destination contract addresses. The message will contain the serialized bytes of the governance decision.
This message will be synced with State Guardian Network, which is a Cosmos SDK based blockchain. Validators in SGN will witness the message and reach consensus on the Cosmos layer that this message indeeded exists and generate a stake-weighted multisignature attestation that is stored on the chain.
A message executor (can be run by Uniswap or run by validators of Celer Network) will collect this message and call executeMessage of a “receive box” contract. After necessary on-chain validation of the message, the message will be eventually relayed to the destination contract.
The validation, except for the generic checking of the validity of the signatures, also has two security models available to determine when the target contract will receive the message. The first security model is to directly pass the message on and rely fully on PoS security of the Cosmos chain.
However, in the case of low-frequency applications like cross-chain governance, we recommend using the second security model: an optimistic rollup-like security model. In this security model, every message that is passed onto the destination chain will be first put into a “quarantine zone” for a configurable period of time. During that quarantine period, every single validator in the SGN and the application executor (collectively, App Guardians) can monitor and cross-check the message arrived on the destination chain vs sent on the source chain. If there is any mismatch, the message path will be cut off immediately and the message will not be executed. This changes the security assumption from “trust majority stake” to “trust any” with app developers capable of running one of the “any” App Guardians themselves. This is how FutureSwap implemented their cross-chain governance module.
Once the quarantine clock times out, the message will be executed by calling a standard interface on the destination governance contract. This will complete the cross-chain governance process.
Next, we answer the questions raised in the post.
Does the bridge support arbitrary message passing?
Of course, this is the core of Celer, and all the cross-chain applications are built on top of this functionality. Celer currently supports arbitrary message passing on all EVM-based chains. For non-EVM chains, Celer supports Aptos, Sui, Flow and Cosmos-based blockchains.
Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?
This is briefly discussed in the previous walkthrough. Here, we provide a more detailed description.
As discussed above, Celer’s generalized message cross-chain solution comes with two security models and we recommend using the optimistic rollup solution here. More context on Celer’s security models:
Celer comes with two security models that each app and users are free to choose from on a per-tx basis.
- Cosmos-consensus Security Model
By default, inter-chain dApps rely on the security of the State Guardian Network (a Cosmos Chain) by processing messages routed from another chain without delay. The SGN offers L1-blockchain level security just like Cosmos or Polygon with it being a Proof-of-Stake (PoS) blockchain built on Tendermint with CELR as the staking asset. If a guardian acts maliciously, its staked CELR will be slashed by the consensus protocol. This level of economic security is something that grows with the staked CELR’s value and is simply not available in simple Multi-signature or MPC/PoA-based solutions.
- Optimistic-rollup-style delay buffer Security Model ( what should be used in this case )
So, what happens if more than two thirds (in staked value) of the validators behave maliciously in the State Guardian Network? Although this is highly unlikely given the economical security and distributed nature of the validators in Celer Network, Celer does have a second security model, inspired by the Optimistic Rollup design, that works securely even under this worst-case scenario.
Instead of instantly processing a message routed by the SGN, a two-phase commit-confirm pattern is used to process any inter-chain message. Before any application consumes the message, the message has to be “committed” to the blockchain by SGN into a “quarantine zone” for a period of time. Only after the delay has passed, can this message be “confirmed” and pushed to the final destination application.
During this delay buffer, a dApp can run an App Guardian service to double-validate the message on the source chain and check the authenticity of the message committed in the quarantine zone. If the App Guardian detects any inconsistency, it can prevent the message from being processed before the time buffer expires. For application developers who cannot run an App Guardian themselves, they can commission the SGN nodes to undertake the task of an App Guardian. In that case, the security model is strengthened to a trust-any model for the SGN. Therefore, even under the worst-case scenario of the SGN consensus failure, inter-chain dApps built on top of Celer’s construct will still maintain safety property without any concern.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is security provided by another third party entity?
When operating in the model of Optimistic-rollup-style model, the security is dependent on the source chain and on the “trust-any” model as described in the security model section. It does not depend on any single third-party entity or a majority of decentralized parties. As long as one single app guardian is still working in a trustworthy way, the system is secure.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
When operating in the model of Optimistic-rollup-style model, as long as there is still one app guardian that is trustworthy, it is not possible to have any fraudulent message to be passed to the destination chain.
This is very different from other models where when a majority (often 2/3) of validators/MPC signers are compromised, a fraudulent message can be passed to the destination chain.
What are the ramifications of fraud to the malicious actor?
Their CELR stake will be slashed.
Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?
Celer was audited by Certik, Slowmist and Peckshield. No vulnerabilities were identified in any of the audits. We also have a $2M standing bug bounty on Immunefi that is not claimed yet. Celer is the only cross-chain system that has processed more than $1b with no vulnerability exploited or identified.