Background

Conceptually, Flow is a permissioned blockchain:

• Only a pre-determined set of nodes is authorized to participate in the protocol. The set of authorized nodes is a-priori known to all network participants. This set is referred to as the Identity Table.
• An Epoch is defined as a period of time, where the set of authorized nodes is constant (or can only shrink due to ejection of malicious nodes).

Seat Assignment

At an Epoch switchover, which is the time when the network transitions from one epoch to the next, the set of authorized nodes can change. For each of Flow's node roles, the Flow protocol admits a protocol-determined number of nodes.

<aside> 📚 Definition of seat: right to participate in the network as a node of a certain type for a specific Epoch.

</aside>

For each Epoch, there is a Staking Period in which new potential node operators may submit Staking Commitments. After the Staking Period is over, the protocol determines which commitments to accept and which to reject (details TBD). The node operators whose staking commitments were accepted are added to the Identity Table for the next epoch, and become authorized participants at the next epoch switchover. Staked Nodes also can submit other operations to modify their existing stake, which are all carried out at the end of the current epoch.

Design Guidelines

There are strong benefits to moving as much of the Epoch-switchover logic into smart contracts as possible.

• Smart-contract-based protocols can be updated (within limits) without a protocol upgrade of the node software (spork).
• Cadence is very well suited to implement the respective distributed protocols.

Favored protocol elements we would like to implement through smart contracts are:

• entire staking mechanics including auction algorithm for assigning network seats
• DKG for consensus nodes
• generating root QCs to start consensus for collector clusters
• all slashing

High-Level Protocol