Problem Definition

The Epoch Preparation Protocol prepares for each subsequent epoch in two steps: EpochSetup and EpochCommit, each represented by a service event.

Most components should only access data (view ranges, etc.) for committed epochs (after EpochCommit step is complete), because uncommitted are tentative and may change.

However, the components directly involved in epoch preparation (namely the DKG engine and QC Voting engine, in Consensus and Collection Nodes respectively, require access to the tentative data associated with uncommitted epochs.

The current epoch API:

• uses the same interface type to represent all epochs, whether committed or not
• exposes all epoch data as soon as it is available, even if the epoch is not committed

Proposed Solution

• Create two types to represent uncommitted and committed epochs distinctly (eg. TentativeEpoch and CommittedEpoch)
  • EpochQuery.Previous() returns CommittedEpoch, nil or nil, NotFound
  • EpochQuery.Current() returns CommittedEpoch, nil
  • EpochQuery.Next() may return nil, NotFound, TentativeEpoch, nil, or CommittedEpoch, nil (need a way for caller to check which of the two return types it is)
• CommittedEpoch is informationally equivalent to current protocol.Epoch API
• TentativeEpoch contains only the information from the EpochSetup service event which is necessary to complete DKG and QC voting
  • (For example, I think we could omit the overall epoch view range)

Related Issues

• https://github.com/dapperlabs/flow-go/issues/6368
• [Protocol KVStore] Move EpochProtocolState data into KVStore #5974