Komodo notarization code differences in zebra

A note how komodo notarization code works differently in zebra

Zebra and Komodod code work differently in block validation:
The komodod validates blocks (and therefore processes notarization transactions) when the best chain is activated. The zebra code validates all blocks when they come and this is a two step process: non-contextual block validation (without connection to the previous chain) and contextual validation (when block is checked against the previous chain). The best chain in zebra is simply one of the currently valid forks with the most power.

This creates differences in processing of the last notarized height (obtained from the regularly created notarization tx, nota, by the komodo notaries) in dPoW code both in komodod and zebra.
In the komodod the dPoW code does two things:

• The dPoW code disables adding a block if it is added to a parent below the last notarized height.
• It also disables activation of a fork of the best chain if this fork branches off below the last notarized height stored in the latest nota.
  

Because of different best chain selection principle the similar dPoW algorithm in zebra works differently:

• It disables block creation below the last notarized height, the same way as in komodod
• But the second part of the validation does more checks: if branch with the new block has more power than the best chain the validation code also checks that the fork point from the current best chain is not below the last notarized height. But if it is still below the last notarized height we cannot assume that the best chain has a nota and we need to check that the current branch has a nota - and in this case we should consider it as a valid branch.
  

With the zebra's dPoW code we allow to temporarily have a best chain with no nota and we just prohibit for such chain to grow. In the komodod the best chain cannot be activated when it does not have a nota but in zebra the best chain may exist for some time without a nota if it has branched off earlier than the branch with a nota came.

There are several questions with this possibility in zebra:

• Should we additionally check that the best chain candidate has a nota in best_chain() if a nota really exists in the non-finalized part? I belive so and this is already made in the komodo zebra main branch (otherwise we could have different best chain in komodod and zebrad)
• If it is allowed to temporarily have a best chain without a nota it may create a danger for losing funds if a user ever sees a unnotarized branch as the best chain
• As zebra finalizes the chain part in memory (non-finalized part) when it grows over 100 blocks and stored only the best chain, could it be possible that it could store the best chain without a nota? Probably yes, when the node received the fork with a nota but it already has a longer part without a nota. One more point to fix best_chain() in zebra.
• What if the validated branch (with no nota) forked not only from the best chain (with no nota) but also forked from yet another branch which has a nota. Seems with the current algorithm we are checking against not the right branch: we should always check against the branch with a nota.