This document details the plan and necessary order of operations for deploying Spork-less Epoch Fallback Recovery Design II: Epoch Extensions, using a Protocol HCU. (As this will be the first Protocol HCU, deployment of parts of the Protocol HCU system itself are also covered by this plan.)

Table of Contents

Upgrade Scope

System Smart Contracts (governance transaction)
- FlowEpoch
- FlowClusterQC
- FlowDKG
- NodeVersionBeacon
Flow-go node software (all node roles)

Potentially Breaking Changes

Core-Contracts https://github.com/onflow/flow-go/pull/6758

Modification of DKG data model (https://github.com/onflow/flow-core-contracts/pull/441)
- EpochCommit.dkgIdMapping field - new field added
- EpochCommit.dkgGroupKey field - new field added
- EpochCommit.dkgPubKeys field - existing field, semantics changed to omit group key
Addition of EFM Recovery transaction and service event
Addition of ProtocolStateVersionUpgrade service event

Flow-go

Modification of DKG data model
- EpochCommit.DKGIndexMap field - field currently exists but is empty since beginning of current spork, post-upgrade will be populated and meaningful
EpochRecover service event, recovery logic
Fix for chunk service event verification bug (https://github.com/onflow/flow-go/pull/6744)
- ChunkBody.ServiceEventCount field - new field added

Upgrade Process

Below we describe upgrade processes for General Service Event Validation and EFM Recovery separately. In practice, we can and plan to combine them (see Combined Upgrade Process).

1. General Service Event Validation

This feature being deployed is necessary to validate extra-system-chunk service events. The Protocol HCU trigger is implemented by an extra-system-chunk service event. Because of this, we will make use of sealing configurations to seal the first ProtocolStateVersionUpgrade without requiring verification.

Outstanding Implementation Requirements

Upgrade mechanism for ServiceEventCount https://github.com/onflow/flow-go/issues/6777; PR https://github.com/onflow/flow-go/pull/6796