Primary Actors

The epoch preparation protocol defines how information about the next epoch is determined and propagated to the protocol state.

There are two primary actors in this protocol:

• Epoch Smart Contract - the smart contracts that manage epochs:
  • FlowClusterQC : Manages the quorum certificate generation for bootstrapping the hotstuff consensus algorithm for each collector cluster.
  • FlowDKG : Manages the Distributed Key Generation that consensus nodes participate in to initialize the random beacon for each epoch.
  • FlowIDTableStaking : Manages the source of truth for the identity table, and enforces rules related to staking FLOW, delegating, paying rewards, and allocating token movements between epochs.
  • FlowEpoch : Ties all of the previously mentioned contracts together to manage the high level epoch lifecycle. FlowEpoch acts as a state machine that transitions between different epoch phases when specific conditions from the other contracts are met and triggers important operations in the other smart contracts when phase changes happen.
• Consensus Committee - the committee of consensus nodes for the current epoch

This document describes the communication protocol between these two actors and the impact on the protocol state.

Communication

The Epoch Smart Contract can send messages to the Consensus Committee using Service Events. The Consensus Committee can update the protocol state, which can be read by the Epoch Smart Contract from a Cadence interface.

Both of these communication mechanisms are fundamentally asynchronous, due to the latency between block execution, finalization, and sealing. Furthermore, both of these communication methods are fork-specific. See Service Events for more details.

Epoch Length

<aside> 💡 The length of an Epoch is measured in terms of consensus views.

</aside>

Let:

• $V^{(N)}$ be the view in which Epoch N starts.
• $\hat{V}^{(N)}$ be the last view of the Epoch N. (Note: $V^{(N)} = \hat{V}^{(N-1)} + 1$)

For Epoch N, $V^{(N)}$ and $\hat{V}^{(N)}$ are known before the Epoch begins. The number of views in an epoch and in different epoch phases are constants stored in the epoch smart contracts.

The length of an epoch is not ****fork-dependent, as it is measured in views. Generally, there is not a block for every view. However this does not pose a problem, as for each fork, the first and last block of each Epoch are clearly defined.

<aside> 🔩 Definition: first block of Epoch A block $\\Omega$ is said to be the first block of Epoch N (in its respective fork), if and only if • $\Omega\textnormal{.view} \ge V^{(N)}$ and • $\Omega\textnormal{.parent.view} < V^{(N)}$

</aside>

📖[Context] Motivation for measuring epoch length in consensus views: