The consensus layer is a key part of Ethereum, ensuring that all participants agree on the blockchain's current state. It verifies transactions, adds them in order, and secures the chain without needing a central authority. Ethereum uses Proof of Stake (PoS), where validators confirm transactions and create new blocks. This article explains the features of the consensus layer and how it keeps Ethereum secure and efficient. When a transaction is created in Ethereum, it is first broadcast to the network using a peer-to-peer protocol. This means the transaction is shared with other Ethereum nodes, which are computers running the Ethereum software. These nodes communicate with each other to ensure that the transaction is known across the network. Once a node receives the transaction, it places it in a temporary storage area called the mempool, which holds all unconfirmed transactions. Validators, which are responsible for confirming transactions, continuously monitor the mempool to pick up valid transactions. They check that the transaction follows the correct rules, like ensuring the sender has enough funds and the transaction is signed correctly. After validating a transaction, the validator groups it with others and proposes a new block that includes these transactions. This block is then sent to other validators for approval. Once enough validators agree that the block is correct, it is added to the blockchain, and the transaction is finalized. The transaction is now part of the Ethereum ledger, and the sender’s balance is updated. We will explore this process in more detail in the following sections. Slots and Epochs The Beacon Chain is a crucial part of Ethereum's system that helps manage the network’s consensus (agreement) on which transactions are valid. It operates using slots and epochs: A slot is a time period of 12 seconds. During each slot, the system has a chance to add a new block to the Beacon Chain. So, every 12 seconds, a new block can be added, but it’s not guaranteed that a block will be added every time. An epoch consists of 32 slots, which equals 6.4 minutes. This means that every 6.4 minutes, the system completes one full epoch. The genesis block (the first block on the Beacon Chain) is at Slot 0, and the first 32 slots make up Epoch 0. While each slot is like a scheduled time to add a block, not every slot will have a block, as validators (who are responsible for adding blocks) might not always be ready to do so. Validators also need to stay roughly in sync with the system's time to ensure things run smoothly. Validators and Attestations In Ethereum’s Proof of Stake (PoS) system, validators replace miners (as in Proof of Work) and help run the network’s consensus. Instead of using computers to solve complex puzzles, validators are like "virtual miners" who participate by staking ETH. Their job is to verify transactions and propose new blocks to be added to the blockchain. A block proposer is a validator randomly selected to propose a new block for the blockchain. This happens every 12 seconds (each slot). Most of the time, validators are attesters—they vote on the validity of proposed blocks. Their votes, called attestations, are recorded on the Beacon Chain and help determine which block is the "head" (latest) of the chain. Validator Rewards and Penalties Validators are rewarded for proposing blocks and attesting to blocks. If a validator misses their chance to propose a block for a specific slot (like missing the 28th slot of an epoch), they lose out on potential rewards. Validators are also rewarded for policing the network. If they catch another validator voting for conflicting blocks or proposing multiple blocks, they get a reward for reporting them. Staking ETH to Activate Validators In Ethereum’s Proof of Stake system, validators are like virtual workers, powered by ETH that people stake. Instead of using expensive hardware like in Proof of Work, anyone can stake ETH to activate and control a validator. For every 32 ETH staked, one validator is created. The more ETH you stake, the more validators you can run. Validators operate through special software called validator clients, which interact with the beacon node that tracks the Ethereum blockchain. The validator client uses this information to propose new blocks or vote on transactions. Once a node deposits 32 ETH into the staking contract (also known as the deposit contract), it becomes activated and starts acting as a validator on the Ethereum network, helping to secure the network. You can manage or act as multiple validator identities through the same node by staking more ETH. For every 32 ETH staked, one validator is activated. So, if you stake 64 ETH, you can manage two validators, and with 96 ETH, you can manage three validators. All of these validators are controlled through the same node, but each operates independently on the Ethereum network. Committees A committee is a group of validators responsible for making decisions together. Each slot (a 12-second period in Ethereum’s blockchain) has committees with at least 128 validators to ensure security. This large number makes it very difficult for an attacker to control more than two-thirds of the committee — the chance of this happening is less than one in a trillion. The Beacon Chain enforces consensus through a random process called RANDAO. This process selects which validators will propose blocks and which will form committees for each slot. The selection is pseudorandom, meaning the randomness isn’t truly random but is generated in a way that everyone can verify and predict once they know the starting point, ensuring fairness in the selection process. At the beginning of each epoch (which lasts about 6.4 minutes), RANDAO chooses the proposers (validators who propose blocks) for each slot and assigns validators to different committees. Each validator has a balance (how much ETH they have staked), and their chance of being selected as a proposer or committee member is weighted by this balance. Although a validator could be both a proposer and a committee member for the same slot, it doesn’t happen often, with a probability of about 1 in 32. So, you’d see this occur once every epoch. Validators can only belong to one committee per epoch, but with over 8,192 validators, multiple committees are formed for each slot. This ensures that each committee has at least 128 validators for security. If there are fewer than 4,096 validators, the number of validators in each committee could drop below 128, making the network less secure. To make sure committees are properly sized, a shuffling algorithm is used to distribute validators evenly across slots and adjust the number of committees based on the total number of validators. This process ensures that committees are always large enough (at least 128 validators per committee) to keep the network secure. The sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot. Why does Ethereum require at least 128 validators per slot, and how is this number decided? Ethereum requires at least 128 validators per slot to ensure the network's security, decentralization, and resilience. This number was chosen to make it difficult for an attacker to control the committee and manipulate the consensus process. With 128 validators, even if some validators are offline, the committee can still function properly. The number balances security and efficiency, ensuring the network remains decentralized without compromising on speed or performance. Lowering the number of validators would increase the risk of manipulation, while a larger number could slow down the process. Imagine the Ethereum network is divided into time slots, and in each slot, a block can be proposed and attested by validators. Slot 1: A block is proposed in Slot 1 by a proposer who has been elected for Slot 1. Two validators in Committee A confirm (or attest to) this block. However, one of the validators in Committee A is offline and couldn't confirm it. This block, along with the validator confirmations (called attestations), spreads across the network and reaches other validators.-Slot 2: In Slot 2, a new block is proposed by the Slot 2 proposer. However, one validator in Committee B doesn’t see the block from Slot 2. This validator instead confirms (or attests) that the most recent valid block is the one from Slot 1. This results in two competing chains in the network: One chain has the block from Slot 1 as the head. The other chain has the block from Slot 2 as the head. Slot 3: In Slot 3, all validators in Committee C follow the LMD GHOST rule to determine which block to confirm as the head of the Beacon Chain. Validators assess the attestations (votes) from other validators: If more attestations support the block from Slot 1, it is chosen as the head of the chain. If more attestations support the block from Slot 2, it becomes the head of the chain. Ultimately, the LMD GHOST rule ensures that validators agree on the chain with the most support, resolving the temporary fork and converging on a single Beacon Chain head. Beacon Chain Checkpoints Checkpoints play a crucial role in this structure: A checkpoint is typically the first block in an epoch. If the first slot of an epoch doesn't contain a block, the checkpoint defaults to the most recent preceding block. Each epoch has one checkpoint, and a single block can serve as the checkpoint for multiple epochs if subsequent epochs lack blocks in their initial slots. Example Scenario: Epoch 1 (Slots 0–31): A block is proposed in every slot from Slot 0 to Slot 31. The block proposed in Slot 0 becomes the checkpoint for Epoch 1. Epoch 2 (Slots 32–63): Slot 32 does not propose a block. However, blocks are proposed in all other slots from Slot 33 to Slot 63. Since no block is proposed in Slot 32, the checkpoint for Epoch 2 reverts to the block at Slot 31 (the last block from Epoch 1). Epoch 3 (Slots 64–95): A block is proposed in Slot 64, making it the checkpoint for Epoch 3. Blocks are also proposed in the remaining slots of the epoch (Slots 65–95). Validators in Ethereum use two types of votes to help secure the network and maintain the consensus process. The first is the LMD GHOST vote, where a validator votes for the most valid block they know of on the blockchain. This helps to determine which block should be considered the "head" or the most recent valid block in the chain. In addition to voting for blocks, validators also participate in Casper FFG voting. This vote involves selecting the checkpoint for each epoch, which is a block that marks the end of an epoch. Validators vote for the checkpoint in the current epoch (referred to as the target) and the checkpoint from the previous epoch (referred to as the source). This ensures that each epoch is properly linked to the previous one, keeping the blockchain consistent. While only validators assigned to a specific slot cast an LMD GHOST vote for that slot, all validators cast FFG votes for the checkpoints in every epoch to maintain overall network agreement. Supermajority A supermajority refers to a vote made by at least two-thirds (⅔) of the total balance of all active validators in the network. For example, suppose there are three active validators. Two of them each have 8 ETH, and one validator has 32 ETH. In order to have a supermajority, the vote must include the vote of the validator with 32 ETH. Even if the two 8 ETH validators vote differently, they cannot form a supermajority because their combined balance (16 ETH) is not enough to reach the two-thirds threshold. Therefore, the vote of the 32 ETH validator is crucial for the supermajority to be reached. This ensures that the weight of votes in Ethereum’s consensus process is proportional to the amount of ETH staked, giving more influence to validators who have more at stake in the network. Finality Finality refers to the point in Ethereum's consensus mechanism where a checkpoint (a block marking the end of an epoch) is permanently secured on the blockchain, meaning it cannot be altered without significant cost or effort. This ensures that transactions within the finalized block and its ancestors are irreversible and immutable. Let’s consider a scenario with epoch 0, epoch 1, and epoch 2, where each epoch has 32 slots, and the chain head is at epoch 2. Epoch 0: The first block of epoch 0 (slot 0) serves as the checkpoint for epoch 0. Validators propose and attest to blocks in this epoch. Suppose in some slots of epoch 0, blocks are not proposed. However, by the end of epoch 0, enough attestations are made for the checkpoint at slot 0 to garner a ⅔ supermajority. This means the checkpoint at slot 0 is justified. Epoch 1: The first block of epoch 1 (slot 32) serves as the checkpoint for epoch 1. Validators propose and attest to blocks in this epoch, and by the end of epoch 1, the checkpoint at slot 32 also garners a ⅔ supermajority. Since checkpoint 32 (epoch 1) is justified and is the immediate next checkpoint after checkpoint 0 (epoch 0), checkpoint 0 is now finalized. Epoch 2: The first block of epoch 2 (slot 64) serves as the checkpoint for epoch 2. Validators continue the same process. If the checkpoint at slot 64 receives a ⅔ supermajority, it will justify the checkpoint and finalize the previous checkpoint at slot 32 (epoch 1). Even if some slots in an epoch are empty (meaning no blocks are created during those slots), it doesn’t impact the finality of the blockchain. This is because finality is based on validators voting with a ⅔ majority for the checkpoint block, not on whether every slot has a block. For example, even if some slots in epoch 0 are empty, the checkpoint at the start of epoch 0 can still be justified as long as enough validators vote for it. This ensures that the blockchain keeps moving forward smoothly, even if some blocks are delayed or missing. Transaction finality usually takes 2.5 epochs. When a transaction is added to a block, it’s typically somewhere in the middle of an epoch. From there, it takes about half an epoch to propose the next checkpoint, and then another two epochs for the checkpoint to be finalized. This means it takes about 16 minutes for a transaction to be fully finalized. In ideal cases, most validator votes are included by the 22nd slot of an epoch, which can reduce finality time to around 14 minutes. Once finalized, the transaction and the blocks leading up to it are permanently secured and cannot be changed. Justified vs Finalized Justified: A checkpoint is agreed upon by at least ⅔ of validators but isn’t yet permanent. It’s valid but could still be changed if needed. Finalized: A checkpoint is permanently locked into the blockchain after two consecutive justified checkpoints, meaning it cannot be reversed or changed. What happened at the Beacon Chain head At the end of Epoch 3 (Slot 96), a block is created that includes votes (attestations) from validators supporting the checkpoint at Slot 64, which is the Epoch 2 checkpoint. These votes have been collected from validators throughout Epoch 3. By the time Slot 96 is reached, the votes for the Slot 64 checkpoint meet the required ⅔ supermajority, which means the Slot 64 checkpoint is now justified. When the Epoch 2 checkpoint (Slot 64) is justified, the previous checkpoint from Epoch 1 (Slot 32) is finalized. Finalization makes Slot 32 and all the blocks before it permanent and unchangeable on the blockchain. This process ensures that the blockchain history up to Slot 32 is secure and cannot be reorganized. While finalization is calculated only at the end of an epoch, validators continuously add their votes in each block during the epoch. This steady accumulation of votes ensures that checkpoints can be justified and finalized as soon as the conditions are met, keeping the blockchain stable and reliable. Why does it take two ⅔ supermajority votes and two epochs for a block to finalize? The first ⅔ supermajority vote justifies the block, but there could still be temporary forks or conflicting blocks in the next epoch. The second supermajority vote ensures that the block is firmly accepted, preventing any reversals or attacks. It also provides confirmation that the block is not part of a temporary fork. This two-step process, across two epochs, guarantees the block's immutability, security, and validity, making it final and secure in the blockchain. What could have happened from genesis to head In Epoch 1 (Slots 0-31), blocks are proposed by validators in each slot. As blocks are proposed, they help gather attestations (votes) from the validators for the Epoch 1 checkpoint, which is the block at Slot 32 (the last block of Epoch 1). Validators start to vote for the Epoch 1 checkpoint as each block gets proposed, and by the time the block at Slot 64 (which begins Epoch 2) is proposed, the attestations for Epoch 1 checkpoint reach 70%. This causes the Epoch 1 checkpoint (Slot 32) to be justified. Now, as Epoch 2 starts (Slots 32-63), the Epoch 2 checkpoint is the block at Slot 64. However, it doesn’t immediately gather enough attestations to reach the ⅔ supermajority required for justification. But when the block at Slot 96 is proposed, validators include their attestations for the Epoch 2 checkpoint, which results in the ⅔ supermajority, causing Epoch 2 checkpoint (Slot 64) to be justified. Once the Epoch 2 checkpoint is justified, the Epoch 1 checkpoint (Slot 32) is considered finalized. This means that all blocks before Slot 32 are now finalized and cannot be changed, ensuring the chain's security and immutability. There is another possibility: Epoch 1’s checkpoint (Slot 32) could have already reached the necessary ⅔ supermajority before Epoch 2’s checkpoint (Slot 64) was even proposed. For example, during the proposal of blocks between Slot 32 to Slot 54 in Epoch 2, attestations for the Epoch 1 checkpoint could have already reached ⅔ supermajority, causing Epoch 1’s checkpoint (Slot 32) to be justified even before the start of Epoch 2. However, even if a checkpoint is justified in its current epoch, it can't be finalized until at least the next epoch has passed. This ensures there’s no potential for forks or conflicting blocks, providing certainty that the checkpoint is truly valid. In rare cases, such as network delays, partitions, or attacks, a checkpoint might take more than two epochs to become finalized. Attestations: A Simple Overview An attestation is a combination of two votes: one for the block's validity (LMD GHOST) and one for the checkpoint (FFG). Validators are expected to submit one attestation each epoch, and they have 32 opportunities (slots) to get their vote included. They earn more rewards if their vote is included earlier in their assigned slot. Validators are assigned to committees one epoch in advance to improve the process, while proposers are chosen at the start of each epoch. When validators in the same committee vote the same way, their votes are grouped into a single, efficient signature. To prevent attacks or bribery, research into secret leader election helps make the process more secure. Staking Rewards and Penalties Attester Rewards: Validators earn rewards for making attestations (votes) that most other validators agree with. If the blocks they vote on are finalized, the rewards are higher. Attester Penalties: Validators are penalized if they don’t make attestations or vote for blocks that aren’t finalized. Downside Risk for Stakers: Validators can lose a significant portion of their stake if they perform poorly. For example, if a validator misses blocks or stays offline for too long, they can lose around 7.5% of their stake for consistently bad performance. Slashings and Whistleblower Rewards: Validators can be slashed (penalized) for dishonest actions. The penalty can be from 0.5 ETH up to their entire stake. If a validator reports another validator’s wrongdoing (like double voting), they can earn a whistleblower reward. Proposer Rewards: Validators who propose blocks that get finalized are rewarded. A good proposer can get extra rewards, and if they include evidence of another validator being slashed, they earn more rewards. Inactivity Leak Penalty: If a validator doesn’t participate for more than four epochs, they face an inactivity penalty. The longer they stay inactive, the bigger the penalty. This penalty ensures that validators who aren’t participating are removed from the system so that others can finalize blocks. Validators who are doing their job properly won’t be penalized. Slashable Offences Double Proposal: A proposer is only allowed to propose one block for their assigned slot. If they propose more than one block, it’s considered a slashing offense. LMD GHOST Double Vote: A validator can only vote for one head of the Beacon Chain in their assigned slot. If they vote for two different heads (two different chain states), it’s a slashing offense. FFG Surround Vote: A surround vote happens when a validator casts a vote that "surrounds" or is "surrounded" by a previous vote they made in a different epoch. For example, if a validator votes for Slot 32 to Slot 128 in Epoch 5, and later votes for Slot 64 to Slot 96 in Epoch 6, this would be considered a surrounding vote. FFG Double Vote: A validator cannot cast two votes for different blocks in the same epoch. If they vote for two different blocks in the same epoch, it’s a slashing offense. This can happen during a fork, where a validator votes for two conflicting blocks in the same epoch. The reason these offenses are slashing offenses is to ensure that validators do not vote for conflicting or multiple versions of the chain. This helps maintain consensus and prevent the blockchain from splitting. Whistleblower Rewards: If a validator notices another validator making a slashing offense (like a double vote), they can report it and earn a whistleblower reward. This helps maintain the integrity of the network. Avoiding Slashable Offenses: Validators are in complete control of their actions and can avoid being slashed by simply ensuring that they do not sign conflicting proposals or attestations. If they act honestly and do not make conflicting votes, they cannot be slashed. Beacon Chain Validator Activation and Lifecycle To become an active validator on the Beacon Chain, a user needs to stake 32 ETH. When this amount is staked into the deposit contract on the Ethereum mainnet, it activates a validator. Once activated, a validator must maintain a balance of 32 ETH. If the balance drops to 16 ETH, the Beacon Chain will deactivate the validator, forcing them to exit the network. However, stakers will be able to withdraw any remaining balance once the system allows it (likely around 2023). A validator can also choose to exit voluntarily after serving for 2,048 epochs (about 9 days). Whether the exit is voluntary or forced, there is a 4-epoch delay before the staker can withdraw the funds. During this delay, a validator can still be slashed for misbehavior. If the validator is honest, their balance can be withdrawn in about 27 hours. However, if the validator is slashed, they will face an 8,192-epoch delay (around 36 days) before they can withdraw their funds. There are mechanisms in place to limit the number of validators that can be activated or exited within a single epoch to prevent sudden changes in the validator set. These restrictions help protect the network from attacks by making it harder to activate a large number of validators in a short time. Additionally, the Beacon Chain uses "effective balances" to manage validators, which change less frequently than validator balances and help with technical optimizations. The consensus layer is a key part of Ethereum, ensuring that all participants agree on the blockchain's current state. It verifies transactions, adds them in order, and secures the chain without needing a central authority. Ethereum uses Proof of Stake (PoS), where validators confirm transactions and create new blocks. This article explains the features of the consensus layer and how it keeps Ethereum secure and efficient. When a transaction is created in Ethereum, it is first broadcast to the network using a peer-to-peer protocol. This means the transaction is shared with other Ethereum nodes, which are computers running the Ethereum software. These nodes communicate with each other to ensure that the transaction is known across the network. Once a node receives the transaction, it places it in a temporary storage area called the mempool , which holds all unconfirmed transactions. Validators, which are responsible for confirming transactions, continuously monitor the mempool to pick up valid transactions. They check that the transaction follows the correct rules, like ensuring the sender has enough funds and the transaction is signed correctly. After validating a transaction, the validator groups it with others and proposes a new block that includes these transactions. This block is then sent to other validators for approval. Once enough validators agree that the block is correct, it is added to the blockchain, and the transaction is finalized. The transaction is now part of the Ethereum ledger, and the sender’s balance is updated. We will explore this process in more detail in the following sections. mempool Slots and Epochs Slots and Epochs The Beacon Chain is a crucial part of Ethereum's system that helps manage the network’s consensus (agreement) on which transactions are valid. It operates using slots and epochs : Beacon Chain slots epochs A slot is a time period of 12 seconds. During each slot, the system has a chance to add a new block to the Beacon Chain. So, every 12 seconds, a new block can be added, but it’s not guaranteed that a block will be added every time. An epoch consists of 32 slots, which equals 6.4 minutes. This means that every 6.4 minutes, the system completes one full epoch. A slot is a time period of 12 seconds . During each slot, the system has a chance to add a new block to the Beacon Chain. So, every 12 seconds, a new block can be added, but it’s not guaranteed that a block will be added every time. slot 12 seconds An epoch consists of 32 slots , which equals 6.4 minutes . This means that every 6.4 minutes, the system completes one full epoch. epoch 32 slots 6.4 minutes The genesis block (the first block on the Beacon Chain) is at Slot 0 , and the first 32 slots make up Epoch 0 . genesis block Slot 0 32 slots Epoch 0 While each slot is like a scheduled time to add a block, not every slot will have a block, as validators (who are responsible for adding blocks) might not always be ready to do so. Validators also need to stay roughly in sync with the system's time to ensure things run smoothly. slot Validators and Attestations Validators and Attestations In Ethereum’s Proof of Stake (PoS) system, validators replace miners (as in Proof of Work) and help run the network’s consensus. Instead of using computers to solve complex puzzles, validators are like "virtual miners" who participate by staking ETH . Their job is to verify transactions and propose new blocks to be added to the blockchain. Proof of Stake validators miners validators ETH A block proposer is a validator randomly selected to propose a new block for the blockchain. This happens every 12 seconds (each slot). Most of the time, validators are attesters—they vote on the validity of proposed blocks. Their votes, called attestations, are recorded on the Beacon Chain and help determine which block is the "head" (latest) of the chain. A block proposer is a validator randomly selected to propose a new block for the blockchain. This happens every 12 seconds (each slot). block proposer Most of the time, validators are attesters —they vote on the validity of proposed blocks. Their votes, called attestations , are recorded on the Beacon Chain and help determine which block is the "head" (latest) of the chain. attesters attestations Beacon Chain Validator Rewards and Penalties Validators are rewarded for proposing blocks and attesting to blocks. If a validator misses their chance to propose a block for a specific slot (like missing the 28th slot of an epoch), they lose out on potential rewards. Validators are also rewarded for policing the network. If they catch another validator voting for conflicting blocks or proposing multiple blocks, they get a reward for reporting them. Validators are rewarded for proposing blocks and attesting to blocks. proposing blocks attesting If a validator misses their chance to propose a block for a specific slot (like missing the 28th slot of an epoch), they lose out on potential rewards. Validators are also rewarded for policing the network. If they catch another validator voting for conflicting blocks or proposing multiple blocks, they get a reward for reporting them. policing Staking ETH to Activate Validators Staking ETH to Activate Validators In Ethereum’s Proof of Stake system, validators are like virtual workers, powered by ETH that people stake. Instead of using expensive hardware like in Proof of Work, anyone can stake ETH to activate and control a validator. For every 32 ETH staked, one validator is created. The more ETH you stake, the more validators you can run. 32 ETH Validators operate through special software called validator clients , which interact with the beacon node that tracks the Ethereum blockchain. The validator client uses this information to propose new blocks or vote on transactions. Once a node deposits 32 ETH into the staking contract (also known as the deposit contract ), it becomes activated and starts acting as a validator on the Ethereum network, helping to secure the network. validator clients beacon node 32 ETH staking contract deposit contract You can manage or act as multiple validator identities through the same node by staking more ETH. For every 32 ETH staked, one validator is activated. So, if you stake 64 ETH, you can manage two validators, and with 96 ETH, you can manage three validators. All of these validators are controlled through the same node, but each operates independently on the Ethereum network. You can manage or act as multiple validator identities through the same node by staking more ETH. For every 32 ETH staked, one validator is activated. So, if you stake 64 ETH , you can manage two validators , and with 96 ETH , you can manage three validators . All of these validators are controlled through the same node, but each operates independently on the Ethereum network. 32 ETH 64 ETH two validators 96 ETH three validators Committees Committees A committee is a group of validators responsible for making decisions together. Each slot (a 12-second period in Ethereum’s blockchain) has committees with at least 128 validators to ensure security. This large number makes it very difficult for an attacker to control more than two-thirds of the committee — the chance of this happening is less than one in a trillion. committee 128 validators The Beacon Chain enforces consensus through a random process called RANDAO . This process selects which validators will propose blocks and which will form committees for each slot. The selection is pseudorandom, meaning the randomness isn’t truly random but is generated in a way that everyone can verify and predict once they know the starting point, ensuring fairness in the selection process. Beacon Chain RANDAO At the beginning of each epoch (which lasts about 6.4 minutes), RANDAO chooses the proposers (validators who propose blocks) for each slot and assigns validators to different committees. Each validator has a balance (how much ETH they have staked), and their chance of being selected as a proposer or committee member is weighted by this balance. epoch RANDAO proposers balance Although a validator could be both a proposer and a committee member for the same slot, it doesn’t happen often, with a probability of about 1 in 32 . So, you’d see this occur once every epoch. proposer committee member 1 in 32 Validators can only belong to one committee per epoch , but with over 8,192 validators , multiple committees are formed for each slot. This ensures that each committee has at least 128 validators for security. If there are fewer than 4,096 validators , the number of validators in each committee could drop below 128, making the network less secure. epoch 8,192 validators 4,096 validators To make sure committees are properly sized, a shuffling algorithm is used to distribute validators evenly across slots and adjust the number of committees based on the total number of validators. This process ensures that committees are always large enough (at least 128 validators per committee) to keep the network secure. The sketch depicts a scenario with less than 8,192 validators, otherwise there would be at least two committees per slot. shuffling algorithm Why does Ethereum require at least 128 validators per slot, and how is this number decided? Ethereum requires at least 128 validators per slot to ensure the network's security, decentralization, and resilience. This number was chosen to make it difficult for an attacker to control the committee and manipulate the consensus process. With 128 validators, even if some validators are offline, the committee can still function properly. The number balances security and efficiency, ensuring the network remains decentralized without compromising on speed or performance. Lowering the number of validators would increase the risk of manipulation, while a larger number could slow down the process. Why does Ethereum require at least 128 validators per slot, and how is this number decided? Why does Ethereum require at least 128 validators per slot, and how is this number decided? Ethereum requires at least 128 validators per slot to ensure the network's security , decentralization , and resilience . This number was chosen to make it difficult for an attacker to control the committee and manipulate the consensus process. With 128 validators, even if some validators are offline, the committee can still function properly. The number balances security and efficiency , ensuring the network remains decentralized without compromising on speed or performance. Lowering the number of validators would increase the risk of manipulation, while a larger number could slow down the process. security decentralization resilience security efficiency Imagine the Ethereum network is divided into time slots , and in each slot, a block can be proposed and attested by validators. Ethereum network time slots Slot 1: A block is proposed in Slot 1 by a proposer who has been elected for Slot 1. Two validators in Committee A confirm (or attest to) this block. However, one of the validators in Committee A is offline and couldn't confirm it. This block, along with the validator confirmations (called attestations), spreads across the network and reaches other validators.-Slot 2: In Slot 2, a new block is proposed by the Slot 2 proposer. However, one validator in Committee B doesn’t see the block from Slot 2. This validator instead confirms (or attests) that the most recent valid block is the one from Slot 1. This results in two competing chains in the network: One chain has the block from Slot 1 as the head. The other chain has the block from Slot 2 as the head. Slot 3: In Slot 3, all validators in Committee C follow the LMD GHOST rule to determine which block to confirm as the head of the Beacon Chain. Validators assess the attestations (votes) from other validators: If more attestations support the block from Slot 1, it is chosen as the head of the chain. If more attestations support the block from Slot 2, it becomes the head of the chain. Slot 1: A block is proposed in Slot 1 by a proposer who has been elected for Slot 1. Two validators in Committee A confirm (or attest to) this block. However, one of the validators in Committee A is offline and couldn't confirm it. This block, along with the validator confirmations (called attestations ), spreads across the network and reaches other validators.- Slot 2: In Slot 2, a new block is proposed by the Slot 1: Slot 1 Committee A attestations Slot 2: Slot 2 proposer. However, one validator in Committee B doesn’t see the block from Slot 2. This validator instead confirms (or attests) that the most recent valid block is the one from Slot 1 . This results in two competing chains in the network: One chain has the block from Slot 1 as the head. The other chain has the block from Slot 2 as the head. Slot 2 Committee B Slot 1 One chain has the block from Slot 1 as the head. The other chain has the block from Slot 2 as the head. One chain has the block from Slot 1 as the head. The other chain has the block from Slot 2 as the head. Slot 3: In Slot 3, all validators in Committee C follow the LMD GHOST rule to determine which block to confirm as the head of the Beacon Chain. Validators assess the attestations (votes) from other validators: If more attestations support the block from Slot 1, it is chosen as the head of the chain. If more attestations support the block from Slot 2, it becomes the head of the chain. Slot 3: LMD GHOST If more attestations support the block from Slot 1, it is chosen as the head of the chain. If more attestations support the block from Slot 2, it becomes the head of the chain. If more attestations support the block from Slot 1, it is chosen as the head of the chain. If more attestations support the block from Slot 2, it becomes the head of the chain. Ultimately, the LMD GHOST rule ensures that validators agree on the chain with the most support, resolving the temporary fork and converging on a single Beacon Chain head. Beacon Chain Checkpoints Beacon Chain Checkpoints Checkpoints play a crucial role in this structure: Checkpoints A checkpoint is typically the first block in an epoch. If the first slot of an epoch doesn't contain a block, the checkpoint defaults to the most recent preceding block. Each epoch has one checkpoint, and a single block can serve as the checkpoint for multiple epochs if subsequent epochs lack blocks in their initial slots. A checkpoint is typically the first block in an epoch. checkpoint If the first slot of an epoch doesn't contain a block, the checkpoint defaults to the most recent preceding block. Each epoch has one checkpoint, and a single block can serve as the checkpoint for multiple epochs if subsequent epochs lack blocks in their initial slots. Example Scenario: Example Scenario: Epoch 1 (Slots 0–31): Epoch 1 (Slots 0–31): A block is proposed in every slot from Slot 0 to Slot 31. The block proposed in Slot 0 becomes the checkpoint for Epoch 1. A block is proposed in every slot from Slot 0 to Slot 31 . Slot 0 to Slot 31 The block proposed in Slot 0 becomes the checkpoint for Epoch 1 . Slot 0 checkpoint for Epoch 1 Epoch 2 (Slots 32–63): Epoch 2 (Slots 32–63): Slot 32 does not propose a block. However, blocks are proposed in all other slots from Slot 33 to Slot 63. Since no block is proposed in Slot 32, the checkpoint for Epoch 2 reverts to the block at Slot 31 (the last block from Epoch 1). Slot 32 does not propose a block. Slot 32 However, blocks are proposed in all other slots from Slot 33 to Slot 63 . Slot 33 to Slot 63 Since no block is proposed in Slot 32 , the checkpoint for Epoch 2 reverts to the block at Slot 31 (the last block from Epoch 1). Slot 32 Slot 31 Epoch 3 (Slots 64–95): Epoch 3 (Slots 64–95): A block is proposed in Slot 64, making it the checkpoint for Epoch 3. Blocks are also proposed in the remaining slots of the epoch (Slots 65–95). A block is proposed in Slot 64 , making it the checkpoint for Epoch 3 . Slot 64 checkpoint for Epoch 3 Blocks are also proposed in the remaining slots of the epoch ( Slots 65–95 ). Slots 65–95 Validators in Ethereum use two types of votes to help secure the network and maintain the consensus process. The first is the LMD GHOST vote , where a validator votes for the most valid block they know of on the blockchain. This helps to determine which block should be considered the "head" or the most recent valid block in the chain. LMD GHOST vote In addition to voting for blocks, validators also participate in Casper FFG voting . This vote involves selecting the checkpoint for each epoch, which is a block that marks the end of an epoch. Validators vote for the checkpoint in the current epoch (referred to as the target ) and the checkpoint from the previous epoch (referred to as the source ). This ensures that each epoch is properly linked to the previous one, keeping the blockchain consistent. Casper FFG voting checkpoint target source While only validators assigned to a specific slot cast an LMD GHOST vote for that slot, all validators cast FFG votes for the checkpoints in every epoch to maintain overall network agreement. While only validators assigned to a specific slot cast an LMD GHOST vote for that slot, all validators cast FFG votes for the checkpoints in every epoch to maintain overall network agreement. Supermajority Supermajority A supermajority refers to a vote made by at least two-thirds (⅔) of the total balance of all active validators in the network. For example, suppose there are three active validators. Two of them each have 8 ETH , and one validator has 32 ETH . In order to have a supermajority, the vote must include the vote of the validator with 32 ETH. Even if the two 8 ETH validators vote differently, they cannot form a supermajority because their combined balance (16 ETH) is not enough to reach the two-thirds threshold. Therefore, the vote of the 32 ETH validator is crucial for the supermajority to be reached. supermajority 8 ETH 32 ETH This ensures that the weight of votes in Ethereum’s consensus process is proportional to the amount of ETH staked , giving more influence to validators who have more at stake in the network. amount of ETH staked Finality Finality Finality refers to the point in Ethereum's consensus mechanism where a checkpoint (a block marking the end of an epoch) is permanently secured on the blockchain, meaning it cannot be altered without significant cost or effort. This ensures that transactions within the finalized block and its ancestors are irreversible and immutable. Finality Let’s consider a scenario with epoch 0, epoch 1, and epoch 2 , where each epoch has 32 slots , and the chain head is at epoch 2 . epoch 0, epoch 1, and epoch 2 32 slots epoch 2 Epoch 0: The first block of epoch 0 (slot 0) serves as the checkpoint for epoch 0. Validators propose and attest to blocks in this epoch. Suppose in some slots of epoch 0, blocks are not proposed. However, by the end of epoch 0, enough attestations are made for the checkpoint at slot 0 to garner a ⅔ supermajority. This means the checkpoint at slot 0 is justified. Epoch 1: The first block of epoch 1 (slot 32) serves as the checkpoint for epoch 1. Validators propose and attest to blocks in this epoch, and by the end of epoch 1, the checkpoint at slot 32 also garners a ⅔ supermajority. Since checkpoint 32 (epoch 1) is justified and is the immediate next checkpoint after checkpoint 0 (epoch 0), checkpoint 0 is now finalized. Epoch 2: The first block of epoch 2 (slot 64) serves as the checkpoint for epoch 2. Validators continue the same process. If the checkpoint at slot 64 receives a ⅔ supermajority, it will justify the checkpoint and finalize the previous checkpoint at slot 32 (epoch 1). Epoch 0 : The first block of epoch 0 (slot 0) serves as the checkpoint for epoch 0. Validators propose and attest to blocks in this epoch. Suppose in some slots of epoch 0, blocks are not proposed. However, by the end of epoch 0, enough attestations are made for the checkpoint at slot 0 to garner a ⅔ supermajority. This means the checkpoint at slot 0 is justified. Epoch 0 The first block of epoch 0 (slot 0) serves as the checkpoint for epoch 0. Validators propose and attest to blocks in this epoch. Suppose in some slots of epoch 0, blocks are not proposed. However, by the end of epoch 0, enough attestations are made for the checkpoint at slot 0 to garner a ⅔ supermajority. This means the checkpoint at slot 0 is justified. The first block of epoch 0 (slot 0) serves as the checkpoint for epoch 0. checkpoint Validators propose and attest to blocks in this epoch. Suppose in some slots of epoch 0 , blocks are not proposed. However, by the end of epoch 0, enough attestations are made for the checkpoint at slot 0 to garner a ⅔ supermajority . This means the checkpoint at slot 0 is justified . some slots of epoch 0 checkpoint at slot 0 ⅔ supermajority justified Epoch 1 : The first block of epoch 1 (slot 32) serves as the checkpoint for epoch 1. Validators propose and attest to blocks in this epoch, and by the end of epoch 1, the checkpoint at slot 32 also garners a ⅔ supermajority. Since checkpoint 32 (epoch 1) is justified and is the immediate next checkpoint after checkpoint 0 (epoch 0), checkpoint 0 is now finalized. Epoch 1 The first block of epoch 1 (slot 32) serves as the checkpoint for epoch 1. Validators propose and attest to blocks in this epoch, and by the end of epoch 1, the checkpoint at slot 32 also garners a ⅔ supermajority. Since checkpoint 32 (epoch 1) is justified and is the immediate next checkpoint after checkpoint 0 (epoch 0), checkpoint 0 is now finalized. The first block of epoch 1 (slot 32) serves as the checkpoint for epoch 1. checkpoint Validators propose and attest to blocks in this epoch, and by the end of epoch 1, the checkpoint at slot 32 also garners a ⅔ supermajority . checkpoint at slot 32 ⅔ supermajority Since checkpoint 32 (epoch 1) is justified and is the immediate next checkpoint after checkpoint 0 (epoch 0) , checkpoint 0 is now finalized . checkpoint 32 (epoch 1) checkpoint 0 (epoch 0) checkpoint 0 finalized Epoch 2 : The first block of epoch 2 (slot 64) serves as the checkpoint for epoch 2. Validators continue the same process. If the checkpoint at slot 64 receives a ⅔ supermajority, it will justify the checkpoint and finalize the previous checkpoint at slot 32 (epoch 1). Epoch 2 The first block of epoch 2 (slot 64) serves as the checkpoint for epoch 2. Validators continue the same process. If the checkpoint at slot 64 receives a ⅔ supermajority, it will justify the checkpoint and finalize the previous checkpoint at slot 32 (epoch 1). The first block of epoch 2 (slot 64) serves as the checkpoint for epoch 2. checkpoint Validators continue the same process. If the checkpoint at slot 64 receives a ⅔ supermajority , it will justify the checkpoint and finalize the previous checkpoint at slot 32 (epoch 1). checkpoint at slot 64 ⅔ supermajority Even if some slots in an epoch are empty (meaning no blocks are created during those slots), it doesn’t impact the finality of the blockchain. This is because finality is based on validators voting with a ⅔ majority for the checkpoint block, not on whether every slot has a block. For example, even if some slots in epoch 0 are empty, the checkpoint at the start of epoch 0 can still be justified as long as enough validators vote for it. This ensures that the blockchain keeps moving forward smoothly, even if some blocks are delayed or missing. Transaction finality usually takes 2.5 epochs . When a transaction is added to a block, it’s typically somewhere in the middle of an epoch. From there, it takes about half an epoch to propose the next checkpoint, and then another two epochs for the checkpoint to be finalized. This means it takes about 16 minutes for a transaction to be fully finalized. 2.5 epochs half an epoch two epochs 16 minutes In ideal cases, most validator votes are included by the 22nd slot of an epoch, which can reduce finality time to around 14 minutes . Once finalized, the transaction and the blocks leading up to it are permanently secured and cannot be changed. 14 minutes Justified vs Finalized Justified: A checkpoint is agreed upon by at least ⅔ of validators but isn’t yet permanent. It’s valid but could still be changed if needed. Finalized: A checkpoint is permanently locked into the blockchain after two consecutive justified checkpoints, meaning it cannot be reversed or changed. Justified vs Finalized Justified vs Finalized Justified: A checkpoint is agreed upon by at least ⅔ of validators but isn’t yet permanent. It’s valid but could still be changed if needed. Finalized: A checkpoint is permanently locked into the blockchain after two consecutive justified checkpoints, meaning it cannot be reversed or changed. Justified: A checkpoint is agreed upon by at least ⅔ of validators but isn’t yet permanent. It’s valid but could still be changed if needed. Justified: Finalized: A checkpoint is permanently locked into the blockchain after two consecutive justified checkpoints, meaning it cannot be reversed or changed. Finalized: What happened at the Beacon Chain head At the end of Epoch 3 (Slot 96), a block is created that includes votes (attestations) from validators supporting the checkpoint at Slot 64, which is the Epoch 2 checkpoint. These votes have been collected from validators throughout Epoch 3. By the time Slot 96 is reached, the votes for the Slot 64 checkpoint meet the required ⅔ supermajority, which means the Slot 64 checkpoint is now justified. When the Epoch 2 checkpoint (Slot 64) is justified, the previous checkpoint from Epoch 1 (Slot 32) is finalized. Finalization makes Slot 32 and all the blocks before it permanent and unchangeable on the blockchain. This process ensures that the blockchain history up to Slot 32 is secure and cannot be reorganized. While finalization is calculated only at the end of an epoch, validators continuously add their votes in each block during the epoch. This steady accumulation of votes ensures that checkpoints can be justified and finalized as soon as the conditions are met, keeping the blockchain stable and reliable. Why does it take two ⅔ supermajority votes and two epochs for a block to finalize? The first ⅔ supermajority vote justifies the block, but there could still be temporary forks or conflicting blocks in the next epoch. The second supermajority vote ensures that the block is firmly accepted, preventing any reversals or attacks. It also provides confirmation that the block is not part of a temporary fork. This two-step process, across two epochs, guarantees the block's immutability, security, and validity, making it final and secure in the blockchain. Why does it take two ⅔ supermajority votes and two epochs for a block to finalize? Why does it take two ⅔ supermajority votes and two epochs for a block to finalize? The first ⅔ supermajority vote justifies the block, but there could still be temporary forks or conflicting blocks in the next epoch. The second supermajority vote ensures that the block is firmly accepted, preventing any reversals or attacks. It also provides confirmation that the block is not part of a temporary fork. This two-step process, across two epochs, guarantees the block's immutability, security, and validity, making it final and secure in the blockchain. What could have happened from genesis to head What could have happened from genesis to head In Epoch 1 (Slots 0-31), blocks are proposed by validators in each slot. As blocks are proposed, they help gather attestations (votes) from the validators for the Epoch 1 checkpoint , which is the block at Slot 32 (the last block of Epoch 1). Validators start to vote for the Epoch 1 checkpoint as each block gets proposed, and by the time the block at Slot 64 (which begins Epoch 2 ) is proposed, the attestations for Epoch 1 checkpoint reach 70% . This causes the Epoch 1 checkpoint (Slot 32) to be justified . Epoch 1 attestations Epoch 1 checkpoint Slot 32 Epoch 1 checkpoint block at Slot 64 Epoch 2 attestations for Epoch 1 checkpoint 70% Epoch 1 checkpoint (Slot 32) justified Now, as Epoch 2 starts (Slots 32-63), the Epoch 2 checkpoint is the block at Slot 64 . However, it doesn’t immediately gather enough attestations to reach the ⅔ supermajority required for justification. But when the block at Slot 96 is proposed, validators include their attestations for the Epoch 2 checkpoint , which results in the ⅔ supermajority, causing Epoch 2 checkpoint (Slot 64) to be justified . Once the Epoch 2 checkpoint is justified, the Epoch 1 checkpoint (Slot 32) is considered finalized . This means that all blocks before Slot 32 are now finalized and cannot be changed, ensuring the chain's security and immutability. Epoch 2 Epoch 2 checkpoint Slot 64 block at Slot 96 Epoch 2 checkpoint Epoch 2 checkpoint (Slot 64) justified Epoch 2 checkpoint Epoch 1 checkpoint (Slot 32) finalized finalized There is another possibility: Epoch 1’s checkpoint (Slot 32) could have already reached the necessary ⅔ supermajority before Epoch 2’s checkpoint (Slot 64) was even proposed. For example, during the proposal of blocks between Slot 32 to Slot 54 in Epoch 2, attestations for the Epoch 1 checkpoint could have already reached ⅔ supermajority, causing Epoch 1’s checkpoint (Slot 32) to be justified even before the start of Epoch 2. Epoch 1’s checkpoint (Slot 32) Epoch 2’s checkpoint (Slot 64) Slot 32 to Slot 54 attestations for the Epoch 1 checkpoint Epoch 1’s checkpoint (Slot 32) However, even if a checkpoint is justified in its current epoch, it can't be finalized until at least the next epoch has passed. This ensures there’s no potential for forks or conflicting blocks, providing certainty that the checkpoint is truly valid. In rare cases, such as network delays , partitions , or attacks , a checkpoint might take more than two epochs to become finalized. network delays partitions attacks Attestations: A Simple Overview Attestations: A Simple Overview An attestation is a combination of two votes: one for the block's validity ( LMD GHOST ) and one for the checkpoint ( FFG ). Validators are expected to submit one attestation each epoch, and they have 32 opportunities (slots) to get their vote included. They earn more rewards if their vote is included earlier in their assigned slot. attestation LMD GHOST FFG Validators are assigned to committees one epoch in advance to improve the process, while proposers are chosen at the start of each epoch. When validators in the same committee vote the same way, their votes are grouped into a single, efficient signature. committees proposers To prevent attacks or bribery, research into secret leader election helps make the process more secure. secret leader election secret leader election Staking Rewards and Penalties Staking Rewards and Penalties Attester Rewards: Validators earn rewards for making attestations (votes) that most other validators agree with. If the blocks they vote on are finalized, the rewards are higher. Attester Penalties: Validators are penalized if they don’t make attestations or vote for blocks that aren’t finalized. Downside Risk for Stakers: Validators can lose a significant portion of their stake if they perform poorly. For example, if a validator misses blocks or stays offline for too long, they can lose around 7.5% of their stake for consistently bad performance. Slashings and Whistleblower Rewards: Validators can be slashed (penalized) for dishonest actions. The penalty can be from 0.5 ETH up to their entire stake. If a validator reports another validator’s wrongdoing (like double voting), they can earn a whistleblower reward. Proposer Rewards: Validators who propose blocks that get finalized are rewarded. A good proposer can get extra rewards, and if they include evidence of another validator being slashed, they earn more rewards. Attester Rewards : Validators earn rewards for making attestations (votes) that most other validators agree with. If the blocks they vote on are finalized, the rewards are higher. Attester Rewards Attester Penalties : Validators are penalized if they don’t make attestations or vote for blocks that aren’t finalized. Attester Penalties Downside Risk for Stakers : Validators can lose a significant portion of their stake if they perform poorly. For example, if a validator misses blocks or stays offline for too long, they can lose around 7.5% of their stake for consistently bad performance. Downside Risk for Stakers Slashings and Whistleblower Rewards : Validators can be slashed (penalized) for dishonest actions. The penalty can be from 0.5 ETH up to their entire stake. If a validator reports another validator’s wrongdoing (like double voting), they can earn a whistleblower reward. Slashings and Whistleblower Rewards Proposer Rewards : Validators who propose blocks that get finalized are rewarded. A good proposer can get extra rewards, and if they include evidence of another validator being slashed, they earn more rewards. Proposer Rewards Inactivity Leak Penalty : If a validator doesn’t participate for more than four epochs, they face an inactivity penalty. The longer they stay inactive, the bigger the penalty. This penalty ensures that validators who aren’t participating are removed from the system so that others can finalize blocks. Validators who are doing their job properly won’t be penalized. Inactivity Leak Penalty Slashable Offences Slashable Offences Double Proposal: A proposer is only allowed to propose one block for their assigned slot. If they propose more than one block, it’s considered a slashing offense. LMD GHOST Double Vote: A validator can only vote for one head of the Beacon Chain in their assigned slot. If they vote for two different heads (two different chain states), it’s a slashing offense. FFG Surround Vote: A surround vote happens when a validator casts a vote that "surrounds" or is "surrounded" by a previous vote they made in a different epoch. For example, if a validator votes for Slot 32 to Slot 128 in Epoch 5, and later votes for Slot 64 to Slot 96 in Epoch 6, this would be considered a surrounding vote. FFG Double Vote: A validator cannot cast two votes for different blocks in the same epoch. If they vote for two different blocks in the same epoch, it’s a slashing offense. This can happen during a fork, where a validator votes for two conflicting blocks in the same epoch. Double Proposal: A proposer is only allowed to propose one block for their assigned slot. If they propose more than one block, it’s considered a slashing offense. Double Proposal : A proposer is only allowed to propose one block for their assigned slot. If they propose more than one block, it’s considered a slashing offense. Double Proposal LMD GHOST Double Vote: A validator can only vote for one head of the Beacon Chain in their assigned slot. If they vote for two different heads (two different chain states), it’s a slashing offense. LMD GHOST Double Vote : A validator can only vote for one head of the Beacon Chain in their assigned slot. If they vote for two different heads (two different chain states), it’s a slashing offense. LMD GHOST Double Vote FFG Surround Vote: A surround vote happens when a validator casts a vote that "surrounds" or is "surrounded" by a previous vote they made in a different epoch. For example, if a validator votes for Slot 32 to Slot 128 in Epoch 5, and later votes for Slot 64 to Slot 96 in Epoch 6, this would be considered a surrounding vote. FFG Surround Vote : A surround vote happens when a validator casts a vote that "surrounds" or is "surrounded" by a previous vote they made in a different epoch. For example, if a validator votes for Slot 32 to Slot 128 in Epoch 5, and later votes for Slot 64 to Slot 96 in Epoch 6, this would be considered a surrounding vote. FFG Surround Vote FFG Double Vote: A validator cannot cast two votes for different blocks in the same epoch. If they vote for two different blocks in the same epoch, it’s a slashing offense. This can happen during a fork, where a validator votes for two conflicting blocks in the same epoch. FFG Double Vote : A validator cannot cast two votes for different blocks in the same epoch. If they vote for two different blocks in the same epoch, it’s a slashing offense. This can happen during a fork, where a validator votes for two conflicting blocks in the same epoch. FFG Double Vote The reason these offenses are slashing offenses is to ensure that validators do not vote for conflicting or multiple versions of the chain. This helps maintain consensus and prevent the blockchain from splitting. Whistleblower Rewards : If a validator notices another validator making a slashing offense (like a double vote), they can report it and earn a whistleblower reward. This helps maintain the integrity of the network. Whistleblower Rewards Avoiding Slashable Offenses : Validators are in complete control of their actions and can avoid being slashed by simply ensuring that they do not sign conflicting proposals or attestations. If they act honestly and do not make conflicting votes, they cannot be slashed. Avoiding Slashable Offenses Beacon Chain Validator Activation and Lifecycle Beacon Chain Validator Activation and Lifecycle To become an active validator on the Beacon Chain, a user needs to stake 32 ETH. When this amount is staked into the deposit contract on the Ethereum mainnet, it activates a validator. Once activated, a validator must maintain a balance of 32 ETH. If the balance drops to 16 ETH, the Beacon Chain will deactivate the validator, forcing them to exit the network. However, stakers will be able to withdraw any remaining balance once the system allows it (likely around 2023). A validator can also choose to exit voluntarily after serving for 2,048 epochs (about 9 days). Whether the exit is voluntary or forced, there is a 4-epoch delay before the staker can withdraw the funds. During this delay, a validator can still be slashed for misbehavior. If the validator is honest, their balance can be withdrawn in about 27 hours. However, if the validator is slashed, they will face an 8,192-epoch delay (around 36 days) before they can withdraw their funds. There are mechanisms in place to limit the number of validators that can be activated or exited within a single epoch to prevent sudden changes in the validator set. These restrictions help protect the network from attacks by making it harder to activate a large number of validators in a short time. Additionally, the Beacon Chain uses "effective balances" to manage validators, which change less frequently than validator balances and help with technical optimizations.
