Introduction

The epoch contract stores a lot of different state, and the state is constantly changing. As an external party, there are two ways to keep track of these state changes. You can either use Cadence scripts to query the state of the contract at any given time, or you can monitor events that are emitted by the epoch contract to be notified of any important occurances.

Monitor Epoch Service Events

These events can be queried using the Go or JavaScript SDKs to extract useful notifications and information about the state of the epoch preparation protocol.

What is a Service Event?

Service events are special messages that are generated by smart contracts and included in execution results. They enable communication between system smart contracts and the Flow protocol. In other words, they serve as a communication mechanism between the execution state and the protocol state.

Concretely, service events are defined and emitted as events like any other in Cadence. An event is considered a service event when it is:

• emitted within the service chunk
• emitted from a smart contract deployed to the service account
• conformant to an event allowlist

Each block contains a system chunk. For each system chunk, all service events emitted are included in the corresponding execution result.

When verifying the system chunk, verifier nodes will only produce result approvals when the system chunks included in the execution result are correct. Thus, the security of this communication mechanism is enforced by the verification system.

When sealing a block containing a service event, the consensus committee will update the protocol state accordingly, depending on the semantics of the event.

For example, a service event may indicate that a node's stake has diminished to the point where they should be ejected, in which case the consensus committee would mark that node as ejected in the protocol state.

Service events are fundamentally asynchronous, due the lag between block execution and sealing. Consequently they are handled slightly differently than other protocol state updates.

The diagram below illustrates the steps each service event goes through to be included in the protocol state.

For conciseness, we say a service event is sealed when the block in which it was emitted is sealed, and we say a service event is finalized when the block containing the seal is finalized.

Event Descriptions

EpochSetup

The Epoch Setup service event is emitted by FlowEpoch.startEpochSetup() when the staking auction phase ends and the Epoch Smart Contracts transition to the Epoch Setup phase. It contains the finalized identity table for the upcoming epoch, as well as timing information for phase changes.

pub event EpochSetup (

/// The counter for the upcoming epoch. Must be one greater than the

/// counter for the current epoch.

counter: UInt64,

/// Identity table for the upcoming epoch with all node information.

/// Includes:

/// nodeID, staking key, networking key, networking address, role,

/// staking information, weight, and more.

nodeInfo: [FlowIDTableStaking.NodeInfo],

/// The first view (inclusive) of the upcoming epoch.

firstView: UInt64,

/// The last view (inclusive) of the upcoming epoch.

finalView: UInt64,

/// The cluster assignment for the upcoming epoch. Each element in the list

/// represents one cluster and contains all the node IDs assigned to that

/// cluster, with their weights and votes

collectorClusters: [FlowClusterQC.Cluster],

/// The source of randomness to seed the leader selection algorithm with

/// for the upcoming epoch.

randomSource: String,

/// The deadlines of each phase in the DKG protocol to be completed in the upcoming

/// EpochSetup phase. Deadlines are specified in terms of a consensus view number.

/// When a DKG participant observes a finalized and sealed block with view greater

/// than the given deadline, it can safely transition to the next phase.

DKGPhase1FinalView: UInt64,

DKGPhase2FinalView: UInt64,

DKGPhase3FinalView: UInt64

)

EpochCommit

The EpochCommit service event is emitted when the Epoch Smart Contracts transition from the Epoch Setup phase to the Epoch Commit phase. It is emitted only when all preparation for the upcoming epoch (QC and DKG) has been completed.

pub event EpochCommit (

/// The counter for the upcoming epoch. Must be equal to the counter in the

/// previous EpochSetup event.

counter: UInt64,

/// The result of the QC aggregation process. Each element contains

/// all the nodes and votes received for a particular cluster

/// QC stands for quorum certificate that each cluster generates.

clusterQCs: [FlowClusterQC.ClusterQC],

/// The resulting public keys from the DKG process, encoded as by the flow-go

/// crypto library, then hex-encoded.

/// Group public key is the first element, followed by the individual keys

dkgPubKeys: [String],

)

Query Information with Scripts

The FlowEpoch smart contract stores important metadata about the current, proposed, and previous epochs. Metadata for all historical epochs is stored permenantely in the Epoch Smart Contract's storage.

pub struct EpochMetadata {

/// The identifier for the epoch

pub let counter: UInt64

/// The seed used for generating the epoch setup

pub let seed: String

/// The first view of this epoch

pub let startView: UInt64

/// The last view of this epoch

pub let endView: UInt64

/// The last view of the staking auction

pub let stakingEndView: UInt64

/// The total rewards that are paid out for the epoch

pub var totalRewards: UFix64

/// The reward amounts that are paid to each individual node and its delegators

pub var rewardAmounts: [FlowIDTableStaking.RewardsBreakdown]

/// Tracks if rewards have been paid for this epoch

pub var rewardsPaid: Bool

/// The organization of collector node IDs into clusters

/// determined by a round robin sorting algorithm

pub let collectorClusters: [FlowClusterQC.Cluster]

/// The Quorum Certificates from the ClusterQC contract

pub var clusterQCs: [FlowClusterQC.ClusterQC]

/// The public keys associated with the Distributed Key Generation

/// process that consensus nodes participate in

/// Group key is the last element at index: length - 1

pub var dkgKeys: [String]

}

Get Epoch Metadata

The FlowEpoch smart contract provides a public function, FlowEpoch.getEpochMetadata() to query the metadata for a particular epoch.

You can use the Get Epoch Metadata(EP.01) script with the following arguments:

Argument	Type	Description
epochCounter	UInt64	The counter of the epoch to get metadata for.

Get Configurable Metadata

The FlowEpoch smart contract also has a set of metadata that is configurable by the admin for phase lengths, number of collector clusters, and inflation percentage.

pub struct Config {

/// The number of views in an entire epoch

pub(set) var numViewsInEpoch: UInt64

/// The number of views in the staking auction

pub(set) var numViewsInStakingAuction: UInt64

/// The number of views in each dkg phase

pub(set) var numViewsInDKGPhase: UInt64

/// The number of collector clusters in each epoch

pub(set) var numCollectorClusters: UInt16

/// Tracks the annualized percentage of FLOW total supply that is minted as rewards at the end of an epoch

/// Calculation for a single epoch would be (totalSupply * FLOWsupplyIncreasePercentage) / 52

pub(set) var FLOWsupplyIncreasePercentage: UFix64

}

You can use the Get Configurable Metadata(EP.02) script to get the list of configurable metadata:

This script does not require any arguments.

Get Epoch Counter

The FlowEpoch smart contract always tracks the counter of the current epoch.

You can use the Get Epoch Counter(EP.03) script to get the current epoch counter.

This script does not require any arguments.

Get Epoch Phase

The FlowEpoch smart contract always tracks the active phase of the current epoch.

pub enum EpochPhase: UInt8 {

pub case STAKINGAUCTION

pub case EPOCHSETUP

pub case EPOCHCOMMIT

}

You can use the Get Epoch Phase(EP.04) script to get the current epoch phase.

This script does not require any arguments.