Cross-Chain Bridge Assessment Process

9

Integration of deBridge Adapter into Multi-Bridge Implementation

In deBridge, we’d like to express our support for a multi-bridge Implementation developed by Celer team. We made a pull request (PR) where developed an adapter that adds support for deBridge infrastructure into the proposed multi-bridge framework.

To test out integration, we performed a mainnet deployment of all smart contracts in BNB and Polygon Chains and made a test updateQuorumThreshold() operation initiated in the MultiBridgeSender contract in BNB Chain and successfully settled in the MultiBridgeReceiver Polygon.

Transaction details can be found in deBridge explorer.

The source code and additional details are available here:
https://github.com/celer-network/sgn-v2-contracts/pull/232

We would like to encourage all bridge teams that support multi-bridge Implementation to make similar pull requests, adding their bridge adapter to the framework

Advantages of multi-bridge implementation

Beyond what was previously mentioned by @modong, there are a few more benefits to the multi-bridge approach:

  1. In order to add an adapter, every bridge team will have to perform a code review of the developed implementation. This helps to improve security by having more pairs of eyes on the code.
  2. Each bridge team should perform the integration and develop the adapter before the start of the assessment process, that allows the assessment team to use the source code and deployed implementation of the adapter to better understand the design of the bridge and review how integration will work in practice.
  3. The multi-bridge solution is versatile and can increase security, even for blockchain ecosystems with a canonical bridge, which is just one of the bridges participating in the framework. In the event of a problem or vulnerability in the canonical bridge, malicious messages or proposals can be prevented as confirmations from non-canonical bridges are still required.

Community feedback

I also wanted to comment on the following points which @Kydo raised above:

  1. The multi-bridge solution turned out to be relatively simple and not much different from vendor-locked integration. Complexities of each specific bridge integration are abstracted into adapters that are developed by each bridge team who wants to join the framework.
  2. Like with a single bridge integration, the code should undergo thorough testing by the community and pass security audits.
  3. The advantage of the proposed solution is that standardization is achieved through adapters developed by each bridge team, providing a standardized approach across all bridges.

We’d love to hear feedback from @kydo and other community members on potential risks and problems of proposed implementation as well as ideas of what can be improved.

Request for Code Reviews and Security Audits

Code reviews and security audits for the solution would help to assess security risks of the developed implementation.

If no significant issues or requests for improvements are identified within next 7 days, we will be ready to initiate and cover the cost of a security audit by Halborn.

3 Likes