Epochs, Slots and Beacon Blocks

Timetable for Validator participation in Ethereum's proof of stake protocol

Proof of stake Ethereum is unique in its design to maximise the number of participants. It allows hundreds of thousands of Validators to actively participate in the decision making process. At the time of this article, there are ~500k instances of Validators (from the protocol’s perspective) who are actively participating.

In fact, within ~384 seconds (6 minutes and 24 seconds), all active Validators will have an opportunity to cast a single vote or propose a block. There are at least 500k messages propagated within ~384 seconds and all messages must be delivered within strict time bounds. There is no other consensus protocol, to the best of my knowledge, that is designed to handle such an active and large set of consensus participants.

In regards to the communication model, consensus protocols are designed for one of the following three settings (typically):

• Synchronous. A universally agreed and known time-out for the delivery of a message.

• Asynchronous. There is no upper bound on how long a message may take to deliver, but it will eventually be delivered.

• Partially Synchronous. In most instances, there is a known time-out for the delivery of a message, but sporadic events can disrupt message delivery for an unknown length of time.

Most modern consensus protocols are designed for the partially synchronous setting as it assumes good conditions most of the time, but periods of unpredictability as events may disrupt communication for a short period of time. On the other hand, and remarkably, proof of stake Ethereum is designed for the synchronous model.

Side note — Casper FFG is designed for the partially synchronous setting, but the strict timing conditions for LMD-GHOST forces the entire system to be synchronous. We’ll explain what is Casper and LMD-GHOST in a future article.

It assumes there is little to no disruption amongst a supermajority of the Validators and all messages must be recorded in the beacon blockchain by a fixed deadline for it to be counted/used. If there is a disruption that leads to the late delivery of a message, then the sender will incur a penalty depending on its lateness. In the worst case, if the deadline is missed, then the message is ignored and the sender will receive the maximum penalty for being inactive. The penalty policies are covered in a future article.

To better understand the synchronous model, we cover the topics of Epochs & Slots. It defines when a Validator is allowed to participate and the strict time window surrounding the delivery of messages. If the time windows are violated, for whatever reason, then there is no guarantee other Validators will act upon the arrival of a late message. Finally, we cover how Validators are allocated a time slot and how the messages are recorded in the beacon blockchain.

If you want an in-depth read about the various communication settings, then I recommend reading this article. There is also a great discussion here about whether ETH2 is partially synchronous or synchronous.

Epochs and Slots

Every epoch has 32 slots and every Validator is allocated to exactly one slot per epoch. A slot is a 12-second time window for when a Validator can participate in the proof of stake protocol to propose or vote on a new beacon block.

Slots grouped by epochs. Epochs and slots act as a timetable for Validator participation in the proof of stake protocol:

• Epoch. A period of 32 slots.

• Slot. A 12-second time window for a committee of Validators to complete their actions.

An epoch represents a complete round of the proof of stake protocol and slots provides a single opportunity for a Validator to participate in the round. By the end of an epoch, all active Validators will have had an opportunity to participate.

Slot committees. A Validator is allocated exactly one slot in an epoch and all Validators are evenly split across the slots to form committees.

There are two roles in a slot:

• Block proposer. A single Validator has an opportunity to propose a block to the committee members.

• Attester. All remaining committee members will vote for a block, in their belief, should be the new head of the blockchain.

There are 32 block proposers every epoch (one for every slot) and all Validators have an opportunity to participate in the proof of stake protocol by contributing a vote towards what should be, in their belief, the tip of the canonical beacon chain.

A slot represents a strict time window for one Validator to propose a block, the committee members to vote on a block, and finally to propagate all slot activity to the next slot’s block proposer.

Slots and timing conditions. All slots occur one after another in a strictly timed sequence. Every slot is allocated exactly 12 seconds and it can be broken into three stages:

• Propose block. A single Validator is appointed to propose a block and propagate it to all committee members within the first 4 seconds.

• Voting period. All other committee members cast a vote (attest) to a block that, in their belief, should be accepted in this block within the next 4 seconds.

• Propagate vote. All committee member votes will be aggregated and sent to the next slot’s block proposer in the final 4 seconds.

All blocks and votes are gossiped within a slot’s committee. There is an additional role in a committee, called the aggregators, who will combine the attestations before passing it onto the next slot’s block proposer. They are self-elected and it is a voluntary role to reduce communication overhead. We’ll skip past the specifics for now — as it is covered in a future article.

If a proposed block or attestation is published after the deadline, then there is no guarantee the activity will be recognised by the other Validators. For example, a late block can be skipped as this slot’s Validators may have already cast a vote for its parent block. A late attestation will be processed by the other Validators in an epoch for up to 32 slots with varying degrees of penalties. If it is published after 32 slots, then it will not be processed by any Validator.

As a final note, the strict time windows place a lower bound on the bandwidth and computational requirements to run a Validator as they must have the capacity to receive, process, and send attestations/blocks on time.

Allocating Validator Committees

We consider the process of allocating Validators to slots in an epoch. All slot committees are approximately the same size. They are allocated according to the output of a random beacon and it is performed two epochs in advance. It requires the use of a shuffle protocol and a source of in-band randomness.

Shuffle protocol. All Validators are allocated to a slot based on the output of a shuffle protocol called swap-or-not. We do not dive into the details of the shuffling protocol and instead turn our focus on how to compute the random beacon which bootstraps how the shuffling is performed.

/* 
 * The block proposer performs a BLS signature over the current epoch 
 * number. It acts as the random beacon for this block. 
 * A nice property is that the signature is deterministic (Validator 
 * cannot tamper with it), but not predictable until the signature is 
 * computed. 
 */

DOMAIN_RANDAO = 0x02000000; // A magic number included in signature
epoch_hash = hash(current_epoch_number, DOMAIN_RANDAO); // Hash to sign
randao_reveal = BLS.sign(epoch_hash, sk); // BLS signature is RANDAO

/* 
 * Take this block's randomness, hash it, and mix the hash into
 * the accumulated randomness to date.
 */

previous_mix = get_previous_mix(parent_block); // Mix from parent block
randao_reveal = new_block.randao_reveal; // Get new block's randao

mix = previous_mix XOR hash(randao_reveal); // Compute new mix 
store_new_mix(new_block); // Associate new "mix" with new block 

Random beacon. All Validators are allocated using a random beacon and the beacon is implemented using a protocol called RANDAO. The goal is to form the random beacon by accumulating randomness as new blocks are appended to the canonical chain.

For every new block, there are two stages:

• Proposed randomness (per block). A new beacon block includes a special value called randao_reveal. It is a BLS signature by the block proposer that acts as the block’s random beacon. It is deterministic to prevent tampering by the Validator, but it is not predictable.

• Mix randomness (per block). All validators take the random beacon from the new block and mixes it with the accumulated randomness from all previous blocks. It forms a new mix which is a potential candidate for the shuffling protocol.

As we can see, every beacon block includes a random beacon that is added and accumulated with the randomness of all previous blocks.

Validators are allocated to their slots for Epoch N+2 using the final random beacon in Epoch N.

Allocation is two epochs ahead. All validators will take the final accepted block’s accumulated mix as the random beacon and use it for the shuffle algorithm. It computes the Validator committees for two epochs in the future.

So, if we consider the current epoch to be N, then random beacon from the final beacon block in epoch N will dictate the committee allocation for epoch N+2.

Validators have ample time to look up their allocated slot as it is known two epochs ahead of time. Expressed differently, the allocation of Validators to slots is publicly known for the next 64 slots (~2 epochs).

Bias-ability of the random beacon. Only one mix can be used by the shuffle protocol and it is the mix from the epoch’s last accepted block.

The last accepted block is not always the block proposed in slot 32. It is the last slot’s block which is recognised as tip of the chain by all Validators. For example, if no block is proposed for slot 32 (or it arrives late), then the committee of Validators for slot 32 will vote for the previous block proposed in slot 31.

As an attacker, this can be leveraged to bias the random beacon. Let’s assume the attacker is the block proposer in slot 32. They can decide to:

• Release block on time. The attacker’s randomness is mixed in with the beacon.

• Withhold block. Force all Validators to vote for the parent block and the attacker’s randomness is not mixed in with the beacon.

The authority to make this decision allows the attacker to bias the random beacon by 1-bit and ultimately decide which one of the two validator allocations will be used in a future epoch. In fact, if the attacker controls the last N block proposers for an epoch, then they can use this as an opportunity to release/withhold a combination of N blocks. A rigorous study to understand the full extent of bias-ability for the last N slots and its implications appears to be missing.

Inspecting a beacon block

Data structure for a beacon block

A single beacon block contains metadata about its position in the beacon blockchain, the execution chain data, and a transcript for the proof of stake protocol. We cover each case in more detail below.

A slot’s block proposer is attempting to extend the canonical chain and they can only pick a single parent block.

Parent beacon block. A block proposer’s goal is to propose and append a new beacon block to the head of the canonical chain. In doing so, they are only allowed to pick a single parent block to extend. It should be the current head of the chain and it is represented as parent_root in the meta-data.

Epochs and slots organise Validators to produce a single canonical beacon blockchain.

Slots != beacon blocks. A beacon block records the meta-data for its slot number (a multiple of the epoch number). It allows other Validators to check that the block proposer was indeed appointed to propose a block for this slot and this is the block that was proposed. Otherwise, if the block proposer was not allocated to the slot number, then the block is rejected.

Crucially, a block’s position in the blockchain does not correspond to the slot number it was proposed in. For example, if we look up slot 5,184,157, then we will find block 16,015,362. This mismatch is inevitable as there is no guarantee a proposed block for an allocated slot will be voted on by all other Validators. As well, the original Ethereum blockchain has already run for >7 years.

Execution chain data. The block proposer proposes two blocks. They propose an execution block that orders user-generated transactions and it is attached to the newly proposed beacon block. This is not surprising as the entire purpose of the consensus layer is to decide the canonical chain for the execution layer.

The block proposer is also responsible for moving messages from the execution layer to the beacon layer and making it readily available for the proof of stake protocol. It includes:

• ETH1 data. A block hash for the attached block from the execution layer.

• Deposits. The deposit contract address alongside a list of unrecorded deposits.

This requires all Validators to run a beacon and an execution client. It is needed as Validators must lookup the corresponding ETH1 block and verify its valid according to the rules of the execution layer. As well, as we discuss in the registration process article, deposits must be transferred from the execution layer to a beacon block at a specific block interval. Otherwise, the beacon block is rejected.

Proof of stake transcript. The consensus protocol transcript is recorded in the beacon blockchain. It includes:

• Metadata. The slot number, epoch number, random beacon and the block proposer for the block.

• Slashing events. It includes evidence of malicious behaviour by other Validators which can be used to penalise them.

• Historical votes. A list of unrecorded votes for previously proposed beacon blocks on this blockchain fork.

• Blockchain fork. It picks a parent block and in turn defines the canonical chain which this block is extending.

• Validator exits. A list of requested exits by registered Validators.

By recording the transcript, anyone can independently replay the entire protocol and be convinced in a deterministic manner that the current state of the beacon’s chain is correct. For example, malicious Validators were slashed in a timely manner, the timetable of slots/epochs was respected by all Validators, and a supermajority of Validators have cast votes in such a way that they have all converged on a single canonical chain.

As a side note, due to weak subjectivity, the proof of stake transcript can convince us that all historical actions were performed according to the rules, but it is not enough to convince an external party that this is indeed the one true beacon blockchain. Put simply, it provides a means to check the integrity of historical actions.