# Week 2

Hi everyone, my Week 2 was spent mostly in studying about the Beacon Chain, how finality and sync committees work, exploring the Consensus Layer more and learning about Consensus Mechanisms like LMD Ghost and Casper FFG.

## Technical Overview of the Consensus Layer

### Preliminaries

* Consensus is a way to build reliable distributed systems with unreliable components.
* Blockchain-based distributed systems aim to agree on a single history of transactions.
* Proof of work and proof of stake are not consensus protocols, but enable consensus protocols.
* Many blockchain consensus protocols are "forkful".
* Forkful chains use a fork choice rule, and sometimes undergo reorganisations.
* In a "safe" protocol, nothing bad ever happens.
* In a "live" protocol, something good always happens.
* No practical protocol can be always safe and always live.

Coming to the last point its important to notice that the Ethereum consensus protocol offers both safety and liveness in good network conditions, but prioritises liveness when things are not running so smoothly.

### Slots and Epochs

Time is strictly regimented in Ethereum's proof of stake consensus, which is a major change from proof of work, which only had casual relationship with time - PoW makes some attempt to keep block intervals constant on average, but that's all.

The two most important intervals are the slot, which is 12 seconds exactly, and the epoch, which is 32 slots, or 6.4 minutes. Slots and epochs progress regularly and relentlessly, whatever else may be happening on the network.
A slot is like the block time, but slots can be empty. The Beacon Chain genesis block is at Slot 0.

### Blocks and Attestations

Every slot, exactly one validator is selected to propose a block. The block contains updates to the beacon state, including attestations that the proposer knows about, as well as the execution payload containing Ethereum user transactions. The proposer shares its block with the whole network via a gossip protocol.

A slot can be empty: a block proposer might be offline, or propose an invalid block, or have its block subsequently reorged out of the chain. These things should not happen often in a well-running beacon chain, but the protocol is intended to be robust when empty slots occur.

Every epoch, every validator gets to share its view of the world exactly once, in the form of an attestation. An attestation contains votes for the head of the chain that will be used by the LMD GHOST protocol, and votes for checkpoints that will be used by the Casper FFG protocol. Attestations are also gossiped to the whole network. Like blocks, attestations can be missing for all sorts of reasons, and the protocol can tolerate this to various extents - crudely, the quality of consensus will decrease as the participation rate of attesters decreases.3

The function of the epoch is to spread out the workload of handling all those attestations. By attesting, every validator is informing every other validator of its view of the world, which could amount to an immense amount of network traffic and processing load if it were all done at once. Spreading the attestation workload across all 32 slots of an epoch keeps resource usage low. In each slot, committees comprising only 1/32 of the validators make attestations.

The protocol incentivises block and attestation production and accuracy via a system of rewards and penalties for validators.

### Committees

A committee is a group of validators. For security, each slot has committees of at least 128 validators. An attacker has less than a one in a trillion probability of controlling ⅔ of a committee.

The concept of a randomness beacon that emits random numbers for the public, lends its name to the Ethereum Beacon Chain. The Beacon Chain enforces consensus on a pseudorandom process called RANDAO.
Proposers are selected by RANDAO with a weighting on the validator’s balance. It’s possible a validator is a proposer and committee member for the same slot, but it’s not the norm. The probability of this happening is 1/32 so we’ll see it about once per epoch. The sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot.
The diagram is a combined depiction of what happened in three slots. In Slot 1, a block is proposed and then attested to by two validators; one validator in Committee A was offline. The attestations and block at Slot 1 propagate the network and reach many validators. In Slot 2, a block is proposed and a validator in Committee B does not see it, thus it attests that the Beacon Chain head is the block at Slot 1. Note this validator is different from the offline validator from Slot 1. Attesting to the Beacon Chain head is called an LMD GHOST vote. In Slot 3, all validators in Committee C run the LMD GHOST fork choice rule, and independently attest to the same head.

A validator can only be in one committee per epoch. Typically, there are more than 8,192 validators: meaning more than one committee per slot. All committees are the same size, and have at least 128 validators. The security probabilities decrease when there are less than 4,096 validators because committees would have less than 128 validators.

### Beacon Chain Checkpoints

A checkpoint is a block in the first slot of an epoch. If there is no such block, then the checkpoint is the preceding most recent block. There is always one checkpoint block per epoch. A block can be the checkpoint for multiple epochs.

### Finality

When an epoch ends, if its checkpoint has garnered a ⅔ **supermajority**(A vote that is made by ⅔ of the total balance of all active validators, is deemed a supermajority), the checkpoint gets justified.

If a checkpoint B is justified and the checkpoint in the immediate next epoch becomes justified, then B becomes finalized. Typically, a checkpoint is finalized in two epochs, 12.8 minutes.

On average, a user transaction would be in a block in the middle of an epoch. It’s half an epoch until the next checkpoint, suggesting transaction finality of 2.5 epochs: 16 minutes. Optimally, more than ⅔ of attestations will have been included by the 22nd slot of an epoch. Thus, transaction finality is an average of 14 minutes (16+32+22 slots). Block confirmations emerge from a block’s attestations, to its justification, to its finality. Use cases can decide whether they need finality or an earlier safety threshold is sufficient.
To simplify the following narratives, assume that validators all have the same balance.

#### What happened at the Beacon Chain head?

The epoch boundary block at Slot 96 is proposed and contains attestations for the Epoch 2 checkpoint. The number of attestations for the Epoch 2 checkpoint now reaches the ⅔ supermajority. This causes the justification of the Epoch 2 checkpoint, and thus the finality of the previously justified Epoch 1 checkpoint. The finality of Slot 32 immediately causes the finality of all blocks preceding it. When finalizing a checkpoint, there is no limit to the number of blocks that can be finalized. Although finality is only computed at epoch boundaries, attestations are accumulated at each block, as described in alternate narratives “What could have happened from genesis to the head” below.

#### What could have happened from genesis to the head?

With the same illustration, here is a storyline that could have been observed from genesis. All the proposers from Slot 1 until Slot 63 propose a block, and these appear on-chain. With each block in Epoch 1, its checkpoint (block at Slot 32) accumulates attestations from 55% of validators. The block at Slot 64 is proposed and it includes attestations for the Epoch 1 checkpoint. Now, 70% of validators have attested to the Epoch 1 checkpoint: this causes its justification. The Epoch 2 checkpoint (Slot 64) accumulates attestations throughout Epoch 2 but does not reach the ⅔ supermajority. The block at Slot 96 is proposed and it includes attestations for the Epoch 2 checkpoint. This leads to reaching the ⅔ supermajority and the justification of the Epoch 2 checkpoint. Justifying the Epoch 2 checkpoint finalizes the Epoch 1 checkpoint and all prior blocks.

Here is another possible scenario. Consider only until Epoch 1. The checkpoint at Epoch 1 could have obtained a ⅔ supermajority before the checkpoint at Epoch 2 is proposed. For example, as the blocks in Slot 32 to Slot 54 are proposed, the attestations to justify the checkpoint (Slot 32) could have already reached the ⅔ supermajority. In this case, the checkpoint would have been justified before Epoch 2. A checkpoint can be justified in its current epoch, but its finalization requires at least the epoch after it.

The justification of a block can sometimes finalize 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.

## Consensus Mechanisms

### LMD Ghost
LMD Ghost stands for Latest Message Driven and Greedy Heaviest-Observed Sub-Tree.
* LMD GHOST is a fork choice rule used by nodes to determine the best chain.
* It assigns weights to branches based on votes from all active validators.
* LMD GHOST does not provide finality, but does support a confirmation rule.
* Slashing is used to solve the "nothing at stake" problem.

LMD Ghost is explained in detail and very well in [here](https://eth2book.info/capella/part2/consensus/lmd_ghost/).

### Casper FFG

The FFG in Casper FFG stands for "Friendly Finality Gadget".
* Casper FFG adds finality to the Eth2 consensus protocol.
* It acts as an overlay on LMD GHOST consensus that modifies its fork choice rule.
* Casper FFG is classically safe under asynchrony when less than 1/3 of validators are faulty or adversarial.
* Moreover, slashing allows Casper FFG to provide accountable safety, also known as economic finality, when more than 1/3 are adversarial.

Some good resources to go into details would again include the [Eth2Book Casper FFG section](https://eth2book.info/capella/part2/consensus/casper_ffg/) and this [paper](https://arxiv.org/pdf/1710.09437).

## Slashable Offences

While being a honest validator would get you incentives, it is important to remember that engaging in any kind of dishonest practices as a validator can lead to getting your staked ETH slashed and even potential ban from the network. The amount of ETH slashed varies and is dependent on the situation.

There are four slashing conditions for validators. They can be described as a double proposal, an LMD GHOST double vote, an FFG surround vote, and an FFG double vote.

A **double proposal** is a proposer proposing more than one block for their assigned slot.

Similarly, an **LMD GHOST double vote** is a validator attesting to two different Beacon Chain heads for their assigned slot.

A **surround vote** is a validator casting an FFG vote that surrounds or is surrounded by a previous FFG vote they made. Here are two examples based on a scenario that a validator made an FFG vote in Epoch 5 with a source of Slot 32 and target of Slot 128:
* An FFG vote in Epoch 6 with a source of Slot 64 and target of Slot 96, would be an FFG vote that was surrounded by their Epoch 5 vote.
* An FFG vote in Epoch 6 with a source of Slot 0 and target of Slot 160 would surround their FFG vote in Epoch 5.

An FFG double vote is a validator casting 2 FFG votes for any two targets at the same epoch. This can happen during a fork.

## Conclusion

At every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. Validators can only be in one slot, and in one committee. Collectively:
* all validators in an epoch attempt to finalize the same checkpoint: FFG vote
* all validators assigned to a slot attempt to vote on the same Beacon Chain head: LMD GHOST vote

Optimal behavior rewards validators the most.

## References
* [The Eth2Book](https://eth2book.info/capella/)
* https://ethos.dev/beacon-chain
* https://www.youtube.com/watch?v=5gfNUVmX3Es