PUP-4: Adjust DAOAllocation to Limit Service Node Counts

Proposals Parameters
28

In lobbying for the little guy a bit - and continuing to preach the gospel of decentralization - I’m opposed to increasing minimum stake to curb node numbers as it would significantly centralize the network. Smaller operators would simply leave.

Instead of making entry into the network harder, I would argue that curbing node numbers should be done primarily by reducing the profitability of running nodes, i.e. reducing the inflation reward per relay to the node operator. Since simply reducing overall inflation doesnt help reduce profitability, it should be done by increasing the DAO allocation percentage depending on how close node number gets to the limit. Possibly to some absurd level like 80% DAO, 1% proposer, 19% service node.

This reduces node profit, forcing inefficient operators with low profitability to shut down first and has a positive effect on the network funding future projects: win-win
Operators that stay online will simply donate a larger share of their work to development of the network, which ultimately will benefit everyone involved. It is also simple to change this parameter back in case more nodes are needed

29

@Garandor & @arnaud-skillz. Thank you for the insightful feedback.

I generally agree with the steps to be taken as outlined by Arnaud and Garandor. I have my concerns about raising the minimum stake for nodes to Garandor’s point. I think that undercuts decentralization and the bottom end of the user market. Plus the organizational hurdles a move like that would cause on short notice would be hard to digest.

As others suggest, the separation between servicers and validators seems to be the best solution in the mid to long-term. I would support this move. I’m also suggesting one other technical (non-economic) fix below.

Through my own personal analysis and modeling, a multi-pronged approach seems to yield the best results in the most amount of circumstances - in the short term until a technical fix can be implemented. I’ll be releasing the model after some additional feedback, but the net result is three suggestions:

  1. Reduce the RelaysToTokensMultiplier by as much as 60% - my models indicate that smaller reductions don’t stem the tide in the long term or with significant POKT price changes.
  2. Increase the proposer allocation significantly to somewhere in the range of 25% - 45%. This encourages consolidation among node runners with large stakes.
  3. The final, and most technical suggestion, is changing the way proposers are selected. Currently, this is calculated by (round down(node-stake / Avg node stake). Changing proposer selection from mean to median would have the effect of granting many more tickets to large node stakes without needing to change the proposer reward %. It would also lead to consolidation for large node runners. If my recent numbers are correct, this would change from an average (unjailed) node stake of about 40K POKT to a median of about 15K POKT. Large node stakes would then benefit greatly from consolidation, especially with suggestion 2 in place.

Overall, the most adaptable strategy (highest probability of providing stability in all scenarios) seems to be doing all three. That said, we should be cognizant of the effects of these for node runners of all sizes.

More to come.

@adam (pikpokt)

30

Point #1: Perhaps yes. Perhaps no. From plenty of interaction with the parties putting these new nodes up. Yes, they “want” to make a profit, but many of them are not making the decision based on the current rewards. They are spinning these nodes because their coins unlocked on Jan 28th and they want to run a bunch of nodes so that they are positioned to take advantage of an expected increase in relays and to offset their percentage loss caused by inflation. They have ZERO capital cost to spin these nodes only operating expense to consider.

Point #2: Took me a while to duplicate your numbers but they are correct. Nonetheless I strongly disagree with this method of adjusting incentives as being extremely unfair to those who bought or plan to buy POKT to run a node. The Whale Wallets have huge stake because they have no choice. They were intentionally limited to 3 nodes to stop them from owning the network from day one. If you bump the proposer payout to the level you are recommending, they will drive all the small stake nodes out of business.

Point #3: I can duplicate this math as well. And - in my opinion - it is far worse in terms of creating unhealthy incentives. I show fun games like spinning up low stake nodes just to get the median to drop so that you get a higher multiplier. Only works if you are a whale though. In any event… this would be a consensus breaking change… so it cannot be addressed in the short term.

My conclusion at this time is that exponentially increasing the DAO allocation as we approach 5,000 is the best option that has been presented so far.

31

@BenVan Your points are well taken. I believe there’s a balancing act we need to strike in the short term until a long-term fix is in place. We may need to make a sacrifice non-ideal economic incentives in the near term in order to secure the long-term existence of Pocket Network. My opinion is that once the long-term fix is completed, we can roll back any changes that the DAO isn’t in favor of.

Can you explain why you believe this is superior to decreasing the RelaysToTokensMultiplier? This has the effect of keeping the inflation at the same rate, assuming relays stay at the same level or increase meaning that node runners/apps would be diluted for the benefit of the DAO (which may be a good thing). By decreasing the RelaysToTokensMultiplier we stem the increase in the total supply of POKT, minimizing dilution which also minimizes the amount of nodes Whales need to run in order to match inflation.

I think it boils down to this notion :point_up_2: which I am still trying to understand. Presuming that relays/node remain similar or increase (due to network relay growth or nodes falling off), rewarding less per node via the RelaysToTokensMultiplier change appears to have the desired effect of reducing node profitability. My point is that the net effect remains the same with the important exception dilution is decreased.

To Benvan’s point, node runners are taking a very long-term view when thinking about the payback period so they are not only evaluating month-to-month profitability, but a drastic change to this number should lengthen that payback period putting pressure on both whales and small node runners alike.

Re: the median comments - this isn’t a near-term fix, but I think it’s more adaptable than it initially appears. Averages are subject to extremes, whereas medians have the effect of ignoring extremes. There’s already games with the average that aren’t being considered. If someone where to accumulate a massive amount of POKT, say 30M POKT and stake it in a single node, they’d drastically increase the average stake massively decreasing the probability that even other whales can be the block producer. Based on my numbers, adding one node at this stake amount would ~1.5x the average stake or decrease everyone else’s odds of producing the block by ~33%. I’ll admit this is an extreme scenario, but it’s illustrative of the point.

In the scenario you mention, trying to game the system by creating many small node stakes, the change in the median may decrease from 15,009 (according to my math of mid-Feb numbers) to 15,001, which is a comparatively minute change when considering the change that might happen with an average. The amount of effort it would take to make this work would be prohibitive.

That said, I could get behind @Garandor’s proposal of scaling up the proportion of the DAO allocation as nodes near 5,000 as it seems to have the least amount of downside.

32

It feels like the two main objectives are, in order of priority:

  1. Prevent a total collapse of the network;
  2. keep the community happy.

Regarding preventing a total collapse of the network

I think this is a sensible approach. Do we have a proposal for a scaled approach at certain milestones, eg rising exponentially every 250 nodes from 2,500 upwards? I know that @JackALaing and @BenVan have mentioned this.

Do we have numbers on the current health of the nodes staked in the network? I.e. what proportion are jailed versus unjailed? I realise that there are over 2k nodes staked in the network at the moment, but I’m not clear as to how many are actually unjailed and servicing relays effectively.

This may be distracting to the main discussion but I also worry about a tail risk whereby more professional node operators start to shut down operations when node running becomes less profitable, but node runners who do not fully understand the economics stay up and running, causing additional network issues due to poor service for applications.

Or is it naive to think that wPOKT will attract those who are not willing to invest the time into running nodes properly on Pocket?

On the last point: keeping the community happy

I think this point is important

We should strive to support every node runner from big to small and I agree that we shouldn’t increase the barriers to entry in terms of the minimum stake at the moment.

However, to push back against the comment below:

raising the proposer allocation from 1% to something higher could make sense as part of a package if also combined with education to new node runners about the benefits of staking a higher sum than 15k POKT per node to increase their chances of earning the validator portion of the relay reward.

It doesn’t need to be in the range of 25-45%, but something in the range of 5-15% could be sufficient to raise the minimum staked per node across the network.

3 Likes
33

A lot of good suggestions have been made thus far. In order to drive the conversation forward, I’m suggesting two adjustment schedules - ways to adjust the servicer allocation based on the node count.

Based on the suggestion to allocate servicer allocation to the DAO in increasing amounts as we hit node growth milestones, I’ve created a simple schedule and calculator that could inform adjustments moving forward:

image
image706×695 16.2 KB

The logic behind the schedule is to dramatically shift servicer allocation to the DAO allocation as node count increases, culminating in a flip in allocations between node servicers and the DAO as the count reaches 5000.

At the extremes, this schedule could be adjusted to 0% allocation to servicers at 5000 (as opposed to the 10% shown above) which would act as an option of last resort. Demonetizing node servicing should be avoided in my opinion and I believe the suggested schedule would properly avoid this scenario.

Although crude, implementation could be handled manually, adjusting the values daily or weekly according to the schedule. The node amount would simply be entered into the calculator and it would spit out the appropriate allocation amounts.

The calculator is illustrated below:

image

As an alternative, I’ve created another derivative of this schedule that splits the servicer allocation 75/25 between the DAO and proposers for discussion purposes:

image
image704×696 16.5 KB

You can find the sources for these calculations here. If you’d like to create your own version, make a copy which will give you edit rights.

1 Like
34

Thanks for pushing this forward Adam.

Could you explain how the Adjustment Factor column is being calculated? Is it just creating linear adjustments between 89% and 10%?

35

Yes, it’s a simple linear decrease based on the number of nodes being run at any given time.

image

We could get more complicated than this, but this is nice and easy for node runners to understand and I think it does the job.

36

this opens up to collective gaming unless the readjustment time is kept random and secret.
node runners could shut down their nodes before snapshot and fire them up right after to enjoy a week of higher rewards than they should get.

Also, not announcing it goes against transparency and I can already see discord blowing up with questions ala “why reward so low :((”
Outside of a controller smart contract i don’t see an easy way to do this transparently though, so secret random readjustments that are communicated after the fact are probably the lowest hanging fruit

Also I would argue for an exponential curve as we don’t want to disincentivize 3000 or even 4000 nodes, they just shouldnt hit the limit, so “punishment” should increase the closer we get to that

37

Can you clarify if these non-consensus servicers are still able to submit claims and proofs for their relays?

38

Yes, this property of ‘servicers’ will be completely intact

39

Okay so here’s the latest:

After running load/functional tests on RC-0.5.2.9 we were able to identify that service and validator separation did NOT work out of the box.

With a small modification to the incoming RC-0.6.0 release we were able to successfully separate Servicer’s and Validators.

Pros:

  1. We can limit the # of Validators until P2P scalability of Tendermint improves.
  2. Servicers can operate independently without the burden of signing blocks

Cons:

  1. If max_validators exceeded, servicers cannot be jailed or punished for being offline. This degradation of service can be quite detrimental to Applications. NOTE: Upcoming updates do solve for offline protection see Timing section below.
  2. Since the implementation is still Tendermint P2P, the scalability problems for non-validators still exists. Meaning at some (unknown) capacity, servicers will have difficulty maintaining service.

Timing:

Con 1 is sufficient enough to provide a case for a delay in lowering the max_validators. By Q3 of 2021, Pocket Network expects to have the solution for Con 1 implemented.
If # of Validators were to exceed 5K by Q3 of 2021, the separation will happen naturally resulting in the introduction of Con 1 to any ‘new’ Validators.

After Con 1 is solved, I believe reducing the # of Validators significantly makes sense to ensure consensus is prioritized.

40

Thanks, Andrew.

With this in mind, I think it still makes sense to control the number of Servicer Nodes as we still don’t know what the count might be that would jeopardize stability. Additionally, we lose that all-important off-ramp for these nodes that comes in the form of jailing - which is the main vector for leaving the network.

I suggest coming up with a new Max Validator cap somewhere under the 5000 validator threshold and a rewards reduction that is complementary to that. That said, it’s no longer mission-critical that we keep total node count under 5K, we may just end up with degradation of service if we do.

@Garandor I’ll see what I can come up with that is expontial, to your earlier point.

41

Here’s what I suggest as a curve:

image

Which happens to have this impact on the allocations:

image

The shape of this curve minimizes the effect to nodes as we approach the limit but makes a clear decrease in rewards as the limit is reached solving for @Garandor’s point.

I would argue for random changes to the parameter and solve the problem of “why rewards so low?” with strong communication about the implementation of this and strong communication of reward allocation adjustments as we go.

Calculator and equations can be found here: PUP 4 - Google Sheets

@JackALaing, I think we need to move on this asap to control node count, which according to the C0d3r node count is 2800 as of writing (pasted below for reference):

image
https://c0d3r.org/NetworkCharts

42

This seems like an elegant solution to me.

If @Andrew is happy with this solution that we’ve all arrived at, I can edit the original proposal and publish it for voting on his behalf.

3 Likes
43

We are less than 60 days from a large unlock of Genesis coins. The sooner we have an agreed upon plan to publish the better. The rumor is already effecting node owner behavior, but in the opposite direction. They are trying to get in “before the slots are full”.

1 Like
44

Thanks for nudging this

cc: @Andrew looks like its your call brother.

45

Already gave the go ahead to Jack to modify the proposal. Seems like a consensus @Patrick727

4 Likes
46

I have two concerns with the current proposal:

  1. Safety: It may not really safeguard the network as much as we want.
    Do we know the number of non-validator full nodes? The reason I am asking is because we may be closer to 5000 limit than we thought. For example, I alone have 2 such full nodes that I use as a block cache for new nodes. There may be others running pocket full nodes as a hobby, or just to test the waters before getting in as a staked validator. Also, a simple attack of just a few hundred nodes can easily push us over 5000. Finally, dis-incentivizing measures move the needle slowly anyways - not every investor keeps up with the latest news. Even if it stops the move of the needle, we would still be perilously close to the limit.
  2. It is in the wrong direction - and this damage to reputation can have long lasting effects.
    2.1) Hundreds of thousands of nodes servicing billions of relays is the vision. Slowing that vision down will send the wrong message to the world of App developers and investors.
    2.2) Node operators, trying to remain profitable, will start penny pinching, and they may start using suboptimal hardware, overloaded eth servers, etc. This can lead to a reduction in the quality of the service, further driving App developers away from the platform.

IMO, a solution at the pocket core level will be safer and also more productive. Isn’t there anything that can be optimized or improved to move it from ~5,000 to ~50,000? I realize, this is an obvious proposal (duh!), and forgive my naivety, also I don’t mean any offense to the brilliant developers of the Pocket network: But why is moving the limit further away with some optimizations just to win us some time such an impossible task to accomplish in the near future?

(edited to articulate #2 better)

47

Won’t the 5K limit be negated with the 0.6.0 update? Is this proposal still necessary? PIP-4: Consensus Rule Change: 0.6.0

With 0…6.0 Pocket will have a set amount of blockchain validating nodes, but will be able to support significantly more Pocket nodes for servicing applications and generating rewards. I’ll call the Pocket nodes that serve apps service nodes.

Is there a limit to the number of service nodes that can be on 0.6.0?

1 Like