I believe this solution does create an incentive for stake consolidation of nodes, which in turns diminishes infrastructure costs. However there’s a few underlying considerations that I want to highlight as we keep seeking for creative solutions such as this one:
The implementation of a ceiling should never carry state bloat (keeping track of average stake, keeping track of stake age, keeping track of more data on the state), which this solution doesn’t so I believe this is in the right track.
One incentive this creates is that nodes will want to edit their stake every session, which means there will be (by current node count) 48k transactions potentially fighting for block space to edit stake, alongside with claims and proofs, creating block space bloat that we don’t want to see. A viable option to deal with that is that this change comes accompanied by a “reward percentage” field in the Node state data, which would indicate a split between how much of the relay reward goes to the Node Account balance and how much of the relay reward goes directly into the Node stake amount, creating an “auto-compound” feature, which should be enough to counter-balance the before mentioned incentive.
I would also recommend exploring upping the transaction fees for claim and proofs, as well as stake transactions, since now more nodes will be fighting for that block space.
Whenever we explore a solution, we must always take into consideration the side-effects, and even if more mechanisms can be created to combat these side effects, the increase in complexity must also be a factor. With that said, I believe this solution is worth exploring.
I get where you are coming from, but even if we do this there’s no systemic defense stopping node runners to just auto-compound every session, causing the block bloat I mentioned in my previous reply, so we would be counting on good will and everyone running the correct implementation. We have seen in the past non-malicious actors trying to over-optimize and cause strain to the network while at it, so I just wanna make sure that we make the correct trade-offs.
Currently node runners have no incentive to “Edit Stake” because right now they have equal chance of earning the same reward by just staking close to the minimum as possible, if we implement @Andy-Liquify solution people will have the incentive to “Edit Stake” as soon as they receive their relay reward, causing transaction bloat on the blocks.
What I’m trying to say is that even if we put the 15k thresholds, nothing defends the blockchain from receiving “Edit Stakes” until nodes fulfil the 15k threshold, which means that’s not a sufficient measure to protect the blockchain from bloating with transactions. If we modify the reward lifecycle as I mentioned in my reply to @Andy-Liquify to make this auto-compound part of the protocol, we can avoid the risk of this incentive to bloat the blockchain at a systemic level.
So if there are 15k steps… wouldn’t it be easier for node runners to just automate staking any incoming rewards so once they hit the next 15k they start receiving their rewards immediately?
I think the issue here is there will be an incentive to automate staking increases, even if the reward is delayed until the next 15k step is reached. If the majority of the network automates edit stake then it will create bloat which the network isn’t prepared for.
The issue is the risk of bloat and finding a protection from that from what I’m gathering.
With everything outlined here you will be able to consolidate up to X nodes (what ever we set the top bin weight as), reducing costs to run the network and validator bloating, with no major changes no state increase/bloating and only 6-8lines of code changes.
PIP-22 is only superior over weighted session selection (or lite hotspots) in that we can release it faster with fewer changes. However, this is an overwhelmingly significant factor considering the realities facing node runners right now. Lets pass this vote!