Explain how Ethereum POS works: Epoch, Slot and beacon block

原文标题：《 解读以太坊 POS 工作原理：Epoch、Slot 与信标区块 》

Source: ETH Chinese

The uniqueness of Ethereum using proof of equity is that it is designed to maximize the number of participants. It allows hundreds, thousands and thousands of validators to actively participate in the decision-making process. At the time of writing there are around half a million validator entities (from a protocol perspective) actively involved in this process.

In fact, for about 384 seconds (6 minutes 24 seconds), all active verifiers will have the opportunity to cast a vote or propose a block. At least half a million messages were broadcast in about 384 seconds, and all messages had to be delivered within a strict time frame. To my knowledge, no other consensus protocol has been designed to handle such an active and large set of consensus participants.

As for the communication model, consensus protocols are designed for one of three situations (usually) :

Synchronous Communication   A generally agreed and known timeout for message delivery. There is no upper limit to the time it takes for an asynchronous communication message to be transmitted, but it will eventually be sent. Partial synchronous Communication   In most cases, there is a known timeout, but sporadic events can disrupt messaging for varying amounts of time.

Most modern consensus protocols are designed for partially synchronous communication because it assumes good conditions most of the time, but there are unpredictable periods because events can interrupt communication for short periods of time. On the other hand, it's worth noting that proof-of-equity Ethereum is designed for synchronous communication.

As an aside -Casper FFG is designed for partially synchronous communication, but the strict timing conditions of LMD-GHOST force the entire system to be synchronized. We will explain what Casper and LDM-Ghost are in a future article.

It assumes that there will be few interruptions in the vast majority of verifiers, and that all information must be recorded on the beacon blockchain by a fixed deadline before this information can be credited/used. If there is an interruption that delays the delivery of the message, the sender incurs penalties depending on how late it is. In the worst case, if the deadline is missed, then the message will be ignored and the message sender will receive the maximum penalty of inactivity. Punishment policies will be covered in a future article.

To better understand the synchronous communication model, we cover Epochs & The topic of Slots. It defines the amount of time a verifier is allowed to participate, as well as a strict time window around messaging. If the time window is violated, for whatever reason, there is no guarantee that other validators will take action when a late message arrives. Finally, we'll look at how the verifier is assigned to a time slot and how the message is recorded in the beacon blockchain.

If you want to dive into the various communication Settings, then I recommend reading this article. There is also a fascinating discussion here about whether ETH2 is partially synchronous or synchronous communication.

Epoch and Slot

There are 32 slots per epoch, and each verifier is assigned to exactly one slot per epoch. A slot is a 12-second window of time during which a verifier can participate in a proof-of-interest protocol to propose or vote on a new beacon block.

Slots are grouped by epochs. Epochs and Slots play the role of a schedule for the verifier to participate in the proof-of-interest protocol:

Epoch    A cycle with 32 slots.

Slot       A committee of validators completes the task in a 12-second window.

An epoch represents a complete turn of the proof-of-interest protocol, and slot provides an opportunity for the verifier to participate in that turn. At the end of an epoch, all active verifiers have the opportunity to participate.

Slot committee A verifier is allocated to exactly one slot in an epoch. All verifiers are equally allocated to each slot to form a committee.

There are two roles in a slot:

Block proposer(Block proposer) A proposer has the opportunity to propose a block to a committee member.

witnessAll remaining committee members (Attester) vote for a block that they believe should become the new blockchain head.

Each epoch has 32 block proposers (one per slot), and all validators have the opportunity to participate in the proof-of-interest protocol by casting a vote for the head of what they believe should be the canonical beacon chain.

A slot represents a strict window of time for a verifier 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.

Slot and time conditions

All slots are created one by one in chronological order. Each slot was assigned exactly 12 seconds and divided into three phases:

Proposed block  Designate a verifier to propose a block and broadcast it to all committee members within the first 4 seconds.

Voting cycle  All the other committee members vote (witness) for a block that they believe will be accepted 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 in the next slot.

All blocks and votes are broadcast in a slot committee. There is an additional role on the committee, called the aggregator, which aggregates the proof before passing it on to the block proposer in the next slot. They are self-selected, it is a voluntary role to reduce the cost of communication. We'll skip the specifics for now -- as this will be covered in a future article.

If a proposed block or witness is posted after the deadline, there is no guarantee that the activity will be accepted by other verifiers. For example, a late block might be skipped because a witness to the slot might have already voted for its parent block. A late witness will be handled by other witnesses in an epoch, up to 32 slots late, with varying degrees of punishment. If it is published after 32 slots, it will not be processed by any verifier.

As a final note, this strict time window guarantees the minimum bandwidth and computing power required to run the verifier, as they must be able to receive, process, and send the witness/block on time.

Allocation by the verifier committee

We consider the process of assigning validators to slots within an epoch. All slot committees are roughly the same size. They do the assignment based on the output of a random beacon, and they do it two epochs ahead. This requires the use of a mash-up protocol and a source with the same signal transmission randomness.

Scrubbing protocol All verifiers are assigned to a slot according to a scrubbing protocol called swap-or-not. We will not discuss the details of the mash-up protocol, but will focus on the random beacon calculation method that underlies the way the mash-up protocol is implemented.

Random Beacon All verifiers are assigned by a random beacon that uses a protocol called RANDAO. The aim is to form random beacons by aggregating randomness as new blocks are added to the gauge chain.

For each new block, there are two phases:

Randomness of proposal generation (per block)  

A new beacon block includes a special value called randao_reveal. It is the BLS signature of a block proposer that acts as a random beacon for the block. It is certain to prevent tampering by the verifier, but unpredictable.

Mixed randomness (per block)  

All verifiers take random beacons from the new block and mix them with randomness from all previously aggregated blocks. It forms a new value, mix, which may be a candidate for the wash protocol.

As we can see, each beacon block includes a random beacon, adding and aggregating the randomness of all previous blocks.

Verifiers are assigned to slots of the NTH + 2nd Epoch by random beacons at the end of the NTH Epoch

/* * The block proposer performs a BLS signature on the current epoch number * to act as a random beacon for the block * One nice thing is that the signature is certain (the verifier cannot tamper with it), but it is not predictable until the signature is calculated */

DOMAIN_RANDAO = 0x02000000; // epoch_hash = hash(current_epoch_number, DOMAIN_RANDAO); randao_reveal = BLS.sign(epoch_hash, sk); // Randao_reveal = bls. sign(epoch_hash, SK); / / is RANDAO BLS signature

/* * Use the randomness of the block, do the hash calculation, and then mix the hash code into the now aggregated randomness */

previous_mix = get_previous_mix(parent_block); randao_reveal = new_block.randao_reveal; // Mix randao_reveal = new_block.randao_reveal; // Get the new block randao

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

Allocation will advance by 2 epochs 

All verifiers use the mix value of the last accepted block as a random beacon and use it in the mash-up algorithm. It calculates the committee of validators for the next two epochs.

So, if we consider the current epoch to be the NTH epoch, then the last beacon block in the epoch will act as a random beacon to determine the committee allocation of the NTH +2 epochs.

The validators have plenty of time to look up the slot to which they are assigned because they know about it two epochs ahead of time. In other words, the assignment of the next 64 slot validators is already public (about 2 epochs).

bias-ability of random beacons 

Only one mix can be used by the scrubbing protocol, and that is the mix value of the last accepted block in an epoch.

The last block to be accepted will not always be the block proposed in slot 32. It is the block of the last slot, the block that is recognized by all verifiers as the head of the blockchain. For example, if no block is proposed for slot 32 (or it is late), then slot 32's verifier committee votes for the previous block that was proposed for slot 31.

An attacker can use this to bias random beacons. Let's assume that the attacker is the block proposer of slot 32. He could decide to do this:

Just-in-time release block  The randomness of the attacker is mixed into the beacon

Delay block  By forcing all verifiers to vote for the previous block, the randomness of the attacker is not mixed into the beacon.

This decision allows the attacker to bias the random beacon by 1 byte and ultimately determine which of the two verifier allocation combinations 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 delay the release of a combination of N blocks. A rigorous study is lacking to understand the full range of bias capabilities for the last N slots and their effects.

Check a beacon block

The data structure of a beacon block

A single beacon block contains metadata about its location in the beacon blockchain, the execution chain data, and a copy of the proof-of-interest agreement. We'll explore more details below.

A slot's block proposer attempts to extend the specification chain and can select only one parent block.

Beacon parent block

The goal of a block proposer is to propose and add a new beacon block to the head of a specification chain. To do so, they can only choose a parent block to extend. The parent block should be the current chain head, whose metadata representation is parent_root.

Epoch and slot organize the verifier to generate a unique canonical beacon blockchain.

Slot is not equal to a beacon block

A beacon block records metadata of its slot number (a multiple of an epoch number). It allows other verifiers to check that the block proposer is indeed designated to propose a block for this slot and that this block is the proposed block. If the slot number is incorrect, the block is rejected.

The point is that a block's location in the blockchain does not correspond to the slot number it is proposed in. For example, if we check slot 5184157, then we see block 16015362. This mismatch is unavoidable because there is no guarantee that a proposed block in an allocated slot will be voted by all the other validators. And Ethereum has been running for more than seven years since its inception.

Execute chain data block

The proposer would propose two blocks, which would propose an execution block that would sort the user's transactions 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 chain of specifications for the executive layer.

The block proposer is also responsible for transferring information from the enforcement layer to the beacon layer and getting it ready for use in the proof-of-interest protocol. This includes:

ETH1   Data   A block hash code from an additional block in the execution layer.

deposits    Deposit contract address and a string of unrecorded deposits.

This requires all verifiers to run a beacon client and an execution client. This is necessary because the validators must check the corresponding ETH1 block and verify its validity according to the execution layer rules. Similarly, as discussed in our article on the registration process, deposits must be transferred from the execution level to a beacon block within a specified block interval, or the beacon block will be rejected.

metadata  slot number, epoch number, random beacon, and block proposer

Forfeiture event  Include evidence of malicious behavior by other verifiers, which can be used to punish them

Voting history  A series of unrecorded votes on this blockchain fork for a previously proposed beacon block

Blockchain fork  It picks a parent block and in turn defines the canonical chain that this block extends.

Verifier exit  A stream of exit requests from registered verifiers.

By recording the copy, each person can review the entire protocol independently and be absolutely confident that the current state of the beacon chain is correct. For example, malicious verifiers are promptly forfeited, slot and epoch schedules are accepted by all verifiers, and the vast majority of verifiers vote this way and produce a separate specification chain.

As an aside, for reasons of weak subjectivity, although the record of proof of interest can convince us that all historical activities were conducted according to the rules, it is not enough to show an outside group that this is indeed the real beacon blockchain. Simply put, it provides a way to check the integrity of historical activities.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia