Impact of Merge on Ethereum’s Application Layer
Ethereum’s transition to proof-of-stake (The Merge) is approaching. The development net was launched, specifications were finalized, and community support began in earnest. Merge is designed to have minimal impact on how Ethereum works for end users, smart contracts, and Dapps. That said, there are a few minor changes worth highlighting. Before we dive in, here are a few links to provide context on the overall merge architecture:
The remainder of this post assumes the reader is familiar with the above. If you’re interested in learning more, check out The Merge’s full specs here.
block structure
After merging, the proof-of-work block no longer exists on the network. Instead, the contents of previous proof-of-work blocks become the building blocks of blocks produced 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. A beacon chain block contains: executable payload, which is the same after merging with the block in the current proof-of-work chain. The image below shows this relationship.
For end users and application developers: executable payload This is where interaction with Ethereum takes place. Transactions in this layer continue to 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 Omer Block sector
After the merge, several fields previously included in the Proof-of-Work block header are not used as they are not relevant to Proof-of-Stake. To minimize tool and infrastructure disruption, these fields are not completely removed from the data structure but are set to 0 or the equivalent value of the data structure. The full changes to the block fields can be found here: EIP-3675.
| field | constant value | comment |
|---|---|---|
| at last | () | RLP(()) = 0xc0 |
| Hash in the end | 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 | = Kechak256(RLP(())) |
| difficulty | 0 | |
| now | 0x0000000000000000 |
Since proof-of-stake does not naturally generate ommers (also known as uncle blocks) like proof-of-work, there is a list of these in each block (at last) is empty and the hash of this list (Hash in the end) becomes the RLP encoded hash of the empty list. Likewise, because difficulty and now The proof-of-work feature is set up as follows: 0Respects byte size values.
mixhashAnother mining-related field, is not set to 0 but instead contains the RANDAO value of the beacon chain. Find out more about this below.
block hash & difficulty opcode change
After merging, block hash The opcode will still be available, but given that it will no longer be forged through the proof-of-work hashing process, the pseudo-randomness it provides will be much weaker.
In relation to, difficulty Operation code (0x44) is updated and renamed to: Prebrandao. After merging, it returns the output of the randomness beacon provided by the beacon chain. This makes this opcode, while still susceptible to bias, a more powerful source of randomness for application developers to use. block hash.
exposed value Prebrandao It is saved in Execution payload where mixhashThe value associated with the proof-of-work calculation is stored. of payload mixhash The field names also change. PreviousRandao.
next difficulty & Prebrandao Opcodes operate before and after merging.
Pre-merge, we have 0x44 The opcode returns: difficulty This is a field in the block header. Post-merge (opcode) was renamed to: PrebrandaoPoints to a previously included header field. mixhash now PreviousRandao The value of the beacon chain state.
This change has been formalized in: EIP-4399, which also provides on-chain applications a way to evaluate whether a merge has occurred. In EIP:
Additionally, the changes proposed in this EIP will allow smart contracts to check whether a PoS upgrade has already occurred. This can be done by analyzing the return value. difficulty opcode. value greater than 2**64 Indicates that a transaction is being executed in a PoS block.
block time
Merges affect Ethereum’s average block time. Currently in Proof-of-Work, blocks come in on average every ~13 seconds, and there is significant variation in actual block times. In proof-of-stake, blocks come in exactly every 12 seconds, unless a validator is offline or doesn’t submit a block on time and a slot is missed. In fact, this currently occurs in less than 1% of slots.
This means that the network’s average block time is reduced by up to 1 second. Smart contracts that assume a certain average block time in their calculations must take this into account.
Completed block and safety head
Proof-of-work always has reconfigurability. Applications typically wait for several blocks to be mined on top of a new head before treating them as unlikely to be removed from the standard chain or “confirmed.” After The Merge we have the following concepts: confirmed blocks and safe head It is exposed to the execution layer. These blocks can be used more reliably than “confirmed” proof-of-work blocks, but their proper use requires a shift in understanding.
The final block is one that has been approved as standard by more than 2/3 of the validators. To create a conflicting block, an attacker would need to burn at least 1/3 of all staked ether. The stake amount can vary, but these attacks are always expected to cost the attacker millions of ETH.
all safe head A block is a block that already exists. justified This means that more than 2/3 of the validators have verified this by the beacon chain. Under normal network conditions, it is expected to be included in the official chain and finally confirmed. In order for this block to not become part of the standard chain, a majority of validators would have to collude to attack the network. Otherwise, the network will experience extreme levels of latency in block propagation. After merging, the execution layer API (e.g. JSON RPC) safe head using safe tag.
The final block is also exposed via JSON RPC. confirmed flag. This could then serve as a more powerful replacement for proof-of-work verification. The table below summarizes this.
| block type | consensus mechanism | JSON RPC | Reconstruction Conditions |
|---|---|---|---|
| head | proof of work | recent | As you can imagine, it must be used with caution. |
| safe head | proof of stake | safe | it’s possible. Either the network delay is high or an attack on the network is required. |
| Confirmed | proof of work | Not applicable | Although unlikely, mining a competing chain with a depth greater than the number of confirmations would require most of the hashrate. |
| confirmed | proof of stake | confirmed | In extremely rare cases, it takes more than 2/3 of the validators to finish a competing chain, with at least 1/3 being cut. |
Note: The JSON RPC specification is still under development. A name change is still expected.
next stage
We hope this post will help application developers prepare for the highly anticipated transition to proof-of-stake. A long-lived testnet will be available for testing by the broader community in the coming weeks. There is also something coming Community currency merge Infrastructure, tooling, and application developers can 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 post.
