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
32 Slots = 1 Epoch 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 be the aggregator, while the other 127 validators are attesting. After each Epoch, the validators are mixed and merged to new committees. There is a minimum of 128 validators per committee.
The Deposit contract is the gateway to Ethereum 2.0 through a smart contract on Ethereum 1.0. The smart contract accepts any transaction with a minimum amount of 1 ETH and a valid input data. Ethereum 2.0 beacon-nodes listen to the deposit contract and use the input data to credit each validator. More infos the Deposit Contract
The Input data, also called the deposit data, is a user generated, 842 long sequence of characters. It represents the validator public key and the withdrawal public key, which were signed with by the validator private key. The input data needs to be added to the transaction to the deposit contract in order to get identified by the beacon-chain. More infos about the Deposit process.
Validators need to deposit 32 ETH into the validator deposit contract on the Ethereum 1.0 chain. Validator operators have to run a validator node. Its job is to propose blocks and sign attestations. A validator has to be online for at least 50% of the time in order to have positive returns.
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 is calculated.
Every validator receives its unique index. beaconcha.in.
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. 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 threshold as seen in the examples above.
Here are examples on how the effective balance changes
If the Current balance is 32.00 ETH – the Effective balance is 32.00 ETH
If the Current balance dropped from 22 ETH to 21.76 ETH – Effective balance will be 22.00 ETH
If the Current balance increases to 22.25 and the effective balance is 21 ETH, the effective balance will increase to 22 ETH
The slasher is its own entity but requires a beacon-node to receive attestations. To find malicious activity by validators, the slashers iterates through all received attestations until a slashable offense has been found. Found slashings are broadcasted to the network and the next block proposer adds the proof to the block. The block proposer receives a reward for slashing the malicious validator. However, the whistleblower (=Slasher) does not receive a reward. Slashable offenses
Double voting An attester signs two different attestations in one epoch.
Surround votes An attester and sign an attestation that surrounds another one.
Double block proposal A block proposer signs two different blocks for the same slot.
Votes by validators which confirm the validity of a block. (=Attester)
A chosen validator by the beacon chain to propose the next block. There can only be one valid block per slot.
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, let us look at the diagram below "1, 2, 3, ... ,9" represent the slots.
Validator at slot 1 proposes the block “a”.
Validator at slot 2 proposes “b”.
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 of the available chains is the canonical one.
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.
Waiting for activation on ETH2
Until 327680 active validators in the network, 4 validators can be activated per epoch. For every 65536 (=4 * 16384) active validator, the validator activation rate goes up by one. 5 validators per epoch requires 327680 active validators.
Amount of activations scales with the amount of active validators and the limit is the active validator set divided by 64.000
Currently attesting and proposing blocks (=block proposer).
The validator will stay active until:
its balance drops below 16 ETH (ejected).
it gets slashed
The Validator has been malicious and will be slashed and kicked out of the system
A Penalty is a negative reward (e.g. for going offline). A Slashing is a large penalty (≥ 1/32 of balance at stake) and a forceful exit ... . - Justin Drake
5. Exiting Validator
Ejected The validator balance fell below a threshold and was kicked out by the network
Exited Voluntary exit, the withdrawal key holder has the ability to withdraw the current balance of the corresponding validator balance.
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.