The transition from Ethereum to Proof of Stake – The Merge – is imminent: Devnets are being set up, specifications are being finalized and public relations have started in earnest. The merger is intended to have minimal impact on how Ethereum works for end users, smart contracts and dapps. Even so, there are a few minor changes that are worth highlighting. Before we get into that, here are a few links to provide context for the overall merge architecture:
The rest of this post assumes that the reader is familiar with the above. For those looking to dig deeper, the full specs for The Merge are available here:
Block structure
After the merger, there are no more proof of work in the network. Instead, the previous content of the proof of work becomes part of blocks that are created on the beacon chain. You can then think of the Beacon Chain as a new proof-of-stake consensus level from Ethereum, replacing the previous proof-of-work consensus level. Beacon chain blocks contain ExecutionPayloads, which are the post-merge equivalent of blocks in the current proof-of-work chain. The following picture shows this relationship:
For end users and application developers, these ExecutionPayloads are where interactions with Ethereum take place. Transactions at this level will still be processed by execution-level clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, The Merge introduces minimal breaking changes due to the stability of the execution layer.
Mining and Ommer Block Fields
After the merging, several fields that were previously contained in the headers of the proof of work are not used because they are irrelevant for the proof of the proportion. To minimize disruption to tools and infrastructure, these fields are set to 0 or the equivalent of their data structure, rather than being completely removed from the data structure. For full changes to block fields, see EIP-3675.
| Area | Constant value | comment |
|---|---|---|
| summer | [] | RLP ([]) = 0xc0 |
| summer hash | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 | = Keccak256 (RLP ([])) |
| difficulty | 0 | |
| not ce | 0x0000000000000000 |
Since the Proof of Stake does not of course generate ommer (also known as uncle blocks) such as proof of work, the list of these in each block (ommers) is empty and the hash of this list (ommersHash) becomes the RLP-encoded hash of an empty list. Since difficulty and nonce are features of the proof of work, these are set to 0, whereby their byte size values are respected.
mixHash, another mining-related field, is not set to 0, but instead contains the RANDAO value of the beacon chain. More on this below.
Changes to the opcodes of BLOCKHASH & DIFFICULTY
After merging, the BLOCKHASH opcode will still be available, but since it is no longer spoofed through the proof-of-work hashing process, the pseudo randomness provided by this opcode will be much weaker.
The DIFFICULTY opcode (0x44) is updated accordingly and renamed to RANDOM. After the merging, the output of the random beacon provided by the beacon chain is returned. This opcode will therefore be a stronger, if still distorting, source of randomness for application developers than BLOCKHASH.
The value provided by RANDOM is stored in the ExecutionPayload in which mixHash, a value that is linked to the calculation of the proof of work, was stored. The payload’s mixHash field is also renamed random.
Here is an illustration of how the DIFFICULTY & RANDOM opcodes work before and after the merge:
Before merging, we see that the 0x44 opcode is returning the difficulty field in the block header. Post-Merge, the opcode renamed RANDOM, points to the header field that previously contained mixHash and now saves the random value from the beacon chain state.
This change, formalized in EIP-4399, also provides on-chain applications with a way to assess whether the merger has taken place. From the EIP:
In addition, the changes proposed by this EIP will enable smart contracts to determine if the upgrade to the PoS has already occurred. 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 carried out in the PoS block.
Blocking time
The merge will affect the average block time of Ethereum. Currently under proof-of-work, blocks come every ~ 13 seconds on average with a significant variance in actual block times. With Proof of Stake, blocks come exactly every 12 seconds, except when a slot is missed, either because a validator is offline or because it does not submit a block on time. In practice, this currently happens in <1% of the slots.
This implies a reduction in the average block times in the network by ~ 1 second. Smart contracts that assume a certain average block time in their calculations must take this into account.
Safe head and completed blocks
Under Proof of Work there is always the potential for reorgs. Applications typically wait for several blocks to be mined on a new head before being deemed unlikely to be removed from the canonical chain or “acknowledged”. After The Merge, we have the concepts of finished and safer head blocks instead. These blocks can be used even more reliably than the “confirmed” proof of work blocks, but require an understanding shift to be used properly.
A completed block is a block that> 2/3 of the validators accepted as canonical. To create a contradicting block, an attacker would have to burn at least 1/3 of the entire stake. At the time of this writing, that equates to over $ 10 billion (or> 2.5 million ETH) on Ethereum.
A secure head block is one that, under normal network conditions, we would expect 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. A presentation on the calculation of the safe head in various scenarios can be found here. In addition, the assumptions and guarantees of a safe head will be formally defined and analyzed in a forthcoming paper.
After merging, execution layer APIs (e.g. JSON RPC) will by default return the safe head when asked for the latest block. Under normal network conditions, the safe head and the actual tip of the chain are equivalent (with the safe head only lagging a few seconds). Safe heads will be less likely to be reorganized than the newest blocks of the current proof of work. To expose the actual top of the proof-of-stake chain, an unsafe flag is added to JSON RPC.
Completed blocks are also made available via JSON RPC via a new finalized flag. These can then serve as a stronger substitute for work confirmations. The following table summarizes this:
| Block type | Consensus mechanism | JSON-RPC | Conditions for the reorganization |
|---|---|---|---|
| head | Proof of work | latest | To be expected, must be used with caution. |
| head | Proof of commitment | unsure | To be expected, must be used with caution. |
| sure head | Proof of commitment | latest | Possible, requiring either a large network delay or an attack on the network. |
| Confirmed | Proof of work | N / A | Unlikely, requires much of the hashrate to mine a competing chain with a depth of> # confirmations. |
| closed | Proof of commitment | closed | Highly unlikely, requires> 2/3 of the validators to complete a competing chain of which at least 1/3 must be truncated. |
Next Steps
We hope this post will help application developers prepare for the much anticipated transition to Proof of Stake. A long-lasting test network will be made available for testing by the wider community over the next few weeks. There is also an upcoming call from the Merge community for infrastructure, tool and application developers to ask questions and hear about the latest technical updates on The Merge. See you there
Thanks to Mikhail Kalinin for providing the core content of the Safe Head section and to Danny Ryan & Matt Garnett for reviewing the drafts of this post.
