Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus Layer Wiki Page #246

Merged
merged 63 commits into from
Jul 30, 2024
Merged
Changes from 1 commit
Commits
Show all changes
63 commits
Select commit Hold shift + click to select a range
a0ae153
CL init, Update overview of CL
shyam-patel-kira May 2, 2024
dd773ff
Update ordering
shyam-patel-kira May 2, 2024
d10c76e
Update to current changes
shyam-patel-kira May 14, 2024
ae4124c
Add validators section to overview
shyam-patel-kira May 14, 2024
e82b698
add iamges; added Beacon chain explainer; checkpoints and finality; s…
shyam-patel-kira May 15, 2024
1fef51a
Added validator life cylce
shyam-patel-kira May 15, 2024
abed432
fix typo; update wordlist
shyam-patel-kira May 15, 2024
17656e0
Update state of validators
shyam-patel-kira May 17, 2024
55e6a24
Improve flow of the page;added simpler explanations; added some links
shyam-patel-kira May 18, 2024
b4fd8c7
add introduction; minor fixes
shyam-patel-kira May 19, 2024
e044716
Minor typos ffix
shyam-patel-kira May 19, 2024
93e3671
add introduction; added byzantine generals problem
shyam-patel-kira May 19, 2024
b0f53d7
revamp overview structure
shyam-patel-kira May 20, 2024
af6f604
fix dark background in svg
shyam-patel-kira May 20, 2024
bec30b3
complete overview of CL; added cl-architecture structure
shyam-patel-kira May 20, 2024
8a6c63d
Added Blocktree and fork-choice rules
shyam-patel-kira May 21, 2024
ad71957
Merge branch 'main' of https://github.com/eth-protocol-fellows/protoc…
shyam-patel-kira May 21, 2024
9705975
fix some typos; update wordlist
shyam-patel-kira May 21, 2024
68087f0
Merge branch 'main' of https://github.com/eth-protocol-fellows/protoc…
shyam-patel-kira May 21, 2024
11dbc63
add reorgs and reversion
shyam-patel-kira May 21, 2024
107038f
Add liveness and safey comparision
shyam-patel-kira May 21, 2024
2750896
Add some more details on consensus protocol
shyam-patel-kira May 23, 2024
89d042d
Add architecture and blobs
shyam-patel-kira May 23, 2024
d516ade
stf; control flow
shyam-patel-kira May 23, 2024
9c34f94
fix a broken link; added gasper file
shyam-patel-kira May 26, 2024
51cbbbe
Use consistent naming for PoW and PoS
shyam-patel-kira May 26, 2024
5d62c91
Complete cl-architecture
shyam-patel-kira May 30, 2024
1e1c000
Update structure of cl-networking
shyam-patel-kira Jun 19, 2024
8488571
fix spelling mistake
shyam-patel-kira Jun 19, 2024
9fe39bb
fix typos; added words to wordlist
shyam-patel-kira Jun 19, 2024
a0477c2
remove whitespace
shyam-patel-kira Jun 19, 2024
36ad561
address some nits
shyam-patel-kira Jun 20, 2024
2f86faf
Omit some redudant content
shyam-patel-kira Jun 20, 2024
32dd223
remove redundant content; fix broken links
shyam-patel-kira Jun 20, 2024
e8d87ec
Update proposer and validator set wording
shyam-patel-kira Jun 20, 2024
e4eabfd
Address some more nits
shyam-patel-kira Jun 20, 2024
2fad7dd
Merge branch 'feat/consensus-layer' of https://github.com/eth-protoco…
shyam-patel-kira Jun 20, 2024
e67c1e1
Add resources; omit whitespace
shyam-patel-kira Jun 20, 2024
d6b78d8
fix typos
shyam-patel-kira Jun 20, 2024
528b7e2
Merge branch 'main' into feat/consensus-layer
shyam-patel-kira Jun 20, 2024
42f3617
Merge branch 'main' into feat/consensus-layer
shyam-patel-kira Jun 28, 2024
b664169
Update wordlist
shyam-patel-kira Jul 4, 2024
9d34f18
nit: grammar
shyam-patel-kira Jul 24, 2024
ae6fed1
nit: space
shyam-patel-kira Jul 24, 2024
502402b
nit: word
shyam-patel-kira Jul 24, 2024
bcd3adc
nit: word
shyam-patel-kira Jul 24, 2024
fa8de57
clean up
shyam-patel-kira Jul 24, 2024
45d4a3d
nit: spell
shyam-patel-kira Jul 24, 2024
8669733
Merge branch 'main' of https://github.com/eth-protocol-fellows/protoc…
shyam-patel-kira Jul 24, 2024
bec3641
nit: content captilization
shyam-patel-kira Jul 24, 2024
a661f2a
Merge branch 'feat/consensus-layer' of https://github.com/eth-protoco…
shyam-patel-kira Jul 24, 2024
3110ef2
Update wordlist
shyam-patel-kira Jul 24, 2024
a9bd4ad
nit: diagram name
shyam-patel-kira Jul 25, 2024
fd996f4
nit: word
shyam-patel-kira Jul 25, 2024
a671998
nit: clean up
shyam-patel-kira Jul 25, 2024
3b5d0bc
nit: clean up
shyam-patel-kira Jul 25, 2024
7bc5acc
nit: title
shyam-patel-kira Jul 25, 2024
8973b79
nit: wording
shyam-patel-kira Jul 25, 2024
0eb994c
nit: title
shyam-patel-kira Jul 25, 2024
b25a252
fix flow for the transition
shyam-patel-kira Jul 26, 2024
67061b5
Merge branch 'feat/consensus-layer' of https://github.com/eth-protoco…
shyam-patel-kira Jul 26, 2024
c941698
Merge branch 'main' of https://github.com/eth-protocol-fellows/protoc…
shyam-patel-kira Jul 26, 2024
bdf947d
Update beacon-api.md
taxmeifyoucan Jul 30, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
add iamges; added Beacon chain explainer; checkpoints and finality; s…
…lots and epochs
shyam-patel-kira committed May 15, 2024
commit e82b6981d5607711a18df70f5d2271e16f3b501e
Binary file added docs/images/cl/RANDAO.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/cl/checkpoints.jpg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/cl/committees.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/cl/finalization.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/cl/slots-and-epochs.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/images/cl/validators.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
147 changes: 146 additions & 1 deletion docs/wiki/CL/overview.md
Original file line number Diff line number Diff line change
@@ -80,4 +80,149 @@ Validators are essentially the participants in the PoS Protocol. They propose an

- **Proposing Blocks**: Validators take turns proposing new blocks during their assigned slots. They must construct valid blocks and broadcast them to the network.
- **Attesting to Blocks**: Validators review and attest to the blocks proposed by others. Attestations are votes on the validity of the blocks, ensuring consensus.
- **Participating in Consensus**: Validators participate in consensus by voting on the state of the blockchain at regular intervals, helping to finalize the blockchain's state.
- **Participating in Consensus**: Validators participate in consensus by voting on the state of the blockchain at regular intervals, helping to finalize the blockchain's state.

## Beacon Chain

The Beacon Chain is the backbone of Ethereum’s consensus. It coordinates validators, manages the PoS protocol, and ensures consensus across the network.

### Slots and Epochs

Each slot is 12 seconds and an epoch is 32 slots: 384 seconds or 6.4 minutes. Each slot has a validator assigned to propose a block, while committees of validators attest to the block’s validity.

A slot is a chance for a block to be added to the Beacon Chain. Every 12 seconds, one block is added. Validators do need to be roughly [synchronized with time](https://ethresear.ch/t/network-adjusted-timestamps/4187). A slot is like the block time, but slots can be empty. The Beacon Chain genesis block is at Slot 0.


<a id="img_slots_epochs"></a>

<figure class="diagram" style="margin-left:10%; width:80%">

![Diagram for slots and epoch](../../images/cl/slots-and-epochs.png)

<figcaption style="margin-left: 15%">

_The first 32 slots are in Epoch 0. Genesis blocks are at Slot 0._

</figcaption>
</figure>


### Validators and Attestations

A block proposer is a validator that has been pseudorandomly selected to build a block. Validators propose blocks and attest to the blocks proposed by others. Most of the time, validators are attesters that vote on blocks. These votes are recorded in the Beacon Chain and determine the head of the Beacon Chain.

Attestations are votes on the validity of the blocks, which are aggregated into the Beacon Chain to ensure consensus.

<a id="img_validators"></a>

<figure class="diagram" style="margin-left:10%; width:80%">

![Diagram for Validator selection](../../images/cl/validators.png)

<figcaption style="margin-left: 15%">

_A slot can be missed as you can see in this diagram on 28th slot_

</figcaption>
</figure>

An **attestation** is a validator’s vote, weighted by the validator’s balance. Attestations are broadcasted by validators in addition to blocks. Validators also police each other and are rewarded for reporting other validators that make conflicting votes, or propose multiple blocks.
shyam-patel-kira marked this conversation as resolved.
Show resolved Hide resolved

The contents of the Beacon Chain is primarily a registry of validator addresses, the state of each validator, and attestations. Validators are activated by the Beacon Chain and can transition to states

**IMPORTANT NOTE on Staking Validators Semantics:** *In Ethereum's PoS, users activate validators by staking ETH, similar to buying hardware in PoW. Stakers are associated with the amount staked, while validators have a maximum balance of 32 ETH each. For every 32 ETH staked, one validator is activated. Validators are run by validator clients, which use a beacon node to follow and read the Beacon Chain. A single validator client can manage multiple validators.*

### Committees

Committees are groups of at least 128 validators assigned to each slot for added security. An attacker has less than a 1 in a trillion chance of controlling ⅔ of a committee.

The concept of a randomness beacon that emits random numbers for the public, is how Beacon Chain got it's name. The Beacon Chain enforces consensus on a pseudorandom process called RANDAO.

<a id="img_randao"></a>
<figure class="diagram" style="text-align:center">

![Diagram for Validator selection](../../images/cl/RANDAO.png)

<figcaption>

_At every epoch, a pseudorandom process RANDAO selects proposers for each slot, and shuffles validators to committees._

</figcaption>
</figure>

**Validator Selection:**
- Proposers are chosen by RANDAO, weighted by validator balance.
- A validator can be both a proposer and a committee member for the same slot, but this is rare (1/32 probability).

The sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot.


<a id="img_committee"></a>
<figure class="diagram" style="margin: auto; width:80%">

![Diagram for Committees](../../images/cl/committees.png)

</figure>

The diagram is a combined depiction of what happened in 3 slots:
- Slot 1: A block is proposed and attested by two validators; one validator is offline.
- Slot 2: A block is proposed, but one validator misses it and attests to the previous block.
- Slot 3: All validators in Committee C attest to the same head, following the LMD GHOST rule.

Validators attest to their view of the Beacon Chain head using the LMD GHOST rule.
Attestations help finalize blocks by reaching consensus on the blockchain’s state.

**Committee Size and Security:**
- With more than 8,192 validators, multiple committees per slot are formed.
- Committees must be at least 128 validators for optimal security.
- Security decreases with fewer than 4,096 validators, as committee sizes drop below 128.

> At every epoch, validators are evenly divided across slots and then subdivided into committees of appropriate size. All of the validators from that slot attest to the Beacon Chain head. A shuffling algorithm scales up or down the number of committees per slot to get at least 128 validators per committee. More details on shuffling can be found in [proto's repo.](https://github.com/protolambda/eth2-docs#shuffling)

### Checkpoints and Finality

At the end of each epoch, checkpoints are created. 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.

A block becomes a checkpoint if it receives attestations from a majority of validators. Checkpoints are used to finalize the blockchain's state. A block is considered final when it is included in two-thirds of the most recent checkpoint attestations, ensuring it cannot be reverted.

<a id="img_checkpoints"></a>
<figure class="diagram" style="text-align:center">

![Diagram for checkpoints](../../images/cl/checkpoints.jpg)

<figcaption>

_Checkpoints for a scenario where epoch contain 64 slots_

</figcaption>
</figure>

For example, if Slots 65 to 128 are empty, the Epoch 2 checkpoint defaults to the block at Slot 64. Similarly, if Slot 192 is empty, the Epoch 3 checkpoint is the block at Slot 180. Epoch boundary blocks (EBB) are a term in some literature (such as the [Gasper](https://arxiv.org/abs/2003.03052) paper, the source of the diagram above and a later one), and they can be considered synonymous with checkpoints.

Validators cast two types of votes: **LMD GHOST** votes for blocks and **Casper FFG** votes for checkpoints. An **FFG** vote includes a source checkpoint from a previous epoch and a target checkpoint from the current epoch. For example, a validator in Epoch 1 might vote for a source checkpoint at the genesis block and a target checkpoint at Slot 64, repeating the same vote in Epoch 2. Only Validators assigned to a slot cast LMD GHOST votes, while all validators cast FFG votes for epoch checkpoints.

#### Supermajority and Finality:
shyam-patel-kira marked this conversation as resolved.
Show resolved Hide resolved

A supermajority, defined as ⅔ of the total validator balance, is required for a checkpoint to be justified. For instance, if validators have balances of 8 ETH, 8 ETH, and 32 ETH, a supermajority needs the vote of the 32 ETH validator. Once a checkpoint receives a supermajority, it becomes justified. If the subsequent epoch's checkpoint also achieves justification, the previous checkpoint is finalized, securing all preceding blocks. Typically, this process spans 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.

#### Closer look on Attestations

Validators submit one attestation per epoch, containing both an LMD GHOST and an FFG vote. These attestations have 32 chances per epoch for inclusion on-chain, with earlier inclusions receiving higher rewards. This means a validator may have two attestations included on-chain in a single epoch. Validators are rewarded the most when their attestation is included on-chain at their assigned slot; later inclusion is a decaying reward. To give validators time to prepare, they are assigned to committees one epoch in advance. Proposers are only assigned to slots once the epoch starts. Nonetheless, [secret leader election](https://ethresear.ch/t/low-overhead-secret-single-leader-election/5994) research aims to mitigate attacks or bribing of proposers.

<a id="img_finality"></a>
<figure class="diagram" style="text-align:center">

![Diagram for Finality](../../images/cl/finalization.png)

<figcaption>

_Example of one checkpoint getting justified (Slot 64) nd finalizing a prior checkpoint (Slot 32)._
shyam-patel-kira marked this conversation as resolved.
Show resolved Hide resolved

</figcaption>
</figure>

Consider a block proposed at Slot 64 containing attestations for the Epoch 2 checkpoint. This scenario can finalize the checkpoint at Slot 32. The finality of the Slot 32 checkpoint, once achieved, propagates backward, securing all preceding blocks.

In essence, Committees allow for the technical optimization of combining signatures from each attester into a single aggregate signature. When validators in the same committee make the same LMD GHOST and FFG votes, their signatures can be aggregated.