What impact will the Merge of Ethereum PoW and PoS have on the application layer?

The Ethereum network’s transition to Proof of Stake (The Merge) is almost here: the development network is being established, the spec is being finalized, and community outreach preparations have begun in earnest. The Merge is designed to transition with minimal impact on end users, smart contracts, and the way dapps operate. That said, there are some small changes along the way that are worth highlighting. Before we dive into those changes, here are some links that provide some insight into the overall architecture of The Merge:

• Roadmap Evolution‌

• Merged Client Architecture‌

The rest of this article will assume the reader is familiar with the above. For those who want to dig deeper, the full specification of The Merge is available below:

• Execution Layer

• Consensus Layer

• Engine API

Block structure

After the Ethereum merger, there will no longer be proof of work (PoW) on the network. Instead, the previous PoW part will become an integral part of the blocks created on the Beacon Chain. You can then think of the Beacon Chain as Ethereum's new PoS consensus layer, replacing the previous PoW consensus layer. Beacon chain blocks will contain ExecutionPayloads, which are the merged equivalent of blocks on the current PoW chain. The following diagram shows this relationship:

For end users and application developers, these ExecutionPayloads are where they interact with Ethereum. 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 and Ommer Block Fields

After the merger, several fields previously included in the PoW block header are no longer used because they are not relevant to PoS. In order to minimize disruption to tooling and infrastructure, these fields are set to 0, or their data structure equivalent, rather than being completely removed from the data structure. You can find the full changes to the block fields in EIP-3675.

Because PoS does not naturally generate ommers (aka uncles) like PoW does, these lists in each uncle block (ommers) will be empty, and the hash of this list (ommersHash) will be an empty list of RLP encoded hashes. Similarly, because PoW also includes difficulty and random numbers, they will be set to 0 from now on, and they will be given a byte size value.

Another mining-related field, mixHash, will not be set to 0, but will contain the RANDAO value of the beacon chain. More on this below.

BLOCKHASH & DIFFICULTY opcode changes

After the merge, the BLOCKHASH opcode will still work, but the pseudo-randomness provided by this opcode will be much weaker given that it is no longer forgeable via the PoW hashing process.

Relatedly, the DIFFICULTY opcode (0x44) will be updated and renamed to RANDOM. Once merged, it will return the output of the randomness beacon provided by the beacon chain. As a result, this opcode will be a more powerful source of randomness for application developers to use compared to BLOCKHASH, although there will still be bias.

The RANDOM exposed value will be stored in the ExecutionPayload, where the mixHash value related to the PoW calculation is stored. The mixHash field of the Payload will also be renamed to random.

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

Before the merge, we saw that the 0x44 opcode returned the difficulty field in the block header. After the merge, the opcode renamed to RANDOM points to the block header field that previously contained mixHash and now stores a random value from the beacon chain state.

This change was formalized in EIP-4399, which also provides a way for on-chain applications to evaluate whether a merge has occurred. According to this EIP:

Additionally, the changes proposed by this EIP allow smart contracts to determine if an upgrade to PoS has occurred. This can be done by analyzing the return value of the DIFFICULTY opcode. If the value is greater than 2**64, it means that the transaction is being executed in a PoS block.

Block time

The merger will impact Ethereum’s average block time. Currently under PoW, a block is produced every ~13 seconds on average, with considerable variation in actual block interval times. Under Proof of Stake, the block interval will be exactly 12 seconds, unless a slot is missed due to a validator being offline or because they did not submit a block in time. In practice, this happens in <1% of slots.

This means that the average block time on the network has decreased by about 1 second. Smart contracts that assume a specific average block time in their calculations need to take this into account.

Safe Head and Final Block

Under PoW, block reorganizations are always possible. Applications typically wait for a few blocks to be mined on a new head block (safe head) before considering it unlikely that the block will be removed from the canonical chain, or "confirmed". After the merger, we have the concept of final and safe head blocks. These blocks can be used more reliably than "confirmed" PoW blocks, but require a change in understanding to use them correctly.

A finalized block is one that is accepted as canonical by more than 2/3 of validators. To create a conflicting block, an attacker would have to destroy at least 1/3 of the total ETH staked, which at the time of writing means more than $10 billion (or >2.5 million) of ETH.

A safe head block is a block that we expect to be included in the canonical chain under normal network conditions. Assuming network latency is less than 4 seconds, most validators are honest, and there are no attacks on the fork choice rule, the safe head will never be orphaned. A presentation detailing how to calculate the safe head in various situations is available here. In addition, the assumptions and guarantees of the safe head will be formally defined and analyzed in an upcoming paper.

After the merger, the execution layer API (such as JSON RPC) will return the safe head by default when asking for the latest block. Under normal network conditions, the safe head and the actual tip of the chain will be equivalent (the safe head is only a few seconds behind). The safe head is less likely to be reorganized than the current PoW latest block. In order to expose the actual tip of the PoW chain, an unsafe flag will be added to JSON RPC.

Finalized blocks will also be made public via JSON RPC, via a new finalized flag. These can then serve as a more powerful alternative to PoW proofs. The following table summarizes this:

Block Type Consensus Mechanism JSON RPC Conditions for reorganization headPoWlatest Can be expected, must be used with caution headPoSunsafe Can be expected, must be used with caution safe headPoSlatest Can happen, but requires large network delays or attacks on the network to achieve. confirmedPoWN/A is unlikely to happen, because most of the computing power is needed to mine a depth > # confirmed competing chain. finalizedPoSfinalized is extremely unlikely to happen, because more than 2/3 of the validators are needed to complete a competing chain, and at least 1/3 need to be cut.

Next step

We hope this post helps application developers prepare for the much-anticipated PoS transition. In the coming weeks, a testnet will be available for the wider community to test. There is also an upcoming The Merge community call for infrastructure, tooling, and application developers to ask questions and hear the latest technical updates about The Merge.

-------------------------------------------------- ----------------------------------

Thanks to Mikhail Kalinin for providing the core content of the "Safe Head" section, and to Danny Ryan and Matt Garnett for reviewing drafts of this article.

Source: Ethereum Official Blog

(https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/)

Author: Tim Beiko, Ethereum developer and community manager of the Ethereum Foundation