The idea in short:
Allow principal representatives (or maybe all nodes) to become active participants in spam prevention.
There are numerous ways to achieve this; In this post, I will talk about one, but I might make another post with another solution.
Introduce a new balance called transaction balance
When your account does a transaction => transaction balance -= 1; To do a transaction, you need at least 1 in the transaction balance.
Creating a new account requires a transaction. The newly created account starts with a transaction balance of 0.
For an account to get a transaction balance, it needs to requests transactions from someone else. So it simply requests a node "Can I please have five transactions please?". The node could then freely decide if it wants to send a transaction balance or not. This decision could be based upon many different criteria; it is up to the node itself to determine its criteria.
The node could decide based on many variables like current transaction balance, current nano, spam history, trust, etc.
The node could also potentially whitelist accounts, like accounts created from a trusted wallet like Natrium or Nault.
If the node agrees, it can send some of its transaction balance to the account through a regular transaction (The same way nano is sent, -5 here +5 there)
How does the node get transactions on their transaction balance?
There are many different solutions here.
#1 What goes in goes out
When someone does a transaction, the account loses one transaction balance. The lost balance goes back to the node based on their voting weight. An additional number n might need to to deal with stale transaction balances. If n is high, the nodes could potentially burn some transaction balance (send it to a burn account) to keep is scarce
Example: a node holds 20% of the voting weight. The node confirms one transaction. The node transaction balance increases with 1 * 20% = 0.2. This number could then be timed with n = 1.01. giving us the final number 0.2*1.01 = 0.202.
Account loses 1 transaction balance, the sum of transaction balances of node increases by >= 1.
It still requires a way to give out transactions initially
This is probably my favorite solution
#2 node gains transaction balance based on time
So a node might get a certain tps into their transaction balance based upon how much voting weight the node has. For example, Natriums transaction balance might increase with 1000 transactions per second.
This might require a transaction within a transaction balance to need an expiration date. This requires the network to know about time.
#3 NF controls transactions.
Since transaction balance does not have anything with consensus for nano, it could be centralized and given out to node in a centralized fashion.
This is probably the least attractive solution.
This could even be a way for nodes to earn money, as they could trade away transactions for a cost!
Essentially the node can make their own spam policy. If someone disagrees with their spam policy, they can change their vote weight to someone with an acceptable spam policy.
- A seamless experience for the end-user:
If the wallet is low in transaction balance, it could seamlessly request, for example, its current node for more transaction balance. The wallet will always have some transaction balance when it needs to do a transaction (except if it spams)
- Effective spam prevention
- Potential money earning method for nodes, though most likely they will be competing with other nodes that are giving them out for free
- Somewhat easy to implement? (dunno really)
- Compared to DPoW it could drastically lower the amount of total spam transactions compared to prioritizing the transactions under saturation.
- It gives more responsibility to the nodes and their operators
Please note: I'm dumb