The Merge: From Proof of Work to Proof of Stake

The Merge

In mid-September 2022, Ethereum’s blockchain completed its long-awaited merge into a Proof of Stake chain, deprecating the Proof of Work system that has found consensus for the network since its inception in 2015. The Merge marks the most significant event in crypto to date, as the community has never seen such a drastic change to such a high-profile chain, and with such unpredictable consequences. It represents the culmination of many years of research and testing by both the Ethereum foundation and its community and is just one step on a long roadmap of planned upgrades.

What is the Problem?

The Ethereum network is, at its core, a decentralised ledger/computer. This means that the information contained in its blocks is transmitted between a distributed network of nodes. Each node is a user’s machine that runs an Ethereum program: listening to blocks of transactions broadcast by other nodes, checking that the data promised by the miner is available and that the transactions dictated by that data are valid, before broadcasting the validated network state update to other nodes.

As the network grows, miners must validate more transactions and store more onchain data to keep up with the growing demands of its users. To do this under the current regime would either require existing nodes to increase their computational power to cope with larger amounts of data or for more nodes to join the network to spread the load. If existing nodes grow larger, then the pool of nodes that can profitably perform the validation of transactions on the network is smaller, introducing a centralisation risk. If the chain scales instead by adding more nodes to the network, then the energy drain of the network grows exponentially over time.

The Merge begins the process of splitting up the tasks performed by miners across multiple nodes whilst reducing the amount of computation needed to perform their tasks. This allows nodes to focus their computational resources on performing their own tasks and reduces the work completed in parallel between nodes. However, this method requires a more intricate reward and penalty structure to ensure that nodes remain incentivised to perform these actions honestly and quickly.

Proof of Stake research by the Ethereum Foundation precedes the launch of the Ethereum network, dating back to 2014. The infamous blockchain trilemma has long prevented single-chain systems from maximising decentralisation, security and scalability without sacrificing at least one property. Examples of this can be seen in the Bitcoin network, which has chosen to optimise for decentralisation and security at the expense of scalability. On the other hand, a chain like the BinanceSmart-Chain chooses to optimise for throughput and security while sacrificing decentralisation. The switch to a Proof of Stake consensus mechanism is the first step in the Ethereum Foundation’s attempt to solve that trilemma.

Why Can’t Proof of Work Solve it?

Ethereum’s Proof of Work system delegates the production of blocks and finding consensus to its miners; they are required to bundle up and verify transactions, embed them within a block, and propose it to the network. Other miners are incentivised to keep up to date with the work of other miners and agree on the latest valid block. The system also comprises independent nodes that inspect the work of the miners by locally verifying the miner’s block, and checking to see if invalid transactions were indeed added to the blocks.

Any user can propose the next block by choosing a published block to build on, bundling new transactions into a block that builds upon the updates in the previously published block, and propagating that information to other nodes. In doing so, they cast a vote of confidence in favour of that block’s chain by using it as a starting point for their own block. At any given moment, the longest chain is considered the canonical chain and single source of truth for the state of the Ethereum network. This is what is known as the “longest-chain” consensus.

ETH tokens are awarded to the miner that creates the next block, included as a transaction to the miner and without a from address. To choose between the many miners that wish to claim this reward, there is a pseudo-random lottery held to determine the one miner to mine the block. To obtain their lottery ticket, miners must first produce a block template containing user transactions. After producing a block template, miners pass the template’s data through a cryptographic function to generate a pseudo-random number linked directly to the input template. To be accepted as a valid addition to the chain, the random number on their ticket must be lower than some target value.

Miners can re-enter the lottery, changing the random number on their ticket by appending some random text at the end of a block’s template and thereby changing the input to the random number generator. This random text holds no information about transactions, and a miner cannot control the random number it outputs. The target value is specified by the Ethereum protocol and controls how many winning tickets are able to be found. The smaller the value of the target, the fewer the numbers that are valid and the more tickets a miner would need to create before they find a winning ticket. This allows the system to control the pace at which new blocks are appended to the longest chain.

Hosting this lottery ensures that each miner must use a substantial amount of energy. If a miner is found to have included an invalid transaction in their block (such as a double-spend) then miners will begin appending blocks to the first block before the offending block, with all blocks downstream of that block considered invalid. As the transaction rewarding the miner for their hard work is included in this invalid chain, miners are incentivised to avoid chain reversions that are costly for other users who have relied upon their transaction being confirmed.

Whilst this does ensure that miners must commit to the transactions they include in their blocks, only the work of the successful miner directly results in the addition of a block to the chain. The work performed by all other unsuccessful miners who enter this lottery by searching for a winning ticket is wasted and must be restarted on the next block. Proof of Stake aims to reduce the work performed by miners in parallel by enforcing nodes to take turns to produce blocks. However, this forgoes the financial incentives that naturally follow PoW miners’ commitment to energy expenditure. As PoS does not require the same commitment to energy use, it must instead use other systems to ensure that its block creators behave honestly, commit to the turn-based system, and are able to come to an agreement on the valid chain in a timely manner.

How Does Proof of Stake Solve it?

Proof of Stake formally decouples the actions currently conducted by PoW miners by splitting the work amongst new roles and discarding miners entirely. PoS introduces proposers who have the role of producing blocks just like a miner does, and validators who have the duty of voting on the blocks that the proposers build. There is one party whose functionality is common to both PoW and PoS mechanisms: the nodes that independently check the validity of the proposed blocks on the network.

In splitting up those roles, the new PoS architecture allows the chain to compartmentalise the three functionalities that are currently performed by Proof of Work’s mining process on a single chain: transaction execution, consensus and data availability, with the intention of increasing the network’s security, decentralisation and scalability.

Instead of a single chain creation process, Ethereum’s new PoS architecture will devote the Beacon chain to finding consensus, with a transaction layer built on top of it responsible for perpetuating the state of the network. That main chain referred to as the network’s consensus layer will then be able to assume the sole responsibility of finding consensus among the distributed nodes regarding the order and inclusion of blocks on its own chain. Transaction execution can then be included on top of this layer, with its data included in a data field within a Beacon block.

Main Characters in Proof of Stake

Nodes

A blockchain protocol’s nodes are the set of users that voluntarily run a version of the software that processes messages from other users on the network. Nodes are, by definition, the set of all parties that participate in this message-sending process. In a Proof of Work system, this includes miners and nodes that do not participate in mining. Nodes on the Ethereum network can broadly be classified into two different categories; block-producing and non-block-producing nodes, the former of which will be discussed in subsequent sections.

In both Proof of Work and Proof of Stake consensus mechanisms, non-blockproducing nodes are typically responsible for maintaining the integrity of the network by storing its history and confirming the validity of the blocks submitted to the network. Whilst miners can also perform these duties, this action does not require the node to be able to change or advance the state of the network. They are nonetheless crucial to the ecosystem as they ensure that the contents of the blocks are indeed valid.

Consider a scenario where all miners/validators on the network are corrupt. The blocks produced by these miners may include invalid transactions. It would be up to the non-block-producing nodes on the network to recognise the invalid blocks and alert the community of users that the network is under attack. It is worth again noting that this class of nodes are unable to effect any changes within the protocol themselves. Non-block-producing nodes are therefore mainly incentivised by the security and utility of the blockchain itself and not by any rewards distributed by the protocol. This corresponds with their lack of power to make changes to the blockchain. PoS preserves the role of non-block-producing nodes with the same rights and responsibilities.

Validators

Some nodes can obtain more power over the network than others by depositing 32 ETH to a smart contract. Doing so entitles them to rewards (commonly referred to as staking yields) and grants them the title of “validator”. This qualifies them to take part in the process that creates new blocks in order to grow the canonical Beacon chain.

In PoW consensus, miners cast an implicit vote towards a block by using its hash to find the next subsequent block on the chain. Ethereum’s PoS system removes mining entirely, and instead assigns this role to validators, who find consensus regarding the canonical chain of blocks by casting votes towards all blocks that have been created. However, this role grants the node extra responsibilities, and nodes that choose to deposit this sum risk losing some or all of their deposit should they perform their duties lazily or dishonestly.

The protocol incentivises these validators to participate in these elections by incrementing their staked balances if they correctly perform their voting duties, which are intended to lead to a secure and smooth functioning of the network. Conversely, the protocol disincentives activities that disrupt this functionality by decrementing a small proportion of the validator’s staked balance. Such actions include (but are not limited to) casting invalid votes and missing the vote entirely. Such actions are often indistinguishable from the actions of a malicious actor, and so are treated as such.

Just as with PoW, the validator set is the largest potential pressure point for attackers. A malicious actor could seek to gain a majority of the validating nodes, which would allow them to vote for their invalid blocks and have them accepted by the network. In certain scenarios, the network issues very harsh penalties for actions that are explicitly linked to an attack on the network, with the penalties they receive during this time proportional to the number of validators caught conducting similarly dishonest actions in the same time frame. These are called slashable offences. In addition to a large fine from their staked balance, colluding validators are queued to be ejected from the network whilst continuing to receive penalties (discussed in detail later) as if they were neglecting their voting duties during this period. These types of actions that warrant these penalties must be reported by other validators in order for the penalties to be issued.

Proposers

Nodes that have deposited 32 ETH to qualify as validators also have a random chance to be selected as block proposers. This role, if performed according to some basic rules, grants the user the right to financial rewards in addition to those it collects from performing its duties as a validator. It is worth noting that all active validators have the chance to be selected as proposers and validators cannot opt in or out of this selection. However, the selection process is weighted by the validator’s staked balance, with validators with larger stakes more likely to be selected as proposers.

Where miners bundle up transactions into blocks and broadcast them to the network in PoW, proposers perform the same functionality in the PoS system. When proposers have been chosen by the network, they are asked to listen for transactions, validate them, and bundle them up into a block to be presented to the network to be added to the main chain. In doing so, they perpetuate the state of the network to a state where the included transactions have been executed.

Alongside transaction data that is included inside the proposed blocks, the proposers must also include the votes cast by previous validators. The protocol incentivises them to do so by giving them rewards based on how many “correct” votes (defined in more detail later) they include in their block. Proposers also receive rewards by including evidence of slashable offences inside of their blocks, an action which aligns the incentives of proposers with the security of the network.

Proposers are subject to the same penalties as validators. However, because validators are in charge of block production, they have the most influence over the state of the network at any given point in time and have the potential to causecontention in the network should they plan to conduct an attack. Because of this, proposers who create more than one block when they are chosen to produce only one are liable to receive slashing penalties as described above.

Issuance

It is worth stating here that all rewards distributed by the protocol are proportional to a validator’s staked balance: the higher their staked balance, the higher their reward. So too are the penalties levied on malicious validators. To further bolster the network’s security, the protocol also encourages validators to monitor one another and keep themselves honest. Validators are rewarded for reports of evidence of any malicious activity, though only specific types of actions are eligible to be reported.

In the previous PoW system, miners were rewarded with nearly 13,000 ETH per day for adding valid blocks to the chain. In PoS, validators are distributed around 1,600 ETH per day as rewards for voting correctly. Prior to the Merge, the Beacon chain was running in parallel to the PoW chain meaning that their combined issuance was close to 14,600 ETH/day pre-merge. After The Merge, only the ~1,600 ETH earned from staking rewards will be introduced to the network per day, and no new ETH will be awarded to miners. This will drop the total new ETH issuance by ~90%, and result in an inflation rate of near 0.49%.

An update in August 2021 introduced the burning of gas fees on the network, which removes a base fee of ETH in every transaction. That fee fluctuates based on market activity and is not fixed. This is planned to continue post-Merge, acting as a balancing force to the introduction of new ETH via staking rewards. Additionally,the penalties levied on the validator’s staked balances result in the removal of that ETH from the network. At the current rate at least 1,600 ETH is burned per day, which effectively brings net ETH inflation to zero or less post-Merge.

The Beacon chain

Ethereum’s new voting system changes the way that nodes propose and confirm new blocks, relying on a fixed timing system composed of slots and epochs. The chance for a proposer to add a block to the chain occurs once in each slot, with 32 consecutive slots defining an “epoch”. However, a proposer may be offline and miss the chance to propose a block in their slot.

Each block proposed adds to a growing tree of blocks, with each branch starting at the original Beacon block. It is the job of the proposers to add new leaf blocks to this tree. It is the job of the validators to link blocks together along a branch, from the original Beacon block to the latest valid block in order to define a canonical history of the Beacon chain.

The slot time, 12 seconds, is the smallest unit of time recognised by the chain, meaning that the chain can confirm a maximum of 32 blocks per epoch, or 32 blocks per 6 minutes and 24 seconds. The chain chooses to regulate the timing of additions to the blockchain in this way so that the distributed nodes are able to first agree on which block they are voting on, and for new blocks to be presented to the network in a predictable manner. In a PoW chain, the regular arrival of new blocks is controlled by the adjustable difficulty of finding a valid hash.

Figure 1. The Beacon chain timing system is comprised of slots and Epochs. Source: https://ethos.dev/beacon-chain/

As previously stated, PoS decouples transaction execution from finding consensus. The Beacon chain’s operation since late 2020 and up to the Merge has been a testament to that. Before the Merge, the Beacon chain did not process nor contain any transaction data. The Beacon chain is simply a consensus-providing template, allowing for transaction execution to be modularised and abstracted into a separate mechanism whose validation data can be included in Beacon chain blocks. After the merge, the Beacon chain will continue to perform in this manner, with the added functionality of transactions being included inside its blocks. In this way, the transactions are secured by the same security and consensus mechanisms that the Beacon chain maintains.

The Beacon chain is responsible for itself, ensuring that security standards of finding consensus are maintained in order to continue its existence as a consensus layer. It is also responsible for the coordination mechanism between the different parties participating in the network, deciding the order in which validators and proposers are assigned to perform their duties. To do so in a manner that upholds the security standard it requires, it keeps a detailed record of the consensus participating parties, namely the validators, including their population, entry and exit times, staked balances, votes, and penalties.

Transaction Lifecycle

To illustrate the mechanisms that Proof of Stake employs to maintain a chain, we will focus on the life cycle of the users’ transactions that make up the contents of its blocks. This will span the moment that a transaction is signed and sent by a user of the network to confirmation of its inclusion onchain.

The minimum time for a transaction to be included in a block onchain is 12 seconds, but the actual time is dependent on the transaction and the gas fee included. Ethereum’s Proof of Work took 13 seconds on average to include the highest fee tier of transactions. For transactions to achieve a solid notion of finality, users must wait for a minimum of 12 minutes (2 epochs) on top of the time taken for the transaction to be included onchain. This is not dependent on the fee paid, but instead on the results of the voting mechanism that confirms blocks as finalised.

Sending a Transaction

After a transaction is signed by a user that wishes to send ETH on the network it is sent to the network of non-block producing nodes. The aggregation of transactions that are waiting to be confirmed is called the mempool.

We can think of the mempool as a waiting room where transactions sit before they are included in blocks. Proposers browse through these transactions to choose those that they wish to include in the data field of their block. If the fee included in the transaction is more attractive, the proposer will include this transaction onchain and enter it into the verification/validation process much earlier. If the transaction is accepted, the proposer receives the fee associated with it.

Validation/Verification Process

To explain the process that takes a transaction from being picked up by a proposer from the mempool to its inclusion onchain, we must first take a step back and discuss the architecture of the system that creates and validates new Beacon chain blocks. This begins with the allocation of validators into the 32 slots in an epoch.

At the beginning of each epoch, the full set of validators is randomly allocated a slot in the following epoch by the protocol. In that slot, all the validators allocated to that slot are required to vote for a block that, based on the messages that they have received from other nodes on the network, they believe is the latest in the canonical chain. As such, every slot has a set of validators that each cast a vote towards what they believe is the head of the beacon chain. Validators are given a one-epoch head-start so that they can prepare to vote for blocks that are proposed in their allocated slot and come to an agreement on the most recent valid block.

At the same time, 32 validators are chosen at random to propose a block for each of the 32 slots in that same epoch, with a single proposer responsible for making a block in one slot only and no proposer making a block in more than one slot.

Randomised Validator Assignment

The random allocation of validators and proposers to slots raises an interesting problem – how to choose a node at random in a consistent but decentralised way. As the Ethereum network acts as a decentralised computer, its actions are deterministic – the same inputs produce the same outputs on each node’s local machine. Therefore any pseudorandom number generator must be unpredictable whilst producing the same outputs for each node on the network given the same onchain input. Once a random number is available onchain, it can be queried by the protocol as an input to sort the list of validators’ addresses into a random order.

The Beacon chain achieves this using RANDAO, an algorithm that “mixes” random numbers submitted by proposers in their blocks to avoid any single input controlling the result. Each block proposer is asked to provide a seed number (similar to a nonce in PoW) in their block. That seed is mixed (by either multiplying or XOR’ing) with the previous block’s final random number before the result is hashed. That hashed output becomes the random value recorded by that block and will be combined with the seed provided by the next block’s proposer in the process to generate their random number. This process is similar to the chain of block headers present in PoW blocks, and further links the blocks in a chain.

Requiring the proposer to use the previous random number as an input and to hash the resulting output adds two hurdles to controlling the final result. Doing so would allow them to choose a favourable slot in a future epoch. However, the proposer of the final block in the epoch (immediately before the random number is used as a seed to choose validators for the next epoch) has a disproportionate influence on the output. If they wish to produce a specific number from this process, they must only find a value that, when combined with the hash of the penultimate contributor, hashes to produce their desired number. This is not true of all other proposers in the epoch, whose results are mixed with subsequent proposer’s seed numbers. However, this task is considered difficult enough to complete in the 12 seconds available to ensure that this algorithm produces a sufficiently unpredictable number.

Decentralised Timing

The Beacon chain’s enforced rhythm poses another important problem for the Proof of Stake consensus system to solve that is not an issue for Proof of Work: decentralised consensus on the timestamp of a message. Without this, nodes could disagree on whether a proposer submitted a valid block in time for its slot, when a block attestation was received, or even on which slot is currently being contested. As no centralised authority can be relied upon to provide the truth, nodes must instead follow a protocol to determine the canonical timestamp of a message they receive and check whether it arrived in time to be used for its appointed vote.

They do this by broadcasting the timestamp at which they received the message and listening to similar broadcasts from other nodes. A node determines the message’s timestamp as either the 33rd or 67th percentile of the distribution of heard timestamps, taking the percentile closest to their own observation. This decision rule does not provide an exact agreement between every node, but in practice has been shown to keep their records consistent enough to allow the protocol to function without major reversions.

Proposers Propose

Now that the validators and proposers know when they will be asked to perform their actions, the processes that happen in each slot can begin: creating a block containing new onchain information and holding a vote to determine the block at the head of the canonical chain from amongst the tree of all proposed Beacon blocks.

In order for a proposer to produce a block, they must first choose an existing chain to append it to. A proposer must choose this in a standardised way so that other nodes on the network, including validators, can do the same and come to an agreement on the result. To do so, the proposer must record every previous vote for every previously proposed block, even if that block was previously rejected. These historical votes are then used to determine the one block at the head of the chain using a decision rule called LMD Ghost. As each block has only one parent, this choice also uniquely determines a canonical chain.

This rule begins with the Genesis block (the first block on the Beacon chain) and iteratively chooses a block to link to it from the set of blocks that have been proposed as its child blocks (blocks that immediately follow the parent block). Each child block can have multiple chains downstream of it, but only one parent block.

The LMD Ghost algorithm chooses the child block whose chain is weighted with the largest number of votes (either for the child block or one of its descendants). In this way, the rule navigates down the chain one block at a time by choosing the branch weighted with the most votes, creating a canonical chain of blocks. This process continues until it finds a leaf block with no existing children. This block is called the block at the head of the canonical chain.

Figure 2: An example of the LMD-GHOST fork-choice rule. The number in each block B is the weight (by stake), with all attestations (circles) having weight 1 in this example. A validator using this view will conclude the blue chain to be the canonical chain, and output the latest blue block on the left, with weight 3, to be the head of the chain. Source: https://arxiv.org/pdf/2003.03052.pdf.

Having chosen an existing block as the latest valid block on the chain, the proposer can begin work on creating the block that it will propose to the rest of the network. Both valid and invalid votes are included in order to keep track of the rewards, penalties, and honest and dishonest validators described above. The proposer includes in this block: the votes that validators cast in the previous slot, any slashable penalties incurred by validators or proposers, any entries and exits by validators, as well as an extra data field.

If a proposed block is accepted by the validators assigned to vote on it (recorded in a later slot), the proposer receives a reward. In their proposed block, the proposer will include votes held in the previous slot’s time window. The reward received by the proposer is proportional to the number of these votes that agree with the proposer’s claim that the block they have appended to was the head of the canonical chain. In this way, a proposer is incentivised to include evidence of consensus from other nodes with their own view of the chain.

LMD Ghost votes are recorded onchain when a proposer includes them in a proposed block in a later slot. We call this proposer the recorder. That vote can be for one of three things: for the block that is the immediate predecessor of the block that records their vote (full agreement with the recorder’s view of the chain), for an earlier block in the same chain as the block that records their vote (partial agreement with the recorder’s view of the chain), or for a block in a different chain entirely (contradiction to the recorder’s view of the chain).

In the first case, the vote would be considered valid as they represent an agreement of the vote with the recorder, and the reward that they are sent as a result will be valid in the canonical chain. In the last two cases, however, the votes express disagreement with the recorder and so would be considered invalid on the canonical Beacon chain (despite being recorded in a block on the canonical chain), and so the canonical version of the history of the Beacon chain would not reward those validators for making those votes.

It is important to note that these votes are only considered valid or invalid in the context of the chain in which they live. If a vote in favour of a block is recorded on a minority chain (on a fork other than the canonical chain), then the validator who made that vote will be rewarded on the minority chain but would be unable to spend it with anyone who is instead listening to the canonical chain and accepts it as the source of truth.

The inclusion of each of these items is crucial for the beacon chain to maintain itsrecord of the activities of the validators in the system. The block created by the proposer is then broadcast in their slot to be considered for addition to the canonical Beacon chain.

Validators Validate

Validators assigned to vote in a slot must listen for the proposed block and decide whether or not they agree with its view on the head of the chain. As each block is at the head of a unique chain, this decision also implies agreement with each of that block’s ancestors. Each validator comes to this conclusion by comparing the proposed block’s parent block to the result of running their own LMD Ghost algorithm on the set of votes that they have heard. As such, the name of the votes cast to run this algorithm is called an LMD Ghost vote.

The validators who cast votes that agree with the state of the chain presented by the proposed block are rewarded with a small increment to their staked balance, proportional to the validator’s staked balance if this block is eventually added to the canonical chain.

If the validators disagree with the block that is proposed in their slot, they will instead cast votes for the block that they deem the current chain head, thereby agreeing with the state of the network that it implies. Despite using the same decision rule as the proposer, each validator may nonetheless still come to a different conclusion about the head of the canonical chain due to hearing a different set of messages, and so missing/hearing a different set of votes. Validators may also choose this option either because the proposer did not submit a valid proposal in the 12 seconds or because they do not agree that the proposed block’s parent was previously the head of the chain.

Both reasons could be caused by either a malicious node or a node experiencing latency issues. If the validator is observed to have not submitted a valid vote in the slot to which they were assigned, they will be penalised by having a small amount of their stake deducted from their balance and burned. This action disincentives validators from casting invalid votes, and rewards attentive participants of the network. Therefore validators’ stakes can change from epoch to epoch depending on the rewards and penalties that they accrue, despite initially depositing 32 ETH each.

Finality

The Issue

Once a transaction is added into a block and that block is added to a chain, the LMG Ghost algorithm allows for this transaction to be reverted should validators in aggregate decide that another chain should be the canonical chain when they learn new information or hear a larger set of messages from other nodes. This means that a slot’s vote can elect blocks from many epochs in the past as the head of the canonical blockchain, or even another branch entirely.

This would result in long-range reversions of arbitrary length that remove any assurance of transaction finality. This is an inherent feature of the LMD Ghost algorithm, and it introduces a concept called liveness that allows the network to make new decisions about the canonical chain. This is a problem, however, for a user who wants to guarantee that their transaction has been successfully completed and cannot be reverted, or “finalised”.

This problem is formally known as FLP impossibility, which is similar to the blockchain trilemma discussed earlier. Like the blockchain trilemma, FLP impossibility states that distributed computing systems must sacrifice either safety, asynchronicity or liveness. As well as introducing liveness, the LMD Ghost algorithm is also asynchronous; the algorithm decides the canonical chain as it accumulates votes over time by communicating messages between a distributed network of nodes. This means that the safety of transactions is in jeopardy.

In a PoW system, the only way that transactions can be reverted is if more than 51% of the network decides to discard a segment of the longest chain, return to an earlier block, and recreate the subsequent blocks to outpace the pace of the rest of the network. Under the longest chain consensus, that branch would become the canonical chain and transactions on the original branch would be rendered invalid. However, the immense difficulty in conducting this attack and finding hashes faster than miners working on the original chain is what gives users the confidence that it will not happen. As PoS’s block proposal is relatively cheap, the system must find another way to prevent nodes from reverting to blocks far in the past.

The Solution

To resolve the FLP impossibility problem, the system uses another vote that periodically elevates certain blocks (and their chains) to a non-revertible status. This vote is performed by the same validators that perform the LMD Ghost vote. This mechanism is a layer on top of the Beacon chain and is agnostic to the consensus mechanism that drives it. In theory, can even be used on top of PoW, but would essentially be redundant given the difficulty of outpacing other miners.

The Beacon chain instead requires potential transaction reverters (attackers or honest) to spend a significant amount of ETH to overturn blocks with a finalised status. This status-elevation is determined by a compulsory, dedicated vote that is held in addition to the regular block verification duties of each validator, requiring them to stake their balance on an additional “Casper the Friendly Finality Gadget (FFG)” vote.

The FFG vote, just like the LMD GHOST vote, is asynchronous in the sense that votes are accumulated over time. By sacrificing liveness, the FFG algorithm is able to introduce safety to Beacon chain blocks. As the data that records transactions is included in each Beacon chain block’s data field, this security is extended to the transaction layer also. This system, used in conjunction with the LMD GHOST algorithm, results in a system that circumvents the FLP impossibility trilemma, called GASPER.

Checkpoints

The elevation in status of validated blocks is performed in Chunks, with two blocks selected to bookend a group of blocks. Only blocks proposed in specific slots can be chosen to bookend these chunks, and the division of the chain into epochs provides an obvious method to choose them. Epoch Boundary Blocks (EBBs), or checkpoints, are blocks in the chain that are proposed in the first slot of an epoch.

However, it is possible that no valid blocks are proposed in the first slot of an epoch, either because the proposer was offline during the slot, or the proposed block was altogether invalid. In such cases, the canonical chain instead defines the last valid block in the previous epoch as that epoch’s checkpoint. If there are no blocks in the chain in a given epoch (and a block’s chain skips over an epoch entirely), the previous epoch’s checkpoint block will be repeated for the “empty” epoch.

Figure 3: Example of epoch boundary blocks and pairs. Blocks are labelled with their slot numbers. “63” is not an actual block but illustrates the perspective of 66 needing an epoch boundary block at slot 64 and failing to find one. Source: https://arxiv.org/pdf/2003.03052.pdf

Figure 4. Each block in the diagram represents a checkpoint block. Red-colored blocks are blocks that have been voted for through the FFG vote. In this example, r is the only finalised block as it is the only block that has had its successive checkpoint justified. Source: https://arxiv.org/pdf/1710.09437.pdf

Like the LMD Ghost vote, when (in a later slot) a Casper FFG vote is recorded onchain by a proposer that agrees with the vote made by the validator, both that proposer and validator are rewarded. This incentivises the proposer to provide evidence of consensus on their own view of the chain.

Unlike the LMD Ghost vote, the vote for the current checkpoint to justify can happen within 32 slots from the slot in which they are asked to vote, and not only in the validator’s assigned slot. The specification of the previously justified block must, however, happen within 5 slots (1 minute) in order for the validator to receive the associated reward. If the validators do not cast these votes in the specified timeframe, they are penalised and their vote is rendered useless. Voting for checkpoints that are not in line with what the current block proser makes the validator liable to the same penalties as if they did not vote at all as their vote will only be included in the canonical chain as evidence of bad voting.

If a supermajority agrees on both a target checkpoint to justify and a previously justified checkpoint to link it to, then the target checkpoint becomes justified. As validators send their votes throughout the epoch, a supermajority can occur before the epoch is over.

If this newly created pair of justified blocks are also consecutive checkpoints (meaning that they are the boundary blocks of consecutive epochs), then the older checkpoint is determined to be finalised. Furthermore, blocks upchain of that block are considered finalised too, recognising that all the blocks upchain of that checkpoint were necessary for reaching the network state that the checkpoint block represents. Once a block is confirmed finalised, the LMD Ghost vote can no longer choose a block upchain of it as the head of the canonical chain and revert the transactions within it.

Perpetually Unfinalised

By requiring that successive checkpoint blocks are voted as justified, this finalisation mechanism leaves the chain susceptible to entering a state where Chunks are perpetually unfinalised. If this happens, and the last finalised block is far upchain of the current chain head, the set of unfinalised blocks remains large, allowing for long-range reversions that may revert a long history of transactions.

The protocol avoids this by introducing a state called inactivity leak. If 4 epochs have elapsed before the chain reaches finality on any checkpoint, the protocol assumes that there are large amounts of inactive participants which leads to the lack of supermajority votes necessary to obtain finalised checkpoints. This state aims to restore the superiority to the hands of active validators by continuously and aggressively reducing the balances of inactive validators so finality can once again be reached.

The protocol tracks an inactivity score for each validator: decreasing the score by 1 every time a validator casts a vote in a correct and timely manner and increasing it by 4 for any other scenario. Every epoch, the protocol makes global adjustments to all validators’ inactivity scores based on whether the chain is currently in an inactivity leak, decreasing the score by 16 when the protocol is not in an inactivity leak, and making no changes to validators’ inactivity scores the when inactivity leak is triggered. In both scenarios, the inactivity scores will continue to change based on a validator’s activity. The score has a floor of 0, ensuring that no user can have a negative inactivity score.

The penalties received by each validator in this state are proportional to their inactivity scores. This system ensures that the inactivity scores of offline validators during inactivity leaks rapidly increase and exacerbate the penalties they are subject to during this period. The changes made to the inactivity scores of validators mean that validators are still liable to receive penalties even after the inactivity leak is over. This is to more decisively give the set of active validators the supermajority, therefore preventing the protocol from flickering in and out of supermajority.

Figure 5: Visual depiction of how validator balances change when the protocol is in Inactivity leak. Source: https://eth2book.info/altair/part2/incentives/inactivity

Security of the Blockchain

Proof of work, the longest battle-tested consensus mechanism, has so far proved difficult for malicious miners to collude and conduct attacks against the network. The security of the network is, in part, derived from the decentralisation of the nodes that comprise its network. The more nodes that hash power is distributed across, the more difficult it is for enough of these nodes to coordinate with one another, overcome the hash power controlled by the rest of the nodes, and successfully complete an attack.

It is natural to question the security mechanisms that PoS employs as, after all, PoS necessarily removes the barrier of hash power that stands between the safety of our transactions and the control of potential attackers. We can draw parallels between the set of active validators in PoS and the miners in PoW; ideally, they will be as decentralised as possible as they are the primary controllers of the chain that an attacker may wish to overpower. Let us break down the main defence mechanisms that protect the PoS consensus mechanism.

The system uses RANDAO to randomly divide the set of validators across different slots to cast votes. The random allocation of validators bolsters the security of the networks by making it highly improbable that an attacker gains the majority of validators allocated in a slot. Coupled with the fact that validators are only given a maximum of one epoch notice as to which slots they will validate in, attackers are given a much harder task of anticipating an opportunity. Proposers are given a much more strict time frame, having less than an epoch’s notice to collate and propose blocks.

How Does the System Prevent Collusion?

Earlier in this report, we mentioned the notion of slashable offences whereby validators take part in malicious activities which the protocol deems as severe. One such explicitly malicious action is the proposal of two conflicting blocks in the same slot. The validators immediately have 1/32 of their effective balance (32 ETH) deducted from their staked balance and are queued to be forcibly ejected from the validating process 8192 epochs (around 36 days) in the future.

The slashed validator continues to receive attestation penalties during this queuing period and is excluded from receiving any attestation rewards for performing correct duties. In addition to this, they receive another penalty, at around 4096 epochs, based on how many other validators were slashed during that period. The larger the number of slashed validators in that period, the larger the penalties received to more severely punish validators who plan a coordinated effort to attack the network.

A validator can cast an invalid FFG vote that contradicts a vote they made in a previous epoch. This is formally known as a surround vote and happens when the two checkpoint blocks that a validator votes for in the current epoch either surround or are surrounded by the two checkpoint blocks the validator previously voted for. Consider 5 checkpoint blocks numbered from 1-5. An example of a surround vote would occur if the validator votes for checkpoints 3 and 4 in one epoch, then votes for checkpoints 2 and 5 in the next. This type of voting directly contradicts finality because, in one epoch, finality is applied between blocks 3 and 4, and then reverted in the next epoch. The CASPER FFG mechanism ensures finality by ensuring that validators’ votes in consecutive epochs must happen sequentially.

Another invalid vote a validator can make is the casting of two different pairs of FFG votes in the same voting period. Such votes make the chain more susceptible to being forked and are detrimental to the finalisation of blocks. Both of these mentioned above subject the validator to slashing penalties. Note that for a validator to be slashed, the offence must be ‘reported’ by other validators and must be included in a block of the following proposer. Rewards are distributed to the validator that reported the offence and the proposer who included this evidence in their block.

The supermajority mechanism introduced by PoS increases the resource threshold that attackers need to carry out damaging attacks. In PoW, miners need to obtain 51% of the network hash power to perform damaging attacks on the network. PoS explicitly defines the supermajority threshold as two-thirds of the total staked balance of all validators and in doing so requires significant capital costs from the attacker. In such cases, the evidence of an attack will be clearly recorded on-chain.

For the decision to finalise historical blocks to be overturned by the network, a supermajority vote must be cast in favour of a contradiction to the previous supermajority that finalised those blocks in the first place. For both the original vote to finalise the blocks and the subsequent vote to change the decision on finalised blocks to pass, two-thirds of the total staked ETH must have voted in each. As the slashing penalty is proportional to the number of validators that have committed slashable offences (and a validator loses their entire stake when they commit an offence at the same time as one-third of the other validators), this would result in at least one-third of the total staked ETH by all validators being destroyed. Attackers or a network in desperate need of a reversion wishing to revert finalised transactions will do so knowing that they will incur a cost of at least one-third of the total staked ETH, which would represent much more than a third of their own staked ETH.

Double Spending

This mechanism also provides security against double spending. Double spending on a blockchain can be caused by two things: including two transactions to two different addresses (and spending the same tokens), and chain reversions. Both PoS and PoW deal with the first case in the same way, by recognising that the second transaction spending the same tokens is invalid and requiring each new transaction to have a unique unspent transaction as a starting point. The second case is more difficult to solve. If a transaction is considered finalised, a victim will send the goods or services that the attacker has paid for. The reversion of that onchain transaction will return the ETH to the attacker, which they can then spend elsewhere.

Proof of Work prevents chain reversions by requiring an attacker to control 51% of the hashpower on the network. To fool someone into believing that a transaction spending your ETH is included onchain, an attacker would need to keep up with the miners contributing to the canonical chain in order to supply a victim with a valid chain longer than the canonical chain.

In PoS, chain reversions are only possible when validators controlling two-thirds of the total staked balance vote to do so. If an attacker is able to gain two-thirds of the staked balance of the network, they are able to send ETH to a victim, obtain goods and services in return, and then revert the state of the network to a state where the transaction had not taken place. As mentioned in the section above, doing so will result in one-third of the total staked balance being destroyed.

Whereas in PoW a user must wait until it has been shown enough valid blocks to make it unlikely that a malicious miner has been able to fool them without 51% of the network’s hashpower, PoS requires users to wait until the block containing their transaction has been finalised. Once that happens, they can be sure that an attacker must control at least two-thirds of the total staked ETH and be prepared to lose half of it.

How did the Merge happen?

The switch highlights the fact that the validity of a chain is not derived solely from the set of rules that the protocol follows to facilitate consensus amongst the nodes concerning the current state of the network. The change to Proof of Stake is spearheaded by the group of core ETH developers, but their power to implement these changes is ultimately derived from the agreement of the nodes of the network to accept those changes, including those nodes controlled by the Ethereum Foundation’s members. At any time, the nodes of the network can (in aggregate) decide to use a different set of rules to reach consensus by forking the chain and working on their own branch with their own set of rules.

That is exactly how the Merge was achieved. It is a hard fork led by the community of core developers and adopted by the nodes participating in the network. It is the ultimate test of the community’s willingness to adopt a completely new set of rules. Though the majority of the Ethereum community has long anticipated the Merge, it leaves a large and important set of stakeholders unhappy by removing their primary income stream. Miners who operated specialised hardware that contribute to securing the PoW chain are now redundant. They must redirect their mining hardware towards other projects, or perhaps sell their equipment altogether.

The Beacon chain is already running in parallel to the Ethereum main chain, its nodes already running the Beacon chain’s consensus client and adding blocks to its chain. Until the Merge, the blocks on this chain mainly consisted of validator data on a block-by-block basis, including their balances, penalties, attestations and their respective entries and exits, all of which are used in finding consensus for the Beacon chain. Before that point, the Beacon chain recorded no transactions between its users.

The Ethereum core developers have collectively produced a standard for which community members could propose potential network upgrades, called Ethereum Improvement Proposals (EIP). They encourage users who submit proposals to follow a technical prototype to allow other developers to critically assess the changes these proposals plan to make. They also encourage users to engage in discussions within community forums about potential EIPs to thoroughly audit the EIP before it is formally proposed to the core Ethereum developers.

Triggering the Merge

Early on in the Ethereum network’s lifecycle, the core developers introduced a difficulty bomb which acts as PoW’s self-destruct mechanism and triggers the chain’s transition to PoS. The difficulty bomb has the effect of exponentially increasing the network’s difficulty over time, making it harder and harder to add blocks to it until it can no longer be mined. Every block on the current PoW chain contains a difficulty parameter which determines the proportion of possible hashes that are valid. Blocks also have a total difficulty parameter which records the sum of all difficulties across all blocks in Ethereum’s history. It represents the total hash power the network has committed to reaching the current state of the network.

In the specification of the EIP introducing the difficulty bomb, a threshold for the total difficulty was introduced called the TERMINAL_TOTAL_DIFFICULTY. This specified when the difficulty bomb was to be triggered beginning the Merge process. Multiple EIPs after this were further implemented to delay the difficulty bomb, with EIP-5133 introducing the latest delay resulting in the current terminal total difficulty (58750000000000000000000). Once a block with a total difficulty larger than the terminal total difficulty is seen onchain, the difficulty bomb was triggered. Execution clients on the current PoW chain began listening to the PoS layer (Beacon chain) for consensus, and Beacon nodes running the consensus clients worked to embed it within a Beacon block whose slot aligns with the time the terminal block is produced. The block that triggered the Merge was mined on the 15th of September 2022.

Merging into the Beacon chain

The Merge introduces an extra data structure called the “Execution payload”, which will be added to Beacon blocks. The structure of this Execution payload is equivalent to a PoW block with the difference being that parameters relevant only to the PoW mechanism such as the difficulty and nonce will be set to 0. There exist new parameters inside this payload such as PREVRANDAO, which contains a random number used by RANDAO.

The final PoW block is embedded in a Beacon chain block’s execution payload; the Beacon consensus layer randomly allocated a proposer who proposed the first payload-containing Beacon block and validated it using the PoS consensus mechanism. The payload included in this Beacon block contains the same transaction details as the final PoW block that was heard by clients. Once the PoS layer finalised the first payload containing the Beacon block, all existing execution clients began relying on PoS for consensus for subsequent blocks.

To become a full validation node after the Merge, all existing clients will need to run their counterparty clients. This means that execution clients will need to run consensus clients and vice versa.

Proof of Work Forked Chain

Off-chain Consensus

The switch of consensus mechanism from Proof of Work to Proof of Stake brings with it an end to mining. The introduction of a difficulty bomb means that miners will eventually be unable to find a valid hash for the next block. The block with a total difficulty equal to the total terminal difficulty arrived on the 15th of September, 2022.

This rule was implemented via an Ethereum Improvement Protocol (EIP) which, in practice, means that the code of each local client that each node runs to interact with the blockchain was changed. This local client follows the rules of the Ethereum protocol as agreed upon via off-chain governance and ETH dev communication with the Ethereum community. These rules can, in theory, be changed anytime by any user. However, for any change to impact the canonical chain, the author of those changes must convince the rest of the network to accept their rule changes and use them in their own local client to produce new blocks.

The eventual phasing out of mining is, understandably, unpopular with Ethereum miners. Their often specialised equipment is rendered obsolete by the new Ethereum protocol. Therefore, many in this group do not accept the rule changes that facilitate this switch and have created a different implementation of the Ethereum client that does not include the difficulty bomb rules.

Nodes that choose to use this implementation will be following different rules than those nodes that accepted the Merge. According to their version of the rules, PoW chain nodes will be able to add valid blocks to the terminal difficulty block’s chain as normal without an exponential increase in difficulty. Nodes that accept the difficulty bomb rules have begun running the PoS client as detailed in the section above. This is a hard fork to the blockchain and is the result of two chains appending blocks to a common ancestor block by following different rules.

The history of both chains is the same up until the block that they fork from. As a consequence, any address that held a balance of ETH, ERC20, ERC721, or NFT tokens on the original chain will hold the same balance of tokens on both the PoW fork and the PoS fork. However, the value of these tokens on one fork chain has no reason to be pegged to the value of the same token on the other fork chain. It is worth noting that there may be many such forks, each with their own tokens that share a history up until the block that they are forked from.

POW Smart Contracts and dApps

Despite tokens being duplicated on both the PoW and PoS branches of the fork, it is unlikely that the PoW DeFi ecosystem will survive long after the Merge date. Stablecoin issuers like USDC and USDT are highly unlikely to honour redemptions on both POS and POW tokens as this would double their supply whilst maintaining the value of reserves. This would cause a significant danger of a redemption run and corresponding de-pegging event. Without the liquidity afforded by stablecoins, it is difficult to imagine any meaningful activity in any future Proof of Work ecosystem.

Exchanges

Many exchanges, including Deribit and FTX, have stated that their derivatives and spot markets will be settled to PoS ETH indices, signalling their support for the Merge. However, Deribit has also previously stated that they will credit all fork tokens to users for withdrawal only, provided that the forked chain in question meets some requirements. It is unclear whether they will also offer derivatives settled on the forked assets in the future.

However, some exchanges already offer POW futures contracts, which were functionally an IOU until the date of the Merge passed. It is unclear how these contracts would have been settled in the case of a delayed or unsuccessful merge.