Table of Contents

Overview and context

image source

<aside> 🚧 This document is a proposal and represents a working document point-in-time description of how this portion of the system ought to function. The final design is documented in Epoch-Aware Protocol State.

</aside>

Requirements

<aside> 0️⃣ The central source of identity-changing events is the execution state.

• identity-changing events are service events
• the stream of service events is order-preserving (for each fork), but delivered asynchronously </aside>

The service events must undergo verification and sealing before they can take effect go guarantee Byzantine resilience.

image source

<aside> 1️⃣ The invariance of the IdentitySkeletonList from the EpochSetup event is a central convention. Therefore, the software design should

• explicitly codify this convention
• document it in detail
• make it relatively apparent for a new engineer looking into the code that the IdentitySkeletons given in the EpochSetup event must remain invariant throughout the epoch.

Clear design and implementation and highly-modular code are key for high-assurance software.

</aside>

The invariance of the IdentitySkeletonList from the EpochSetup event is a central convention — accidentally breaking it will likely result in a variety of widespread malfunctions and major outages.

For an entire epoch, the set of IdentitySkeletons given in the EpochSetup event remains invariant. Exactly the consensus nodes and collector nodes are authorized to contribute to Flow’s main consensus or cluster consensus respectively.

• Context