Probability of orphans at the end of observers set epoch

[HaySayCheese]

Due to the chosen tokenomic model, observers are selected for some period of time (observers epoch, at the moment, the epoch is approximately equal to 1 week). epoch is measured in ethereum blocks, so each one observer's generated block must contains anchor to the ethereum chain (ethereum block number, during which this block was generated).

At the end of the epoch, next vote round should be done in ethereum, and the next observers list should be formed. This process is expected to be endless, so the observers list would be refreshed aproximately every epoch period.

In this model, there are 2 cases possible on epoch change:

Definitions

Current epoch: CE
Next epoch: NE.
Scenario: CE reaches the end. NE is several ethereum blocks from beginning.

Case 1: Majority of observers from NE is the same as from CE

In this case (if observers are not malicious) orphans in observers chain are not possible. Even if some part of observers chain has been changed, the majority set was not changed, so even in case if some block was generated after epoch change with observers set from CE - it is OK (it would pass validation in future, due to corresponding majority), and this block would not be dropped. In this scenario epoch change would be done softly (Soft Epoch Change).

Case 2. Majority of observers from NE significantly differs from majority of CE

In this case orphans in observers chain are possible. Due to the significant majority set changes, for some short period of time, there would be present 2 concurrent majorities sets, that are able to generate independent blockchains. This is due to Observers and GEO nodes notifications lag: there would be a period when some GEO nodes would already be informed about epoch change, and some would still know nothing. The same is true for observers.

In case if some GEO Nodes, that knows nothing about epoch change, would send their Claims to the majority from CE - this claims would be processed, so the GEO Nodes would receive OK response, but this claims would not be included in the final main chain, so there is a syncronisation failure possibility between GEO Nodes and Observers Chain. In worst case, GEO Nodes would commit the operation that would be dropped away from the observers chain as an orphan, but because GEO node thinks it is comitted -- it would never check it again and even might drop the TSL from it's internal storage.

This scenario is Hard Epoch Change.

The proposed solution

GEO Nodes must be able to predict the type of epoch change (Soft vs Hard) significantly before the change would happen. To do this, we should maintain 3 epochs in the same time:

• Current Epoch;
• The Next Epoch (that is known already, and no changes are possible);
• The Epoch Candidate (changeable observers list, that would freeze when it became Next Epoch).

In case if next change is Hard Epoch Change - GEO Nodes must ensure proper epoch change before any communications to the chain.

What should be done

• Claim period (period from transaction starting to the last block to which it might be included) must cover Hard Epoch Changes.

• GEO nodes must maintain epochs list.

• Observers must maintain epochs list.