EIP-3675 Switching Consensus to Proof-of-Stake (Upgrade consensus to Proof-of-Stake)
Final · Consensus & staking · EIP status Final · created 2021-07-22
Ends proof-of-work (PoW) mining and replaces Ethereum mainnet's consensus mechanism with proof-of-stake (PoS) led by the beacon chain. It specifies the changes to the block structure, validity checks, fork choice rules, and network behavior needed for this.
Why it is needed
Ethereum has so far produced blocks and secured the chain with Proof-of-Work, that is, a competition of computing power. Meanwhile, the beacon chain, which runs Proof-of-Stake, has operated separately since December 2020, and no safety or liveness issue has been found during that time. Based on this incident-free record, the original text states that the beacon chain is ready to take responsibility for the security of Ethereum mainnet. However, because this replaces the consensus machinery of a live network as a whole, this EIP is designed to change only what must change, which secures both the safety of the work and the timing of its rollout. In particular, because the block format is kept as is, most smart contracts and services keep working with almost no changes, both during and after the transition.
What changes
Today
- Miners produce blocks through proof-of-work (a hash computation race), and the chain with the most accumulated computation becomes canonical.
- The miner who produced a block and the uncle block submitters receive block rewards on the execution layer.
- PoW-specific fields such as difficulty, nonce, mixHash, and the uncle list hold meaningful values.
- New blocks spread through the block gossip messages of the eth protocol.
After EIP-3675
- Beacon chain proof-of-stake handles block production and validation, and the PoS fork choice (LMD-GHOST) decides the canonical chain.
- Block and uncle rewards on the execution layer disappear, and reward issuance is handled by PoS consensus. Fee handling stays the same.
- PoW-specific fields are fixed to set constants, and the block format itself does not change.
- Block propagation moves to the gossip of the beacon chain network, and the existing block gossip messages are phased out.
Who is affected
- Users: Because the block format is kept, ordinary users have nothing special to do during the transition.
- Smart contract and app developers: The DIFFICULTY opcode always returns 0, and pseudorandomness obtained from BLOCKHASH becomes less safe under PoS, so code that depends on them needs to be checked.
- Client teams: Block validity rules, fork choice, network message handling, and fork identifier configuration must all be changed according to this specification.
- Miners and validators: Proof-of-work mining and its rewards are retired, and the block production role passes to beacon chain validators.
In depth
Transition trigger: terminal PoW block and total difficulty
A terminal PoW block is a PoW block whose total_difficulty is greater than or equal to TERMINAL_TOTAL_DIFFICULTY and whose parent's total_difficulty is below it. The mainnet value is 58750000000000000000000. Several children of the same parent can satisfy the condition at the same time, so there may be more than one terminal PoW block. Total difficulty is used instead of block number to prevent attacks. With a height condition, an attacker with a small amount of hash power could build a malicious fork that only matches the height, propose the first PoS block on top of it, and undermine the security of the transition. Also, even if a minority sees a different terminal PoW block because of a temporary network partition, re-orgs between forks that satisfy the terminal block condition are allowed until FIRST_FINALIZED_BLOCK is received, which prevents an unrecoverable split.
Block structure: PoW fields fixed to constants
From TRANSITION_BLOCK onward, ommersHash is fixed to 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, the value of Keccak256(RLP([])), difficulty to 0, mixHash to 0x0000000000000000000000000000000000000000000000000000000000000000, nonce to 0x0000000000000000, and ommers to the empty list []. The extraData length must be at most MAX_EXTRA_DATA_BYTES (32 bytes). The fields are turned into constants rather than deleted to preserve backward compatibility of the block format. Contracts that verify Merkle proofs of transactions, receipts and state by matching the hash of an externally supplied block header against the BLOCKHASH result keep working unchanged after the transition. A later EIP can redefine these constant values to provide new features, and EIP-4399 is an example.
Validity rule changes and reward removal
From TRANSITION_BLOCK onward, the difficulty formula check, the nonce and mixHash checks based on the Ethash function, and all validation rules for the ommer list and its members are removed. The constant-field checks above are added instead, and a block is invalid if it violates any of the new rules. TRANSITION_BLOCK must be a child of a terminal PoW block. Rewards change as well. Increasing the beneficiary account balance with the block reward, the reward for including ommers, and the ommer reward paid to the beneficiary of an ommer block are all removed. However, transaction fees still go to the beneficiary account as before. PoS consensus takes over responsibility for sealing blocks and issuing rewards.
Fork choice: LMD-GHOST and no optimistic updates
From the first POS_FORKCHOICE_UPDATED event onward, the PoW heaviest chain rule is removed and the PoS LMD-GHOST rule is followed. Each time an event occurs, the chain from genesis to the head named by the event is treated as the canonical chain, and from FIRST_FINALIZED_BLOCK onward the latest finalized block is also set as the event names it. Before the first finalization, the finalized block hash in the event is the stub 0x00...00. Changes to the block tree store must be applied atomically, and even if a new block was processed on top of the current head, it must not be promoted to head without an event (no optimistic updates). The POS_CONSENSUS_VALIDATED event in the draft was an unnecessary optimization and was removed because it is dangerous: the same block can receive different verdicts on two conflicting PoS branches.
Network: phasing out block gossip and the fork identifier
NewBlockHashes (0x01) and NewBlock (0x07) messages announcing descendants of a terminal PoW block SHOULD NOT be sent. After FIRST_FINALIZED_BLOCK is received, incoming messages of this kind MUST be dropped, and from the next finalized block onward the message handlers themselves must be removed. Peers that keep sending them after that are recommended to be disconnected. After the transition only the beacon chain network has the information needed to validate blocks, so block gossip in the eth protocol becomes unsafe and is deprecated. Meanwhile, FORK_NEXT in the EIP-2124 fork identifier must be the block number of the next fork, but because the transition condition is dynamic the TRANSITION_BLOCK number cannot be known in advance, so an explicitly chosen FORK_NEXT_VALUE is used instead.
Emergency accelerator: overriding TERMINAL_BLOCK_HASH
Two emergency situations that require accelerating the transition are considered. If the hash rate drops sharply and the transition is delayed significantly, TERMINAL_TOTAL_DIFFICULTY can be lowered to a value from an earlier point and FORK_NEXT_VALUE adjusted to match. In the more serious case where the PoW network is attacked before the transition, the terminal PoW block is designated by setting TERMINAL_BLOCK_HASH to a specific block hash and TERMINAL_BLOCK_NUMBER to that block's number. In that case the canonical chain must include the block with that hash at that height, which is similar to the block hash whitelist feature of existing clients. However, this approach causes significant liveness failures on mainnet, so it is considered only in the most extreme scenarios. If TERMINAL_BLOCK_HASH is the stub (0x00...00), the two parameters have no effect.
Impact on existing contracts and node operation
This EIP does not change the EVM directly, but it affects two areas. The DIFFICULTY opcode always returns 0 because the difficulty field is fixed to 0. Changing this opcode to return the beacon chain's randomness is being considered in a separate EIP. Pseudorandomness obtained from BLOCKHASH output becomes less safe as PoW, which reduced the malleability of block hashes, goes away. For node operators, unlike PoW, verifying the entire chain history is no longer required. PoS sync relies on a weak subjectivity checkpoint, a past snapshot shared by peers, so old blocks before it are not essential for determining the canonical chain. This EIP has been finalized as Final and applied to mainnet.