You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
Blockchain bridges serve a simple yet crucial function: they facilitate the transfer of messages from one database to another, acting as a communication protocol between a sender and a receiver. However, the current design of these bridges, which relies heavily on trusted authorities, is at odds with the fundamental ethos of the cryptocurrency movement, which seeks to eliminate the need for trust through cryptographic proof. This article explores the challenges and potential solutions in the quest for a more secure and trustless bridge design.
A well-functioning communication protocol, such as a blockchain bridge, aims to ensure timely delivery, integrity, and authentication of messages. The receiver should be able to access the message as soon as possible, receive the message in its entirety, and verify that the message was indeed sent by the sender. Unlike many communication protocols, however, blockchain bridges do not typically strive to protect the confidentiality of the message.
The primary challenge that a bridge must address is the attestation process, which involves convincing the receiver of the message's authenticity. In most bridge designs, a set of authorities sits between the sender (Database A) and receiver (Database B), which could be smart contracts residing on the respective databases. These authorities are responsible for fetching new messages from Database A, digitally signing these messages, and sending the digital signature and message to Database B.
The receiver database (Database B) must then verify that the message was indeed digitally signed by the trusted authorities. If this verification is successful, the receiver can be confident about the message's content and origin. However, this process requires both the sender and receiver to place blind trust in the appointed authorities, as they cannot view the outside world without third-party assistance.
This design, which could be termed a human-operated bridge, relies on humans (or server-side applications) to facilitate communication and enforce rules on behalf of the sender and receiver. While this design is easy to deploy and can be applied to a wide range of blockchains, it is challenging to secure and protect at scale.
The reliance on trusted authorities contradicts the core principle of the cryptocurrency movement, initiated by Satoshi Nakamoto, which seeks to eliminate the need for trust through cryptographic proof. As we continue to innovate in the blockchain space, we must strive to develop bridge designs that align with this principle, replacing trust with cryptographic proof to ensure secure and trustless communication.
Bridges allow end users and Web3 protocols to transfer assets or make cross-chain function calls. However, this would not be possible without an infrastructure that monitors the source chains and relays the transfers and calls on the destination chain. Typically, this relaying infrastructure is operated by trusted third parties with immense power, including minting or unblocking assets and making authorized function calls.
When constructing a risk framework for bridges, it's important to consider several key factors. First, the security of the bridge itself is paramount. This includes the robustness of its code, the security measures in place to protect against hacking or other malicious activities, and the transparency of its operations.
Second, the stability of the bridge's underlying technology is a crucial consideration. This includes the reliability of the blockchain networks it connects, their susceptibility to congestion or other technical issues, and the potential impact of these issues on the bridge's functionality.
Finally, the economic factors surrounding the bridge, including the liquidity and volatility of the digital assets it facilitates, can also contribute to its risk profile.
By considering these factors and understanding the potential worst-case scenarios, investors and users can make more informed decisions about using different bridges in the cryptocurrency space and look to avoid certain kinds of risks.
Some risks associated with trusted bridges include:
- Financial Risks: These primarily involve the potential loss of funds, often due to malicious activities or systemic failures. Examples include collusion by oracles, relayers, or validators to submit fraudulent proofs, such as block hashes or validity proofs, or to relay fraudulent transfers. Other risks involve the compromising of validator or relayer private keys, the illicit minting of new tokens by validators, and the successful submission of false claims. Additional risks could emerge from a reorganization of the destination blockchain following the passing of an optimistic oracle/relayer dispute time or from the presence of malicious code or abusable functionality in unverified contracts linked to or used by a protocol. Furthermore, risks may arise when token bridge owners act maliciously or execute time-sensitive emergency actions without adequate communication with the user base.
- Functional Risks: These relate to the freezing of funds, which could occur if relayers or liquidity providers fail to act on user transactions. Risks can also arise from a pause in protocol contracts, the receipt of a malicious code update by protocol contracts, or a lack of sufficient liquidity in the target token on the bridge.
- Censorship Risks: These are typically associated with oracles or relayers failing to facilitate a transfer on either the source or destination Layer 2 solutions or from a pause in protocol contracts.
Additionally, the way a bridge handles assets can affect whether or not it requires liquidity providers. If the bridge allows the withdrawal of the token on the destination chain, which the bridge operators do not mint, the liquidity providers must deposit it first. On the contrary, if the bridge mints its wrapped version of a token, the liquidity is not required, but the minted token is, in fact, a different one from the originally bridged token (a wrapped bridge token) and might not be as widely accepted in applications as the original one.
Bridge Hack Examples and Causes
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 multiple keys protect funds, 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.
Another significant case of leaked private keys involved the Harmony Bridge. Although details are scarce, it is known that two keys were leaked, and the US officials have attributed this to the Lazarus group. Harmony's team stated that these keys were doubly encrypted using a passphrase and a key management service. However, the exact method of the leak remains unknown.
At its core, while multi-sig is better than trusting one individual, these setups still have risk and rely on humans. These wallets, requiring multiple individuals to authorize a transaction, introduce an added layer of security to the bridge mechanism by preventing a single signer from exerting unilateral control. Multisigs often play a pivotal role in enabling upgrades or pauses in bridge contracts, thus serving as an essential control mechanism. However, multisigs are not impervious to risks despite their importance and necessitate meticulous management.
Multisig wallets function as smart contracts and, like any contract, are susceptible to potential exploits. These contracts, having managed billions in assets over time, have undergone rigorous testing in real-world scenarios. However, they still represent an additional vector for attacks. The complexity and inherent features of these contracts could be exploited, posing a risk to the assets they safeguard.
At their core, multisigs rely on a group of individuals - the signers. The security of multisig wallets is as robust as the practices of these signers. Each signer's private keys must be securely managed to prevent unauthorized access. Trust in these individuals extends beyond their intentions; it encompasses their adherence to fundamental security protocols. The human factor introduces a variable that can be exploited through social engineering tactics like phishing and malware attacks, making signers attractive targets for malicious actors.
Unfortunately, human trust continues to be an indomitable pillar in cryptocurrency solutions. The human element remains despite the overarching emphasis on decentralized and trustless systems. Distinctively, solutions leaning on human trust can typically be categorized into two predominant types: Reputational Security and Independence. The Ronin case was based on Reputational Security.
Solutions founded on reputational security employ a multi-signature (multi-sig) system. In this setup, several entities authenticate and endorse transactions. Once endorsements meet or surpass a specified threshold, the transaction attains legitimacy. This structure is anchored in the belief that a majority of the entities involved are principled. Therefore, a transaction that wins the endorsement of most entities is deemed valid.
However, the crux of this approach lies in the reputational risk carried by the participants. Their standing and credibility in the community act as collateral, ensuring their commitment to the process's integrity. Other examples include Multichain (Anycall) and Wormhole.
Contrastingly, independence-centric solutions fragment the message-passing process, distributing its management across two separate entities. These entities, by design, operate autonomously and free of mutual influence, ensuring a lack of collusion.
LayerZero provides a classic illustration of this model. Here, decentralized oracles stream block headers on-demand while transaction proofs are dispatched through relayers. The transaction's validity is contingent on the proof's alignment with the headers. Although the proof alignment leans on mathematical and code validation, the system requires unwavering trust in the entities to uphold their independence.
How messages get sent via LayerZero. Source: Messari
LayerZero further enhances trust by offering flexibility. Applications built atop LayerZero can opt for their preferred Oracle and Relayer or even host their proprietary Oracle/Relayer. This customization minimizes risks associated with potential collusion between individual oracles and relayers. Nevertheless, for users, trust is paramount. They must be convinced of the impartiality and benevolence of LayerZero, any third party, or the foundational application overseeing the oracle and relayer operations.
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 makes a swap with a permit. 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. This allowed the attacker to make a call to the safeTransferFrom with any value of the 'from' parameter, thereby stealing from anyone who approved the bridge contract.
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.
UPGRADEABLE SMART CONTRACTS
In the rapidly evolving world of Web3 projects, 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. This article explores the complexities and potential pitfalls of upgradeability, using real-world examples to illustrate the importance of robust security mechanisms in the management of Web3 projects.
SIMPLE CODE MISTAKES
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, the team confirmed a zero-value root. 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. This led to a flurry of activity as individuals, including white-hats attempting to save tokens, processed malicious messages.
The Nomad bridge case underscores the importance of careful authorization, a process that specifies access to data or functions. In the context of smart contracts, this typically involves specifying who can call a particular function, often through the use of modifiers such as onlyOwner. However, this approach is not without its challenges. For instance, the transitivity of access to specific functions can lead to security vulnerabilities that are difficult to detect and cannot be fixed with a simple modifier.
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.
Zk-Proofs to the Rescue?
Promising developments are underway to mitigate these risks, particularly leveraging the power of zero-knowledge-proof (zkp) technologies. Zkps facilitate trustless and secure transactions, since the correctness of block headers on source and target blockchains can be proven by zk-SNARKs, verifiable on EVM-compatible blockchains. Additionally, they support permissionless and decentralized operations, obviating the need for PoS-style validation schemes. Zkps also enable extensibility and efficiency, courtesy of new, optimized proof schemes with fast proof generation and verification times.
Other Bridging Best Practices
By understanding these attack surfaces, we can take steps to mitigate them and protect our funds when using bridges.
Here are some additional tips for protecting yourself when using bridges:
- Use a reputable bridge: Reputable bridges have a good track record of security and are less likely to be attacked.
- Diversify your assets: Don't keep all of your assets on a single bridge. If one bridge is attacked, you won't lose everything.
- Be careful with social engineering attacks: Attackers may try to trick you into giving them your private keys or other sensitive information. Don't fall for these scams.
In summary, the exploration of blockchain bridges reveals a complex landscape where the convergence of technological innovation and human trust factors heavily. While these bridges are indispensable in ensuring the seamless transfer and communication between distinct blockchain databases, their reliance on trusted authorities presents a fundamental paradox to the inherent trustless ethos of the cryptocurrency movement. This article underscores the multifaceted challenges inherent in bridge designs, ranging from the security and stability of their technological underpinnings to the economic dynamics of the assets they handle. Risks associated with these bridges, such as financial, functional, and censorship dangers, highlight the critical need for robust, resilient, and transparent mechanisms.
The reliance on human-operated bridges and multisig wallets, despite their advanced security measures, introduces vulnerabilities primarily due to the potential for human error or malfeasance. This susceptibility is exemplified in various high-profile bridge exploits, where the compromise of multisig keys led to significant losses. The effectiveness of these systems is thus contingent upon the security practices of individual signers and the integrity of the smart contracts that underpin them.
The future of bridge security may lie in innovative approaches like zero-knowledge proofs (zkps), offering a more trustless and efficient solution. However, as the blockchain space continues to evolve, it is imperative for developers, operators, and users to remain vigilant, adopting best practices and a proactive stance toward security. This vigilance is crucial in ensuring that the dynamic and rapidly evolving world of Web3 projects can sustain growth and innovation without compromising the trust and security of its users.