Rob Behnke
October 19th, 2021
Traditional Distributed Denial of Service (DDoS) attacks are designed to exploit bottlenecks within a system. This is accomplished by sending it more traffic than its network card can handle, overwhelming an application with more requests than it can manage, etc.
One of the main selling points of blockchain technology is its resistance to DDoS attacks. A traditional DDoS attack targets a fixed single point of failure within a system such as a web server. If the web server goes down, then an organization’s website may not be available to visitors.
Within a blockchain network, no fixed single point of failure exists. No node in a blockchain network is indispensable, meaning that any node can go down due to a DDoS attack or other incident without taking down the network as a whole.
However, this does not mean that blockchain networks are immune to DDoS attacks. By flooding the blockchain with spam transactions, an attacker can reduce its availability for legitimate users and potentially have other impacts on the network.
The decentralization of blockchain networks has made some say that DDoS attacks against a blockchain are impossible. However, this is not strictly true. Traditional DDoS attacks can be executed against a blockchain to slow its operations, and attackers can work within the blockchain ecosystem to perform a DDoS attack.
Many traditional DDoS attacks are performed at the application level rather than at the network level. An organization may have invested in large network links that make it infeasible to overload their capacity. However, this does little good if the application that the traffic is intended for can only handle a few hundred requests at a time.
In the blockchain space, the main DDoS threat is transaction flooding. Most blockchains have a fixed capacity because they create blocks with a certain maximum size at regular intervals. Anything that doesn’t fit in the current block will be stored in mempools for consideration for the next block.
If an attacker sends many blockchain transactions to the network, they can fill up blocks with spam transactions causing legitimate transactions to sit in mempools. If legitimate transactions aren’t included in blocks, they’re not being added to the ledger, and the blockchain isn’t able to do its job.
A transaction flooding DDoS attack can be designed to fill blocks and block legitimate transactions from being added to the distributed ledger.
However, it can also have a variety of other impacts, including:
A transaction flooding attack can degrade the blockchain’s effectiveness by making it incapable of adding legitimate transactions to blocks and the distributed ledger. However, it can also have a variety of other effects, including the ability to crash large numbers of blockchain nodes by exploiting their shared vulnerabilities and the distributed nature of the blockchain network.
DDoS attacks against blockchains are not just a theoretical threat. On September 14, 2021, two blockchain protocols suffered successful DDoS attacks: Solana and Arbitrum One.
On September 14, 2021, the Solana blockchain was offline for several hours. The root cause of this issue was a DDoS attack caused by the launch of a new project on the blockchain. When the project was launched, bots started generating large amounts of transactions that flooded the network.
At its height, this traffic spike reached 400,000 transactions per second, which caused the “forwarder queue” to grow dramatically. Additionally, the transactions added to blocks were resource-intensive, making them slow and difficult for nodes to process.
The growth of the forwarder queue caused validator processes to run out of memory and crash, bringing those nodes offline and slowing the network. At the same time, block producers – noticing the size of the validator queue and resource-intensive blocks – began suggesting forks of the blockchain. When crashed nodes were restarted, the large backlog of forks that they needed to consider made it impossible for them to catch up with the rest of the network.
In the end, the Solana network agreed to perform a hard fork, rolling back the network to the last place where 80% of validators agreed on the state of the blockchain. After the upgrade was coded and rolled out, nodes applied the patch and the Solana network was back online within a few hours.
Arbitrum One is a layer 2 protocol that runs on top of the Ethereum blockchain. Arbitrum includes an entity called the Sequencer, which receives transactions and reorders them within the Inbox, which is the list of transactions waiting to be included on the blockchain.
Arbitrum One also experienced a DDoS attack on September 14, 2021. A transaction flood overwhelmed the Sequencer, knocking it offline for approximately 45 minutes. Without the Sequencer, transactions were waiting in the queue but no new transactions were being accepted or being added to the blockchain.
In the Arbitrum protocol, only the Sequencer can submit transactions without a delay, meaning that a Sequencer outage causes downtime on the system. However, Arbitrum users can also submit their transactions on the Ethereum chain, and Arbitrum will process them after a delay even during a Sequencer outage.
DDoS attacks are designed to overwhelm a bottleneck within the software or hardware on a blockchain node. The primary ways to defend against them are to ensure that nodes have adequate storage, processing power, and network bandwidth and to build failsafes into the code. The ability to identify a potential attack and fail gracefully creates less of an impact than if software suddenly runs out of memory and crashes hard.
From a blockchain network perspective, DDoS attacks can be defended against by filtering transactions. Block creators have the choice of which transactions to include in their blocks. Identifying and discarding potential spam transactions can prevent these from being included in the ledger and clogging up the network.
To learn more about securing a blockchain against a DDoS attack or other attacks, reach out to Halborn’s blockchain security team at halborn@protonmail.com.