Consequences of removing POW with the election scheduler upgrade

I would like to make a sepparate post to address concerns regarding removal of POW as a spamm prevention mechanism.

Although we can all aggree that POW doesn't provide the necessary spamm mitigation, it provides a barrier for average users in spamming the network. You have to put a minimal amount of electricity in order to use the Nano network. Keeping the cost of the transaction out of the network is what makes Nano brilliant from an economic standpoint.

Removing POW will make all tiers/buckets susceptible to spamm without any inconvinience on the spammer's side. While this spamm will not be as dangerous for QoS as the current one is due to transaction prioritization mechanisms, bloating the ledger will be easier than ever.

Let's say that Nano can operate at 100TPS and that node operators set a bandwidth limit that allows such performance. We can assume that all the lower tiers will be constantly spammed because the cost of spamming is ~0 and the middle tiers, which are used most often but require a small financial investment, could also be spammed by sending a minimum tier specific balance in circles. Only the few high level tiers would be spamm free and they optimistically would take 20TPS of total 100TPS.

If every transaction could be used to open a new block, then we have a ledger bloat attack on our hands with 80 new accounts being opened every second. Almost 7 million new accounts-per-day can be opened without taking a single dime out of the attacker's wallet.

I'd like to emphasize, this isn't a discussion about performance issues, this is a discussion about ledger bloat resulting from POW removal and ways in which it can be mitigated.

6 Likes

I share this worry too, while prioritization will work to put authentic transactions up, atleast for now, we do not have huge amounts of user or services generated transactions that something like bounded block backlog can weed out, the average authentic transaction capacity is only 2-5 CPS. I think the removal of POW was done to simplify the prioritization protocol as having dynamic POW and Election scheduling based on time makes it quite complex to test and implement quickly.

I suggested we use POW to stop dust attacks rather than prioritization while authentic transactions can rely on the new election scheduling & prioritization techniques.

In my proposal I encouraged the idea to let nodes reach a consensus on unwanted transactions with a manual setting and penalise the attacker with huge POW Burst Control, SPAM Filter & POW as Defence for Dust SPAM

There could be better ways than this, but a discussion around it would help mitigate unwanted dust/ledger bloat to the network.

2 Likes

The primary means of mitigation that I can see is a minimum account balance. This could be set at 0.00001 Nano. Doesn't seem like a fix unless we go for higher minimum balances, since using the 7 million txs/day a 0.00001 minimum balance amounts to $70 per day. 0.001 Nano balances would increase that to $7k, which is still not prohibitively expensive while having many other downsides, such as faucets and small transactions to try out Nano becoming far more difficult, and the marketing downsides associated with a minimum account balances.

Rather, I think we might want to accept ledger bloat, and look at whether it's a big problem in the first place. I do not think it is. Storage is remarkably cheap. A 5 TB HDD costs roughly $100. 5 TB stores about 8.7 billion transactions - taking the example of running at 100 CPS this would be enough storage for 2.7 years worth of transactions. Obviously, we prefer SSDs, since these have faster read/write capabilities. So why not implement the option to automatically move blocks with a voting timestamp >X time ago (say a year) and <X size (say 0.000001), where both can be set on a per-node basis, to more permanent storage, on HDDs? Keep all the recent, or decently sized transactions and accounts on an SSD for quick access. If transactions from a HDD are requested these might take a few seconds to confirm, rather than sub-second, which I don't think is a huge issue. Combine this with ledger pruning to stop the spam vector of sending 1 Nano amounts around, and it seems to decently "solve" ledger bloat by making it cheaper to store the ledger even if it grows to large amounts.

I feel like such a solution stays true to the decentralized nature of Nano, without imposing minimum account balances.

4 Likes

I think MAB is a good trade-off to have for a financial network that won't be at saturation all the time. The ledger bloat is not the only issue, the fact that prioritization will feel like prioritization is the problem as having a free-flowing network whose capacity is being used fairly is in the best interest of all. Sync issues and Nodes falling out or bandwidth restrictions are also tradeoffs for a reliable finance protocol and would hinder large players to confidently adapt to NANO.

0.00001 NANO is a good enough balance and adds to the cost of the spammer, especially with an appreciating price, this will just become expensive and pointless to keep up for the spammer.

1 Like

@Senatus New attack vector to the network is spam a million accounts this year... wait 2 years and spam again using the same accounts... hdd access across the network brings everything to it's knees?

@srikar_tech this is a key point.. the network is only as strong as it's weakest link currently... every node has to handle every transaction... if there is never any spare capacity in the network then slower nodes never get a chance to catch up... imo it's crucial that we remove the incentive to send transactions... if it's trivial to spam the network to bloat the ledger then plenty of bad actors will do just that.

4 Likes

Can't the bandwidth of the network be capped according to the "real" TPS? I mean, if there are currently 2 "real" TPS and the network can only process that amount of TPS, the "spam" TPS will be constantly deprioritized and never enter the ledger. Or am I misunderstanding it?

To keep the lowest performing nodes in sync would mean limiting the whole network to the capacity of the worst node (lowest common denominator). With constant spamming that is made much worse as there is no slack in the schedule for nodes that fail to handle peak burst to catch up... there are no peaks and troughs... it's peak burst all the time. Nano will never scale to be a successful global payments network by limiting the capacity to lowest common denominator.

How and when do we increase that? Load will increase when there is capacity, limiting the network for the fear of dust transactions is not a long term solution, if there are parties interested in using NANO for FX, NANO as payment gateways, for eCommerce, etc, its beneficial for NANO to present itself as a high txn capacity network - the pipes should be broadened and opened up - 1000CPS, 2000CPS etc with every node update - that is exactly what we have been doing for so many updates, cherishing NANO's network capacity. Whatst he point of limiting it to a dozen CPS.

NANO is a high-performance financial network that could potentially carry out billions of value transfer every minute, it is essential to keep it at its full potential and protect it from malicious actors at all times.

Edit : My stance is not with any specific solution, MAB or POW or maybe something else, but I feel unease at the fact that NANO's network capacity can be used up at 0 cost by malicious actors. With the current proposal if MAB is put in place, we would be in a good place until a better idea comes along, although I am not saying MAB is a bad idea to begin with.

2 Likes

That depends, right? HDD access is slower, but does it also cause more strain on the processor? Because if not, I don't see why you can't just have the processor access the HDD to the extent of that it can be accessed, while also doing SSD transactions to the extent that that is possible. In short, I can see how it might lead to lower TPS temporarily, but bringing the network to its knees seems a bit farfetched right?

@Senatus I don't know how the network would cope under such an attack. I guess my point is that I don't think anyone would know as it would never be a tested scenario. But unless the node software is parallel processing the incoming work queue (does it?) then every txn will be impacted and so you could easily see a prolonged period of reduced cps... how much? No idea but possibly an order of magnitude? Although maybe the full mempool idea (no writes to disk of unconfirmed blocks) would negate this attack.

The problem here is nodes can process a finite number of transactions before falling out. Since it costs little to nothing, there always will be dust transactions that will push nodes to their limits.

Imagine a script that generates dust NANO transactions distributed across the web that any basic laptop can run. Clearly, more transactions can be generated than nodes can process and they must process them all.

If bandwidth limits are removed, the dust spam will increase, if they are kept, NANO is artificially bottlenecking itself - DISK or CPU or Bandwidth - All three will be eaten up by dust - every last bit of it. There is no mechanism to stop these. There should be.

The network's aim to be able to process thousands of transactions per second will not be realized because node operators have no incentive to run the best hardware as the network is bottlenecked by bandwidth limitations for the fear of dust spam as the weakest link is a node whose capacity disk/CPU limit is unknown and the fact that there is more dust than real transactions demoralizes node hardware upgrades. It becomes a chicken and egg problem.

Edit: After speaking to @Qwahzi about it, I do realize that maybe, as long as txns priority are being handled and bandwidth limitations are scaled with need, despite having a few nodes fall out, it will always work as intended, it will be annoying to see the dust and some pruning or max account number could be a solution to the ledger bloat. Nothing alarming right away.

1 Like

The new election scheduler scheme starts with the assumption that the network will almost always be at or near saturation. It doesn't matter if that's due to spam or legitimate transactions, it could be either. With LRU rules, legitimate users will almost always get prioritized in front of the spam, and that's all that matters. That automatically kills much of the incentive to spam, except for ledger bloat, which is addressed by bandwidth limits, cheap storage, pruning, Moore's law, and the extremely long time-frames required for a spammer to see any impact (as @Senatus mentioned, 5TB for $100 == 2.7 years of 100 CPS transactions, without pruning)

5 Likes

I agree 100% that the new proposal provides a throttle on storage but concerns, but I have to disagree with the quote above. Yes, putting "legitimate users" ahead of spam is key, but I think we also have to consider prioritizing economically beneficial transactions from lower balance accounts over non-economically beneficial transactions from higher balance accounts.

Having the "cost" of PoW for each transaction helps define a set of viable use cases. If the "cost" of each transaction is zero then large accounts could use the network for just about any activity (and push out lower balance users)

I don't have thoughts yet on how to define this and adjust over time, but I think some "cost"/PoW for each transaction is critical for keeping the network used for it's intended purpose (digital currency)

2 Likes

That automatically kills much of the incentive to spam, except for ledger bloat, which is addressed by bandwidth limits, cheap storage, pruning, Moore's law, and the extremely long time-frames required for a spammer to see any impact (as @Senatus mentioned, 5TB for $100 == 2.7 years of 100 CPS transactions, without pruning)

If the ledger is 5TB then by my rough calculation that will cost every node operator in the order of $1000 for SSD storage every month (see Disks and images pricing  |  Compute Engine Documentation  |  Google Cloud)... multiplied by (say) 1000 nodes is about a million dollars of someone's hard earned cash EVERY MONTH to store 99.99% complete crap of no economic value to anyone. This kind of thinking seems insulting to node operators to me.

And Nano should be targetting 1700 cps at a minimum and is not going to get anywhere near that by giving in to spam (lowest common denominator issue).

1 Like

but I think we also have to consider prioritizing economically beneficial transactions from lower balance accounts over non-economically beneficial transactions from higher balance accounts.

That's a good point - being able to "push" a transaction's priority if you're willing to pay the (PoW) cost, but isn't this a different question/issue than having a PoW minimum?

Having the "cost" of PoW for each transaction helps define a set of viable use cases. If the "cost" of each transaction is zero then large accounts could use the network for just about any activity (and push out lower balance users)

Most cryptocurrencies start with zero cost for transactions and then let the market decide. Why shouldn't Nano adopt a similar strategy? To clarify, I'm not yet for or against removing PoW in the new election scheduler, I'm just not opposed to the idea of no base PoW cost

1 Like

Don't bandwidth limits solve this? The network as a whole comes to a consensus on the maximum rate of ledger growth that's acceptable (through a combination of vote weight distribution and node bandwidth limits), and then the users of the network compete for that space. Spam gets pushed out because it can't compete with market rates

If Nano targets 1700 CPS, shouldn't we assume that the network will be at or near capacity at some point? It doesn't matter if it's spam or legit, because it could be either. Minimum PoW isn't the solution to ledger bloat imo (which seems to be the real concern here)

3 Likes

It doesn't matter if it's spam or legit, because it could be either.

IMO it does matter - fundamentally. Node operators are doing a service to the network and the community. If the ledger is growing rapidly due to actual human economic activity then Nano is realising it's mission (and most likely the price is going up) and Node operators are pleased. If the ledger is growing rapidly due to spam then every month the costs of running a node go up and yet there is no associated warm fuzzy feeling. Some Node operators will throw in the towel.

Bandwidth capping is currently being used to limit spam but that is diametrically opposed to the mission of scaling the network capacity up.

If we launched a new network topology tomorrow that greatly reduced bandwidth usage by an order of magnitude then currently we would just be bloating the ledger 10 times quicker. Where's the incentive to improve network capacity for the Node runners??

1 Like

From what I'm seeing it wouldn't be purely balance-based, there's a balance and time component. If your balance is 1000 and mine is 1, but you transact every second while I transact every half hour, my priority could still be higher (depending on the exact implementation).

I find the PoW question a difficult one. I think that it's hard to come to a PoW level that provides enough disincentive to spam yet retains low cost for regular users. If, for example, the base PoW level increases to $0.0001, then it will still only cost $700 a day to send 7 million transactions. At $0.001 I think you start pricing out legitimate small usage, right?

Hence my point of looking into whether it would be possible to spam what are generally seen as spam transactions (dust amounts, long time idle) on HDDs, which are far cheaper to use than SSDs. Combine that with pruning, and I think that would reduce the costs for node operators by a large amount, given that a 5 TB HDD costs roughly $100. Right?

1 Like

IMO it does matter - fundamentally. Node operators are doing a service to the network and the community. If the ledger is growing rapidly due to actual human economic activity then Nano is realising it's mission (and most likely the price is going up) and Node operators are pleased. If the ledger is growing rapidly due to spam then every month the costs of running a node go up and yet there is no associated warm fuzzy feeling. Some Node operators will throw in the towel.

The bandwidth cap is the storage growth cap. Node operators choose the rate of growth that's acceptable to them. If 640MB/day (~15 CPS) is acceptable to them, then that's what they choose. It could be spam or not, but with that kind of limit and functional prioritization/scheduling, legit transactions will price out spam

Bandwidth capping is currently being used to limit spam but that is diametrically opposed to the mission of scaling the network capacity up.

Bandwidth capping is not necessarily opposed to the mission of scaling the network imo, because the cap doesn't affect real world users (especially if prioritization is working correctly). If real world usage actually hits ~15 CPS, or the node operators (or vote weight) decide that they are ok with a higher ledger growth rate, then the limits would be increased

There's fundamental tension between network capacity (throughput) and storage capacity. If node operators are ok with X throughput, then they also need to be ok with X storage capacity. It doesn't make sense to increase throughput if they're not ok with the corresponding storage increase

3 Likes

So the node operators get to choose the max cps... but how do they decide what that should be? They are given the task of determining what constitutes legitimate traffic and tuning the network accordingly? Surely it would much more efficient to put measures in place to keep illegitimate traffic to a minimum so they didn't have to do that?