10 Strategies for Cross-Chain Security

deBridge

Feb 16, 2022 • 5 min read

With one of the largest hacks in crypto recently involving a cross-chain bridge, our team at deBridge have decided to share some strategies and actions we’re looking into to mitigate security risks associated with bridges and cross-chain interoperability.

No two cross-chain bridges are designed exactly the same. These strategies are specifically for the decentralized, lock-and-mint type of bridge approach which includes the design of the deBridge protocol.

1. Validators incentives and slashing mechanism

Validators play a crucial role in interoperability protocols since in addition to being infrastructure providers, they also secure the protocol by validating all cross-chain transactions passing through the protocol. Validators work for and are elected by the governance and should bear financial responsibility for the service they provide through the risk of being slashed in case of validating a non-existent transaction or long downtime of the infrastructure. Anyone can help to secure the protocol by being a delegator and staking assets (e.g. ETH, USDC) for validators’ collateral. Both validators and their delegators receive part of the protocol fees as an economic incentive for helping to secure the protocol and maintaining its infrastructure.

2. Validation of consistency of the protocol’s state

Another important role of the validators is to continuously update the state of the bridged assets (deAssets) balances on each supported blockchain. They must never allow an asset’s total withdrawals to exceed its actual deposits, and it’s crucial to automatically pause validation for a chain if any asset becomes unpegged. Before signing any transaction, validators check the consistency of the protocol state by comparing the total balance (Sum of all token deposits minus sum of all withdrawals) calculated in the deBridge node for a chain with the actual supply of the corresponding deAsset at the moment of the transaction. They should immediately pause validation for the blockchain in case there are any differences between the states. This allows to localize any potential damage to the protocol within one specific network, and will not enable withdrawals of unpegged assets to any other chains.

3. Transaction finality rules

Interoperability and bridging protocols are middleware that depend on the security and specifications of the underlying blockchains. The most important metric for bridges is transaction finality in the blockchain where the transaction was initiated. The protocol should only confirm the transaction once it’s irreversible and achieved its insured finality, otherwise double-spending may occur when the sender receives an asset on the destination chain and gets back the deposit on the original blockchain. Validators have to wait for a certain number of block confirmations according to the social consensus or official specifications for each specific chain (e.g. 11 block confirmations for Ethereum and BSC, 128 block confirmations for Polygon, or 1 confirmation from the sequencer in Arbitrum). In case a significant amount is passed through the protocol within a short block range, validators can strengthen the finality rules. This can be proportional to the current liquidity flow e.g. require 11 block confirmations on Ethereum in case the liquidity flow is below $2M and 20 block confirmations in case it exceeds $10M.

This approach will make any potential 51% attacks on bridges expensive since the attack will have to be performed over a longer time span.

4. Validation of nonce sequence

In all supported blockchains, deBridge smart contract assigns a unique sequence number to every transaction passing through the protocol. This number is called “Nonce” and it helps to avoid double-spending and adds an additional layer of protection against chain reorgs and 51% attacks. Validators must always confirm transactions in ascending order of the nonces and any nonce collisions make validators immediately suspend validation for this blockchain as any nonce duplicates mean that something unusual happened (reorg or 51% attack), that goes beyond specification.

5. Off-chain validation

For all bridging protocols, it’s important to have a chain-agnostic design and make the protocol operation fully independent of the uptime of all supported blockchains. In case of the stop of any underlying blockchains, the protocol should keep processing the transactions for all other chains. deBridge achieves this setup thanks to off-chain validation as validators don’t need to broadcast any transactions and bear gas costs, but just sign a unique identifier (hash) of the transaction and store the signatures into IPFS. Anyone can claim transactions on the destination chain by retrieving validators’ signatures and passing them to the smart contract together with all transaction parameters needed to let the smart contract restore the hash. With this design, even if a blockchain would go offline, all transactions going to this blockchain will be processed as soon as it’s up again.

6. Validation of unusual transactions

Let’s imagine that a protocol has $500M of liquidity locked in the form of USDC and some transaction appears that transfers80% of the total supply ($400M) of the wrapped asset in a single transaction. The probability of the existence of such a transaction is close to zero and even in case all the state validations have passed, additional validation checks for the transaction should be performed by the validators.

7. Excess confirmations

Besides the above-mentioned security measures implemented in the deBridge node, there are additional security checks developed on the smart contract level to make it difficult for validators to get into collusion. Normally 2/3 (e.g. 8 of 12) validators signatures are needed to have transactions executed on the destination chain, but in case the transaction amount exceeds the threshold value assigned by governance, or in case there are too many claims in one block, the protocol will automatically require 2 excessive confirmations (10 of 12) in order to make sure there was no collusion of validators.

8. Validators scaling

Validators’ signatures can be sharded and formed using ECDSA threshold signature or fusion algorithms that allow one EOA address to be controlled by multiple validators and each signatory has its own secret phrase. This approach allows unlimited scaling of a set of validators keeping gas prices at the same level as only 12 signature verifications are needed by the smart contract while the number of validators can be arbitrary.

9. Audits

In addition to security measures laid into the protocol design, there are additional steps such as audits and bounty programs that can be performed to minimize the risk surface. Any blockchain security audit firm worth their salt should be able to mitigate various smart contracts bugs and vulnerabilities. The deBridge protocol has been audited by Halborn, Zokyo, and Ackee Blockchain (with more being announced in the near future) — Tier-1 security auditors in the space.

10. Bug Bounty

A bug bounty program is a great way to work with whitehats and experienced developers in the space to find potential vulnerabilities and exploits. There’s an ongoing bug bounty program on Immunefi to double down on our security efforts. As security is our main priority, we invite developers to help review the code during the early stages and to facilitate protocol security. Our main focus is the security of user funds, even if it means sacrificing full uptime. While we do our best to ensure uptime, users could expect downtime and outages in the early days, which will gradually decrease over time.

In conclusion, cross-chain interoperability is complex and hard, and it takes time to build a secure and reliable protocol. We believe that cross-chain security is an ongoing effort for projects to dedicate their time and efforts towards, and we’ll keep our community updated based on the industry’s best practices.

About deBridge

deBridge is a cross-chain interoperability and liquidity transfer protocol that allows the decentralized transfer of assets between various blockchains. deBridge protocol is an infrastructure platform and hooking service for:

Cross-chain composability of smart contracts
Cross-chain swaps
Bridging of any arbitrary data and assets
Bridging of NFTs