Block Production V3

In this topic, we are presenting an improvement in block production that would help address:

  • The overhead of message exchange between validators will be cut in half by splitting the committee into two subsets.

  • This opens up the possibility of increasing the number of the committee, which makes Incognito chain more decentralized.

  • The chain retains the same level of security. This is guaranteed because each group will verify the correctness of the other by appending its blocks to those of the other.


For each shard, only a subset of its committee list will be picked to create a new block, as the following rule:

  • Dividing the committee list into two subsets, one for committees with odd indexes in the list and the other for committees with even indexes in the list.

  • Two subsets of committees will take turns to create a new block as the round-robin method.

In this version, a full committee list will be split equally into two subsets. All validators with even indexes will be grouped into Subset 0 or Even Subset and the rest is grouped into Subset 1 or Odd Subset.


The Above picture illustrates 2 subsets from shard0 take turn to create block:

  • Block 80,82,… is created by subset 0
  • Block 81,83,… is created by subset 1

Thank you!


32 validators of each shard are split into 2 subsets of 16 and each block will be validated by only 16 validators? How is this supposed to retain security? Correct me if I’m wrong.

Plus, how are rewards calculated when spliting the nodes? Will rewards be the same as the regular method?

Sorry for the confusing.
If there is any application trusts the block by its aggregated signature without validating its content, then this mechanism reduces security.
This special case is beacon block, the signature is used to unshield asset to other blockchain. There will be secuirty concern if we apply this to beacon chain.
However, this mechanism applies only to shard, and when inserts shard block the node need to validate the correctness of the block, so malicious shard block will be rejected eventually. And currently, there is no business logic relies on shard block signatures to make security-related decisions. That is why we say the security still retains.

Regarding the reward, a committee from a subset is rewarded based on the number of the blocks created from that subset.


Do this imply that with the same probability of being chosen, a validator now only receives half the regular reward?

Actually, it is the same. The reward for a subset will be half the regular, but when it is distributed to only 16 nodes, the reward per node will be same.


As the block, created by one subset, will be validated by another subset before inserting. In the worst-case, if one subset creates false blocks continuously, none of these blocks can be finalized. At the end, the Beacon chain would apply slashing penalty to the faulty nodes.