How Merging Affects Ethereum’s Application Layer

Ethereum’s transition to proof-of-stake – The Merge – is near: devnets are being created, specifications are being finalized, and community outreach has begun in earnest. The merger is designed to have minimal impact on the operation of Ethereum for end users, smart contracts and dapps. That said, there are a few minor changes worth noting. Before we get into them, here are some links to provide context on Merge’s overall architecture:

The remainder of this article will assume that the reader is familiar with the above. For those wanting to dig even deeper, The Merge’s full specs are available here:

Block structure

After the merge, proof of working blocks will no longer exist on the network. Instead, the old content of proof-of-work blocks becomes a component of the blocks created on the Beacon chain. You can then think of the Beacon Chain as becoming Ethereum’s new proof-of-stake consensus layer, replacing the previous proof-of-work consensus layer. Beacon chain blocks will contain Execution Payloadswhich are the post-merge equivalent of the current proof-of-work chain blocks. The image below shows this relationship:

For end users and application developers, these Execution Payloads This is where interactions with Ethereum occur. Transactions on this layer will always be processed by execution layer clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, due to the stability of the execution layer, The Merge only introduces minimal changes.

Mining fields and Ommer Block

After the merge, several fields previously contained in the headers of the proof-of-work blocks become unused because they are not relevant to the proof-of-stake. To minimize disruption to tools and infrastructure, these fields are set to 0, or the equivalent of their data structure, rather than being removed from the data structure entirely. Full changes to blocking fields can be found in EIP-3675.

Because proof of stake does not naturally produce ommers (aka uncle blocks) like proof of work, listing 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. Likewise, because difficulty And occasionally are proof of work elements, these will be defined on 0while respecting their byte size values.

mixHashanother mining related field, will not be set to 0 but will instead contain the RANDAO value from the tag string. More on this below.

BLOCHASH & DIFFICULTY opcode changes

After the merger, the BLOCHASH The opcode will still be available, but since it will no longer be tampered with through the proof-of-work hashing process, the pseudo-randomness provided by this opcode will be much lower.

In relation, the DIFFICULTY opcode(0x44) will be updated and renamed to PREVRANDAO. After merging, it will return the output of the random tag provided by the tag chain. This opcode will therefore be a stronger source of randomness, although still biased, that application developers will be able to use than BLOCHASH.

The value exhibited by PREVRANDAO will be stored in the Execution payload Or mixHasha value associated with the calculation of the proof of work, has been stored. Payload mixHash the field will also be renamed previousRandao.

Here is an illustration of how DIFFICULTY & PREVRANDAO opcodes work before and after merge:

Before the merger we see the 0x44 the opcode returns the difficulty field in the block header. After the merge, the opcode, renamed to PREVRANDAOpoints to the header field that previously contained mixHash and now stores the previousRandao tag string state value.

This change, formalized in EIP-4399also provides on-chain applications a way to assess whether the merge has occurred. From the PEI:

Additionally, the changes proposed by this EIP allow smart contracts to determine whether the upgrade to 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 executing in the PoS block.

Blocking time

The merger will impact the average block time on Ethereum. Currently under proof of work, blocks arrive on average approximately every 13 seconds with some variation in actual block times. Under proof of stake, blocks arrive exactly every 12 seconds, except when a slot is missed, either because a validator is offline or fails to submit a block on time. In practice, this currently occurs in <1% of locations.

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

Finalized blocks and sure head

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

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

A sure head the block is the one that was justified by the Beacon Chain, which means 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 not to be part of the canonical chain, a majority of validators would have to agree to attack the network, or the network would have to experience extreme levels of latency in the propagation of blocks. Post-merge execution layer APIs (e.g. JSON RPC) will expose the sure head using a on label.

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

Note: The JSON RPC specification is still under active development. Name changes are still to be expected.

Next steps

We hope this article helps app developers prepare for the long-awaited transition to proof-of-stake. In the coming weeks, a long-running testnet will be made available to the wider community for testing. There is also a next Merge Community Call allowing 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 article.