PUP-6: Recend PUP-4

Proposals Parameters
1

Attributes

  • Author(s): BenVan

History

An exponential reward reduction curve was approved in PUP-4 which has the effect of reducing relay rewards to near zero as the number of validator nodes approaches 5,000.
PUP-4: Adjust DAOAllocation to Limit Service Node Counts

As a result of improvements in software and configuration which have occurred after the adoption of PUP-4, the current state of the peer-to-peer network is no longer in need of this drastic change in economic policy.

Abstract

At the time of the PUP-4 vote, the network was experiencing rapid growth in network nodes AND increasingly poor performance of the peer-to-peer network. With block times and failed proposer blocks increasing. PUP-4 was approved as an emergency measure to stop node count growth. It was never meant to be a permanent parameter change. Rather, it was meant to be a stop-gap measure to protect the network until such time as the danger of consensus failure and/or chain halt do to network congestion has been successfully resolved.

At this time, and resulting from a combination of improvements in software, configuration and community cooperation, the network is no longer displaying signs of distress. In fact, - judging by the block interval and number of consensus retries - the network is healthier than it ever has been.

Motivation

The network is about to experience another significant increase in node count due to a coin unlock scheduled for May 15th. This node count increase is going to happen with or without removal of the PUP-4 reward reduction.

We are in for one hell of a Public Relations nightmare if 1 or 2 thousand nodes join this network at the same time that rewards for all nodes get cut to near zero. Let’s not create this issue if it is not necessary. It is proposed that we nullify PUP 4 and continue to monitor and improve network performance in case a similar proposal to PUP 4 is needed in the future.

Dissenting Opinions

TBD

Specific Actions to be voted on:

  1. Nullify PUP 4
6 Likes
2

I’m comfortable with rolling back PUP-4 (recending) given the current P2P scalability at 3.5K Validators in the network. I move to reevaluate the circumstances at 5K validators if P2P circumstances stay constant. If there is an observable instability in the number of Missing/Byzantine Validators, block timings, or jailings, I’d expect a proactive evaluation and subsequent reinstatement of a ‘PUP-4 like’ solution.

2 Likes
3

I think the factor that needs to be addressed here is the lack of clean exit from the network of Service Nodes. Because of the split between Service Nodes and Validator nodes, Service Nodes can no longer gracefully exit via jailing which could have an overwhelmingly bad effect on Pocket’s quality of service as we exceed 5,000 nodes. Simply put, Service Nodes will degrade network quality without a mechanism to gracefully exit the network for maintenance or downtime. Without this, I’m concerned good nodes could become overrun with poor quality nodes that aren’t active on the network.

To my knowledge, there’s no fix for this at this time (it’s coming in a future release).

@AlexF is there anything the gateway can do in this regard?

4

How could we rely on the gateway as a protective mechanism without it being a centralised way of solving the problem over which the community has no power?

5

That’s a fair point. I was viewing that as a stop-gap measure until the next release fixed that problem.

1 Like
6

This is up for a vote now.
https://gov.pokt.network/#/pokt-network/proposal/QmPRcpZdgBWtBf9XB8vAm8SvqnGUsvYM9UDA3hp5JfS9Y8

1 Like
7

This proposal has passed with 8 yes votes and 0 no votes. The results of the vote can be seen at the link @BenVan shared.

I’ll now close this topic.

8