Cross-chain bridge, in short, is a technology that allows communication between two separate blockchain networks. Transferring and swapping assets, calling functions in contracts from other blockchains, and more. The evolving cross-chain ecosystem has allowed its users to get what’s best from specific blockchains. Some of the desired factors are:
- Reducing transaction fees and speeding up transactions’ confirmation process (which often comes with lower security and decentralization),
- Utilizing arbitrary functionalities which are accessible on different networks,
- Transferring assets to blockchains with larger liquidity pools.
However, bridges, like any early-staged component, introduce new threats to the system.
They also know substantial funds are crossing these intersections. With total assets estimated at more than $54 billion, decentralized finance (DeFi) presents an especially attractive target. Even before the BNB attack, crypto bridges featured in more than $1.6 billion of the $2 billion stolen from DeFi protocols in 2022. The magnitude and regularity of these exploits demonstrate why fallen bridges are gaining notoriety.
-
February: Wormhole – $375 million
-
March: Ronin Bridge – $624 million
-
August: Nomad Bridge – $190 million
-
September: Wintermute – $160 million
What makes cross-chain bridges so vulnerable? and what do we mean by security?
Security is the absence of risk. In our case, we understand risk as to the risk of a bridge relaying an invalid message. This includes not relaying a valid message like a valid withdrawal request. To put this into economic terms, a bridge is secure if it is not subject to economic attacks where the amount of funds required to compromise the bridge is less than the one required to compromise the underlying blockchains it connects.
Bridges are an attractive target because they often feature a central storage point of funds that back the “bridged” assets on the receiving blockchain. Regardless of how those funds are stored – locked up in a smart contract or with a centralized custodian – that storage point becomes a target. Additionally, effective bridge design is still an unresolved technical challenge, with many new models being developed and tested. These varying designs present novel attack vectors that may be exploited by bad actors as best practices are refined over time.
Types of Bridges
1. Rollups – can be seen as highly secure bridges. The validity of messages and resulting states can be proven on layer-1. They implement a light client on layer-1 that checks the validity of the state root from layer-2. That way, rollups have the fewest trust assumptions of all bridges. The bridge will only release the funds if there is a mathematical or cryptoeconomic proof of correctness. This proof happens on layer-1 and that way those bridges inherit the security of the layer-1 blockchain.
Examples: StarkGate, Arbitrum Bridge, Optimism Bridge
2. Optimistic Bridges – Those bridges optimistically assume that a relayed message or a bundle of relayed messages is correct until proven otherwise. However, the destination chain cannot check the actual validity of a message, but they trust that there is at least one honest watcher – who can check the validity and prove fraud on the source chain. A proposer proposes messages and a watcher can check the validity and step in if there is fraud. Because there is always the possibility that an honest watcher is secretly watching the bridge to prevent any fraud, an attacker can never be secure of succeeding, making any attack anti-economical. However, the security of Optimistic Bridges relies on the fact that there is a permissionless watcher set. If the watcher set is permissioned, in theory, all watchers could be bribed to collude.
Examples: Nomad/Connext, Across, NEAR Rainbow Bridge
3. The next category consists of bridges implementing a “consensus” light client. Consensus-checking light clients are less secure than Rollups as they can not validate if a block is correct – they trust the Miners/Validators of the source blockchain have agreed on a certain state. Basically, they check if a block is signed correctly and in the case of PoW they check the difficulty. That means a light client bridge assumes that the validator set of the source chain is not colluding. If the Miners/Validators are compromised, the bridge can accept an invalid block. However, if a block is accepted by the bridge, merkle proofs can be used to show that something happened on the source chain.
Examples: Cosmos IBC
4. Finally, we have bridges that rely on an external set of validators attesting to the validity of messages. It could be MultiSig, dynamic validator set with PoS consensus, MPC scheme, Intel SGX security box, Oracles, whatever. It is ultimately all the same category. The security of these systems relies on economic incentives. Most of them require validators to stake a certain amount of tokens that can be slashed if they commit any fraud. By design, there is no way to guarantee that they will act honestly once the amount of money a validator can steal from bridging becomes larger than the amount staked. Some bridges only use two parties – a relayer and an oracle – that are in charge of relaying and validating the message. In this case, if the system is permissionless, there is no way to guarantee these two actors will not collude together.
Examples: Multichain, Celer cBridge v2 (can be Optimistic by user choice), Layer0, Axelar, Wormhole, Polygon PoS
How can these types of bridges be secured?
Extensibility: where can you bridge to?
Human Problems
When conducting investigations we often talk things through with a project’s team members – because, often, they’re the target of exploits. Hackers rarely do anything totally new with every exploit, but instead rely on a series of age-old tricks
Social engineering, or targeting people in order to gain access to privileged accounts, is a classic case in point. People can be befriended and let their guard down or be badgered with enough questions that they reveal a secret.
We also see human limitations impacting the ability to create code fit for purpose. An ongoing developer shortage means there are just not enough experts capable of building and analyzing bridges. Looking again at the Wormhole incident, we see it was abetted by a coding glitch that let hackers set up a fraudulent signature set authorizing transactions to mint ether (ETH).
Bridges are soft targets – central points where large sums are stored without the robust protection – and will continue to be attacked. But we should bear in mind, it’s not just the bridges that are vulnerable; blockchains on both sides are put at risk by poorly guarded connections. It’s time to get educated and audited.
Education:
-
Consider taking a certified class in blockchain security.
-
Keep up to date with current affairs in the space.
-
When an exploit hits the news, do your own research. What can you learn that might benefit your own project?
Auditing:
-
Ensure the new bridge code is audited before release and then tested afterward.
-
Increase validator numbers.
-
Check regularly for false deposit events.
-
Set up a staff task force to focus on security
-
Consider using experts to undertake an audit. Ask if they use the latest cross-chain tracking tools.
-
Offering bug bounties will help you cover more ground.
-
Ensure smart contract addresses are continuously monitored.
How to secure your blockchain bridge?
No man is an island. Neither are blockchains. As the cross-chain systems are gaining more and more importance in the crypto world, there is a huge room for improvement for this technology in the security field. If one is developing a cross-chain protocol, remember about past attacks and stick to the requirements described in Smart Contract Security Verification Standard C6 Bridge chapter. Moreover, it is encouraged you not to forget about a brief conclusion of those attacks:
- Do not rely on a decentralized consensus algorithm if your infrastructure is not decentralized,
- Always validate and constrain users’ input.
- Restricting users from directly calling highly privileged contracts is not sufficient. Remember about cross-contract calls.
According to Vitalik Buterin, the future will be related to multi-chains blockchain ecosystem rather than bridges. As the main reason, he emphasized fundamental security limits that this mechanism has. It definitely expands the available attack surface, adding the additional level of complexity. Nevertheless, cross-chain adoption keeps increasing given the main course associated with protection improvements.
