Attributes:
-
Author(s): @msa6867
-
Parameter: MaxValidators
-
Current Value: 1000
-
New Value: 2000
Summary:
Vote on PP-14 (Increase MaxValidators to Improve economic security) was halted on July 3 to allow for more consensus building on parameter value. The main area of concern expressed regarding the proposed value of 5k in PUP-14 was blocksize bloat caused by adding 4k new signatures to the block.
Moving MaxValidators to 2000 rather than to the value of 5000 proposed in PUP-14 adds one quarter this number of new signatures to the block as compared to PUP-14. Such level of âblock bloatâ in manageable and worth the increase to network security that comes with doubling the tokens staked to Pocket Network validators.
Abstract:
The recent implementation of PUP-19 and PIP-22 caused a 4-fold increase in POKT-denominated network securitization compared to June 2022 levels. However, due to market conditions, the US dollar-denominated vulnerability to the Pocket Network remains an ongoing concern and has not changed much from June 2022 levels.
Vote on PUP-14 was deferred, in part, to give time for the system to absorb PUP-19 and PIP-22/PUP-21, as well as to work out the engineering concerns related to raising MaxValidators. Those concerns centered on blocksize bloat due to added signatures. The system has had several months to absorbed PUP-19 and PIP-22, and it is now time to revisit the question of raising Max Validators.
Max blocksize in v0 is 4MB. At the time of PUP-14 submittal, average blocksize was approximately 2.6 MB. Adding 4k validators as per PUP-14 would have added approximately 880 kB (~220 B per signature) to the block, which equates to an encroachment of two-thirds of the headroom between the current average blocksize of 2.6 MB and the maximum blocksize of 4 MB. On the other hand, raising MaxValidators to 2000 only adds ~220 kB to the block and thus only about 15% of the headroom between the current average and the maximim size.
Furthermore, it was shown in the June time period, that while blocksize did occasionally hit the 4MB limit, this was due to spiky outliers rather than due to a gaussian distribution of block sizes. Thus raising average block size by 220 kB should hardly change the probability of a block bumping against the max block size.
It is felt therefore that raising MaxValidators from 1000 to 2000 will not have negative impact on the system. This can be confirmed by checking that current distribution of blocksize has not changed substantially from the June time period.
Note that raising MaxValidators from 1000 to 2000 will have a dilutive effect on per-validator rewards, causing the probability of a validator being selected as a proposer to be cut in half, and thus for the expected monthly proposer rewards to be cut in half. Raising ProposerAllocation to a value greater than 5% could ameliorate this reduction at theexpense of servicer rewards, but the author declines to suggest raising ProposerAllocation as part of this proposal, as it is felt that further reduction to servicer rewards cannot be justified at this time.
Motivation:
By itself, raising MaxValidatprs from1000 to 2000 will approximately double the network security in terms of USD/POKT it will take to launch a DoS or Byzantine attack on the network. In conjunction with PUP-27, network securitization would be increased by a factor of approximately 2.3. While this may seem small compared to the 10x or more increase in securitization called by many in the community, it is a good start and it is low-hanging fruit that can be achieved without distracting development team from other duties related to upcoming transition to v1.
Rationale:
Setting MaxValidators to 2000 is a good balance giving significant boost to network security without triggering major engineering concerns associated with raising it further.
Dissenting Opinions:
Copyright
Copyright and related rights waived via CC0.