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.
Goal:
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.
