Original title: "Epochs, Slots and Beacon Blocks》
Original title: "
Author: Patrick McCorry
Original translation: John, ECN
The uniqueness of Ethereum using Proof-of-Stake lies in its design to maximize the number of participants. It allows hundreds and thousands of validators to actively participate in the decision-making process. At the time of writing there are about half a million validator entities (from a protocol perspective) actively participating in the process.
In fact, in about 384 seconds (6 minutes and 24 seconds), all active validators will have the opportunity to cast a vote or propose a block. At least 500,000 messages are broadcast in approximately 384 seconds, and all messages must be delivered within a strict time frame. As far as I know, no other consensus protocol has been designed to handle such an active and large set of consensus participants.
As far as the communication model is concerned, consensus protocols are designed (usually) for one of three situations:
Synchronous communication A generally agreed upon and known message delivery timeout.
There is no upper bound on how long an asynchronous communication message can take to deliver, but it will eventually be sent.
Partially synchronous communication has a known timeout in most cases, but sporadic events can disrupt message delivery for varying lengths of time.
Most modern consensus protocols are designed for partially synchronous communication, as it assumes that conditions are good most of the time, but there are unpredictable periods as events may disrupt communication for short periods of time. On the other hand, it is worth noting that proof-of-stake Ethereum is designed for synchronous communication.
Digression -- Casper FFG is designed for partially synchronous communication, but the strict timing conditions of LMD-GHOST force the entire system to be synchronous. We will explain what Casper and LMD-GHOST are in a future article.
It assumes almost no outage among the vast majority of validators, and all messages must be recorded on the beacon blockchain by a fixed deadline before they can be credited/used. If there is an outage that delays delivery of the message, the sender incurs a penalty based on how late it was. In the worst case, if the deadline is missed, then the message will be ignored and the sender of the message will be penalized for maximum inactivity. The penalty policy will be covered in a future article.
If you want to dig into various communication setups, then I recommend reading this article. There's also a great discussion here about whether ETH 2 is partially synchronous or synchronous.
first level title
Interpretation of the working principle of Ethereum POS: Epoch, Slot and beacon blocks
There are 32 slots per epoch, and each validator is assigned exactly one slot per epoch. A slot is a 12-second time window during which validators can participate in the proof-of-stake protocol, proposing or voting on new beacon blocks.
Slots are grouped by epoch, and epoch and slot play the role of a schedule for validators to participate in the proof-of-stake protocol:
Epoch A period including 32 slots.
Slot A 12-second window in which a validator committee completes a task.
An epoch represents a complete round of the proof-of-stake protocol, and a slot provides a validator with an opportunity to participate in the round. At the end of an epoch, all active validators have a chance to participate.
Slot Committee A validator is assigned to exactly one slot in an epoch, and all validators are evenly distributed to each slot to form a committee.
There are two roles in a slot:
Block proposer A validator has the opportunity to propose a block to committee members.
Attester All remaining committee members vote for a block they believe should become the new blockchain head.
Interpretation of the working principle of Ethereum POS: Epoch, Slot and beacon blocks
A slot represents a strict time window for a validator to propose a block, committee members to vote on a block, and finally broadcast all activity in that slot to the next slot's block proposer.
Slots and Time Conditions All slots are generated one after the other in time order. Each slot is allocated exactly every 12 seconds and is divided into three stages:
Proposing a block specifies that a validator proposes a block and broadcasts it to all committee members within the first 4 seconds.
Members of all other committees vote (witness) for a block in the voting cycle, and they believe that their vote will be accepted by this block within the next four seconds.
Broadcast Voting The votes of all committee members in the last four seconds should be aggregated and sent to the block proposer for the next slot.
All blocks and votes are broadcast within a slot committee. There is an additional role in the committee called aggregators who aggregate proofs before passing them on to the next slot's block proposer. They are optional, a voluntary role to reduce the cost of communication. We will skip the specifics for now - as this will be covered in a future article.
As a final reminder, this strict time window guarantees a lower bound on the bandwidth and computing power required to run validators, as they must be able to receive, process, and send witnesses/blocks on time.
first level title
Allocation of the validator committee
We consider the process of assigning validators to slots in an epoch. All slot committees are roughly the same size. They do the assignment based on the output of a random beacon and do so two epochs in advance. This requires the use of a shuffling protocol and a source of randomness with the signal transmission.
Shuffle Protocol All validators are assigned to a slot according to a swap-or-not shuffle protocol. Instead of going into the details of the shuffle protocol, we will focus on the calculation method of the randomness beacon, which lays the foundation for the way the shuffle protocol is executed.
Random Beacon All validators are assigned through a random beacon using a protocol called RANDAO. Its purpose is to form random beacons by aggregating randomness when new blocks are added to the canonical chain.
For each new block, there are two phases:
The randomness proposed to generate (per block) a new beacon block includes a special value called randao_reveal. It is a block proposer's BLS signature that acts as a random beacon for the block. It is deterministic to prevent tampering by the verifier, but unpredictable.
Mixed randomness (per block) All validators take a random beacon from a new block and mix it with the randomness of all previous aggregated blocks. It forms a new value mix, a possible candidate for the shuffling protocol.
Interpretation of the working principle of Ethereum POS: Epoch, Slot and beacon blocks
The verifiers are assigned to the slot of the N+2 Epoch through the last random beacon of the Nth Epoch
/* * The block proposer performs a BLS signature on the current epoch number * to act as a random beacon for this block * A very good point is that the signature is deterministic (the verifier cannot tamper with it), but until the signature is calculated Unpredictable until it comes out */
DOMAIN_RANDAO = 0x 02000000; // The magic number contained in a signature epoch_hash = hash(current_epoch_number, DOMAIN_RANDAO); // The hash code to be signed randao_reveal = BLS.sign(epoch_hash, sk); // BLS signature is RANDAO
/* * Use the randomness of the block, perform a hash calculation, and then mix the hash code into the randomness that is now gathered */
previous_mix = get_previous_mix(parent_block); // mix from the parent block (Mix) randao_reveal = new_block.randao_reveal; // get the randao of the new block
mix = previous_mix XOR hash(randao_reveal); // calculate new mix store_new_mix(new_block); // associate new "mix" (mix) with new block
The allocation will happen 2 epochs in advance and all validators will use the mix value aggregated from the last accepted block as a random beacon and use it in the shuffle algorithm. It computes the validator committee for the next two epochs.
So, if we consider that the current epoch is the Nth, then the last beacon block in this epoch will be used as a random beacon to determine the committee allocation for the N+2th epoch.
Validators have plenty of time to look up their assigned slots, since they know it two epochs in advance. In other words, the allocation of verifiers for the future 64 slots is already known to the public (approximately 2 epochs).
The bias-ability of the random beacon is that only one mix can be used by the shuffle protocol, and that is the mix value of the last accepted block in an epoch.
The last accepted block will not always be the one proposed in slot 32. It is the block of the last slot, that is, the block recognized as the head of the blockchain by all verifiers. For example, if no block is proposed for slot 32 (or it is late), then the committee of validators for slot 32 will vote for the previous block that was proposed for slot 31.
An attacker can exploit this to bias random beacons. Let us assume that the attacker is the block proposer of slot 32. He can decide to:
The randomness of releasing blocks on time is mixed in the beacon
This decision-making power allows an attacker to bias the randomness beacon by 1 byte and ultimately determine which of the two validator assignments will be used in a future epoch. In fact, if an attacker controls the block proposers of the last N blocks in an epoch, they can use this opportunity to release or suspend the release of a combination of N blocks. There is currently a lack of a rigorous study to understand the full extent and impact of bias power for the last N slots.
first level title
image description
The data structure of a beacon block
image description
A block proposer for a slot attempts to extend the canonical chain and can only choose one parent block.
image description
Epoch and slot organization validators produce a single canonical beacon blockchain.
Slot ≠ beacon block A beacon block records the metadata of its slot number (a multiple of an epoch number). It allows other validators to check that the block proposer was indeed designated to propose a block for this slot, and that this block is the proposed block. If the slot number is wrong, the block will be rejected.
The point is that a block's position in the blockchain does not correspond to the slot number in which it was proposed. For example, if we check slot 5184157, we will see block 16015362. This mismatch cannot be avoided because there is no guarantee that a proposed block in an assigned slot will be accepted by all other blocks. Validators voted in, and Ethereum has been running for over 7 years since its inception.
The execution chain data block proposer will propose two blocks, they propose an execution block, order the user's transaction, and attach it to the newly generated beacon block. This is not surprising since the ultimate purpose of the consensus layer is to determine the canonical chain for the enforcement layer.
Block proposers are also responsible for transferring information from the executive layer to the beacon layer and making it ready for use by the proof-of-stake protocol. This includes:
ETH 1 data A block hash code of an additional block from the execution layer.
Deposit The deposit contract address and a chain of unrecorded deposits.
This requires all validators to run a beacon client and an enforcement client. This is necessary because validators must check the corresponding ETH 1 block and verify its validity according to the enforcement layer rules. Also, as we discussed in our article on the registration process, deposits must be transferred from the execution layer to a beacon block within a certain block interval, or the beacon block will be rejected.
Metadata slot number, epoch number, randomness beacon and block proposer
Slashed events include evidence of malicious behavior by other validators, which can be used to punish them
Vote History A list of unrecorded votes on this blockchain fork for previously proposed beacon blocks
Blockchain forks which pick a parent block and in turn define the canonical chain that this block extends from.
A validator exits a chain of exit requests for registered validators.
As an aside, due to weak subjectivity, although the proof-of-stake record can convince us that all historical activities are carried out according to the rules, it is not enough to explain to an outside group that this is indeed the real beacon blockchain . Simply put, it provides a way to check the integrity of historical activity.
