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
- 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.
- Lowering
MaxValidatorsfrom 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
- 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.
- 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 upgradetransaction. - 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.
- 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.
