EFM is a fallback mode for Epochs which allows for continued operation in the presence of an epoch preparation failure. EFM is triggered when the protocol is about to transition into the next phase of an epoch or a new epoch and that epoch has not been fully committed by the Epoch Preparation Protocol.

When EFM is triggered, the consensus committee periodically appends “epoch extensions”. See Spork-less Epoch Fallback Recovery Design II: Epoch Extensions for design details. See ‣ for EFM Recovery instructions.

Observability

When EFM is triggered, we can observe it in the metrics:

EFM is visible in the EFM metrics and the epoch phase metric

• If EFM was triggered by a specific invalid service event, this will be logged by dynamic_protocol_state.

EFM Trigger Conditions

• (1) We enter a view beyond the currently committed view range and the next epoch is not committed.
• (2) We observe an invalid epoch-related service event

Condition (1) can be caused by many factors, including DKG failure and cluster QC voting failure.

Condition (2) is generally caused by a bug in the system smart contracts.

EFM is caused by the DKG more often than cluster QC voting, so when debugging it is best to start there (see Appendix: Debugging DKG Failure).

What Causes DKG Failure?

Generally, if too few nodes successfully complete the DKG, it will fail. The success threshold can be obtained using this script.

• 🚧 Consensus Nodes restarting during the EpochSetup phase
• Machine account misconfiguration
• Sustained poor network conditions

What Causes Cluster QC Voting Failure