Ethereum’s transition to proof-of-stake, The Merge, is near: development networks are being raised, specifications are being finalized, and community outreach has begun in earnest. The Merge is designed to have minimal impact on the way Ethereum operates for end users, smart contracts, and dapps. That being said, there are a few minor changes worth noting. Before we dive into them, here are some links to provide context on the overall Merge architecture:
The remainder of this post will assume the reader is familiar with the above. For those who want to dig even deeper, the full specs for The Merge are available here:
block structure
After The Merge, proof-of-work blocks will no longer exist on the network. Instead, the old content of the proof-of-work blocks becomes a component of the blocks created on the Beacon Chain. So you can think of Beacon Chain as Ethereum’s new proof-of-stake consensus layer, replacing the old proof-of-work consensus layer. The blocks of the Beacon chain will contain ExecutionPayloads, which are the post-merge equivalent of blocks in the current proof-of-work chain. The following image shows this relationship:
For end users and application developers, these ExecutionPayloads they are where interactions with Ethereum occur. Transactions in 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.
Ommer Blocks and Mining Fields
After the merge, several fields previously contained in the proof-of-work block headers are no longer used, as they are irrelevant to proof-of-stake. To minimize disruption to tools and infrastructure, these fields are set to 0, or their data structure equivalent, rather than being removed from the data structure entirely. Full changes to the block fields can be found at EIP-3675.
| Field | constant value | Commentary |
|---|---|---|
| after all | () | RLP(()) = 0xc0 |
| after all Hash | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 | = Keccak256(RLP(())) |
| difficulty | 0 | |
| in the meantime | 0x000000000000000000 |
Because proof-of-stake does not naturally produce ommers (also known as uncle blocks) as proof-of-work, the list of these in each block (after all) will be empty, and the hash of this list (after all Hash) will be converted to the RLP-encoded hash of an empty list. Similarly, because difficulty Y in the meantime are proof-of-work features, will be set out in 0respecting their byte size values.
mixHash, another mining-related field, will not be set to 0, but instead will contain the RANDAO value of the beacon string. More on this below.
BLOCKHASH & DIFFICULTY opcode changes
After the merger, the BLOCKHASH The opcode will still be available for use, but since it will no longer be forged through the proof-of-work hashing process, the pseudo-randomness provided by this opcode will be much weaker.
Related, the DIFFICULTY opcode (0x44) will be updated and renamed to PREVRANDAO. After the merge, it will return the output of the beacon of randomness provided by the beacon chain. This opcode will therefore be a stronger, though still skewed, 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 the proof-of-work calculation, was stored. payload mixHash the field will also be renamed previousRandao.
Here is an illustration of how the DIFFICULTY & PREVRANDAO the opcodes work before and after the merge:
Pre-fusion, we see the 0x44 the opcode returns the difficulty field in the block header. Post-merge, the opcode, renamed to PREVRANDAOpoints to the header field that previously contained mixHash and now stores the previousRandao beacon chain status value.
This change, formalized in EIP-4399, it also provides on-chain applications with a way to test whether The Merge has occurred. From the EIP:
In addition, the changes proposed by this EIP allow smart contracts to determine if the PoS update has already taken place. This can be done by parsing the return value of the DIFFICULTY opcode. A value greater than 2**64 indicates that the transaction is running in the PoS block.
block time
The merger will affect the average block time on Ethereum. Currently, based on proof of work, blocks arrive on average every ~13 seconds with a large variance in actual block times. Under proof-of-stake, blocks arrive exactly every 12 seconds, except when a slot is lost because a validator is offline or fails to send a block on time. In practice, this currently happens in <1% of slots.
This implies a ~1 second reduction in average block times on the network. Smart contracts that assume a particular average block time in their calculations will need to take this into account.
Blocks finished and head safe
Under proof of work there is always the possibility of reorganizations. Applications typically wait for several blocks on top of a new head to be mined before considering it unlikely to be removed from the canonical chain or “committed”. After The Merge, we instead have the concepts of finalized blocks and safe head exposed in the execution layer. These blocks can be used more reliably than “confirmed” proof-of-work blocks, but they require a change in understanding to use them correctly.
A completed block is one that has been accepted as canonical by >2/3 of the validators. To create a conflicting block, an attacker would have to burn at least 1/3 of the total ether staked. While stake amounts may vary, such an attack is always expected to cost the attacker millions of ETH.
A safe head block is one that has been justified by Beacon Chain, which means >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 become part of the canonical chain, most validators would have to collude to attack the network, or the network would have to experience extreme levels of latency in block propagation. Post-merge runtime layer APIs (eg JSON RPC) will expose the safe head using a sure label.
Completed blocks will also be exposed via JSON RPC, via a new finalized flag. These can serve as a stronger substitute for proof-of-work confirmations. The following table summarizes this:
| block type | Consensus Mechanism | JSON RPCs | Conditions for reorganization |
|---|---|---|---|
| head | Work test | latest | As expected, it must be used with care. |
| safe head | proof of participation | sure | Possible, requires a large network delay or network attack. |
| confirmed | Work test | N/A | Unlikely, requires a majority hashrate to mine a competing chain of depth > # of commits. |
| finalized | proof of participation | finalized | Extremely unlikely, requires >2/3 of the validators to terminate a competing chain, requiring at least 1/3 to be removed. |
Note: The JSON RPC specification is still under active development. Name changes are yet to be expected.
Next steps
We hope this post helps app developers prepare for the long-awaited transition to proof-of-stake. In the coming weeks, a full-length testnet will be available for the community at large to test. there is also a next Merge community call for infrastructure, tool and application developers to ask questions and hear the latest technical updates on The Merge. See you there 👋🏻
Thanks to Mikhail Kalinin, Danny Ryan, and Matt Garnett for reviewing drafts of this post.
