Ethereum’s shift to proof of stake — The Merge — is approaching: development networks are being established, specifications are being completed, and outreach to the community has commenced in earnest. The Merge aims to have minimal repercussions on how Ethereum functions for end users, smart contracts, and decentralized applications (dapps). Nonetheless, there are a few subtle changes worth noting. Before we jump into those, here are some links to furnish context regarding the overall architecture of The Merge:
The remaining sections of this article will presume that the reader is knowledgeable about the aforementioned concepts. For anyone interested in delving further, the complete specifications for The Merge can be found here:
Block configuration
Following The Merge, proof of work blocks will be eliminated from the network. Instead, the earlier contents of proof of work blocks will form part of blocks generated on the Beacon Chain. One can consider the Beacon Chain as the new proof of stake consensus layer for Ethereum, replacing the preceding proof of work consensus layer. Blocks on the Beacon chain will include ExecutionPayloads, which are the post-merge equivalent of blocks on the existing proof of work chain. The illustration below depicts this relationship:
For end users and application creators, these ExecutionPayloads are where transactions with Ethereum take place. Transactions on this layer will continue to be managed by execution layer clients (Besu, Erigon, Geth, Nethermind, etc.). Thankfully, due to the reliability of the execution layer, The Merge brings about only limited breaking changes.
Mining & Ommer Block Fields
After the merge, multiple fields that were once present in proof of work block headers will become obsolete as they no longer apply to proof of stake. To avoid disruption to tools and infrastructure, these fields will be set to 0, or their structure’s equivalent, rather than being entirely expunged from the data format. The complete modifications to block fields can be referenced in EIP-3675.
| Field | Constant value | Comment |
|---|---|---|
| ommers | [] | RLP([]) = 0xc0 |
| ommersHash | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 | = Keccak256(RLP([])) |
| difficulty | 0 | |
| nonce | 0x0000000000000000 |
Since proof of stake does not inherently generate ommers (commonly known as uncle blocks) as proof of work does, the list of these in every block (ommers) will be nonexistent, and the hash of this list (ommersHash) will become the RLP-encoded hash of an empty list. In the same vein, because difficulty and nonce are characteristics of proof of work, these values will be set to 0, while still respecting their byte size.
mixHash, another field related to mining, will not be set to 0 but rather will contain the RANDAO value from the beacon chain. More on this follows below.
BLOCKHASH & DIFFICULTY opcode modifications
After the merge, the BLOCKHASH opcode will remain accessible, yet since it will no longer be generated through the proof of work hashing process, the pseudorandomness offered by this opcode will be notably weaker.
In relation, the DIFFICULTY opcode (0x44) will be revised and renamed to PREVRANDAO. Post-merge, it will output the randomness beacon’s result provided by the beacon chain. Consequently, this opcode will present a more robust, albeit still susceptible, source of randomness for application developers compared to BLOCKHASH.
The value revealed by PREVRANDAO will be stored in the ExecutionPayload where the mixHash, associated with proof of work calculations, was previously located. The payload’s mixHash field will also undergo a name change to prevRandao.
Here is a depiction of how the DIFFICULTY & PREVRANDAO opcodes operate before and after the merge:
Prior to the merge, the 0x44 opcode retrieves the difficulty field from the block header. After the merge, the opcode, now called PREVRANDAO, refers to the header field that once held mixHash and now retains the prevRandao value from the beacon chain state.
This modification, formalized in EIP-4399, also offers on-chain applications a method to verify if The Merge has occurred. From the EIP:
Furthermore, alterations suggested by this EIP enable smart contracts to ascertain whether the transition to PoS has already taken place. This can be achieved by examining the return value of the DIFFICULTY opcode. A value exceeding 2**64 denotes that the transaction is being carried out in a PoS block.
Block Duration
The Merge will affect the typical block duration on Ethereum. Currently operating under proof of work, blocks are generated approximately every ~13 seconds, with a significant degree of variability in actual block durations. Under proof of stake, blocks are generated precisely every 12 seconds unless a slot is missed due to a validator being offline or failing to submit a block timely. In reality, this is currently occurring in
This suggests an approximate ~1 second decrease in average block intervals on the network. Smart contracts that presume a specific average block duration in their computations will need to factor this in.
Finalized Blocks & Secure Head
Under proof of work, there is always a risk of reorganizations. Applications typically wait for several blocks to be mined on top of a new head before considering it improbable to be removed from the canonical chain, or “confirmed”. After The Merge, we instead have the concepts of finalized blocks and secure head made available on the execution layer. These blocks can be utilized more reliably than the “confirmed” proof of work blocks but necessitate a change in comprehension to apply correctly.
A finalized block is defined as one which has been recognized as canonical by over 2/3 of validators. To generate a conflicting block, an attacker would need to destroy at least 1/3 of the total staked ether. While stake amounts may fluctuate, such an assault is always anticipated to cost the attacker millions of ETH.
A secure head block is one which has been justified by the Beacon Chain, signifying that over 2/3 of validators have attested to it. Under standard network conditions, we expect it to be incorporated into the canonical chain and ultimately finalized. For this block to not be part of the canonical chain, a majority of validators would need to be colluding to compromise the network, or the network would have to be experiencing extreme delays in block propagation. Post-merge, execution layer APIs (e.g. JSON RPC) will reveal the secure head utilizing a secure tag.
Finalized blocks will also be made accessible through JSON RPC, utilizing a new finalized flag. These can then act as a stronger alternative for proof of work confirmations. The table below summarizes this:
| Block Type | Consensus Mechanism | JSON RPC | Conditions for Reorganization |
|---|---|---|---|
| head | Proof of Work | latest | As anticipated, must be handled with caution. |
| secure head | Proof of Stake | secure | Possible, necessitates either significant network lag or an attack on the network. |
| confirmed | Proof of Work | N/A | Improbable, requires a majority of hashrate to mine a competing chain of depth greater than the number of confirmations. |
| finalized | Proof of Stake | finalized | Highly unlikely, necessitates more than 2/3 of validators to finalize a conflicting chain, requiring at least 1/3 to be slashed. |
Note: the JSON RPC specification remains under active development. Changes in naming should still be anticipated.
Subsequent Steps
We hope this article aids application developers in getting ready for the eagerly awaited shift to proof of stake. In the coming weeks, a long-lasting testnet will be made available for testing by the wider community. There is also an upcoming Merge community call where infrastructure, tooling, and application developers can pose questions and receive the latest technical updates regarding The Merge. Looking forward to seeing you there 👋🏻
Thanks to Mikhail Kalinin, Danny Ryan & Matt Garnett for their contributions in reviewing drafts of this article.
