The evolution of blockchain technology has led to the emergence of bridges, initially designed to facilitate the transfer of assets such as native cryptocurrencies and tokens from one chain to another. This development has paved the way for a plethora of cross-chain Web3 applications, including cross-chain DeFi applications. Bridges in the blockchain space continue to grapple with the persistent issue of hacking. As Ethereum co-founder Vitalik Buterin has noted, bridges face "fundamental security limits." The more critical and higher volume a bridge becomes, the more appealing it is as a target for hackers due to the potential for substantial rewards. One of the most significant vulnerabilities lies in improper key management.
Key Management
Keys are crucial as they typically safeguard the essential functions of minting or unlocking assets. If these keys are compromised, it can lead to the unauthorized minting of tokens or the withdrawal of all locked tokens. To mitigate this risk, multisigs are often employed, where funds are protected by multiple keys, and a subset of these keys is required to authorize transactions.
However, the effectiveness of multisigs can be undermined if operators degrade the multisigs to a single key, as was the case with the Ronin bridge used by the Axie Infinity game. Initially, the Ronin bridge was protected by a 5-of-9 multisig, requiring any five out of nine key holders to sign a transaction. However, four of these keys were controlled by Sky Mavis, the developer of Axie Infinity, effectively reducing the security to a 2-of-6 multisig. This situation was further exacerbated when the Axie DAO, which controlled another key, granted access to Sky Mavis, effectively making it a 1-of-5 multisig. This meant that a single security breach could compromise the entire bridge.
Validation
Another common vulnerability lies in insufficient validation of transaction parameters. This was evident in the case of Multichain (formerly known as Anyswap) and its bug in the function that enables a swap without the correct permissions. The function did not validate the token parameter, and the attacker was able to pass the address of a previously deployed malicious contract, which returned the Wrapped ETH (WETH) address in the underlying function.
The case of THORChain's bridge (Bifrost) hack illustrates the complexity of building multi-stack applications. The vulnerable part of the bridge was built on CosmosSDK, and its purpose was to parse transactions sent to a specific contract on the Ethereum network and generate corresponding transactions in THORChain. However, the code assumed that all transactions were direct transactions to the bridge contract. The attacker exploited this assumption by preparing a contract that sends back the received value and makes an internal transaction to the Bifrost contract. This bug allowed the attacker to fake deposits on Ethereum and withdraw the free tokens on THORchain.
Are Upgradeable Smart Contracts the Answer?
The immutability of smart contracts is a double-edged sword; on the one hand, it assures all parties that not even the creator can amend the contract post-deployment, fostering trust in the system's integrity. On the other hand, it precludes the rectification of unforeseen security flaws or the implementation of enhancements, potentially leaving the door open to risks as the contract remains static in a dynamic digital environment.
Enter the concept of Upgradeable Smart Contracts (USC), which emerges as a salient solution to this rigidity. By design, USC introduces a mechanism for post-deployment modifications, presenting a suite of advantages while maintaining the decentralized ethos of blockchain technology.
The primary merit of USC is the enhancement of security protocols. It enables developers to address vulnerabilities expeditiously, ensuring the robustness of the contract over time. The addition of new features is another significant benefit, permitting teams to augment and refine their offerings in response to market demands or technological advancements without the need to deploy an entirely new contract. This adaptability is critical in the rapidly evolving landscape of DeFi.
From a cost perspective, USC is a boon for developers and users alike. Upgrading an existing contract conserves the network's computational resources, translating to lower gas fees—a consideration of paramount importance given the current concerns over the scalability and efficiency of blockchain networks.
Moreover, USC upholds data consistency, a critical factor for user confidence. During an upgrade, integral data, such as user balances, remains intact, obviating the need for data migration—a process often fraught with complexity and risk.
The user experience also benefits considerably from USC. With a single, unchanging contract address, users enjoy simplified interactions with the contract. This consistency is not merely a convenience; it represents a reduction in the fragmentation of services and addresses, thereby minimizing the potential for confusion and errors in a field where mistakes can be costly.
However, the concept of upgradeability has emerged as a double-edged sword. On one hand, it allows for the continuous improvement and adaptation of protocols to meet changing needs and circumstances. On the other hand, it introduces a new attack surface that, if not properly secured, can lead to the total collapse of a project.
Consider the case of the Nomad bridge, a protocol that utilizes the Merkle tree structure to track all valid cross-chain transfers. In this system, users must first prove that a specific transfer message is included in the tree, using a Merkle tree path that results in a root assigned to the message. The process function then verifies that this root is one of the previously confirmed acceptable roots. This system worked as expected until June 2022, when the Nomad Replica contract was upgraded. During this upgrade, a bug was introduced. The implications of this action were significant: anyone could now process non-proved messages, as their initial roots were zero, which was now an accepted value.
In conclusion, the management of upgradeability and authorization in Web3 projects presents significant challenges and risks. The examples of the Nomad bridge and Chainswap highlight the potential for security vulnerabilities and the importance of robust security mechanisms. As the Web3 landscape continues to evolve, it is crucial for developers and operators to remain vigilant and proactive in their approach to security, ensuring that their projects can adapt and grow without compromising the trust and safety of their users.
Or Maybe Universal Settlement Bridges (USBs)?
Three key challenges need to be addressed to enhance the security and efficiency of bridges: liquidity, cross-chain finality, and cross-chain security. Interestingly, these issues can essentially be addressed through a single solution: Universal Settlement Bridges (USBs).
USBs leverage one of the largest liquidity pools, stablecoins, as the settlement layer. This eliminates the need for liquidity pairs for each swap, a concept similar to Thorchain's settlement system, except that it relies on stablecoins instead of RUNE as the settlement layer. In this scenario, liquidity is not a concern since the 'bridge,' which requires stablecoin liquidity, is its own stablecoin issuer.
Cross-chain finality, another significant issue with cross-chain swaps, arises from the fact that all swaps are not instantaneous and are constrained by the receiving chain's finality. This problem can generally be solved if the bridge or liquidity provider is willing to relax security constraints in exchange for a faster transaction, although this introduces risk. However, it becomes far easier to scale in a trust-minimized and efficient environment if the stablecoin issuer, rather than the bridge, bears the finality risk. This is particularly true given that slippage may occur during the cross-chain transaction. Using a stable asset as the settlement layer involves less slippage since there is less value variance to account for.
From a technical perspective, the way the stablecoin issuer decides to build their bridge will influence how one considers the added security concerns of cross-chain transactions. The options range from a Zero-Knowledge (ZK) solution to an oracle-type solution similar to LayerZero. Economically, if one is already comfortable with the centralization risk of Circle or Tether, then any stablecoin bridge solutions, which are likely semi-centralized in practice, will simply inherit the existing trust assumptions and be no more or less secure. In fact, one could argue that a centralized stablecoin issuer would be practically obligated to cover any hacked capital, considering USDC as a tokenized receipt for deposit tokens.
