Factors that should be considered for Nodes moving forward

I wasn’t sure how to tag the other thread with nodes so copying some content into this Node category for discussion and recommendation.

-How Presearch reduces node rewards and how you move forward with node rewards SHOULD incentivize things important and necessary for the project to survive and thrive.

Recommended Node Factors:

Quality Reliability score for now should play a bigger role
Stake gives users some say in what nodes they want higher rewarded but if min stake is met this should be less of a factor than quality
loyalty/ service time If you have been running nodes longer and all other things are equal you should be prioritized for rewards
VPS provider percentage Jurisdiction of providers and number of nodes per provider should be considered because these become attack vectors or areas of risk to the project. more centralized = more risk. more decentralized the better especially if quality is the same.
Location/ Jurisdiction of VPS or node (country and state) More counties and even down to the state level of decentralization the better
Number of nodes per user Should be limited at least for now as the project cuts rewards. This ensures broader spread and decentralization of node ownership and less risk of bad actors or any one entity controlling too many nodes DECENTRALIZATION.

Example of important nodes factors/consideration for reward distributions: A model similar to this would ensure competition with quality, decentralization, staking, etc. while also rewarding loyalty of early supporters.

This last item alone decentralization of node ownership if implemented at a relatively high 1k node limit or some percentage of total nodes per user would probably bring the number of nodes drastically lower while benefiting all node runners but the .1 percent. I don’t wish to limit anyone or harm those who helped get this project going but a limit implemented seems like a better alternative than average node runners leaving or consolidating their lower relative number of nodes potentially creating additional centralization of node ownership. This can always be increased in the future and if loyalty/time is also a consideration as I firmly believe it should be those who save their node keys would easily be able to spin up more nodes in the future and maintain priority over newer node runners as long as quality or other decentralization features were equal and their percentage of total node ownership is at or below the community prescribed limit.

How much better would this be for the project to be able to show that instead of ~10-50 users controlling 25-75% of the “decentralized” nodes we could show the world that the node ownership distribution is fairly decentralized?
Other crypto projects and even centralized non-crypto corps are typically looked at very negatively by many people when ownership is consolidated into very few hands. The more decentralized typically the better people feel about it. I am not suggesting capping nodes at 10 or even a hundred maybe not even 1k nodes; And maybe my assumptions are wrong in which case we may not need a limit at all but I think it depends on the data for example if 10 people control 50% of the nodes that seems a bit excessive especially if node rewards are being cut to the bone for sustainability. That would be ~3630 nodes on average per top 10 node runners so limiting to just 3k nodes or maybe alternatively a user may not be rewarded for any nodes over 5% or 10% of the total nodes. This could cut ~6300 nodes and make the cuts hardly felt by all other node runners.

Example of decentralization of node ownership:

1 Like

This thread like most of my posts are meant to provoke thought, considerations, and change ideally prior to implementing changes. It is much easier to discuss and develop well thought-out proposals or considerations before the team implements changes and best case before the team begins development.
This way more diverse ideas are considered before throwing money into an idea. If the team used the community in this way they would save resources and have more thoroughly developed ideas to implement ensuring resources have greater impact, messaging is more consistent, and less changes, tweaks, and community angst once a MVP is shipped. This approach is the Gold standard – We would like to do x or we Need to do x help us get to a better solution on this No Later Than x date?

Is the above model regarding node rewards the end all be all? No, absolutely not! This model for node rewards might be way off-base but it is something that needs be discussed and agreed upon sooner rather than later, as it is the only decentralized aspect of the project thus far and the backbone of the network. All I am attempting to do is create a discussion on this important topic and start narrowing down what we think and know to be important for the success of the project moving forward.
Think of this as a starting block to build on. Feel free to tear pieces off or add things on change percentages etc. just explain your reasoning the WHY.

I firmly believe the node reward model should be designed to encourage the things we think are important to the network’s success. We should also understand that the things important today will change in the future as the network matures. We may need to enforce or reward different behaviors or shift these node factors/qualities.
At a minimum we need a node reward model that accounts for important items we think the network needs and can be easily tweaked over time to benefit the Network.
If we do that then the node rewards model will live a very long life and the community can be updated or vote on simple changes/tweaks to percentages etc while adjusting alignment with the needs of the network.

I have outlined my goal and overall vision and macro level overview of WHY this is important now I will explain a bit more of the nuanced micro considerations I have thought about.

-Quality: I think we can all agree maybe not on the percentages or the timing but that quality now and into the future matters a great deal. To give the team credit they already have a great mechanism for ranking quality of nodes. I am not necessarily trying to reinvent the wheel on this and I am pretty happy with what they have developed and currently use. But feel free to add any criticism or adjustments that should be considered or that would make that All-Important feature even better.

-Stake: this is self-explanatory but I think stake still has value in any model moving forward as it
a) retains a mechanism for user control when perhaps other factors are outside of their control and allows the user to self-nominate higher rewards to any given node(s) over others.
b)It is also a feature beneficial to the network because it takes some amount of PRE out of circulation for the duration of the stake.

-Decentralization: I broke down decentralization into three different areas
a)VPS Providers – I feel like too many nodes hosted on a single provider becomes a potential attack or risk vector. This could be due to National or State jurisdiction, regulations, law, internal policy changes, or outside influence attacks preventing API access. For these reasons it seems important to decentralize providers. If for example 80-90% of nodes were allowed to be under two providers and those two providers changed policy or were disallowed API access this could destroy the Networks ability to sustain search queries.
b)Location (country / state) – The map on the network page is great and shows a good amount of decentralization. But that is mostly due to personal decisions not because it is being rewarded, which means this could potentially change rapidly or over time get less decentralized instead of more. If the reward model rewarded this behavior the map would continue to turn more and more blue, increasing decentralization and network resiliency.
c) Node ownership – This is the concept of decentralizing the node ownership into more hands, preventing potential bad actors or individuals from controlling too many nodes. What percent or number is too much? Another thought on this if a cap were implemented would be to allow additional nodes just at reduced rewards. Lets say the vote was no more than X% of the nodes can be owned and operated by a single controlling interest/entity/or user. Instead of not allowing any additional nodes to be rewarded what if the first X# nodes past the cap were rewarded at 50% and the next X# at 40% etc. This would allow lots of nodes that otherwise would be shut down and not usable by the network to instead perform network functions, providing redundancy for a cheaper or same cost. The node runners may even have a solution for this to be cost effective or it might make sense to them in order to have their less rewarded nodes fill in as fully rewarded automatically if other nodes go down or the Network demand increases.

-Loyalty/Reputation/Service time: Using the above example of people running nodes that might be lesser quality, less decentralized or over the user limit and therefore would be earning loyalty / service time even if they are currently earning reduced rewards. This system still helps them and helps the network. Their loyalty helps those nodes to be prioritized as the network grows or if other nodes that are poorly managed and go down their nodes can step in and pick up work and become fully rewarded. This auxiliary or redundancy for the network would cost resources but seems like a beneficial feature to implement if there is incentive built in since the network also benefits from more overall nodes for the same or less overall cost. Ex: node reward budget 20k if you prioritized 18k to full rewards and 2k to reduced auxiliary/buffer rewards you could get more overall nodes than simply rewarding 20k towards full rewards. I don’t think anyone knows what exactly the right amount of nodes there needs to be for x million number of users as there are so many variables to consider so building a feature like this seems prudent for the network, surge capacity, down nodes, and scalability. If the network surges in use these nodes are available to be leveraged.
Now assume surges to 10 million searches a day became the new normal and the network needs another X-thousand nodes online depending on the other variables of the network now you have created more choices. You can either increase the rewards budget probably in most cases this would be the right decision but if other competing interests made this not feasible or not the best decision at that time we would now have another built in option that we could vote on to increase the auxiliary rewards from 2k to 5k keeping the overall reward budget at 20k. If this was communicated effectively and the why or duration needed until other issues are resolved. The community could potentially step up and support the network while not fully rewarded they would at least earn reputation/loyalty/service time and earn some amount of PRE tokens.

Just wanted to bring an important point to the community and team regarding node rewards and why thinking about this now is important.

Node rewards are currently a product of two major things:

  1. The total reward pool
  2. The total # of nodes (more nodes means less rewards as the pool is shared; less nodes means more rewards per node)

Yes there are some other minor variables and the above ideas are trying to ensure that rewards are paid out in alignment with the needs of the network. But also to ensure attack vectors or weaknesses in the design are also addressed. We recently saw a VPS service shut down thankfully not many node runners were using it but if that were racknerd for example that could be catastrophic to the network. This is an example of an attack vector I am trying to get us to address.

What I am talking about now and have alluded to in other comments but haven’t broken it down yet, is that there is no mechanism to limit the number of nodes connected to the network. There is no dis-incentive for thousands of new users from spinning up thousands of nodes. Therefore, the risk is to all node runners and to the quality of the network. People could attempt to retain running nodes and more people excited about the project could come in and run more nodes not understanding anything about profitability or what the network needs. All this does is reduce node rewards for everyone!

Even if the project is very successful and node rewards are able to be increased there is nothing in place to limit or dis-incentivize more and more nodes from coming online and destroying everyones profitability other than potentially increasing the stake limit.

We have seen this with nearly every community-run crypto project helium, Planetwatch, MatchX, etc. the eagerness of the masses needs to be accounted for in the rewards algo otherwise it becomes very easy to destroy the network. Google for example could easily spin up 20k or 200k nodes (depending on the ongoing or future stake amount) and make everyone currently running nodes not profitable, ultimately consolidating or taking nodes off-line which would allow Google to actually slowly take over the network. Seems crazy but this is the reality of not addressing these concerns.

I am saying this because these are vectors of attack and potential issues with the design of the network. We have to not only think about HOW TO WIN but also and equally important HOW NOT TO LOSE. They must be discussed and addressed. It is especially important right now as reward pool is in the process of being cut back. We have no transparency on nodes per user or per CORP or top 5% of node runners etc. what prevents a competitor from destroying us from within now while the network is weak and has not considered these important factors.

Very interested to hear from other node runners on my thought process what I am missing and how we can tackle these risks more effectively?