How will Ethereum's transition to PoS "The Merge" affect the application layer?

星球君的朋友们

Odaily资深作者

2021-11-30 22:44 (UTC+8)

This article is about 2656 words, reading the full article takes about 4 minutes

The Merge is designed to transition with minimal impact on end users, how smart contracts and dapps operate.

AI Summary

Expand

The Merge is designed to transition with minimal impact on end users, how smart contracts and dapps operate.

source:

source:Official Ethereum Blog

The Ethereum network’s transition to proof-of-stake (The Merge) is imminent: the dev network is now being built, the specification is being finalized, and preparations for community outreach have begun in earnest. The Merge is designed to transition with minimal impact on end users, how smart contracts and dapps operate. That said, there are a few small changes worth highlighting along the way. Before we delve into the changes, here are some links that provide some insight into The Merge's overall architecture:

Roadmap Evolution
Merged Client Architecture

consensus layer

executive layer
consensus layer
block structure

1 block structure

After the Ethereum merger, Proof of Work (PoW) will no longer exist on the network. Instead, the former PoW portion will become an integral part of the blocks created on the Beacon Chain. You can then think of the beacon chain as a new PoS consensus layer for Ethereum, 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 diagram below shows this relationship:

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

2 Mining and Ommer block fields

After the merger, several fields that were previously included in PoW block headers are no longer used because they are not relevant to PoS. To minimize disruption to tools and infrastructure, these fields are set to 0, or their data structure equivalents, rather than removed from the data structure entirely. You can find the full changes to block fields in EIP-3675.

Because PoS does not naturally generate ommers (aka uncle blocks) like PoW, these lists in each uncle block (ommers) will be empty, and the hash of this list (ommersHash) will become an empty hash of the RLP encoded hash. list. Also, since the PoW also includes the difficulty and nonce, they will be set to 0 thereafter, giving them a byte size value.

BLOCKHASH & DIFFICULTY opcode changes

3 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 forged by PoW hashing procedures.

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

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

Here's an illustration of how the DIFFICULTY & RANDOM opcodes work before and after merging:

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

This change, formalized in EIP-4399, also provides on-chain applications with a way to assess whether a merge has occurred. According to the introduction of this EIP:

block time

4 block time

The merger will affect Ethereum's average block time. At present, under PoW, a block is produced every about 13 seconds on average, and the actual block interval time has considerable differences. Under proof-of-stake, the block interval will be exactly 12 seconds, unless a slot is missed because a validator went offline or because they didn't commit a block in time. In practice, this happens for slots<1%。

This translates to ~1 second reduction in the average block time on the network. Smart contracts that assume a certain average block time in their calculations need to take this into account.

5 safe head and final block

Under PoW, block reorganization is always possible. Applications typically wait for a few blocks to be mined on the new safe head before considering it unlikely to be removed from the canonical chain, or have been "confirmed". After merging, we have the notion of a final and secure head block. These blocks can be used more reliably than "confirmed" PoW blocks, but require a change in understanding to be used correctly.

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

A safe head is a block that we would like to include in the canonical chain under normal network conditions. Assuming the network latency is less than 4 seconds, most validators are honest, and there is no attack on the fork choice rule, then the safe head will never become an orphan block. A presentation detailing how safe heads are calculated in various situations is available here. Furthermore, the assumptions and guarantees of the safe head will be formally defined and analyzed in an upcoming paper.

After the merge, execution layer APIs (such as JSON RPC) will default to returning safe heads when asked for the latest block. Under normal network conditions, the safe head and the actual top of the chain will be equivalent (safe head and tail for only a few seconds). The safe head is less likely to be reorganized compared to 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 exposed via JSON RPC, via a new finalized flag. These can then serve as stronger alternatives to PoW proofs. The table below summarizes this:

Next step