Swords of Damocles: 4 Potential Blockchain Vulnerabilities

Vulnerabilities are inherent to any automated system, yet the stakes are especially high in Web3 given the total value of funds under management.

Introduction

According to ancient Greece’s Cicero, a king named Dionysius offered a flatterer named Damocles an opportunity to switch places for a day, so that Damocles could enjoy the good fortunes of being a king firsthand. Damocles took the deal and was showered with exotic food and other luxuries, but he noticed that King Dionysius had hung a sword from the ceiling, held by a single strand of horsehair. 

Damocles could no longer enjoy the luxuries of being king alongside the paralyzing fear that was brought upon by the stress of being in such an exposed circumstance. That is, Damocles learned that the opulences of power came with grave responsibilities, and that a fatal destiny could arrive at any moment without warning. The same lesson Damocles learned may be applied to the Web3 stack and their applications in global finance, so that we can advance confidently and with grace instead of cowering in fear. 

As Web3 continues to mature and a slew of use cases are being rolled out for commercialization, those looking to apply the tech to their existing business models must also focus their attention on the potential risks that blockchains and digital assets may involve. This is especially true when the technology is automated and all-encompassing of an organization’s core financial infrastructure, not to mention the totality of the funds which are often allotted to smart contract protocols, mining operations, or other logistical investments related to commercial adoption.

Vulnerabilities are essentially things which can be taken advantage of by scammers to exploit computer software, hardware, or in the case of Web3, a smart contract protocol. This could be inherent to a given blockchain’s underlying infrastructure; flaws or limitations in the smart contract’s coding languages, or could accumulate over time if centralization takes hold regarding nodes or other network participants which might compromise the integrity of their assets.

Of course, the stakes of these vulnerabilities couldn’t be much higher given the tremendous value of assets being managed by Web3 protocols and the like. This high valuation makes Web3 protocols highly attractive targets for hackers, making it extremely important that projects spare no expense in eradicating blockchain vulnerabilities, and the painful losses that users incur from exploits. 

It’s helpful to familiarize oneself with some of the potential landmines to avoid stepping on in Web3, hopefully helping to inform one’s security concerns regarding Web3, even if only from a bird’s eye view. This article will therefore summarize a few of the most common vulnerabilities inherent to blockchains and the Web3 stack more broadly and various risk-mitigation strategies used by projects so the audience can more effectively evaluate their risk tolerances and participate accordingly. Nevertheless, nothing found here or elsewhere on the site should be considered financial advice in any way.

Dreaded Words in Web3: Centralization Risks

Perhaps the most common vulnerability threatening Web3 protocols has to be the risk of centralization. Ironically, centralization is one of the main issues that distributed ledger technology was originally designed to improve upon. Identifying centralization risks is not as simple as counting how many nodes are in a network and stamping it with approval, it’s important to consider a number of angles from which centralization risks could subsequently make themselves known. 

Centralization risks typically arise either by nature of a project’s underlying consensus framework, the total number or geographical distribution of nodes participating in a given network, or even the ratio of nodes running the most current version of the network’s software, among other things. This creates single points of failure which hackers can exploit to gain privileged access to a user’s wallet or a network’s liquidity pools.

For instance, what is the minimum number of entities necessary to disrupt the network’s operation? This has been dubbed the Nakamoto Coefficient by researchers, and effectively represents the number of nodes that would have to work in collusion to disrupt the operation of a given blockchain. If the number of nodes needed to take down a network becomes implausibly large, it is considered functionally secure.

Similarly, the amount of hashing power controlled by a mining pool, validator node, or staking pool could also factor into a blockchain’s properties of decentralization. Slush Pool and F2Pool have both been put forth as examples of decentralization within the Bitcoin community for their size and collective hash power. 

Protocols which utilize privileged access accounts are another form of centralization risk, since hackers will inevitably attempt to exploit those privileged user accounts. Even with the most prudent operational security, the trust required for this sort of setup all but negates the benefits of decentralization enjoyed by blockchains while still taking on the risk of smart contract exploits.

If bad actors access the privileged account’s sensitive information or infect it with a malicious program, the losses can and have been catastrophic. This is often done via phishing attacks, like emails tricking the user into clicking a link or typing in part or all of a string of sensitive information. However, this is not unique to Web3 and will be left for more generalized discussions, though digital assets have certainly become common targets for phishing attacks and the like.

The implementation of Web3-specific analytics tools, audits, and whitehat campaigns can monitor for suspicious activity, though if something legitimate is actually detected, large amounts of crypto will have already been drained. The old saying, “better late than never,” comes to mind, but striving to circumvent the problem a priori via decentralization and properly aligned disincentives for on-chain mischief is preferable, if not ideal.

Exploitable Logic in a Web3 Protocol’s Code

Code is essentially the law that dictates how elements of software should arrange themselves so that the desired outcomes are completed with predictability and certainty. Anticipating misbehavior or unexpected behavior, however, is much more difficult than it may appear at first glance. Consequently, this presents the opportunity for vulnerabilities to be exploited.

Logical issues can sometimes be exploited, depending on how lines of code execute. This will always be trouble for automated systems, since hackers will be persistent threats looking for ways to exploit a system for its vulnerabilities. For example, a common logical issue is the incorrect set-up of how smart contracts timestamp blocks, the order of operations which check ledger balances for double-spending, the guardianship of users’ private keys, and so on.

Reentrancy attacks are hacks that exploit such logical issues, enabling hackers to drain a protocol of its funds by repeatedly submitting and then recalling transactions before the protocol has been able to update its balance. Essentially, this means that attackers can trick smart contracts into repeatedly sending funds that have already been sent by sending and retracting withdrawal requests unless developers reorder the operations of their code’s logic.

Following previous reentrancy attacks, Web3 developers began restructuring their own code to guard against the threat. One common resolution has been to write code functions in such a way that external listener functions happen after the blockchain’s state change, use eventual-sends, resource constraints, or pull payments. Pull payments are recommended by Open Zeppelin as they prevent recipients in a transaction from canceling a transaction, thus eliminating reentrancy complications.

Potential Third-Party Chokepoints: Oracles and Bridges

The endpoints at which blockchains intersect with either other protocols or external systems provide attractive targets for bad actors to steal funds by exploiting the system in some way. Thus, vulnerabilities associated with oracles and cross-chain bridges are key targets for Web3 security audits. 

If a blockchain is only as strong as its weakest link, then any data coming into contact with the blockchain must be fresh, pristine, and sterile. If the data that Oracles transmit to a Web3 protocol is faulty or delayed, it causes suboptimal or erroneous execution of the smart contracts. Perhaps a fitting analogy is that of hospital surgeons and their working environments, it must be perfect so that it does not infect the patient’s immune system, or otherwise create undesirable symptoms needing to be treated. 

In order to scale past their own native blockchains, hybrid smart contracts use oracles to fetch data from external systems in order to ‘know’ when their conditions have met, and to execute the agreement. To accomplish this, they rely on third-party Oracles which provide periodically updated data streams that enable smart contracts to adapt rapidly changing off-chain conditions or events.

Related Articles

• Blockchain Nodes: How to Run Your Own the Easy Way
• Does Blockchain Protect or Erode Privacy?
• Blockchain Governance: Consensus & Finality

Learn More

• What is Proof of Space and Time?
• Quantum Computing and Blockchain: What You Need to Know
• Blockchain DNS: Is Blockchain The Future of Domain Names?