Do not produce an empty domain block

[NingLin-P]

Do not produce an empty domain block when there are no corresponding domain bundles in the consensus block, a consensus block is no longer mapped to an execution block in one-to-one, this required more than refactoring but also some changes to the chain fork handling.

Currently, to handle chain fork properly, when a new best primary block is imported, we use the primary block that drives the best domain block and the new best primary block to compute a tree_route, and use this to determine the primary blocks that need to process and the initial domain parent block that we should build on top with.

(For convenience, in the following, an empty primary block refers to the primary block that does not contain the corresponding domain bundles)

There are some issues if we just simply skip producing an empty domain block:

• There may be some duplicated processing of the empty primary block
  • The primary block that drives the best domain block may not be the latest processed primary block, as there may be some empty primary blocks that got processed after the best domain block, and these blocks will be re-processed if the common_block is before them and in the same branch
  • This does not affect correctness but performance
• We can not find the initial domain parent block if the common_block of tree_route points to an empty primary block

To resolve the above issue we can replace the (domain_hash, primary_hash) mapping with:

• (best_domain_hash, latest_primary_hash) mapping, updated after a primary block is processed, if it is an empty primary block the best_domain_hash will be the same but latest_primary_hash will be updated.
  • This is used to get the latest processed primary block that is used to compute the tree_route
• (primary_hash, best_domain_hash), a reverse version of the above mapping, updated after a primary block is processed
  • This is used to find the initial domain parent block by the hash of the common_block

cc @liuchengxu

[liuchengxu]

Make sense to me.

Just to give some more context for others interested, the principle of following the consensus chain forks remains unchanged. The general idea is to:

1. Find the consensus block that derives the current domain best block as from, as the new consensus block as to to calculate the consensus chain tree route (from -> to).
2. Once we know the common consensus block and enacted consensus blocks, we find the domain block corresponding to the common consensus block as the domain base block and process the enacted consensus blocks from there.

Previously, one consensus block means there is a corresponding domain block, $B^{consensus}_N$ => $B^{domain}_N$. Now we don't produce new domain blocks if there are no bundles in the consensus block, which means multiple consensus blocks can be mapped to the same domain block

• Non-zero bundles in the consensus block N, $B^{consensus}_N$ => $B^{domain}_n$
• Zero bundles in the consensus block N+1, $B^{consensus}_{N+1}$ => $B^{domain}_n$

1. The first step is to find the last consensus block that derives $B^{domain}_n$.

   It is $B^{consensus}_{N+1}$ in the example above, hence we need to track the last consensus block hash that derives $B^{domain}_n$.

   Use $B^{consensus} _{N+1}$ as from to calculate the consensus chain tree route, then we get the common consensus chain block $B^{consensus} _{common}$ and the enacted consensus chain blocks.

2. The second step is to find the domain block corresponding to $B^{consensus}_{common}$.

   $B^{consensus}_{common}$ => $B^{domain} _{?}$, therefore, we need to track the corresponding derived domain block whenever a consensus block is processed even if the bundles are zero.