I share the need to increase the Pocket Network security. Changing the number of MaxValidators might seem a valid way of doing so, however, the current blockchain conditions do not allow this.
TL-DR:
I do not support this proposal due to (please read justifications below):
- While the block size seems to be low enough, in the case of an increase in TXs, there could be problems with lost TXs. There is no room to increase the number of validators if we want to stay in a 96% confidence zone.
- Consensus will be more difficult to reach.
- Validators nodes requirements will increase due to gossip overhead and probably the new 1000 validators wont be able to handle this (as they did not choose to be validators, this has happened in the past with PIP-22 up-staking)
- Increased blockchain disk size (increases costs, disk is very expensive on cloud instances).
- The number of validators is already outside the Tendermint normal number of validators (1000 of Pocket vs 150 in Cosmos).
- Increasing validator number will reduce the average validator rewards. Reducing the rewards of servicers to remedy this is something that I find unfair (just an opinion, since it is not part of the proposal).
Justification
1 - Block Size
I want to give some insights on block size calculation and current status. This will help us understand where we are. The data was obtained from POKTscan, where you can find the historical block size. At first glance you will see that we are really close to 4 MB:
Fear not, this is not RAW block size that @msa6867 is writing about. The actual raw size is approximately:
RawBlockSize = BlockSize - 800 KB
Using this corrected value we analyzed the current proposal. You will find the data here.
Currently the block size limit (formally introduced in this PR) is set to 4 MB.
Since 2022-10-01, the size of the blocks has oscillated far from this limit:
The actual block size distribution during the observed time period is:
The block size is not near the given limit. It is outside the 96% region (if we assume Gaussian distribution).
If we increase the number of validators to 2000 (adding 1000 more), we can expect an additional 212 KB of block size. According to PIP-7, the footprint of validators on the block size is calculated as:
ValidatorsBlockSize = NumOfValidators * 223 Bytes
Then:
ExtraValidatorsBlockSize = ExtraNumOfValidators * 223 Bytes = 1000 * 223 Bytes = 223000
If we introduce this change, the new block size distribution will look like this:
In this scenario, the 4 MB block size is still outside the 96% region.
To recap, these are the expected values for current and proposed scenario:
| scenario | Mean Size | High Size (96%) | Free Space (mean) | Free Space (high) |
|---|---|---|---|---|
| Current | 2.93 MB | 3.52 MB | 1.07 MB | 491 KB |
| Proposed | 3.15 MB | 3.74 MB | 870 KB | 266 KB |
You will notice that I included two new columns, the Free Space, (mean) and (high). These columns represent how much extra block size is left from the 4 MB block space that is the current limit. This is important since this Free Space is in fact used to store the TXs. During validation, the validator will grab as many TXs it can until the block is full. If we add too much validators, we will not have space to include additional TXs. Moreover, the TXs that are not included in a block are only keep in the mempool for two blocks:
Mempool Tx Eviction, TxmaxLife = 2
In conclusion, yes, we can increase the number of validators in terms of block size. But we are reducing the size of the block to include new transactions. If the number of TXs increases we will be too close to the 4MB limit, and TXs will start to be pushed to other blocks or lost.
2 - Consensus Problems
Increasing the number of validators will create consensus problems. We had our share of problems with only 1000 validators trying to push new features (such as non-custodial). Also, it will create even more problems in cases of chain halts (god forbid!), where reaching a rapid consensus is critical.
3 - Gossip and Peering
The Pocket Blockchain is based on Tendermint for its consensus mechanism. It is known that peering is not its efficent. Increasing the validators size will create even more problems here.
Also, the gossip of the increased number of validators will require more computing power from the validators. When increasing from 1000 validators to 2000 validators, many nodes that are not probably prepared to be validators will suddenly become one. This can cause instabilities in the network.
4 - Disk Size
More validators mean more disk usage for the blockchain. This detail should not be overlooked.
5 - Validator number out of specification
The Tendermint team only has 150 validators on its Cosmos SDK. It is hard to find some Tendermint application with more than 300.
I think that we are currently running Tendermint with a number of validators that is way outside its specification. This can be risky and stability is crucial for our network. We are not only providing a token, we are running a service that must be always online.
P.S.: Thanks to the people that helped me gather this info, it was quite difficult!