# The Merge: Ethereum’s Transition to Proof of Stake The Ethereum Merge to Proof of Stake is the biggest upgrade in the history of the blockchain, aiming to make it more scalable, secure and efficient. *Published 2022-09-12* The Ethereum Merge to Proof of Stake is the biggest upgrade in the history of the blockchain. It is expected that the switch to proof of stake will make Ethereum less energy intensive and will reduce the energy consumption by approximately 99 percent. With the Merge, Ethereum is set to become more sustainable, secure and will allow the implementation of more scalable solutions. The blockchain is now ready to enter its next chapter, expected to occur in [the middle of September](https://www.ethernodes.org/merge) (around September 15th). ## What is Proof of Stake? Proof-of-stake (PoS) is a consensus mechanism that is more complex than proof-of-work and it took the Ethereum community years to research, develop and define it. In PoS, in order to achieve distributed consensus, validators stake capital in the form of ether (32 ethers) into a smart contract on Ethereum. It serves as a collateral and if the validator acts dishonestly or lazy, it can be destroyed. The validator’s job is to store data, process transactions, and add new blocks to the blockchain by ensuring that new blocks are valid. In the Proof-of-Work consensus, the miners prove they have capital at risk by expending energy. Here are some of the characteristics of Proof-of-Stake: - Efficiency: less computation power means less energy consumption - Lower entry barriers: stakers won’t need expensive hardware to participate - Better decentralization: due to the lower requirements to enter, more nodes are expected to take part in securing the network, reducing the risk of centralization - Strong security and defense: An attacker would need to hold 51% of the staked ETH to perform an attack on the network, making it more costly compared to proof-of-work. In addition, the community would have other tools to counter-attack and secure the blockchain ## The New Block Structure With the Merge, the Beacon Chain becomes the new proof of stake consensus layer of Ethereum, taking the place of the proof of work consensus layer. Proof of work blocks will not exist on the network and they will become a component of blocks created on the Beacon Chain. The blocks on the [new Beacon chain](https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer) will contain *ExecutionPayloads*, which are the post-merge equivalent of blocks on the current proof of work chain. ![Diagram of a post-Merge Ethereum block: the consensus layer holds slot, parent-root, state-root, signature, randao, graffiti and deposit-root fields alongside attestations, deposits and exits, and wraps the execution layer containing parent-hash, state-root, base-fee and the transaction list.]() Transactions on the execution layer will still be processed by clients like Besu, Geth, Nethermind, etc. so your API requests won’t change. Still, the Merge introduces minimal changes related to several fields previously contained in proof of work block headers that are irrelevant to proof of stake. In order to minimize disruption to tooling and infrastructure, these fields won’t be entirely removed from the structure, but their value will be set to 0 or their data equivalent. The full changes to block fields are described in [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675#block-structure). ![Table of the block header fields made constant after the Merge: ommersHash fixed to the Keccak256 of an empty RLP list, difficulty to 0, mixHash and nonce to zero, and ommers to an empty array.]() ## Opcodes Changes The Merge will also influence BLOCKHASH & DIFFICULTY opcodes. The BLOCKHASH opcode will still be available for use, but it will no longer be forged through the proof of work hashing process, making its pseudorandomness much weaker. The DIFFICULTY opcode (0x44) will be updated and renamed to PREVRANDAO. After the Merge, it will return the output of the randomness beacon provided by the beacon chain. This opcode will thus be a stronger, albeit still biasable, source of randomness for application developers to use than BLOCKHASH. The value exposed by PREVRANDAO will be stored in the ExecutionPayload where mixHash, a value associated with proof of work computation, was stored. The payload's mixHash field will also be renamed prevRandao. Here is how the two opcodes work pre and post-merge: ![Side-by-side diagram of a block before and after the Merge: the proof-of-work block nests the execution layer with a difficulty field, while the post-Merge block adds the consensus layer and replaces mixHash with prevRandao, so opcode 0x44 returns PREVRANDAO instead of DIFFICULTY.]() ## Finalized and Safe Head Blocks The Merge introduces the concepts of finalized and safe head blocks. These are new block types that are more reliable than the "confirmed" blocks in proof of work and are less likely to be reorged. A finalized block is one which has been accepted as canonical by more than 2/3 of validators. To create a conflicting block, an attacker would have to burn at least 1/3 of the total stake. A safe head block is one which, under normal network conditions, is expected to be included in the canonical chain. Assuming network delays of less than 4 seconds, an honest majority of validators and no attacks on the fork-choice rule, the safe head will never be orphaned. Execution layer APIs (e.g. JSON RPC) will expose the safe head and finalized tags that can then serve as a stronger substitute for proof of work confirmations. ![Table of Ethereum block types and their reorg risk: head (proof of work, JSON-RPC "latest") to be expected; safe head (proof of stake, "safe") possible under large network delay or attack; confirmed, unlikely without a majority of hashrate; and finalized ("finalized"), extremely unlikely without more than two thirds of validators.]() ## Fixed Block Time Under proof of work, Ethereum blocks come in on average every 13 seconds, but the actual block times may vary. The Merge will reduce the block time by approximately 1 second, setting it exactly on 12 seconds. This will be the rule except when a slot is missed either because a validator is offline or because they do not submit a block in time. In practice, this currently happens in less than 1% of slots. Note: Smart contracts which assume a particular average block time in their calculations will need to take this block time change into account. ## Crypto APIs is Ready for the Merge As a Crypto APIs’ customer you don’t need to do anything. We have already upgraded our Ethereum nodes to the latest versions and we have the Goerli testnet running live. You can check it out in our [block explorer](https://blockexplorer.one/ethereum/goerli). You can continue making API requests using the same endpoints and no code changes are required at the moment. --- More on the [Crypto APIs blog](https://cryptoapis.io/blog), or see the [products](https://cryptoapis.io/products) this is built on.