# key terminologies in Eth2.0 ###### tags: eth2.0 , terminology references: * [https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-client-architecture/](https://) * https://ethos.dev/beacon-chain ## Ethereum2.0 client architecture With Ethereum 2.0, we move away from the concept of a single full node to maintain the security of the network to two separate clients, the beacon node and the validator client. ![](https://i.imgur.com/5svmegy.png) ## Ethereum 2.0 phases * Phase 0 – Beacon Chain * Phase 1 – shards * Phase 2 – execution > [execution := smart contract feature], recently people have started calling eth1 as execution layer ## Beacon Node * Run and maintain the random beacon chain from the genesis block * Sync this beacon chain with peer nodes via peer to peer (as Eth1.0 nodes do today when they maintain the Eth 1.0 blockchain) * Process block attestations from validator clients/committees * Serve as RPC server/endpoint for validator clients to leverage to propose/attest beacon blocks * Handle beacon chain state transitions for each beacon block * Serve as source of randomness for validator slot/shard assignment * Sync and maintain current state of a subset of shards (anticipated to be the shards that connected validator clients are staking on) * Listen for block hashes/validator deposits on Eth 1.0 chain for new validators * Maintain the validator registry on the beacon chain, including adding and removing validators as necessary * Maintain a synchronized clock with other beacon nodes to help enforce slashing rules for validator clients :pencil: **Beacon Node staking requirements:** > Beacon nodes are the fundamental building blocks of Eth 2.0. Theoretically, anyone can run a beacon node and sync the current state of the overall beacon chain as there is no staking requirement to operate a beacon node. It is expected that most wouldbe validators on Eth 2.0 will run their own beacon nodes as *validator clients will need to trust the beacon node* they connect to ensure that their block proposals/attestations are broadcasted correctly. ## Beacon Chain The Beacon Chain provides the heartbeat to Ethereum 2.0. It provides the tempo and rhythm for the system’s harmony and consensus. Each slot is 12 seconds and an epoch is 32 slots: 6.4 minutes. ## Validator client The validator client is more or less equivalent to the miner on the Ethereum 1.0 blockchain and responsibilities are outlined below: * Propose new blocks on shards to which the validator is assigned * Participate in committees by signing attestations on blocks proposed by other validators within the committee * Aggregrate attestations from other validators on a committee when assigned for broadcasting to the beacon chain * Maintain an RPC connection to a trusted beacon node to listen for validator assignment/shuffling * Sync assigned shard with beacon chain for each proof of custody period > Each validator client requires a 32 ETH stake in the deposit contract on the Eth 1.0 blockchain. ## Validator Miners in Eth1.0 are equivalent to validators in Eth2.0 ## Block Proposer A block proposer is a validator that has been pseudorandomly selected to build a block. ## Deposit Contract to become a validator one needs to deposit an amount of 32 ETH in a deposit contract in Eth1.0 chain. ## Slots ![](https://i.imgur.com/Z9Aubef.png) every block in this the above image(beacon chain) is called a slot. > note: a slot can have empty block if the block proposer for that slot went offline or did not publish the block ## Epochs every consecutive 32 slots are treated as an epoch. ## Checkpoint every first slot in an epoch is considered as a checkpoint, the blue block in the above beacon chain image. we have introduced this notion of checkpoints so that a client sync is fast. ## Attestations Most of the time, validators are attesters that vote on beacon blocks and shard blocks. These votes are recorded in the Beacon Chain. The votes determine the head of the Beacon Chain, and the heads of shards. > attestation = to give vote on something ## Slashing Conditions Slashing is defined as when a validator is ejected from the active validator set and has some portion of deposited validator funds burned. This can occur for two specific violations as part of Phase 0 * Proposer slashing - occurs when a validator signs two different beacon blocks in the same epoch * Attester slashing - occurs when a validator signs two conflicting attestations ## Differences between beacon nodes and validator clients * Networking - Beacon nodes are connected via p2p to other beacon nodes while validator clients maintain a dedicated connection with a single beacon node * Staking - Only validator clients are required to stake Eth to be able to participate in the network * Block creation - Only validator clients may propose/sign blocks and beacon nodes merely validate attestations and propogate blocks across the beacon chain ``` Eth 2.0 APIs There are two main APIs defined by the Eth 2.0 spec that should be supported by beacon nodes. All APIs are currently defined using a REST spec served over HTTP with a JSON return type. Beacon Node API The Beacon Node API allows for interactions between beacon nodes, including p2p networking connectivity as well as getting current beacon chain state and blocks from other nodes. Validator Client API The Validator Client API is specifically designed for the interactions between a single validator client and the beacon node it is connected to for purposes of propagating block proposals and attestations to the network. ``` ## Altair Altair is a planned upgrade to the beacon chain that optimises some accounting and introduces sync committees for light clients. ## Fork choice rule A function evaluated by the client that takes, as input, the set of blocks and other messages that have been produced, and outputs to the client what the 'canonical chain' is.