This living document is a non-exhaustive list of key terms to understand the eth2 protocol, as defined by the Bison Trails Protocol Ops Team. Want to learn more? Check out the Bison Trails guide to eth2.
On eth2, the activation queue is a window of time between submitting an eth1 deposit to the eth2 deposit contract, and activation of one’s validator in the eth2 network.
The queue exists as only four validators can enter the network per epoch. It becomes longer as more validators enter the network.
On eth2, the active set includes all validators with balance greater than 32 ETH.
On eth2, active validators are validators that have completed the activation queue, are not in an exit queue, and have effective balances greater than 32 ETH.
Attestations are how validators vote in eth2 in order to reach consensus on the state of the network.
On eth2, the primary source of load on the Beacon Chain will be "attestations." Attestations in Phase 0 are consensus votes that include information about: (i) the target slot, (ii) the last justified checkpoint–the “source” checkpoint, and (iii) the next proposed justified checkpoint–the “target” checkpoint. Every active validator must attest once in every epoch.
The Beacon Chain is the central controller of the eth2 system.
The Beacon Chain holds eth2’s shards together and enables consensus and cross-shard communication. It has a registry of validator addresses, the state and balance of each validator, attestations, and links to shards. It is the coordination mechanism of the eth2 network, implementing the network's proof of stake consensus mechanism.
Casper the Friendly Finality Gadget makes the final decision on which blocks are part of the chain on eth2.
Casper FFG also provides security by finalizing epochs.
The checkpoint is the first block of an epoch in eth2, where committees and validators for the epoch are decided.
eth2's checkpoint is the first block of an epoch; this is where all the validators for the epoch, and committees of attesters for the next epoch, are decided. The eth2 protocol uses checkpoints as the benchmarks for blockchain time. For example, finality is achieved by counting votes from validators towards source and target checkpoints.
Committees review the proposed beacon blocks and shard blocks, and vote on them. Within each slot, the first member of the committee has the chance to propose a block and all others must attest to it.
The minimum committee size that the protocol targets is 128 attesters, and the maximum is ~5,000. As the active validator set increases, so will the number of committees. There can be 64 committees per slot at maximum.
The eth2 deposit contract is the smart contract used to create new validators on the eth2 chain.
The deposit contract is a smart contract on the Ethereum 1.X chain that allows users to create validators in eth2 by moving ETH from Ethereum 1.X onto the eth2 Beacon Chain in 32 ETH chunks. The contract is unidirectional: once you move your ETH, it can not be withdrawn until eth2 Phase 1.5.
The deposit contract went live on November 4th, 2020. You can track the activity related to it here.
The detection delay is the period between when a slashable offense occurs and when the validator responsible has their funds slashed as a result.
The effective balance in eth2 is the 32 ETH a validator uses for consensus, regardless of how much higher the validator’s overall balance of ETH is.
The effective balance is the amount of ETH that is actually actively participating in consensus in an eth2 validator, equal to 32 ETH.
Because validator balances change every epoch it is very computationally expensive to continuously use new balances. The effective balance is just the validator balance, but rounded (in a special way) to a whole ETH number. Even if a validator accrues 2 ETH from rewards on the validator, bringing the validator balance to 34 ETH, only 32 ETH will be actively participating.
An epoch is the main time-measurement unit in eth2. Each epoch is composed of 32 slots in which blocks can be proposed. An epoch corresponds to ~6.4 minutes.
The eth2 exit queue is the waiting period for validators to leave the eth2 protocol.
Validators that exit the eth2 protocol are put in an exit queue before they are able to exit the network. The exit queue is 4 epochs long.
While in the exit queue, validators do not actively participate in consensus, but can still be slashed for prior violations that took place while they were active.
An exit oneth2 is the act of a validator leaving the network. This can be either voluntary or enforced by the protocol, tied to a violation of protocol rules. Even if a validator voluntarily exits in Phase 0, they are not able to withdraw their locked ETH until Phase 1.5 is activated.
Finality is the state eth2 reaches when the information included on a block can no longer be changed.
Finality is a state the chain achieves when a block (and its contents—e.g. transactions) can no longer be changed without a large percentage of stake getting destroyed. eth2 guarantees finality, with a target of two epochs to reach it, at any given point in time. In order for finality to be reached, ⅔ of active validators need to get their attestations included on-chain.
Hysteresis is the rounding factor that impacts the validator balance to give the effective balance. The final settings are that once the validator balance falls by .25ETH below a whole number (i.e., 32 ETH -> 31.75 ETH) the effective balance goes from 32 ETH to 31 ETH. In order to bring it back up to 32, the validators balance needs to be 1.25 ETH above the whole number (i.e., once the validator balance hits 32.25 ETH, the effective balance goes from 31 to 32 ETH).
The Inactivity Leak Penalty is a countermeasure for if the network stops finalizing blocks due to a large number of validators going offline simultaneously.
The eth2 inclusion delay is the period between when a validator is is called to do work and when that work is included on-chain.
eth2's inclusion delay is the delta between the slot that a validator is called to attest in and the slot that their attestation is included on-chain. This takes a value of 1 at minimum; for example, if said validator has been allocated an attestation duty on slot x in epoch y, their attestation will be included in slot x+1 at minimum.
eth2's justification is a product of attester votes on checkpoints being included on the chain. The goal of justification is to decide which checkpoint is the head of the beacon chain.
If 2/3 of active validators agree on a source and target checkpoint pair, wherein the source epoch is justified, then the target epoch is also justified. If two epochs in a row (with an arbitrary gap allowed between them–to allow the chain to finalize eventually, even under extreme conditions when the majority of validators have been offline for an extended period of time) are justified, the first one of those two is deemed finalized.
LMD GHOST stands for Last Message Driven Greediest Heaviest Observed SubTree. This is the module that adds new blocks and decides what the head of the chain is.
eth2's slashable violations are a collection of deviations from protocol rules that result in slashing.
s1>s2>t2>t1. See here for an example.
A slot is a period of time in which a block proposer in eth2 may propose a block. This is the most granular measurement of “on-chain” time.
A validator client is a node that holds validators. It can technically also simultaneously serve as a beacon node, but this is not advisable because then it will be at risk of DoS attacks. The validator client will connect to public-facing beacon nodes to enable its validators to participate in consensus.
A validator is an entity that directly participates in consensus on eth2.
In order to operate a validator, one must put 32 ETH in the eth2 deposit contract on the Ethereum 1.X chain. Each eth2 validator is primarily identified by a public_key and validator_index.
eth2’s weak subjectivity period is the period of time after a slashable offense is committed during which the validator who committed it can still be slashed.
The weak subjectivity period on eth2 is an arbitrarily long period of time during which a validator can be slashed for prior misconduct. In practice, this means that slashing proofs can be included on-chain (and slashings can be enforced) much later than the slashable offense actually took place.
→ View more terminology.
Bison Trails is a blockchain infrastructure platform-as-a-service (PaaS) company based in New York City. We built a platform for anyone who wants to participate in 21 new chains effortlessly.
We also make it easy for anyone building Web 3.0 applications to connect to blockchain data from 33 protocols with Query & Transact (QT). Our goal is for the entire blockchain ecosystem to flourish by providing robust infrastructure for the pioneers of tomorrow.
In January, 2021, we announced Bison Trails joined Coinbase to accelerate our mission to provide easy-to-use blockchain infrastructure, now as a standalone product line. The Bison Trails platform will continue to support our customers. With Coinbase’s backing, we will enhance our infrastructure platform and make it even easier to participate in decentralized networks and build applications that connect to blockchain data.