The Bucketing System: Prioritizing Transactions through Time and Balance
In this article I describe Nano’s method of transaction prioritization — a way to prioritise transactions without fees, yet offering spam resistance through prioritising by time and balance.
In this article I describe Nano’s method of transaction prioritization — a way to prioritise transactions without fees, yet offering spam resistance. If you would like to read more about the theory behind this way of prioritization, I have written an earlier article on it here.
The problem: prioritising without fees
Nano is a feeless cryptocurrency. This offers great UX and has all kinds of benefits. However, it also means that transaction prioritization can’t be done the way it is done in most other cryptocurrencies, which is via a fee market.
A fee market to prioritise transactions also goes against Nano’s ethos. If you want to have a currency that is usable by anyone, yet due to competition for blockspace users have to pay $1 or more to transact, you’ve failed at your goal.
The solution: prioritising by time and balance
To ensure that everyone has the ability to transact on the network, a bucket system was created. This system can be summarized in two bullets:
Every transaction is placed into a bucket based on the balance of the account doing the transaction.
Within buckets, the least recently used account has their transaction processed first.
Adding some specifics: there are 62 buckets (note: this used to be 129 buckets but is being simplified in v24), ordered from small (0.0001 Nano) to large (100 million Nano). When a transaction is done, the maximum value of the balance before the transaction and balance after the transaction is used to place the transaction in a specific bucket. As an example, if my account has a 65 Nano balance and I send 60 Nano to a different account, my remaining balance of 5 Nano would place the transaction in bucket 41 which takes in balances from 4 to 8 Nano, but because there used to be 65 Nano in the account the transaction is instead placed in bucket 45 which takes balances from 64 to 128 Nano.
Nodes that are processing transactions pull transactions from each bucket in turn to verify them. Within each bucket, they verify the transaction from the account whose most recent transaction is longest ago. Having verified this transaction, they move on to the next bucket.
How does this protect against spam?
An attacker that spams the network does so to impact real users. If there is no noticeable impact, there is no point to spamming. The goal of the bucketing system is to make it difficult and illogical to try and impact real users, by forcing a large investment of time and money.
To impact real users, a spammer would need to fill up buckets with transactions and have sufficient priority to be processed before real users. To do so, they would first need to purchase enough Nano to be able to do transactions that fall within that specific bucket, and then need to wait so that the spammer’s accounts have priority within the bucket, by not having transacted in a while. Aging empty accounts would not work - a receive transaction to put a higher Nano balance in them would reset their priority.
While spamming, the would-be spammer by definition holds Nano. If the goal of the spam is to impact Nano users and thereby devalue the network, they are directly attacking the value of their own holdings. This should provide a disincentive to spam.
At the same time, as soon as the spammer starts spamming, his spam becomes less and less effective. Accounts that have been used have their priority reset, as they have now done a transaction very recently. Regular users whose transactions have lower priority on the other hand see their priority increase further and further, as it has been longer since their most recent transaction. It therefore becomes harder and harder for a spammer to keep this up.
By prioritising transactions based on account balance and time since last transaction, Nano is able to be spam resistant without needing fees. The bucket system means that a would-be attacker needs to fill up buckets with transactions, forcing them to buy Nano to do so therefore attacking their own holdings, while at the same time rendering their attack less and less effective the longer they try and keep it up.
Thanks for reading Senatus’s Newsletter! Subscribe for free to receive new posts and support my work.