Bridges are used to move digital assets from one blockchain to another and are a foundational concept for interoperability. Unfortunately, they are frequently cited as a significant vulnerability point in large-scale hacks and theft. This doesn’t have to be the case, bridges can be designed securely if the right architecture and protocols are in place, explains Dr Luke Riley.
Blockchain bridges connect separate blockchain networks. They work by moving a digital asset and its associated information – a token, stablecoin, cryptocurrency or NFT – from one blockchain to another. Bridges can also facilitate the transfer of assets between the so-called layer 1 blockchain networks (which are standalone) and layer 2 blockchain networks (that are reliant on layer 1 networks).
Bridges can vary in complexity. It’s easiest to build a bridge to connect two networks of the same distributed ledger technology type, such as moving an ERC-20 token from Ethereum to Polygon, which are both Ethereum-based. However, it becomes more challenging when bridging between different DLT types, such as moving assets from a Hyperledger Fabric network to a Corda network.
Why bridges carry risk
Blockchain technology has many clear advantages over centralised database technology. Its distributed nature provides cryptographic security, data transparency and near-frictionless transaction potential. DLTs use trust minimised technology; all parties involved are assumed to be potentially malicious and so interactions are continually authenticated and validated.
DLTs are also exceptionally robust – to attack a major blockchain network is extremely difficult due to its distributed and decentralised nature. To perform a successful attack, you would need to strike most nodes on the network simultaneously. This so-called ‘majority attack’ would usually (dependent on network size) prove extremely costly on proof-of-stake blockchain networks, and require massive amounts of energy/computational power on proof-of-work blockchain networks.
Yet bridges have fewer participants and operators than major blockchain networks, and therefore offer more vulnerabilities for attack. Bridges are typically designed with smart contracts on both the origin and destination blockchain. This smart contract code is often written by a small number of developers, and might not be thoroughly checked, tested, or validated by high-quality third-party experts. Therefore the resulting smart contracts may have bugs and vulnerabilities that are open to exploitation.
Bridge attack methods
There are two common ways to attack bridges. The first one requires the attacker to find a bug in the related smart contract code and exploit that. This weakness was played on in the 3 February 2022 wormhole attack between the Solana and Ethereum networks, resulting in a loss of 120,000 wrapped Ether tokens worth about $375m.
Another way is to steal private keys through weaknesses in their off-chain infrastructure, such as via the bridge‘s use of hot wallets (private keys connected to running code). This is what happened in the 29 March 2022 attack on the Ronin network that lost 174,000 Ether and 26m USD coins worth $540m. In this incident, five validator private keys were hacked, which enabled the hacker to take control of the bridge.
Considerations for secure transfer
Bridges commonly move assets using a ‘lock and mint‘ flow. This is where tokens are sent to a specific ’escrow’ address on the origin chain. The tokens remain locked there while a representative version of this token is minted (created) and continues to exist on the destination chain. Users can reclaim these locked tokens by burning (destroying) the representative version on the destination chain. Therefore these escrow addresses attract more and more liquidity, effectively creating a ‘honeypot‘ for a possible attacker. There have been instances where the hacker unlocks the original tokens from this escrow, if they identify exploits in any associated smart contact code or if they hack the associated private key(s) from the bridge’s off chain infrastructure. If a successful attack occurs, the wrapped tokens on the destination chain then lose their value, as the peg is broken between the locked funds on the origin chain and the minted funds on the destination chain.
One way for safer digital asset transfers is to use a ‘burn and mint’ flow so that only one version of the token exists at any time. The token is burned on the origin chain, and then minted on the destination chain. This can work if the bridge owner controls both sets of token contracts on the origin and destination chain. This method is commonly used to transfer assets from permissioned (restricted to only certain individuals) to permissionless (open to anyone) blockchain networks. The ’burn and mint‘ flow does not require the use of an escrow address on the origin chain and therefore removes this honeypot attack problem.
Another good bridge design feature is to use trusted execution environments – hardware and software isolated from other parts of the blockchain ecosystem to store private keys. This type of ringfencing is best practice in many IT architectures, not just blockchain. Trusted execution and custody environments add another layer of security for asset transfer and are an essential component for enterprise-grade DLT environments.
An additional security consideration for a multi-organisational bridge is to use a threshold signature scheme instead of a multiple signature (multi-sig) scheme. For multi-sig, a signature must be collected from each organisation, and packaged up into a transaction, which increases the transaction data payload size (costing more in transaction fees). In this case, usually the transaction needs to be signed again by a designated transaction sender. This transaction then commonly requires the multi-sig to be verified in a smart contract, which has the potential to introduce software bugs that can be exploited. A threshold signature scheme can offer an advantage as it only requires a partial signature from each organisation. These partial signatures are collected and becomes the single transaction signature (the transaction sender’s signature) to be verified by the blockchain nodes themselves (i.e. no smart contract signature verification is needed in this case). Therefore the threshold signature scheme presents fewer possible vulnerabilities than the multi-sig process.
Finally and importantly, we recommend that all smart contract code be thoroughly tested and externally validated. Best practices for cybersecurity and the use of continuous development and improvement processes can help ensure that bridges are safe, secure and fit for purpose.
International standard development
Quant is leading the space in international standard development for asset transfer bridges. We are a key contributor to the Internet Engineering Task Force (IETF) Secure Asset Transfer Protocol (SATP), which aims to standardise digital asset transfers from one network to another. We invite interested parties to join this group. Further information can be found here.
