PIP-7 Consensus Rule Change – Validator/Servicer Split & Validator Consolidation

Attributes

  • Author(s): @Andrew

  • Implementer(s): Pocket Network Inc.

  • Category: Protocol Upgrade / Parameter Change

Summary

Currently validator nodes and service nodes are bundled; nodes eligible for servicing are also eligible for block production and vice versa. Pocket Network Inc. is proposing a change to this with the RC-0.7.0 release to address block space limitations that we are fast approaching. Before Pocket reaches 18k validators, we need to implement a new consensus rule that will bench validator nodes outside of the top MaxValidators limit but allow them to continue participating as service nodes (processing relays). In combination with this, we are proposing that MaxValidators should be lowered from 50k to 1k, which means only the top 1k staked nodes would be eligible for block production, while every other node would be eligible to continue servicing relays.

Motivation

At 18k validators, we will run out of block space for transactions as per the following formula:


MaxTxBytes =

4MB -

(

653 Bytes (HeaderBytes)

+

11 Bytes (Amino Overhead)

+

NumOfValidators * 223 Bytes

+

NumOfEvidence * 484 Bytes

)

Paying attention to the NumOfValidators * 223 Bytes portion of the formula we can see that at 18k nodes the amount of votes for consensus in a block will reach 4.01400 megabytes which exceeds our max block space of 4mb.

Specification

RC-0.7.0 implements an oft-discussed Servicer/Validator split, which cleanly benches any validator nodes that exist outside of the top MaxValidators staked nodes, while still allowing them to participate as service nodes, processing relays and earning 89% of the block reward. Service node counts can remain unbounded; in fact, lowering the validator count enables service node counts to go far higher than they will otherwise.

In addition to implementing this consensus rule change, we are also proposing that the MaxValidators parameter be reduced from 50k to 1k. This would mean that the top 1k nodes (by stake) would be the only nodes eligible to produce blocks, while every other node would be able to continue servicing relays.

Rationale

  1. Splitting Servicers & Validators

Splitting the roles allows us to enforce a safe hard limit on validator nodes without closing out community members from participating as service nodes. We have observed that the majority of node runners optimize for service rather than block production, so we don’t expect this to be an unpopular change. To clarify on that point, optimizing for service means staking your POKT across many nodes each close to the StakeMinimum, which is currently 15k POKT, while optimizing for block production means consolidating all of your POKT into one node.

  1. Lowering MaxValidators from 50k to 1k

Splitting servicers from validators means nothing for the 18k validator limit if the protocol is being told not to split until the 50,000th validator. Thus, while we normally wouldn’t bundle a parameter change with a PIP, this parameter change is necessary for the PIP to have any effect.

Why 1k? We know that most node runners are optimizing for relay rewards, by keeping their stakes close to the StakeMinimum. Since selection for block production is proportional to stake size, these smaller node runners are already not being selected very often to produce blocks. And as far as we can tell they don’t mind this because service rewards are their top priority. This is easily demonstrated by the node stake distribution. If you sort nodes in descending order of stake size, Node 400 is 16k POKT, Node 150 is 50k POKT, Node 100 is 444k POKT, and Node 50 is 1M POKT. If you make MaxValidators 1k, the smallest validator will have 15.5k POKT staked. Thus, although only 1k nodes will be eligible, being eligible will only cost >15.5k POKT according to the current node distribution.

If we are able to to lower MaxValidators to this level without disrupting the economics, this is an opportunity to achieve greater consensus efficiency with no downsides.

Viability

Functional, integration, unit, load, and simulation tests will be completed leading up to this upgrade. These will be found in the release notes, which node runners will be able to audit prior to upgrading their nodes.

Implementation

  1. If this proposal is approved, and after testing has taken place for BETA-0.7.0 on Testnet, RC-0.7.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.7.0 using the “Consensus by Version” chart displayed here or the equivalent “Node Versions for Staking Power” chart displayed here.
  2. Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors and they will pass this height to the chain through the pocket gov upgrade transaction.
  3. The upgrade height chosen by the Foundation Directors will be communicated in advance to ensure node runners are prepared to react if necessary. A time will be targeted that maximizes the availability of node runners, accounting for all time zones and working hours.
  4. Once the upgrade has executed successfully, the Foundation Directors will submit the parameter change transaction to lower MaxValidators from 50k to 1k.

Audit

There will be no external audit, refer to Viability.

Copyright

Copyright and related rights waived via CC0.

6 Likes

I support this proposal.

Faster smaller block production, encourages higher stake which helps keep tokens locked and acts as a stabilizer on the marketplace, less storage requirement (which has been a major issue for our bare metal nodes).

There is some discussion floating around which perceives this as “cutting off” minimum stake nodes from earning validator rewards, so I recommend running some economic models to distribute to the community which shows the relative value of participating in validation versus servicing in the proposed model.

4 Likes

Thank you, Andrew.

This is quite a significant change on paper. However, in reality, nodes are not optimising to be the block producer, as per Andrew’s comment.

I fully see the practical need for this change and will therefore support it.

In parallel to these changes, I think it is essential to kickstart an ongoing discussion around the “optimal” number of validators for Pocket Network.

Maybe, it is correct to limit the number of validators to 1000 and have an uncapped number of service nodes. But, maybe, it should be more.

If we want to optimise for great competition for the fixed number of validator slots - a quasi Harberger’s tax - we will most likely need to increase the block reward. For example, I am running many nodes in my personal capacity (along with a business partner) and via my role at Eden Block. My napkin maths tells me that increasing the minimum stake (to 15.5k POKT per node or above) isn’t worth it with only a 1% block reward for validators.

While this isn’t an issue, for now - we should move on with the proposed change sooner rather than later - a more profound discussion around this point is necessary. We all want to ensure that any future parameter changes to the max validator number and the validator portion of block rewards are seen as legitimate and a proactive researched decision, rather than reactive.

1 Like

For those less-technical, is there somewhere where we can visualize the following:

  1. Current (and always-updated) snapshot of stake size per node? (the entire node ecosystem)

  2. A sliding-scale chart that showcases the value of the 1% validator reward based on variable POKT price?

1 Like

I think these datapoints would be quite easy to add to POKTscan and I’ve suggested as much to Jorge. I envision the homepage having Min Validator Stake, Avg Validator Stake, Avg Node Stake, etc.

As for modeling the value of validator rewards relative to servicer rewards, this is definitely something we can and should provide more visibility into moving forward. It requires modeling out the probability of being selected for validation/service, which is a function of the number of service nodes (for service rewards) or a function of your stake compared to the average stake (for validator rewards).

@adam has put together an initial model here. Let him know if you have any feedback on the model and I’ll also be sure to embed/link this in the docs for all node runners.

This model should also help us to refine the ProposerAllocation to incentivize competition for the 1k validator slots, as @Dermot has highlighted. I would recommend that we observe changes (or lack thereof) in node behavior after this change, then if consolidation doesn’t happen to the degree that we desire, we can use the economic model to inform a change to the ProposerAllocation parameter.

Since there are no objections to the contents of the proposal itself, just requests for educational models and further discussion about the ProposerAllocation parameter, I’ve gone ahead and put this to a vote.

https://gov.pokt.network/#/proposal/0xd2e704b11e2a35d1ad60e9763c890754c4d87af40b1b7afaca415a6bb4ac398d

4 Likes

This proposal has passed!

https://cloudflare-ipfs.com/ipfs/QmSm9BR2kCfnS4LBqomQKhQ9uViMVsKmy6khuygBikNouU

1 Like

Hello, let’s suppose I have many POKT, around 500k-1M. What do you think will be more profitable, being a top 1000 validator or having multiple service nodes with 15.5K POKT?

I have done some math and, with the current number of nodes in the network and assuming there are only 1k validators, being a validator looks more profitable:

For 18k nodes, 17k are service nodes and 1k are validator nodes.
The service nodes earn 89% of the block rewards, and the validators get 11%.
For each 1000 POKT of block rewards:

  • 890 are distributed among 17k service nodes → 0.0523 POKT per service node
  • 110 distributed to the 1k validators → 0.11 POKT per validator

Is my math correct or am I missing anything? I’m not sure if the RPC service rewards are included in the block rewards or not.

Many thanks