If you want more cryptocurrency analysis, including full-length research reports, trading signals, and social media sentiment analysis, use the code "Publish0x" when subscribing to CryptoEQ.io to make your first month of CryptoEQ just $10! Or simply click the button above!

Only secure as the weakest chain

In cross-chain scenarios, bridge contracts assume transactions executed on the other blockchain are valid based on the rules of that chain. Accordingly, users need to trust that another chain’s validators won’t collude, be corrupted/compromised, and that they can execute transactions and withdrawals at any time. This consideration is also before evaluating any additional trust assumptions introduced from an external relayer bridge.

Additionally, networks connected by a bridge but that don't have a shared state (i.e., EVM-to-EVM chain) entertain additional risk, specifically around finality on each chain. For blockchains, a transaction is considered final when the block containing it cannot be altered. However, the finality of the majority of blockchains (specifically, Ethereum, as it is involved in the majority of bridging activity) is probabilistic, not deterministic. That is, there is no set number of blocks, after which the block becomes immutable. It merely becomes ever more expensive with each additional block built on top of it, and thus less economically rational/feasible, for an attacker to alter the transaction. 

When a transaction is conducted on a source blockchain, an event is typically recorded and utilized to trigger a similar transaction on a destination blockchain. For a relayer to transfer an event on the source chain, the source chain transaction must be finalized. The destination chain must select the number of block confirmations required to feel comfortable that the block is final and security on the Ethereum base layer cannot be compromised. 

Assets that have been bridged from Chain A and “wrapped” on Chain B would suffer if chain A is 51% attacked and transactions are reverted. This would result in Chain B assets no longer being fully collateralized. In these scenarios, the bridge and bridged assets are only as safe as the weakest blockchain.

With L2 networks and rollups, bridge smart contracts don't make these same assumptions. They can verify that transactions executed on L2 are valid per the rules of Ethereum L1. Validation is executed by proving systems (fraud proofs and validity proofs) that can be checked on L1. Therefore, L2 users are far less exposed to the centralization risks presented by the validator sets of other chains or bridges. 

With an L1 rollup, a protocol only needs to deploy an asset once for default interoperability with all rollups. Rollups inherit the security of the L1 while featuring “escape hatches” that allow users to exit to L1 vs. being stuck on the destination chain if something goes wrong. Because of this, they need an exponentially cheaper security budget than creating your L1 or bridge with a validator set. Finally, rollups can store data on or off-chain depending on their need, creating flexibility in the design space and user experience.

However, interacting with any type of bridge carries risk (on both chains!):

• Smart Contract Risk — A bug in the code that can cause user funds to be lost
• Technology Risk — Software failure, buggy code, human error, spam, and malicious attacks can disrupt user operations
• Speed — If adequate liquidity isn’t available, users must wait until there is. This can be hours, days, or even weeks while the crypto markets continue to trade and funds are tied up

Moreover, since trusted bridges add trust assumptions, they carry additional risks, such as:

• Centralization/Censorship/Custodial Risk — Some bridges have a small set of operators that can censor and, in the worst cases, steal user funds.
• Poor security practices - Trusted third parties are human and make mistakes. As in the Ronin hack (discussed later), the Sky Mavis team had poor multi-sig security practices, and one individual was the victim of a social engineering hack.

MPCs

To this last point around poor security practices, some bridges utilize a Multi-Party Computation (MPC) strategy to reduce risk/colluision. Multi-party computation is a solution for securing data among several participants in a private manner. It allows many parties, each with their own private data, to verify the final computation without revealing their own secret portion of the data. Each participant in an MPC possesses a piece of confidential information. Typically, in the case of bridges, one entity owns one part of a cryptographic key that can move funds or change code.

MPCs are (generally) utilized when a bridging system has multiple and/or a permissionless relayer set and are looking to eliminate one bad actor as a single point of failure. MPCs shard a private key into many segments, with each individual possessing a portion of the private key. When signing a transaction, a subset of MPC nodes must independently sign the transaction and communicate then communicate it to the larger group. 

Even if a bridging protocol has a limited quantity of relayer nodes, the relayers can be chosen at random from the pool of candidates to create the multi-party computing (MPC) group. To authorize a cross-chain transaction, the protocol can require a minimum number of relayers to come together and sign the message before any action can be taken. The greater the threshold of an MPC group, the less likely it is that relayer groups will collude.

MPC also guarantees if a number of parties inside the group decide to disclose information or depart from the protocol's instructions during execution, the MPC will not allow them to coerce the honest parties into outputting an inaccurate result or leaking confidential information. 

Cross-chain bridge contracts that secure immense amounts of crypto in a single location—a source-side smart contract—are a single point of failure and honeypot for hackers. This is the reality of most cross-chain bridging today. 

General security questions that should be top of mind for any serious bridge user (or developer) include:

• Who has the ultimate authority/say on what transactions are valid? Who are the multisig signers/validators?
• Are there “backdoors” to upgrade or alter the mechanics of the bridge?
• How do validators communicate with one another? At what frequency? Is there an intermediary? Is it private/encrypted/hide revealing information like IP addresses?
• If it is a general-purpose cross-chain bridge solution, is each bridge connection isolated, or can one bug affect all chains? AKA, is there a risk of contagion?
• How many security audits did the project pass? Who are the auditors, and is there any bug bounty program live?