[ad_1]
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 becomes 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.
| Field | Constant value | Comment |
|---|---|---|
ommers |
[] |
RLP([]) = 0xc0 |
ommersHash |
0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 |
= Keccak256(RLP([])) |
difficulty |
0 |
|
nonce |
0x0000000000000000 |
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 RANDOM. 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 RANDOM 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 random.
Here is an illustration of how the DIFFICULTY & RANDOM 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 RANDOM, points to the header field which previously contained mixHash and now stores the random 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**64indicates 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.
Safe Head & Finalized Blocks
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 and safe head blocks. These blocks can be used even 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 stake. At the time of this writing, this represents over $10 billion (or >2.5 million ETH) on Ethereum.
A safe head block is one which, under normal network conditions, we 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 detailing how the safe head is calculated under various scenarios is available here. Additionally, the assumptions and guarantees of safe head are being formally defined and analysed in an upcoming paper.
Post-merge, execution layer APIs (e.g. JSON RPC) will return the safe head by default when asked for the latest block. Under normal network conditions the safe head and the actual tip of the chain will be equivalent (with safe head trailing only by a few seconds). Safe heads will be less likely to be reorged than the current proof of work latest blocks. To expose the actual tip of the proof of stake chain, an unsafe flag will be added to JSON RPC.
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:
| Block Type | Consensus Mechanism | JSON RPC | Conditions for reorg |
|---|---|---|---|
| head | Proof of Work | latest |
To be expected, must be used with care. |
| head | Proof of Stake | unsafe |
To be expected, must be used with care. |
| safe head | Proof of Stake | latest |
Possible, requires either large network delay or attack on network. |
| confirmed | Proof of Work | N/A | Unlikely, requires a majority of hashrate to mine a competing chain of depth > # of confirmations. |
| finalized | Proof of Stake | finalized |
Extremely unlikely, requires >2/3 of validators to finalize a competing chain requiring at least 1/3 to be slashed. |
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 for providing the core content of the “Safe Head” section and to Danny Ryan & Matt Garnett for reviewing drafts of this post.
[ad_2]
