Algorand’s Resiliency Against Adversarial Attacks

In this article, I’ll try to explore some of the most common adversarial attacks on blockchains and how Algorand responds to these attacks.

Sybil Attacks

Sybil Attack is a type of attack seen in peer-to-peer networks in which a node in the network operates multiple identities actively at the same time and undermines the authority/power in reputation systems. The goal of this attack is to gain the majority of influence in the network to carry out illegal (with respect to the rules and laws set in the network) actions in the system. A single entity (a computer) has the capability to create and operate multiple identities (user accounts, IP address-based accounts). To outside observers, these multiple fake identities appear to be real, unique identities.

They are further subdivided into two categories

(I) Direct Sybil Attack: Where the nodes are under the direct influence of malicious (Sybil) node(s).

(II) Indirect Sybil Attack: Where a node is attacked by a compromised node which is under the direct influence of a Sybil node.

In permissionless blockchains, since anyone can participate, an adversary can create an arbitrary number of pseudonyms (“Sybils”), thereby making it infeasible to rely on traditional consensus protocols that require a fraction of honest users. Proof of Work crypto projects like Bitcoin rely on unforgeability of computational effort to differentiate actors in their system. Proof of stake systems must find another way…

Alogorand’s Immunity against Sybil Attacks

To prevent Sybil attacks, Algorand assigns a weight to each user. Byzantine Agreement in Algorand is designed to guarantee consensus as long as a weighted fraction (a constant greater than 2/3) of the users are honest. In Algorand, users are weighed based on the money (number of ALGOS) in their account. So, it does not matter whether the adversary creates “i” number of pseudonyms to influence decision or vote as one single entity; the result of its vote will remain the same in either of the scenarios as a collective weight of all the pseudonyms will be equal to single weight adversary would’ve had if he did not split his money across “i” number of public keys.

Thus, as long as over 2/3rds of the money is owned by honest users, Algorand can avoid double-spending.

Distributed Denial of Service Attack (DDoS)

In DDoS attacks, a malicious actor infects a large number of computers/devices on the web with malware (this could be done via social media, email attachments, etc.). The infected computers get under control of this malicious actor and awaits instructions from the master (attacker). When the attacker decides to launch a DDoS attack, all the computers/devices under its control flood the target server with communication packets thereby crippling its online infrastructure. The goal is to slow down or crash the system.

In the past, a lot of mining pools were DDoS attacked by bad actors. (links corresponding to attacks are included under the reference section of the article)

Much of the key work done in the Algorand protocol is accomplished in one time use committees with about a thousand participants. Bringing down these committees could negatively impact the running network.

Attacking any committee member in Algorand with DDoS would require the adversary to know about the identity of a committee member. However, given that at every round different committee members are elected, it makes it impossible for the attacker to ascertain the identity of the user until the user has cast the vote.

Partition Resiliency Against Network Attacks

Any decentralized system is susceptible to a network attack in which an adversary targets the communication links between users, making it difficult or impossible for users to interact. An adversary could partition the network into isolated pieces, so that members of one piece can only communicate with each other but not with members of other pieces.

During a network partition, the network is completely asynchronous and the adversary has total control over who receives which messages and when. If the partition lasts long enough and the underlying blockchain didn’t take this into consideration in its design, then the adversary may be able to convince different groups of users to accept different blocks at the same height in the blockchain in the different network pieces. As a result, contradicting transactions will be accepted by different users, potentially allowing the adversary to double-spend their money once the partition is resolved.

By contrast, during a network partition in Algorand, the adversary is never able to convince two honest users to accept two different blocks for the same round. This is true even when the partition may last for an indefinite amount of time and nobody knows when it will be resolved. Algorand’s chain never forks and users’ balances remain secure. At most, one block can be certified and written to the chain in a given round. Accordingly, all transactions are final in Algorand. Once a block appears, users can rely on the transactions it contains immediately and they can be confident that the block will forever be part of the chain, which means the assets they receive are safe.

Chain-Split Hard Forking

Although not traditionally classified as an attack per se; however, in light of past hard forks of various blockchains, I am of the view that chain split hard forks are one of the most lethal instruments for mounting attacks on the entire ecosystem of a particular blockchain. They are akin to Civil War. Take for example the contentious hard fork of bitcoin in 2017 where Bitcoin split into bitcoin and bcash. This hard fork created serious divisions in the community. The tech-talent working on bitcoin’s code split into two different camps. The entire belief system of the community which had been backing bitcoin since its past 9 years of inception was put into question.

Following the split from earlier hard fork, bcash’s community was already so small that even a minor disagreement could trigger further division in this infant community. This is exactly what happened, disagreements between Craig and Jihan led to bcash getting hard forked into two different coins- Bitcoin ABC, Bitcoin SV. The continuous exchange of verbal attacks between “Team-Jihan” and “Team-Craig” during this period of hard fork led to a severe depreciation in monetary value of bcash. Had they a strong community of people backing bcash since its genesis, the outcome wouldn’t have been so acidic. (I have included a link to a video where Andreas deftly talks about the perils of hard forking. Be sure to check it out)

Another point to observe here is…Governance. Who is governing these new forked coins? It certainly isn’t the community. It is just a bunch of rich miners who are mining it, and unloading it in the market. In the case of BSV, nearly 46% of the hash rate comes from Calvin Ayre’s Coingeek mining pool and 29% from BMGPool (owned by Craig’s company nchain). They collectively make up 75% hash rate of BSV. Calvin and Craig happen to be the original promoters of BSV. That is, effectively two like-minded, friendly people are at the helm of mining a coin with a market cap $ 2.63 bn. It certainly chokes the Satoshi’s vision of decentralized governance.

To put things into perspective, the consequences of a chain split are

1. Community Division

2. Depreciation in monetary value

3. Questionable Governance

Algorand, on the other hand, is fork-less i.e. No-forks. None. NADA!

Algorand believes in the power of a united community than a divided community. It works on the mechanism of propose (a block by block-proposer) and agree (byzantine agreement). In a case, where some technical updates are to be done in the code, the majority will have to agree on the proposal for it to be embedded in the blockchain.

Final Words

I hope this article enlightens you about the sturdy architecture of Algorand from a security point of view.

Feel free to leave comments, happy to have discussions :)



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store