top of page


Updated: Jun 8, 2023


Authors: Mikhail Kalinin, Danny Ryan , Vitalik Buterin

Mikhail Kalinin, Danny Ryan, Vitalik Buterin, "EIP-3675: Upgrade consensus to Proof-of-Stake," Ethereum Improvement Proposals, no. 3675, July 2021. [Online serial]. Available:

 EIP's in PARIS Upgrade
Mental model

POS FORKCHOICE UPDATED => An event occurring when the state of the POS Fork choice is updated.

FORK NEXT VALUE => A block number set to the fork next parameter for upcoming consensus upgrade.

Client software Configuration

The following set of parameters is a part of the client software configuration & must be included in its binary distribution:


-Fork Next Value

-Terminal Block Hash

-Terminal Block Number

If the terminal block hash is stubbed with 0x00, the terminal block number and terminal block hash parameters must not take an effect.

POW Block Processing

Pow blocks that are descendants of Terminal POW block must not be imported.

Terminal POW block is the last POW block on the Canonical Chain.

Block Structure

Transition Block:

Difficulty set to 0

Block Validity


The following actions must be taken:

  • Remove increasing the balance of the block’s beneficiary account by the block reward.

  • Remove increasing the balance of the block’s beneficiary account by the ommer inclusion reward per each ommer.

  • Remove increasing the balance of the ommer’s beneficiary account by the ommer block reward per each ommer.

Note: the transaction fee mechanism affecting the block beneficiary account must remain unchanged.

Fork Choice Rule

If set, the TERMINAL_BLOCK_HASH parameter affects the PoW heaviest chain rule in the following way:

  • Canonical blockchain MUST contain a block with the hash defined by TERMINAL_BLOCK_HASH parameter at the height defined by TERMINAL_BLOCK_NUMBER parameter.

Note: This rule is akin to block hash whitelisting functionality already present in client software implementations.

As of the first POS_FORKCHOICE_UPDATED event, the fork choice rule MUST be altered in the following way:

  • Remove the existing PoW heaviest chain rule.

  • Adhere to the new PoS LMD-GHOST rule.

The new PoS LMD-GHOST fork choice rule is specified as follows. On each occurrence of a POS_FORKCHOICE_UPDATED event including the first one, the following actions MUST be taken:

  • Consider the chain starting at the genesis and ending with the head block nominated by the event as the canonical blockchain.

  • Set the head of the canonical blockchain to the corresponding block nominated by the event.

  • Beginning with the FIRST_FINALIZED_BLOCK, set the most recent finalized block to the corresponding block nominated by the event.

Changes to the block tree store that are related to the above actions MUST be applied atomically.

Note: This rule MUST be strictly enforced. “Optimistic” updates to the head MUST NOT be made. That is – if a new block is processed on top of the current head block, this new block becomes the new head if and only if an accompanying POS_FORKCHOICE_UPDATED event occurs.


Using a predefined block number for the hard fork is unsafe in this context because the POS fork choice takes priority during the transition.

Minority hash power = Chain with the lowest block height, meets block height requirement earlier than canonical chain

An attacker may use minority hash power to build a malicious chain fork that would easily satisfy the block height requirement. Then the first POS block may be maliciously proposed on top of the POW block, from this adversarial fork, becoming the head and subverting the security of the transition.

As a safeguard from this type of attack, Difficulty accumulated by the chain (TD) is used to trigger the upgrade.

Parameterizing terminal block hash

Terminal POW block overriding

There is a mechanism allowing for accelerating the consensus upgrade in emerging cases. This EIP considers the following emergency case scenarios for the acceleration to come into effect:

Case 1

A drop in network hash rate which delays upgrade significantly

Case 2

Case 1

Safely accelerated by updating the following parameter:

TTD: Reset to a value that is closer in time than the original one. Fork_Next_Value adjust accordingly.

Real case scenario (where the opposite happened)

Ropsten testnet Merge => the TTD was increased, to slow down the merging process So that it doesn't happen before the Bellatrix upgrade.

Case 2

A dire attack scenario requires a more intensive override:

Terminal_block_hash = set to the hash of a certain block to become the terminal POW block

Termina_Block_Number = Set to the number of block designated by terminal block hash

Terminal_Total_Difficulty = Set to TD value of block designated & terminal block hash

Fork_Next_Value = adjust accordingly

Ancient blocks are no longer a requisite for a network security

Ancient block = Previous blocks of the network (Since the Genesis Block)

Keeping Historical blocks starting from Genesis is essential in the POW network. A header of every block that belongs to a particular chain is requisite to justify the validity of this chain with respect to the POW seal.

Validating the entire history of the chain is not required by POS network. Instead, the sync process in POS network relies on weak subjectivity checkpoints, which are historical snapshots shared by peers on the network.

This means historical blocks beyond the weak subjectivity checkpoints are no longer required for determining the canonical chain.

Halt the importing of POW blocks

Scenario as mentioned below
Visual of POW blocks being built beyond the Terminal POW Block

Suppose that the part of the client software that is connected to the beacon chain network goes offline before the Execution layer hits TTD & stays offline while the network meets this threshold. Such an event makes client software unable to switch to POS and allows it to keep following the POW chain if this chain is being built beyond the terminal POW block. Based on how long the Beacon chain part was offline, It could result in different adverse effects such as:

- The client has no post state for terminal POW block (the state has been pruned) which prevents it from doing the re-org to the POS chain. The only option to recover is to sync from scratch.

- An application, user or service uses data from the wrong fork (POW chain that is being built beyond the Terminal POW block) which can subvert the security of the network.

Thus, not importing blocks that are beyond the terminal POW block prevents these adverse issues on safety/re-org in the event of software/configuration failure in favour of liveness failure.


The value of Fork_Next in EIP-2124 refers to the block number of the next fork a given node knows about and 0 otherwise.

The number of Transition_Block cannot be known ahead of time given the dynamic nature of the transition trigger condition. As the block will not be known prior, nodes cant use its number for Fork_Next and in light of this fact, an explicitly set Fork_Next_Value is used instead.

EIP 2124 / 3675 ???? ####

Changes mentioned in this EIP target a minimal requisite set of consensus and client software modifications to safely replace the existing proof-of-work consensus algorithm with proof-of-stake consensus represented by the already in-production beacon chain.

This EIP was designed in a way to minimize the complexity of hot-swapping the live consensus of the Ethereum network. Both the safety of the operation and time to production were taken into consideration. Moreover, a minimal change set helps to ensure that most smart contracts and services will continue to function as intended during and after the transition with little to no required intervention.

Replacing block fields with constraints

Deprecated block fields are replaced with constant values to ensure block format remains backwards compatible. Preserving the block format aids existing smart contracts and services in providing uninterrupted services during and after the transition.

Replacing difficulty with 0

After deprecating POW, the notion of difficulty no longer exists and replacing block header difficulty with 0 constraints.

Changing block validity rules

Rule set -> enforcing POW validity -> replaced with POS rules along with consensus upgrade.

Removing block rewards

Existing rewards for producing and sealing blocks are deprecated along with POW mechanism. The new POS consensus becomes responsible for both sealing and issuing block rewards once this specification enters into effect.

Supplanting fork choice rule

The fork choice rule of POW mechanism becomes completely irrelevant after the merge upgrade and it is replaced with new rule of the POS Consensus mechanism.

Removing Block Gossip

After the upgrade of the Consensus mechanism (Bellatrix), only the beacon chain network will have enough information to validate a block. Thus, Block gossip provided by Ethereum network protocol will become unsafe and is deprecated in favour of the block gossip existing in the beacon chain network.

Restrict the length of extraData

This EIP restricts the length of extraData to 32 bytes

Backwards Compatibility

Introduces backward incompatibility in block validation, the block reward and fork choice rule.

Transition Process

Client software doesn't process any POW block beyond a terminal POW block.

Beginning with theTransition_Block, client software applies new block validity rules.

Starting with the first POS_FORKCHOICE_UPDATED, client software switches its fork choice rule to POS LMD-GHOST.

The Transition_Block must be a child of the Terminal POW block.

3 views0 comments

Recent Posts

See All



bottom of page