This post primarily focuses on how block and chunk producers will be selected once sharding is enabled.
Due to the complex nature of challenges, we decide to enable sharding first with all block producers tracking all shards and we call this version The Simple Nightshade. Naturally it implies that block producers will have to run more expensive hardware, which harms the decentralization of the network. Fortunately, not everyone who stakes will have to track all shards — chunk producers, who are solely responsible for producing chunks in some shard, will only need to track one shard and therefore can run with the same hardware requirement as what we require today. Furthermore, we can have a large set of chunk producers to increase the number of validators, thereby improving the decentralization of the network.
To ground the proposal in concrete numbers, let’s say we have up to 100 block producers and up to 300 chunk producers (these numbers are subject to change). When validators stake, they specify whether they would like to become a block producer or a chunk producer. At the end of each epoch, the proposals are collected and we calculate the new block and chunk producer set by
- If there are
Nproposals for block producers, the top
min(100, N)proposals are selected.
- If there are
Mproposals for chunk producers, then we pool the proposals for block producers and chunk producers together, order them by their stake in decreasing order, and take the first
min(100 + 300, N + M)proposals to be chunk producers.
We will not discuss in this post how block and chunk producers map to each height. There is already an existing proposal on this topic and we can mostly follow the same proposal. Some important things to note here:
- Each shard should have at least a few different chunk producers so that even if a chunk producer is offline, the shard can still keep operating.
- As we can see from the selection process mentioned above, block producers can and in most cases will be chunk producers as well.
- Those who stake to become chunk producers should only be responsible for one shard so that there is no unpredicted increase in hardware requirement. On the other hand, block producers are free to be chunk producers in multiple shards since they already track every shard and it takes very little extra effort to produce chunks.
The total reward will be split equally between block producers and chunk producers, i.e, block producers will together earn 50% of the reward and the same with chunk producers. For each individual block producer, their reward will be calculated as
total_block_producer_reward * adjusted_online_ratio * validator_stake / total_block_producer_stake
Similarly, for each individual chunk producer, their reward will be calculated as
total_chunk_producer_reward * adjusted_online_ratio * validator_stake / total_chunk_producer_stake
adjusted_online_ratio is computed as
min((online_ratio - 0.9) / max(0.99 - online_ratio, 0), 1)
Notice that in the majority of cases
total_chunk_producer_stake will be the same as the sum of all stakes between block producers and chunk producers. Therefore for someone with a large amount of stake, per capita return is strictly better if they stake for block producer.
- Implementation requires adding a new action
StakeForChunkProducer. Because of this, the current staking pool implementation will not work directly for chunk producers and there needs to be a separate staking pool implementation. However, in the longer term this may not be a huge concern since chunk producers will likely not require a lot of tokens and they may be able to stake their own tokens without needing to pool tokens from other token holders.