PUP-4: Adjust DAOAllocation to Limit Service Node Counts

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.


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

Thanks for nudging this

cc: @Andrew looks like its your call brother.

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


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)

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

This is an interesting and well-made point. However, I’m not sure it’s an argument to NOT go ahead with the proposal, but rather to be more strict about the measures we’re taking. Which seems to conflict with your next argument about not taking any economic measures.

Apps care about reliability above all else. I would think that our DAO being thoughtful about the reliability of the network sends a positive rather than negative signal.

Not every node operator will keep updated with the news, but they’ll surely be monitoring the profitability of their node? There might be a lag for some of them but when they realize their service node rewards are dropping, they’ll take notice and enough should spin down nodes in response to keep our node count at a reliable level.

We have a solution at the Pocket Core level. PIP-4: Consensus Rule Change: 0.6.0 introduces a change that means any nodes beyond the 5k limit will become just service nodes. However, and this answers @shane’s question too, service nodes are still likely to face the scalability problems that Tendermint P2P is known for, so we still need to go ahead with this proposal to help prevent possible degradation of service.

The limit is “unknown” but we should generally be conservative where the reliability of service is concerned, especially since we already have more than enough nodes to service the apps that we’ll be servicing in the mid-term.

@bulutcambazi A general rule of thumb would be to assume that the developer’s have already thought about optimizations like you describe and that they’re working to the best of their ability to optimize our network to balance scalability and reliability without breaking anything along the way. The separation of validators/servicers in 0.6 is a monumental achievement that is coming a lot sooner than we anticipated and the core devs are working on many other improvements that will help realize the full-scale vision that you describe.

1 Like

The only node operators who will do this are those using cloud services. Those running nodes on their own hardware, whether at home, in an office, or racked in a datacentre, have a sunk cost and I doubt those nodes will spin down regardless of dropping profitability.

I think it’s safe to assume that most of our nodes are currently being run in cloud services, especially with the popularity of our third-party service providers. Not everyone is as awesome as you :wink:

1 Like

Even at 9% of rewards going to node runners, I believe it would still be profitable to run a node on AWS if you have multiple nodes.

In the previous month, the average node earned about 35 POKT per day at the 89% payout. If we move that to the maximum point of the curve where nodes earn 9% payout, the average node would earn 3.5 POKT per day or 105 POKT per month.

You can do the math with the current OTC price or another imaginary price, but I believe that would still make an AWS node profitable given that multiple Pocket nodes share the more expensive Ethereum node – even at the maximum point of the curve. At any point above 15% payout, I’m positive it is still profitable to run a cloud node and probably would not encourage anyone to shutdown, even people paying retail prices to resellers like C0d3r.

I believe this limit only applies to validators, hence the 6.0 fix of separating staked validators that participate in consensus from service nodes. @Andrew, correct me if I’m wrong here.

Profitability depends on

  • relays and POKT price - yesterday, there were 2.5M relays. With closer to 5000 nodes, that’s 500 relays per day, 5 POKT total, 0.45 POKT for the validator. That’s about $10 a month, even with very optimistic OTC valuation…
  • cost of running nodes - this is increasing because now new networks are being added (Kovan, Rinkeby, etc. so it is not just a Eth server anymore)

If this is the case, then it’s irrational behavior from those node owners.

It will not be the first 5,000 nodes that are validators, it will be the top 5,000 stakes, so it won’t matter when you get a “slot” and you won’t lock it in.

Also, service rewards are the bulk of profitability for nodes right now, not block rewards.

The only thing I’ll add here is that I would expect that node runners will only follow the relays as it’s the only way to maintain profitability. As we have relay diversity across networks, it’ll only make sense to spin up infra for profitable chains.

To your point about node rewards, I’d be hard pressed to keep my nodes running at the ~5000 node validator limit with that sort of POKT reward. I’d focus my nodes on the networks that provided the most profitability.

I fully agree that it is irrational behavior. That is why I pointed it out. We need to get some clear communication out there to stop the rumor reaction.

1 Like

I agree with Ben. We need more clear communication. We also need clarity on:

  • How long this will last?
  • What happens when 5000 validator limit is no longer needed? Do we go back to 89% allocation or some other number?

If you’re asking how long the measures outlined in the finalized proposal will last, assuming the DAO approves them, they’ll last until the DAO passes another proposal to revert them or adopt a new parameter value.

This will be up to the DAO to decide.

Thanks, I understand that. I was asking in terms of a time frame. Next 3 months? Next 6 months? More than a year? Sorry, maybe this is an unfair question, I don’t know the difficulty of the changes needed…

The protocol devs are focused on the upcoming 0.6 release (referenced here) and will be releasing a roadmap addressing these concerns after the release.

I’ve now edited the proposal to incorporate the new solution and attempt to aggregate everyone’s analysis. There are still outstanding arguments for/against different solutions, but we’re at the stage now where we should poll the DAO’s voters to get a more tangible measure of their preferences.

The vote will start tomorrow morning 8am EST and last for 7 days.