Hi,
We are closing in on HC node implementation. It will do everything described in the whitepaper and could be a subject of further optimisations. The goal here is making a stable HC framework that can be improved further on. What relates to the node, we have two major tasks to implement still: lazy leader and parent chain reorganisations.
Lazy leader
This might be a poor choice for a term but I am following the Whitepaper. A leader who does not produce a key block is called “lazy”. In a case of a lazy leader, any delegate can produce a key block on behalf of them. Subsequently, the network is most likely split in the same way as in a generational fork. Therefore, such a situation shall be resolved the same way. This also means it makes sense to produce key blocks even while not being a leader.
In a case in which a lazy leader submits a delayed key block, it is up to the network whether to consider it. One may argue that a syncing peer would not have a proof that the leader was ignored due to their laziness, but it is not different from blacklisting. This behavior is available in almost every PoW and PoS blockchain and in general does not cause threat, therefore we do not consider it an issue as well.
I say it could be a poor term as we later on discovered that it is a part of a larger class of potential problems, one that includes the case where no staking validator produces a commitment on the parent chain. In this case we have no lazy leader at all but still follow the same approach. In this context - a further renaming of the term is likely to happen.
This is actually implemented already but there are some bugs and race conditions to be fixed still.
Parent chain reorganisation awareness
The child node elects the next leader depending on the set of commitments and the hash of the block that included them on the parent chain. If there is a fork on the parent chain that replaces the current one - the order of the the commitments could be different but it is guaranteed that the hash of the new block would be different. This all means that whoever was elected as a leader on the child chain node is likely not a valid leader anymore. This means that any reorganisation on the parent chain will propagate in (every!) child chain and will revoke blocks that belong to leaders that are suddenly invalidated. There are two approaches for this:
- Let the parent chain fork propagate to all child chains and revert the some of their blocks respectively. This is what we will implement - it is not optimal and could be improved later on
- Devise a voting mechanism so staking validators can negotiate between themselves sticking to the current child chain and not allowing the parent chain fork to impact the child chain. This is a big project by itself as would mean that any new syncing node must allow invalid blocks by invalid leaders to be accepted only to find a vote that supports this fork further down the chain. This is much more advanced approach but opens the doors for many more issues and attack vectors. This could be the optimisation of (1) but would need some heavy R&D.
Stay tuned for more news!
