This is an automated archive made by the Lemmit Bot.
The original was posted on /r/nanocurrency by /u/1401Ger on 2024-02-03 16:51:33.
There is a limit to how many transactions the nano network can confirm and while it will be pushed much further in the future, there always will be such a limit. This means the network has to prioritize certain transactions over others. If it would be feasible for a malicious entity to use up a significant portion of the network’s resources (spamming), without an appropriate cost to deter such an attack, nano would not work.
What I want to discuss here on the basis of some concrete examples is
- what a malicious entity currently would have to do and invest in order to impact the nano network
- what this means for nano and its future
Prioritization and the bucket system
Unlike many other decentralized networks, nano does not prioritize by fees - we don’t have any of those. So, with finite resources any system has to prioritize. Nano currently does that by a combination of how much nano an account owns and how long it has been since they made a transaction. In order to still allow small accounts to participate in the network, nodes cycle through 62 “buckets” that each contain blocks from accounts that are in a similar range of nano net worth. This means that the send block of an account that owns about 1 nano only “competes” for network resources with similarly sized accounts (0.97-1.11 nano to be precise, bucket#13). Importantly, the buckets are not about the value of the transaction but about the maximum value of the account before or after that block. So, if an account with 1000 nano publishes a receive block for 0.01 nano, it goes into the 1000 nano bucket (#48). If an account with 1000 nano publishes a send block for 0.01 nano it also goes into the 1000 nano bucket.
What happens when the network reaches saturation?
Currently the rate of how many blocks can be confirmed by the network is around 100 blocks per second (bps) or 50 transactions per second (tps, 1 send + 1 receive block) which equates to about 4.32 mio transactions per day. This is not a fixed “magical” number but a limit that is continuously improved with node hardware and node software. It can also be artificially lowered by nodes for example with a bandwidth limit.
If that tps limit is surpassed, the average confirmation time goes up. Following the prioritization mentioned above, some blocks are still confirmed almost instantly while others have to wait longer or even indefinitely until the demand is below the saturation point and the network has caught up. Currently none of the transactions are lost but will be confirmed eventually but the dev team is working on a system where transactions that are not confirmed within a certain time are dropped (similar to BTCs mempool). I should also mention that there are currently still some inefficiencies in the node software that lead to an impact on network performance across buckets. The dev team is working on that.
Scenarios for attacking the nano network with spam
In order to impact the service for “regular” users, an attacker has to
- keep the network in a state of saturation for a significant amount of time and
- use blocks that are prioritized over a significant number of blocks from regular users
In order to keep the network above saturation, an attacker currently would have to publish blocks at 100 bps and keep doing it for a decent amount of time (let’s say 1 h). So they would require 360,000 blocks in the bucket(s) they want to impact. After a wave of spam, they would have to let their accounts "rest" to get below the time_since_last_use of regular users in order to have their spam blocks prioritized by the network over those of other users. We are probably talking hours here, for the majority of regular users it's probably even days.
1. Scenario:
The attacker wants to clog up all small buckets up to 1 nano (buckets#0-13) and there is very low usage by regular users in comparison. Then the attacker would have to "refill" these 14 buckets at network saturation rate, this means they require 25,714 (360,000/14) precomputed blocks for each one, so they would have to invest 97,929 nano on these accounts (24,957 nano for bucket#13, 21,137 nano for bucket#12…)
Impact: All accounts that have 1 nano or less (before sending or after receiving) would likely face significant delays of several seconds or minutes until their blocks get confirmed. Some transactions might take even longer or until the spam stops after 1 h. Some transactions would still be confirmed within 0.5 s if the users did not transact for longer than the attacker had their accounts “rest”.Every account that has more than 1.12 nano (before sending or after receiving) would not see any impact, blocks would confirm within ~0.5 s.
2. Scenario:
Attack on all buckets from 1 to 10 nano (buckets 13-22): The attacker needs to invest at least 1,638,240 nano.
Impact: Accounts that own 1 to 10 nano can face delays with their transactions until the spam stops after 1 h. Transactions would still be confirmed within 0.5 s if the users did not transact for longer than the attacker had their accounts “rest”. All other users are not impacted.
3. Scenario:
Attack on all buckets below 100 nano: Requires at least 4,593,802 nano.
Impact: All accounts with 115 nano or less will face some delays. Since the spam is spread over so many buckets, each bucket is only filled with about 3 spam blocks per second so regular users still have a decent chance to have their blocks confirmed decently quick (probably seconds). All other users are not impacted.
4. Scenario: Attack a single bucket around 1000 nano (bucket#48): Requires at least 335,876,703 nano
Impact: Accounts with 932 to 1,541 nano face significant delays when transacting until spam stops after 1 h. All other users are not impacted.
Conclusion and open questions
The amount of nano invested by the attacker is not lost, they can keep repeating the attack with this amount of nano after having their accounts “rest”. Yet by attacking the network they would also likely reduce the value of these nano. I ignored the current cost of spam attacks in terms of computational resources (mainly the small PoW calculations that are currently required for each block) since those would likely only deter low-motivated attackers and PoW might be removed altogether in the future.
Since there is no way to gain anything directly from a spam attack, we only have to consider what an attacker could gain from impeding the experience of other users. Shorting nano obviously comes to mind, yet the impact of a continuous spam attack on the valuation of nano is difficult to estimate. My guess is that it would depend a lot on the main use cases of nano at that time. If it is for microtransactions mainly, preventing very small accounts from transacting might have a significant impact and as we can see in the 1. scenario, this would also not be too costly.
If the main use case for nano is payments and foreign exchange, keeping larger accounts that own 100s or 1000s of nano from transacting via spam is basically unaffordable (4. scenario).
All of this is under the assumption that the time and bucket prioritization technically works properly. The neat thing is that these costs for impacting the network scale proportionally to the network performance, so if we increase the throughput of the network by a factor of 10 (via hardware and node software improvements), the cost of impacting the network by spamming would also rise by a factor of 10.
What is your opinion? What can be done to make nano even more robust for the future?