It introduces Proof of stake to Ethereum1 and runs along it. It’s also called the coordination layer.
Assign validators their duties
Perform a protocol level random number generation (RNG)
Progress the beacon chain
Vote on the head of the chain for the fork choice
Link and vote in transitions/data of shard chains
A time period of 12 seconds in which a randomly chosen validator has time to propose a block. Each slot may or may not have a block in it. The total number of validators is split up in committees and one or more individual committees are responsible to attest to each slot. One validator from the committee will be chosen to propose a block, while the other 127 are attesting. After each Epoch, the validators are mixed and merged to new committees (minimum of 128 validators per committee).
Represents the number of slots and takes approximately 6.4 minutes and consists of 32 Slots (12 seconds each).
Each validator needs to deposit 32 ETH into the validator-deposit-contract on the ETH1 chain and requires the user to run a validator node. Their job is to propose blocks and attestations.
1. Deposited: 32 ETH has been deposited to the ETH1 deposit-contract and this state will be kept for around 7 hours. This offers security in case the ETH1 chain gets attacked.
2. Pending: Waiting for activation on ETH2
Until 327680 active validators in the network, 4 validators can be activated per epoch (900 per day). After that 5 can be activated per epoch and the number of validators that can be activated increases by 1 for every 64k additional active validators.
Amount of activations scales with the amount of active validators
and the limit is the active validator set divided by 64.000
3. Active Validator Currently attesting and proposing blocks (=Block proposer).
The Validator will stay active until:
the balance drops below 16 ETH (ejected).
4. Slashing Validator: The Validator has been malicious
5. Exiting Validator
Ejected: the validator balance fell below a threshold and was kicked out by the network
Exited: voluntary exit
A validator which was chosen by the beacon chain to propose the next block. There is only one per slot.
Votes by validators which confirm the validity of a block.
Refers to pending validators. The deposit has been recognized by the ETH2 chain at the timestamp of “Eligible for activation”. If there is a queue of pending validators an estimated timestamp for activation will be calculated.
The current balance is the amount of ETH held by the validator as of now. The effective Balance represents a value calculated by the current balance. It is used to determine the size of a reward or penalty a validator receives. The effective balance can never be higher than 32 ETH.
Here are examples on how the effective balance is calculated:
Current balance: 32.00 ETH – Effective balance: 32.00 ETH
Current balance: 21.76 ETH – Effective balance: 22.00 ETH
Current balance: 21.749 ETH – Effective balance: 21.00 ETH
Current balance: 29.99 ETH – Effective balance: 30.00 ETH
Current balance: 21.58 ETH – Effective balance: 21.00 ETH
In order to increase the effective balance, the validator requires “effective balance + 1.25 ETH”. In other words, if the effective balance is 20 ETH, a current balance of 21.25 ETH is required in order to have an effective balance of 21 ETH. The effective balance will adjust once it drops by 0.25 below the threshhold as seen in the examples above.
In Ethereum 2.0 at least two third of the validators have to be honest, therefore if there are two competing Epochs and one third of the validators decide to be malicious, they will receive a penalty. Honest ones will be rewarded.
In order to determine if an Epoch has been finalized, validators have to agree on the latest two epochs in a row (= “justified”) then all previous Epochs can be considered as finalized.
Proposed: The block passed and was proposed by a validator.
Scheduled: Validators are currently submitting data.
Missed/Skipped: The proposer didn’t propose the block within the given time frame, so the block was missed/skipped.
Orphaned: In order to understand this easily we look at the diagram below: (the numbers "1, 2, 3, ... ,9" represent the number of the slots).
Validator at slot 1 proposes the block “a”.
Validator at slot 2 proposes “b”.
Validator 3 proposes “c”.
Slot 4 is being skipped because the validator didn’t propose a block (e.g.: offline).
At slot 5/6 a fork occurs: Validator(5) proposes a block, but validator(6) doesn’t receive this data (e.g.: the block didn’t reach them fast enough). Therefore Validator(6) proposes its block with the most recent information it sees from validator(3).
The fork choice rule is the key here - It decides which one of the available chains is the canonical one.