Hi everyone, I’m Alex — co-founder of deBridge
Since BNB Chain doesn’t have any canonical/trust-minimized bridge, I’d like to suggest using deBridge as a secure solution to execute and relay any Uniswap governance decisions from Ethereum to BNB Chain.
deBridge Overview
deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.
A transaction through deBridge’s architecture passes through two key layers:
-
Protocol Layer (on-chain) – a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and list of validators, are managed by deBridge governance.
-
Infrastructure Layer (off-chain) – nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.
According to the cross-chain Deployment Proposals Framework, here are answers to the Bridge Security questions in the context of deBridge:
Does the bridge support arbitrary message passing?
Yes, deBridge infrastructure supports any message transfers and has delivered 126,000+ messages since its launch in February 2022. Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deExplorer
Is the bridge secured by a trusted entity, by a multi sig, or by a protocol/set of incentivized nodes?
Validation of any cross-chain transactions goes down to social consensus around forks. That’s why canonical or trust-minimized bridges based on light or full clients are possible only between two blockchain ecosystems (normally L1 and L2) as if there is a fork in L1, then there is a fork in L2 and users can always pick which of the forks to use.
Non-canonical interoperability layers and bridges can’t be fully trustless by their nature, due to the need to have a validation layer that should at least determine which of the forks is valid and supported by the community, so it’s all a matter of how this validation layer is implemented.
Different protocols have different implementations, such as:
- Oracle and relayer model
- Optimistic approach
- Zk or Succinct proofs
- Set of validation nodes
deBridge validation layer uses a “delegated staking and slashing” with a set of validation nodes, optimizing for security and speed. All validators are elected by and work for deBridge governance. To be confirmed, a transaction must be signed by at least ⅔ of the validators, i.e., 8 out of 12. The validators are disincentivized to act maliciously as they bear financial risks through a delegated staking and slashing module.
deBridge plans to scale its validator set, increasing the threshold of signatures required for message validation, and thus enhancing the protocol’s overall security.
Thanks to off-chain validation, the validators don’t need to communicate with each other, thus their IP addresses are never exposed, increasing the overall security of the infrastructure.
Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity?
As described in the previous paragraph, any bridges and interoperability layers (except canonical ones) have to rely on the validation layer. deBridge leverages professional infrastructure providers to validate cross-chain messages passing through deBridge protocol.
Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?
In order to forge a message, ⅔ of deBridge validators would need to collude and each one would need to provide a signature of the malicious message identifier. deBridge validators are professional infrastructure providers that validate many other protocols and blockchains. All validators bear reputational and financial risks
What are the ramifications of fraud to the malicious actor?
The validators are disincentivized to act maliciously as they bear financial risks for their service as per the delegated staking and slashing module.
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?
Security has always been the top priority for our team. deBridge and its’ periphery modules have been audited 17 times by Halborn, Zokyo, Ackee Blockchain, and Neodyme. Additionally, deBridge offers a $200,000 bounty program on Immunefi. All the findings and remediations can be seen in the published security audit reports available in the public Github repository
Additional resources:
Documentation portal
Developers portal
deBridge explorer
deBridge team will be glad to facilitate the development and security audit of all smart contracts needed to relay and execute Uniswap governance decisions from Ethereum to BNB Chain. If deBridge is chosen as messaging provider, our team will cover costs for the security audit, performed by our long-term security partner Halborn
We welcome any questions about deBridge in the comments below