Table of Contents
<aside> ⚠️ This document outlines an approach to spork-less EFM Recovery using injected fallback epochs. Due to an inability to easily generate new cluster QCs for these fallback epochs, we have decided to investigate a different approach. See Spork-less Epoch Fallback Recovery Design II: Epoch Extensions
</aside>
EFM = Epoch Fallback Mode
EFM is triggered in the same way as currently (invalid or lack of Service Event), however:
EpochResetEvent which:
EpochResetEvent acts like an EpochSetup event (i.e. specifying the next epoch’s config) that moves the Protocol State’s evolution back to the happy path.EpochResetEvent requires that the new epoch counter is exactly one greater than the current epoch counter → will likely need to change this
[Alex H] EpochResetEvent acting like an EpochSetup event is very intuitive. In that context, would we accept such a recovery event only during the fallback epoch’s “staking phase”? In that case, we already have a place to store the EpochResetEvent's identity table.
However, if we allow the EpochResetEvent to be emitted at any arbitrary time, we would need an additional extra field somewhere in the protocol state to store this, because we could have an EFM EpochSetup and EpochCommit event (generated by the protocol state) and additionally the EpochResetEvent. I feel that might get a bit convoluted.
For EFM recovery, we are already assuming intervention of humans deeply familiar with the Flow protocol. Requiring that recovery attempts happen during the fallback epoch’s “staking phase” (by far the largest portion of an epoch) is a well-acceptable limitation in my opinion.
These are components which currently observe and behave differently depending on whether Epoch Fallback Mode is triggered.