Ethereum Foundation | What impact will there be on the application layer if successful transition to PoS next year?
This article is translated from an Ethereum Foundation article. The original article can be found here.
Ethereum's transition to Proof of Stake (PoS) is imminent with The Merge: the current Devnet developer community has been established, and the specifications have been finalized, eagerly awaiting to be shared with the community. The Merge is designed to minimize the impact on end-users, smart contracts, and decentralized applications (dapps). In other words, only minor changes are worth noting. Before we delve deeper, you can gain background knowledge from the following links:
This article assumes that readers already have the basic knowledge mentioned above. For a more in-depth understanding, you can refer to the complete specifications from the following content:
Advertisement - Continue scrolling for more content
Table of Contents
Block Structure
After the merge, blocks with proof of work will no longer exist on the network. Instead, the content of past proof of work will become components for creating blocks on the Beacon Chain. Think of the Beacon Chain as a new Ethereum proof-of-stake consensus layer that replaces the previous proof-of-work consensus layer. Beacon Chain blocks will contain ExecutionPayloads, which are equivalent to blocks on the current proof-of-work chain after the merge. The diagram below illustrates this:
For end-users and application developers, these ExecutionPayloads refer to where interactions with Ethereum occur. Transactions at this layer will still be handled by clients of the execution layer such as Besu, Erigon, Geth, Nethermind, etc. The benefit is that due to the stability of the execution layer, the merge will only bring minimal disruptive changes.
Mining and Ommer Block Fields
After the merge, many fields containing the block header of proof of work will be deprecated as they are irrelevant to proof of stake. To minimize impact on tools and infrastructure, these fields will be set to 0 or a homogenous equivalent of their data structure, rather than being completely removed. For full block field changes, refer to EIP-3676.
Since proof of stake does not naturally produce Ommers (uncle blocks) as proof of work does, the ommer lists in each block will be empty, and the hash of these ommer lists will become a set of empty lists encoded in RLP (Recursive Length Prefix) hash. Similarly, because difficulty and nonce are primary features of proof of work, they will be set to 0 to represent byte values.
mixHash is another field related to mining that will not be set to 0 but will contain the RANDAO value from the Beacon Chain. More details below.
Change in BLOCKHASH and DIFFICULTY Opcodes
Post-merge, the BLOCKHASH opcode can still be used, but its pseudo-randomness provided by the hashing process of proof of work will be significantly weakened.
Additionally, the DIFFICULTY opcode 0x44 will be updated and renamed to RANDOM. Post-merge, it will return a random beacon output value provided by the beacon chain. This opcode will be more powerful for application developers compared to BLOCKHASH as it serves as a subjective source of randomness.
The value produced by RANDOM will be stored in ExecutionPayloads, where it was previously related to mixHash and proof of work calculations. The mixHash field in the payload will also be renamed to random.
The image below shows how the DIFFICULTY and RANDOM opcodes operate before and after the merge:
Prior to the merge, opcode 0x44 returned the difficulty field from the block header. Post-merge, the opcode that previously pointed to the mixHash header field will be renamed to RANDOM and will be responsible for storing the random value from the beacon chain state.
This change, outlined in EIP-4399, allows on-chain applications to assess if the merge has occurred. According to the EIP:
Furthermore, the improvements proposed by this change will enable smart contracts to determine if the PoS upgrade has occurred by analyzing the value returned by the DIFFICULTY opcode. When the value exceeds 2**64, it indicates transactions have been executed in a PoS block.
Block Time
The merge will impact the average block time of Ethereum. Currently under proof of work, the average block time is approximately 13 seconds, with variations in actual times. Under proof of stake, blocks will be produced exactly every 12 seconds, unless validators go offline and fail to submit a block in time, causing them to miss a slot. In practice, such occurrences are less than 1% of all slots.
This means the overall network average block time will decrease by about one second. Smart contracts that rely on specific average block times will need to take this into consideration.
Secure Head Blocks and Finalized Blocks
Under proof of work, reorgs are possible. Applications typically wait for several blocks after a new head block to confirm it will not be removed from the canonical chain, or "block confirmation." Post-merge, the concepts of "finalization" and secure head blocks will no longer exist. Blocks can be more reliably used compared to proof of work's "block confirmation," but they also require understanding and adaptation for proper usage.
A finalized block is one accepted by over two-thirds of validators on the main chain. To create a conflicting block, an attacker would need to destroy at least one-third of the total stake. At the time of writing, this equates to over $10 billion on Ethereum or more than 2.5 million ETH.
A safe head block is one that, under normal network conditions, is expected to be included in the main chain. Assuming network latency is less than four seconds, there are honest majority validators, and no one chooses to attack with fork rules, the safe head block will never be orphaned. The calculation of safe head blocks in various scenarios can be seen here. These safe head blocks are assumed and guaranteed and have been formally defined and analyzed in upcoming reports.
Post-merge, APIs of the execution layer like JSON RPC will default to returning the safe head block when requesting the latest block. Under normal network conditions, the safe head block will align with the actual latest chain, catching up within seconds. Unlike the current latest block under proof of work, the safe head block is less likely to be part of a block reorg. To indicate the actual latest state on the proof of stake chain, JSON RPC will add an "unsafe" tag.
Next Steps
We hope this article helps application developers prepare for the anticipated transition to proof of stake. In the coming weeks, long-standing testnets will be available for broader community testing. Communities supporting the merge will engage with infrastructure, tools, and application developers through calls to understand the latest technical updates on the merge. We look forward to connecting with you.