Protocol Design - Attack Vectors¶
Part of work in progress Living Whitepaper
This page is part of the Living Whitepaper revisions currently underway to replace the original static whitepaper. These efforts include the Protocol Design and Node Implementation sections of the docs, which will cover and expand on details and topics covered in the original whitepaper.
See the bottom of the page for related whitepaper sections and other related details. Some of the sections and headers on this page may be in draft form or just suggestions/framework for later consideration. If you are interested in helping with revisions please connect with us on the
#documentation channel on our Discord server.
Block gap synchronization¶
|Impacts||Network amplify, denial of service|
|Description||Each block has a link to its previous block. If a new block arrives where we can't find the previous block, this leaves the node deciding whether it's out of sync or if someone is sending junk data. If a node is out of sync, synchronizing involves a TCP connection to a node that offers bootstrapping which is much more traffic than sending a single UDP packet containing a block; this is a network amplification attack.|
|Defense||For blocks with no previous link, nodes will wait until a certain threshold of votes have been observed before initiating a connection to a bootstrap node to synchronize. If a block doesn't receive enough votes it can be assumed to be junk data.|
|Description||Transaction flooding is simply sending as many valid transactions as possible in order to saturate the network. Usually an attacker will send transactions to other accounts they control so it can be continued indefinitely.|
|Defense||Each block has a small amount of work associated with it, around 5 seconds to generate and 1 microsecond to validate. This work difference causes an attacker to dedicate a large amount to sustain an attack while wasting a small amount of resources by everyone else. Nodes that are not full historical nodes are able to prune old transactions from their chain, this clamps the storage usage from this type of attack for almost all users.|
Sybil attack to change ledger entries¶
|Description||A Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, in order to get a disproportionate vote on networks where each node gets an equal vote.|
|Defense||The Nano voting system is weighted based on account balance. Adding extra nodes in to the network will not gain an attacker extra votes.|
|Description||A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes.|
|Defense||Blocks publishing is rate-limited by work so this limits accounts to a certain extent. Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is probably not a valid account. Finally, Nano is tuned to use minimal permanent storage space so space required to store one additional account is proportional to the size of one block + indexing ~ 96b + 32b ~ 128b. This equates to 1GB being able to store 8 million penny-spend account. If nodes want to be aggressive, they can calculate a distribution based on access frequency and delegate infrequently used accounts to slower storage.|
|Description||The metric of consensus for Nano is a balance weighted voting system. If an attacker is able to gain over 50% of the voting strength, they can cause the network to oscillate their decisions rendering the system useless. An attacker must have at least some value tied up in the network as a balance which they're willing to forfeit as an expense to performing this type of attack since this attack ruins the integrity of the system. An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DDOS.|
|Defense||There are multiple levels of defense against this type of attack:
The most sophisticated version of a >50% attack is detailed in the diagram below. "Offline" is the percentage of representatives who have been named but are not online to vote. "Stake" is the amount of investment the attacker is voting with and will be lost if they successfully attack the system. "Active" are representatives that are online and voting according to the protocol. An attacker can offset the amount of stake they must forfeit by knocking other voters offline via a network denial of service attack. If this attack can be sustained, the representatives being attacked will become unsynchronized and this is demonstrated by "Unsynced". Finally, an attacker can gain a short burst in relative voting strength by switching their denial of service attack to a new set of representatives while the old set is resynchronizing their ledger, this is demonstrated by "Attacked".
If an attacker is able to cause Stake > Active by a combination of these circumstances, they would be able to successfully flip votes on the ledger at the expense of their stake. We can estimate how much this type of attack could cost by examining the market cap of other systems. If we estimate 33% of representatives are offline or attacked via denial of service, an attacker would need to purchase 33% of the market cap in order to attack the system via voting.
Voting attack cost:
|Impacts||New-user denial of service|
|Description||The longer an attacker is able to hold an old private key with a balance, the higher the probability of balances that existed at that time no longer having representatives that are participating in voting because their balances or representatives have transferred to new people. This means if a node is bootstrapped to an old representation of the network where the attacker has a quorum of voting stake compare to representatives at that point in time, they would be able to oscillate voting decisions to that node. If this new user wanted to interact with anyone besides the attacking node all of their transactions would be denied since they have different head blocks. The net result is nodes can waste the time of new nodes in the network by feeding them bad information.|
|Defense||Nodes can be paired with an initial database of accounts and known-good block heads; this is a replacement for downloading the database all the way back to the genesis block. The closer the download is to be current, the higher the probability of accurately defending against this attack. In the end this attack is probably no worse than feeding junk data to nodes while bootstrapping since they wouldn't be able to transact with anyone who has a contemporary database.|
- Network Attacks Part 2 - Additional deep-dive into potential attack vectors & mitigations
Existing whitepaper sections related to this page: