As mentioned here
I don’t think Presearch should make any changes to nodes until there is a definitive understanding of how many nodes / million searches are optimal. Yes there is a cost to keeping things the way it is but if funding has been shored up and there is no solvency risk why not keep it the way it is for now. Gather the data before you potentially make rash decisions that affect the core business. The data should then be shared on how it was analyzed so that the community could engage on any potential blind spots not being considered in the analysis then and only then should we begin to discuss the best solutions to properly align the number of nodes to the number of searches. The risk with implementing node changes without the data to back it up is if nodes get cut too low just as you are trying to bring on users and any users have a bad experience, that would be a complete failure and turn those users away.
You need to have qualitative understanding of the right number of nodes with some level of redundancy. Too much redundancy can be costly but what are the risks and what level of redundancy is the right amount? Also what mechanism or reward construct should be built out or developed to quickly spin up constellations of nodes in catastrophic scenarios to keep the core business up and running?
The two methods mentioned by Tim were reduction of rewards and eliminating grandfathered node status.
I think the team needs to better understand what the right number of nodes should be before making any decisions. However, I will address the two mentioned ideas and some of the drawbacks then provide recommendations:
Flat reductions for rewards is not a good method to reduce nodes because although it would likely reduce the number of nodes it would have the un-intended consequence of the higher quality nodes being replaced by lower quality, ultimately producing less reliable and longer to response times for search results. This would be catastrophic for the project. You can’t afford for users to have a bad search experience, especially as you are trying to onboard new users. They try it and don’t get results or it takes a long time they will leave and may never come back.
Eliminating grandfathered nodes may be a better alternative than a flat reduction for rewards but also cuts the backbone of the community derived network. It also is a slap in the face of early supporters. And although doesn’t have the quality concern as much it would still drastically cut the number of nodes very quickly which is an unknown amount and a concern.
*Full disclosure most of my nodes are grandfathered so both of the considerations would affect me personally as it would likely affect most node runners.
However, if it is determined that less nodes are indeed required and the project is overpaying for needless redundancy then we should consider ways to address this that are beneficial to all.
Are there other options than the two already mentioned by Tim to cut back on the number of nodes and doesn’t use a flat reduction of rewards and doesn’t eliminate the grandfathered status or at least takes into consideration early supporters in the community?
I think there are ways to reward early supporters and keep the nodes scaling with the network requirements. I just don’t agree with the currently offered solutions.
If we are rewarding people by the level and quality of the contribution to the network, as the vision paper lays out, then I think we will always be doing the right thing for the network.
Recommendations:
Scaled rewards
Instead of a flat reduction of rewards there could be a scaling of rewards. This scaling would take multiple factors into consideration most obviously the quality of nodes (as per the current node scoring), but also other factors like diversity of providers, diversity of jurisdictions of nodes, and time of service for nodes just to name a few things that come to mind.
What this would do is take these various things into account and based on the total number of nodes required per million searches it would prioritize those factors and pay out on a scaling PRE rewards system. Nodes with highest run times, highest quality, quotas for different VPS providers based on risk, and quotas for nodes in different jurisdictions would make up the core decentralized node pool that would receive the highest PRE rewards. The rest of the nodes outside of the defined pool number/ million searches would have scaled back rewards some on the fringe higher than those newer less quality nodes that may get next to nothing in PRE rewards. This rolling construct is the ultimate model to ensure constant competition for the fully rewarded node slots. Those that are getting paid less may choose to keep their nodes running even at a slight loss or even a major loss in order to preserve their status and time with the network if another node runner in the full reward pool does a poor job managing their nodes they might fall out of the primary node pool and those fringed nodes could be immediately pulled in to a fully rewarded status. To compete or break into the higher rewarded primary node pool you would have to bring on better quality nodes in all the above categories and/or other key metrics I may not be considering. This would disincentivize more of the same, ensure all nodes are of the highest quality, and the practice of current node runners spinning up new nodes every time they get 4-8k PRE rewards. The current and potential node runners would begin to track the node network and fully rewarded node pool to possibly try to break in or expand and spin up new nodes when the network demands it. You might get to have your cake and eat it too because current node runners may still run current nodes even at a loss in order to be first in when the node pool scales and expands with new users and searches. They may even spin up nodes at a loss to anticipate the growth. A construct like this seems more fair and rewarding than flat cuts or eliminating grandfathered nodes. It simply rewards value in proportion to the value provided to the network and rewards older nodes (early supporters) unless a better location, provider, jurisdiction, or quality can out compete.
The above idea is primarily designed for search nodes but other considerations may be required for new node types. I think some of the nodes that might be rejected or eliminated by potential short-term changes in the structure could actually be better for some of the other node roles. For this reason I think before we chop a bunch of nodes without having the data to know what we need we probably should also consider some of these nodes for new roles on the horizon even if for beta testing.
Option to address grandfathered nodes
A potential option to reward early supporters if the decision is made to cut grandfathered nodes and merge all nodes into 1 rewarded structure, might be to give them access to an NFT prior to the change. The NFT would allow the users to earn a much higher reward rate on their nodes, this might only last until the difference in the grandfathered status is recouped.
What would this look like in execution?
Lets say you have 1k, 2k, and 4k nodes but the decision is made to increase the node min to 8k. Presearch would allow those grandfathered users ~73k to mint new 1-time NFTs representing their support status. Then those users that minted NFTs could attach those NFTs to any ongoing 8k min staked nodes, which would allow them to earn higher rewards maybe double the normal reward rate until the node has reached the difference between the grandfathered amount and the current min stake amount. A 1k node NFT would earn double rewards until 7k PRE are earned then the NFT would be expended and the node would start earning regular rewards (a 2k NFT would earn double rewards until 6k are earned; and a 4k NFT until 4k are earned). This would prioritize and honor early supporters but allow the nodes and costs to be reduced and merged into a single format in-line with the scaling of the network.
Ex: If Node stake changes to 8k min. ~73k nodes are grandfathered at 1k, 2k, and 4k
→ ~70k nodes actually mint 1-time NFTs this assumes a little breakage.
→ A massive consolidation of the number of nodes happens. VPSs are shut down and nodes are re-staked to 8k creating a likely reduction in total nodes down to ~18k-25k nodes.
→ Now each user that has the minted NFTs could align the NFTs to one of their 8k nodes and each node with an NFT would start earning double the current reward rate as described above.
->Not everyone would immediately use the NFTs for higher earn and so the total cost to the network would be immediately reduced and eventually once all the NFTs are used the network is fully merged into a single format for all node rewards.
If my first scaled rewards recommendation is implemented this grandfathered situation may not need to be addressed. However, if it is determined for simplicity-sake to merge to a single min stake and reward model this option could easily be implemented in conjunction with the first recommendation and keep all the loyal community node runners happy.