Adding pow bucket to elections scheduler

I'm a huge fan of removing POW. For us in WeNano that would make integrations a lot easier and less dependent on other services. I do think there are issues though, many of those discussed in the Consequences of removing POW with the election scheduler upgrade post.

One of the issues is of course how easy/cheap it will be to spam the network. The motivation to spam is to disrupt the use of the network or make it more expensive to run a node by ledger bloat. This post does not go into the last issue, but tries to allow the removal of POW, but at the same have a way for services that want to make sure their blocks is prioritized across the network have a way of doing this, without it requiring them to have a huge balance.

There are three major changes in this proposal

  1. Making pow optional in a block
  2. Adding a 129th bucket called the pow bucket or the priority bucket(P bucket from now on)
  3. Increasing the pow difficulty significantly(50x-250x over todays base level, this obv needs to be discussed in detail)

The concept is pretty simple really; we add an additional bucket the nodes pass over in the election scheduler that only include blocks that has pow. Similar to other buckets it will order by LRU. Contrary to other buckets though, this bucket will take up 50% of the election scheduler if needed. Instead of a round robin of all buckets, I’m thinking doing it like this: bucket 0 -> bucket P -> bucket 1 -> bucket P -> bucket 2 -> bucket P …. All the way to bucket 128 and start over again.

The reason I say up to 50% is because in regular usage 99% of services and wallets will not use pow in their blocks, and the nodes will use the regular 128 buckets, except perhaps some large financial actors in the network who want to use it on every block to be 100% sure their transaction is confirmed instantly. But if the bucket you are going to use is under heavy load, or your transactions has taken more than 10-15 seconds to get confirmed, a service/you as a user, can choose to (re)broadcast the block with the pow, and get it prioritized immediately. This also makes spamming the network even with a high balance less useful, as services can choose to use the P bucket instead, removing the incentive to attack it, which is really what is important. If an attacker wants to spam the P bucket, he has to cover 50% of the total capacity of the network at a huge price for him.

As much as we like the network to be equally available to everyone, I believe having 50% of the capacity of the network available to those who want to pay a «fee» by using higher pow, just gives them an additional security in using the network, knowing they at any point can choose to pay a price to get their transaction confirmed instantly.

An additional benefit to this over only letting a huge balance be the way to get prioritized is with upcoming block hand off(mentioned here: https://forum.nano.org/t/work-generation-changes-for-consideration/914). With this change, a service can provide the pow to a customers receive block and they will be prioritized even if their balance is low, and the network is under heavy load.

Let me know your thoughts on this, I’m sure there are ways to improve it, or there is something I’ve missed that makes this not work as intended.

4 Likes

First I would like to see a DB without any PoW involved to see how the election scheduler works without it. Is it possible that cps could increase without PoW? How long does a round robin cycle take with the majority of buckets having a transaction? After this PoW could be added where needed. It is my understanding that PoW will only be used within the bucket after LRU. I am also a fan of getting rid of the PoW but I do see need in certain situations. Would it be possible to set a value threshold for Balance* time_last_use as it relates to PoW? If the value is over a certain threshold then no PoW will be allowed. If it is under the value then you can use PoW to get to the front of the line.

I’m also one for weaning ourselves off pow instead of a complete overhaul but I feel we should be really careful not to fall into the trap of giving pow too much power again. I like orb’s original threat model of infinite pow. I also see many benefits of keeping things simple.

Hence I like the idea of an extra bucket that is prioritised by pow not lru. But I’m against giving it 50% cps. I think it should be treated like any other bucket.

We should remember the scheduler is round robin so each bucket is treated equally. Large balances doesn’t necessarily give you priority but of course chances of having buckets in that range saturated is much less. I rather have a system that is skewed in favour of people with stake (but still democratic) than skewed in favour of pow which can be generated outside the network.

Getting into the pow bucket could be something as simple as if your bucket is full then an attempt is made to put you into the pow bucket. If the pow bucket is full as well then you get dropped. So the pow bucket is a last resort for all saturated buckets to fight it out but not as a sure fire way to get ahead of everyone else regardless of stake.

Pow should be kept as it now (validation) as a minimum so not optional. So a first line of defence against opportunists. But people are free to up that if they think their bucket is saturated.

I feel we need to keep the core principle of balance * time as the main priority mechanism.

1 Like

Thanks for the feedback. Just to clarify a few things.

I think we should really try to either remove pow or make it optional. Pow is so cheap now anyway, so removing it completely doesn't really make that big of a difference is someone wants to spam attack us now. Removing it would be such a huge improvement with regards to services wanting to implement Nano into their products, and we avoid reliability of centralized services like distribute pow or boompow. We have seen big services and wallets stop working for several hours when one of these had issues before.

And I do believe that the new elections scheduler will work as intended, but even still, someone could with a decently huge balance slow down transactions for a large portion of the users significantly with some preparation. With the proposed priority bucket, this gives large actors on the network a way to make sure they can get their transactions prioritized at a cost, and at the same time makes spamming it less worthwhile. It is a lot more to gain by spamming a network if you can disrupt big services.

The priority bucket will have a much much higher pow than today though. And I'm thinking we remove the pow prioritization, since it is not really working anyway unless you go 15-25x over base pow. It would be more a set fee to access this bucket. And if we allocate 5% or 10% of 50% to this bucket is perhaps not that important, the reason though for picking such a significant part is that the spammer can only occupy 50% of max cps if enough services decides to go for the priority lane. If we give it same size as the rest(1/129), the spammer could in theory occupy more than 99% of the capacity without having to pay the expensive pow. During regular usage it won't be used at all, but would be a backup lane for those who want to use it during an attack or a priority lane for those who opt to pay a fee for every transaction for whatever reason.

1 Like