How the merger affects Ethereum’s application layer

The transition of Ethereum to Proof of Stake-the merger-is coming: the development network is being established, the specifications are being finalized, and the community outreach has begun in earnest. The merger aims to have minimal impact on the way Ethereum is the end user, smart contracts, and dapps. In other words, there are some small changes worth highlighting. Before we dive into them, here are some links to provide context about the overall Merge architecture:

The rest of this article will assume that the reader is familiar with the above. For those who want to dig deeper, the full specifications of The Merge can be obtained here:

Block structure

After the merger, proof of work will no longer exist on the network. Instead, the previous proof-of-work content becomes an integral part of the blocks created on the beacon chain. Then, you can think of the beacon chain as Ethereum’s new proof-of-stake consensus layer, replacing the previous proof-of-work consensus layer.The beacon chain block will contain ExecutionPayloads, They are the merged equivalents of the blocks on the current proof-of-work chain. The following figure shows this relationship:

For end users and application developers, these ExecutionPayloads It is a place to interact with Ethereum. Transactions on this layer will still be processed by the execution layer clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, due to the stability of the execution layer, The Merge only introduced the least disruptive changes.

Mining and Ommer block area

After the merger, several fields previously included in the proof of work block header are no longer used because they have nothing to do with the proof of equity. In order to minimize damage to tools and infrastructure, these fields are set to 0, or their data structure equivalent, rather than completely deleted from the data structure.Complete changes to the block fields can be found in EIP-3675.

Because proof of equity does not naturally generate ommers (also known as uncle blocks) like proof of work, these lists in each block (ommers) Will be empty, and the hash of this list (ommersHash) Will become the RLP-encoded hash of the empty list.Same because difficulty with nonce Are features of the proof of work, these will be set to 0, And respect their byte size value at the same time.

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

BLOCKHASH & DIFFICULTY Opcode change

After the merger, BLOCKHASH The opcode can still be used, but considering that it is no longer forged through the proof-of-work hashing process, the pseudo-randomness provided by this opcode will be much weaker.

Relatedly, DIFFICULTY Opcode (0x44) Will be updated and renamed to RANDOMAfter merging, it will return the output of the random beacon provided by the beacon chain.Therefore, compared to application developers, this opcode will become a more powerful source of randomness, although there are still biases BLOCKHASH.

Exposed value RANDOM Will be stored in ExecutionPayload Where mixHash, A value related to the proof-of-work calculation is stored.Payload mixHash The field will also be renamed random.

This is a description of how DIFFICULTY & RANDOM The opcode works before and after the merge:

Before the merger, we saw 0x44 Opcode return difficulty The fields in the block header.After merging, the opcode is renamed to RANDOM, Points to the header field previously included mixHash Store now random The value from the state of the beacon chain.

This change is formalized in EIP-4399, It also provides a way for on-chain applications to evaluate whether a merger has occurred. From EIP:

In addition, the changes proposed by this EIP allow the smart contract to determine whether it has been upgraded to PoS. This can be done by analyzing the return value of the DIFFICULTY opcode.Value is greater than 2**64 Indicates that the transaction is being executed in the PoS block.

Block time

The merger will affect the average block time of Ethereum. At present, under the proof of work, the block appears every about 13 seconds on average, and the actual block time is quite different. Under Proof of Stake, a block occurs exactly once every 12 seconds, unless a certain time slot is missed because the verifier is offline or because they did not submit the block in time. In practice, this currently occurs in <1% of slots.

This means that the average block generation time on the network is reduced by about 1 second. Smart contracts that assume a specific average block time in the calculation need to take this into account.

Safety header and final block

With proof of work, it is always possible to reorganize. Applications usually wait for a few blocks to be mined on the new head, and then treat it as unlikely to be removed or “confirmed” from the canonical chain.After the merger, we have Finalize with Safety head Piece. These blocks can be used more reliably than “confirmed” work block proofs, but require a change in understanding to use them correctly.

The final block is the block accepted by more than 2/3 of the validators. To create a conflict block, the attacker must destroy at least 1/3 of the total stake. At the time of writing, this represents more than $10 billion (or >2.5 million ETH) in Ethereum.

A sort of Safety head A block is one that we want to be included in the specification chain under normal network conditions. Assuming that the network delay is less than 4 seconds, the majority of verifiers are honest and there is no attack on the fork selection rule, Safety head Never be an orphan.Provides a presentation detailing how to calculate the safety head in various situations hereIn addition, assumptions and guarantees Safety head It will be formally defined and analyzed in an upcoming paper.

After merging, the execution layer API (such as JSON RPC) will return Safety head By default, when requested latest Blocked.Under normal network conditions Safety head And the actual tip of the chain will be equivalent (the safety head only trails for a few seconds). Safety head Compared with the current proof of work, the possibility of reorganization is less latest Piece.In order to expose the actual tip of the proof-of-stake chain, a unsafe Flags will be added to JSON RPC.

The final block will also be exposed through JSON RPC, through a new finalized banner. These can then be used as stronger alternatives to proof of work. The following table summarizes this:

Next step

We hope this article can help app developers prepare for the much-anticipated Proof of Stake transition. In the next few weeks, a long-standing testnet will be available for testing by the wider community.There is coming soon Consolidate community calls For infrastructure, tool and application developers to ask questions and listen to the latest technical updates about The Merge. See: wave:

Thanks to Mikhail Kalinin for providing the core content of the “Safe Head” section, and thanks to Danny Ryan and Matt Garnett for reviewing the draft of this article.