3 Steps To Understand The Ethereum Beacon Chain In 5 minutes.
Understanding how the Beacon Chain works is extremely important for every developer and researcher, especially if you are interacting with oracles or liquid staking protocols, which nowadays means mostly everyone.
However, I found most of the articles on this topic can feel very bloaty and intimidating for newcomers. So I tried to package it in the most succinct form I could, while still keeping most of the meat in there.
This will be a top-down view of how it works, the forrest before the trees approach. I hope you find it useful!
Step 1 - Understanding what the Beacon Chain goal is:
The goal of the Beacon chain is to choose the blocks that will make up the Ethereum Blockchain - that’s it, done. Easy right?
Step 2 - Understanding the different terms and moving pieces:
Slots and Epochs:
The Beacon Chain is measured in Epochs, each Epoch contains 32 slots.
1 slot takes 12 seconds, so each Epoch takes 6.4 minutes.
What is a slot?
It is a chance for a validator to add a block to the Beacon Chain.
Slots can but not necessarily need to contain a block, hence they can also be empty (no block).
Block:
Contains all the execution payload for Ethereum user transactions as well as information on the state of the beacon chain
Stakers:
User’s who stake 32 ETH to activate and control validators.
Validators and its different flavours:
Validators:
Run Ethereum’s consensus mechanism to propose and vote on blocks for slots as well as policing other validators. They have a maximum effective balance of 32 ETH and are activated by Stakers.
Attester:
Validators that vote on a proposed block.
Such votes are also called Attestations. This vote is weighted by the validator’s balance and contains both a LMD GHOST vote and a FFG vote (more on that later).
Block proposer:
A validator that has been pseudorandomly (weighted by it’s balance) selected to build a block for that slot. This validator receives rewards if Attesters vote for his proposed block.
In case a block is not proposed (due to validator being offline or out of sync), the slot will be empty and the block proposer misses out on the reward.
Proposers are only assigned to slots once the epoch starts.
Committee:
Group of at least 128 pseudorandomly selected validators for each slot as Attesters. There can be more than 1 committee per slot. A validator can only be in one Committee per Epoch.
Validators are assigned to committees one Epoch in advance. When different attesters make the same LMD GHOST and FFG votes their signature is combined into a single Committee aggregate signature.
Checkpoint:
Block in the first slot of an Epoch, if non existent, then it is the most recent block in a previous Epoch.
Target:
Block on the current epoch being voted as the next checkpoint. This vote is a called a Casper FFG vote.
Supermajority:
A vote that is made by ⅔ of the total balance of all active validators. At the end of an epoch if its checkpoint has garnered a ⅔ supermajority, the checkpoint gets justified.
Checkpoint Justification:
Target 0 is set as the next checkpoint (justified) by 2/3 of the validator set.
Checkpoint Finalisation:
Target 1 is set (justified) which triggers Target 0 to get Finalised. The Finalisation of Target 0 leads to the finalisation of all its preceding blocks. Aka official inclusion in the blockchain!
LMD GHOST vote:
Attesting to the Head of the Beacon Chain. It is basically a vote on what should be the next block in the chain, making sure the chain keeps churning new blocks.
Casper FFG vote:
Vote for the block (target) to be the next checkpoint in its current epoch. Includes the prior checkpoint, also referred to as Source. This provides finality of transactions and makes keeps the chain from having multiple forks.
Note:
all validators in an epoch attempt to finalise the same checkpoint: FFG vote.
all validators assigned to a slot attempt to vote on the same Beacon Chain head (LMD GHOST vote).
Step 3 - Understand how those moving pieces fit together:
Validators incentives:
There are 6 types of validator incentives, 3 of them are positive rewards, the other 3 are penalties.
Validators Positive Rewards:
Attester Rewards: When a validator votes(Attestations) on blocks that the majority of validators agree with they get rewarded. Attestation in finalised blocks give more rewards
Whistleblower Rewards: The validator who reports others validators who are committing slashable offences will get a whistleblower reward. An honest validator cannot be slashed, however one that is misbehaving by committing slashable offences(see below) can have 0.5 ETH up to its entire balance slashed. The more validators commit a slashable offence simultaneously, the higher will be their penalty, following this formula: validator_balance*3*fraction_of_validators_slashed.
Proposer Rewards: Earned by the validator chosen to be the block proposer for that block. This is a more rare and sizeable type of reward in comparison to the Attester Reward. Block Proposers are also currently the recipients for the Whistleblower Rewards.
Validators Penalties:
Attester Penalties: If validators do not vote they are penalised.
Downside Stakes Risk: This is similar to the one above but also take into account failure to propose blocks, which also incurs a penalty. In general a Staker downside risk mirror the amount it can earn, if their honest validator is operated horribly.
Inactivity Penalty: A severe penalty that is incurred if a validator is inactive for more than four epochs since finality. This penalty increases quadratically until the finalisation of a checkpoint. By doing so it forces the exit of inactive validators in and enables active validators to become part of the 2/3 majority.
Slashable Offences For Validators:
There are 4 slashing conditions that could affect validators.
1. Double Proposal:
When a Block Proposer attempt to propose more than one block for their slot.
2. LMD GHOST Double Vote:
When an Attester attempts to vote for two different Beacon Chain heads for their slot.
3. FFG Double Vote:
When a validator attempts to vote for two different Targets at the same Epoch. More likely during a Fork.
4. Surround Vote:
FFG votes involve a Source (prior checkpoint) and a Target (current checkpoint), for example Source is at slot 32 and Target at slot 64. A surround vote occurs when a validator makes a FFG vote that surrounds or is surrounded by a previous vote they made.
A vote that surrounds in this instance, would be one that has a Source at slot 0 and a Target at slot 96, and the surrounded vote would be the one where Source is at slot 32 and the Target at a slot 64. Example diagram where bold represents the vote that surrounds: [0] - [32] - [64] - [96].
On validator Activations & Exits:
There are mechanisms limiting how many validators can be activated or exited within an epoch. These mechanisms make it more difficult to quickly activate many malicious validators to attack the system.
Putting everything together (very simply):
Stakers stake ETH to create and control a validator.
A validator is responsible for voting, proposing blocks and policing other validators.
If a validator misbehaves it gets punished by having its balance slashed.
Committees of validators will together arrive at an agreement for the chosen block.
Fun Facts:
A Proposer can also be part of a committee on the same slot with a 1/32 probability, so once per Epoch.
Only validators assigned to a slot cast an LMD GHOST vote for that slot. However, all validators cast FFG votes for each epoch checkpoint.
The justification of a block can sometimes finalise a block two or more epochs ago. The Gasper paper discusses these cases. They are expected only in exceptional times of high latency, network partitions, or strong attacks.
An attestation, because of how they can be aggregated, can appear to be more than one vote. The same attestation can appear in different aggregates, but it is still the same attestation and not a double vote.
In any voluntary or forced exit, there is a delay of four epochs before stakers can withdraw their stake. Within the four epochs, a validator can still be caught and slashed.
An honest validator’s balance is withdrawable in around 27 hours. But a slashed validator incurs a delay of 8,192 epochs (approximately 36 days).
Now you know from a high level how the Beacon Chain actually works. This is a short summary and skips over many of the intricate operational details. If you want to dive deeper we recommend diving into these resources:
If you found this useful, please share!