How The Merge Impacts Ethereum’s Application Layer

Ethereum’s transition to proof of stake — The Merge — is near: devnets are being stood up, specifications are being finalized and community outreach has begun in earnest. The Merge is designed to have minimal impact on how Ethereum operates for end users, smart contracts and dapps. That said, there are some minor changes worth highlighting. Before we dive into them, here are a few links to provide context about the overall Merge architecture:

The rest of this post will assume the reader is familiar with the above. For those wanting to dig even deeper, the full specifications for The Merge are available here:

Block structure

After The Merge, proof of work blocks will no longer exist on the network. Instead, the former contents of proof of work blocks become a component of blocks created on the Beacon Chain. You can then think of the Beacon Chain as becoming the new proof of stake consensus layer of Ethereum, superseding the previous proof of work consensus layer. Beacon chain blocks will contain ExecutionPayloads, which are the post-merge equivalent of blocks on the current proof of work chain. The image below shows this relationship:

For end users and application developers, these ExecutionPayloads are where interactions with Ethereum happen. Transactions on this layer will still be processed by execution layer clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, due to the stability of the execution layer, The Merge introduces only minimal breaking changes.

Mining & Ommer Block Fields

Post-merge, several fields previously contained in proof of work block headers become unused as they are irrelevant to proof of stake. In order to minimize disruption to tooling and infrastructure, these fields are set to 0, or their data structure’s equivalent, rather than being entirely removed from the data structure. The full changes to block fields can be found in EIP-3675.

Because proof of stake does not naturally produce ommers (a.k.a. uncle blocks) like proof of work, the list of these in each block (ommers) will be empty, and the hash of this list (ommersHash) will become the RLP-encoded hash of an empty list. Similarly, because difficulty and nonce are features of proof of work, these will be set to 0, while respecting their byte-size values.

mixHash, another mining-related field, won’t be set to 0 but will instead contain the beacon chain’s RANDAO value. More on this below.

BLOCKHASH & DIFFICULTY opcodes changes

Post-merge, the BLOCKHASH opcode will still be available for use, but given that it will no longer be forged through the proof of work hashing process, the pseudorandomness provided by this opcode will be much weaker.

Relatedly, the DIFFICULTY opcode (0x44) will be updated and renamed to PREVRANDAO. Post-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 an illustration of how the DIFFICULTY & PREVRANDAO opcodes work pre and post-merge:

Pre-merge, we see the 0x44 opcode returns the difficulty field in the block header. Post-merge, the opcode, renamed to PREVRANDAO, points to the header field which previously contained mixHash and now stores the prevRandao value from the beacon chain state.

This change, formalized in EIP-4399, also provides on-chain applications a way to assess whether The Merge has happened. From the EIP:

Additionally, changes proposed by this EIP allow for smart contracts to determine whether the upgrade to the PoS has already happened. This can be done by analyzing the return value of the DIFFICULTY opcode. A value greater than 2**64 indicates that the transaction is being executed in the PoS block.

Block time

The Merge will impact the average block time on Ethereum. Currently under proof of work, blocks come in on average every ~13 seconds with a fair amount of variance in actual block times. Under proof of stake, blocks come in exactly each 12 seconds 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 <1% of slots.

This implies a ~1 second reduction of average block times on the network. Smart contracts which assume a particular average block time in their calculations will need to take this into account.

Finalized Blocks & Safe Head

Under proof of work there is always the potential for reorgs. Applications usually wait for several blocks to be mined on top of a new head before treating it as unlikely to be removed from the canonical chain, or “confirmed”. After The Merge, we instead have the concepts of finalized blocks and safe head exposed on the execution layer. These blocks can be used more reliably than the “confirmed” proof of work blocks but require a shift in understanding to use correctly.

A finalized block is one which has been accepted as canonical by >2/3 of validators. To create a conflicting block, an attacker would have to burn at least 1/3 of the total staked ether. While stake amounts may vary, such an attack is always expected to cost the attacker millions of ETH.

A safe head block is one which has been justified by the Beacon Chain, meaning that >2/3 of validators have attested to it. Under normal network conditions, we expect it to be included in the canonical chain and eventually finalized. For this block to not be part of the canonical chain, a majority of validators would need to be colluding to attack the network, or the network would have to be experiencing extreme levels of latency in block propagation. Post-merge, execution layer APIs (e.g. JSON RPC) will expose the safe head using a safe tag.

Finalized blocks will also be exposed via JSON RPC, via a new finalized flag. These can then serve as a stronger substitute for proof of work confirmations. The table below summarizes this:

Note: the JSON RPC specification is still under active development. Naming changes should still be expected.

Next Steps

We hope this post helps application developers prepare for the much-anticipated transition to proof of stake. In the next few weeks, a long-lived testnet will be made available for testing by the broader community. There is also an upcoming Merge community call for infrastructure, tooling and application developers to ask questions and hear the latest technical updates about The Merge. See you there 👋🏻

---

Thank you to Mikhail Kalinin, Danny Ryan & Matt Garnett for reviewing drafts of this post.