Background
There is some ongoing work on changing the validator selection algorithm to introduce chunk producers, thereby increasing the total amount of validators in the network. This post, however, will focus on a somewhat different approach that will allow us to have many more block producers.
Motivation
Today the number of seats for block producers is limited to a rather small number, which is not great for the decentralization of the network. This post presents an idea that, if implemented, will increase the number of possible block producers in the network.
Idea
The reason why we limit ourselves to a relatively small number of validators today is mostly because:
- Reed-Solomon code computation will become slow
- Distributing chunk parts to thousands of validators may incur too much delay and cause some validators to fall behind.
- Approvals take time to collect
- Verifying a lot of approvals may be slow
However, we don’t necessarily need to assign a part to every block producer. In fact, we can, for each block, sample the set of block approvals from the entire block producer set and only assign a part to each of the sampled block approver. We can use the block vrf output as the randomness seed for sampling. The exact algorithm here is yet to be determined. For example, we can always fix the top 2/3 of the stake and sample a fixed number of block approvers from the rest of the validators. Or we simply sample a fixed total number of block approvers according to the stake distribution. Notice that here the condition for block production does not change – we still need more than 2/3 approvals (weighted by stake) to produce a block. Therefore consensus is not affected.
For most of the existing proof-of-stake blockchains, it is the case that a few validators own the majority of the stake. Therefore, we assume here that the stake distribution has a long tail. With that assumption, we know that the number of parts a chunk producer need to compute and the number of approvals required are bounded by a relatively small number and the issues mentioned above won’t create too much trouble.
Block producers will be selected based on their stake, similar to what is proposed in the new validator selection algorithm. To prevent abuse of proposals, we can a lower bound, say, 10,000 NEAR on the amount of stake required.
Drawbacks
- The likelihood of the network getting stalled increases because it could be that there are more than 2/3 of the stake online but no block can be produced because some selected block approver is offline. While this is certainly a possibility, if we always end up sampling the top 2/3 of the stake, it does not have much impact in practice.
- Validators can split their stake. In the worst case scenario where everyone stakes the same amount, this scheme does not help. We can set some upper bound on the number of validators per epoch, or even compute the bound dynamically based on the staking proposals received. In addition, since we do not change how validator rewards work, it is not clear why a validator would want to split their stake.
Alternatives
Another idea is to make the data availability providers a subset of the block approvers, since the main bottleneck seems to be on erasure code computation and chunk distribution. More concretely, we can require that for there is a fixed number of data availability providers for each block and require that sufficient number of them approve the block to guarantee data availability for chunks. Since data availability for each block is independent and that the providers are sampled randomly, even though the total stake for data availability will be smaller, it is still difficult for an adversary to corrupt enough block producers to undermine data availability guarantees.