The transition from Ethereum to POS (Proof of Rights and Interests)-the merger-is now in sight: the development network is being established, the specifications are being finalized, and the community publicity is already in full swing. The purpose of the merger is to minimize the impact on the operation of Ethereum’s end users, smart contracts and DApps, that is to say, there are some small changes worth highlighting. Before we dive into them, here are a few links to provide background on the overall merger architecture.
- Evolution of the roadmap
- Merged customer structure
The rest of this article will assume that the reader is familiar with the above content. For those who want to know more about it, the full specifications of The Merge can be found here.
- Executive layer
- Consensus layer
- API engine
After the merger, the POW (Proof of Work) block will no longer exist in the network, and the content of the previous POW chain will become part of the block created on the Beacon Chain. Then you can think that the Beacon chain has become the (proof of stake) consensus layer of the Ethereum POS chain, replacing the previous proof of work consensus layer. The beacon chain block will contain ExecutionPayloads, which is the equivalent of the block on the current proof-of-work chain after the merger.
The picture below shows this relationship.
For end users and program developers, these ExecutionPayloads are where they interact with Ethereum. Transactions at this level will still be processed by the execution level clients (Besu, Erigon, Geth, Nethermind, etc.). Fortunately, due to the stability of the execution layer, the merger brings only minimal destructiveness.
Mining and Ommer block farm
After the merger, several fields previously contained in the proof of work block header become unusable because they have nothing to do with POS (Proof of Stake). In order to minimize interference with tools and infrastructure, these fields are set to 0, or their data structure equivalents, rather than completely deleted from the data structure. Please refer to EIP-3675 for details about the modification of the block field.
Since POS (Proof of Rights) does not naturally generate omers (also known as uncle blocks) like POW (Proof of Work), these lists (omers) in each block will be empty, and the hash value of this list (omersHash) ) Will become the RLP-encoded hash value of an empty list. Similarly, since difficulty and nonce are characteristics of POW (Proof of Work), they will all be set to 0 considering their byte size value.
mixHash, another field related to mining, will not be set to 0, but will contain the RANDAO value of the beacon chain.
For more details on this, please see the following chapters.
BLOCKHASH and DIFFICULTY opcode changes
After the merger, the BLOCKHASH opcode can still be used, but since it can no longer be forged through the proof-of-work hash calculation process, the pseudo-randomness provided by the opcode will be greatly reduced.
Related to this, the DIFFICULTY opcode (0x44) will be upgraded and renamed RANDOM. After merging, it will return the random beacon output provided by the beacon chain. Therefore, this opcode will become a more powerful (albeit still biased) source of randomness for program developers than BLOCKHASH.
The value exposed by RANDOM will be stored in ExecutionPayload, where mixHash is a value related to the proof-of-work calculation. The mixHash field of the payload will also be renamed to random.
Below is an explanation of how the DIFFICULTY and RANDOM opcodes work before and after the merge.
Before merging, we see that the 0x44 opcode returns the difficulty field in the block header. After the merger, the opcode was renamed RANDOM, pointing to the block header field that previously contained mixHash, and now stores the random value from the state of the beacon chain.
The change formalized in EIP-4399 also provides a method for on-chain applications to assess whether a merger has occurred.
In addition, the changes proposed in 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. A value greater than 2**64 indicates that the transaction is being executed in the PoS block.
The merger will affect the average block time of Ethereum. At present, under POW (Proof of Work), on average, a block is entered every 13 seconds (the actual block time is somewhat different), and under POS (Proof of Stake), a block is entered every 12 seconds, unless it is due to The validator was offline or missed a time period without submitting the block in time. In practice, this situation has only occurred in <1% of the time.
This means that the average block time on the network will be reduced by 1 second, and those smart contracts that need to calculate a specific average block time will need to take this into consideration.
Safety header block and finalized block
Under POW (Proof of Work), there is always a possibility of rearrangement. The application usually waits for a few blocks to be mined on a new head, and then treats it as unlikely Remove from the recognized chain, or “confirm”. After the merger, we instead have the concepts of finalized and safe head. These blocks can even be used more reliably than “confirmed” POW (Proof of Work) blocks, but the concept needs to be changed to use them correctly.
A final block is accepted as a recognized block by more than 2/3 of the validators. To create a conflicting block, the attacker must burn at least 1/3 of the total stake. At the time of writing this article, this represents more than $10 billion (or more than 2.5 million ETH) on Ethereum.
The security header block refers to the block that we expect to be included in the recognized chain under normal network conditions. Assuming that the network delay is less than 4 seconds, most validators are honest, and there is no attack on the fork selection rule, the security head will never become an orphan.
Here is a report detailing how to calculate the safety head in various situations. In addition, the assumptions and guarantees of the security header block are being formally defined and analyzed in an upcoming paper.
After the merger, the execution layer API (such as JSON RPC) will return the security header by default when asking for the latest block. Under normal network conditions, the security head and the actual top of the chain will be equal (the security head block is only a few seconds behind). The security header will be less likely to be resuspended than the latest block of the current POW (Proof of Work). In order to expose the actual top end of the POS (Proof of Stake) chain, an unsafe flag will be added to the JSON RPC.
The finalized block (finalized) will also be made public through JSON RPC with a new finalized flag. Then, these can be used as a more powerful substitute for proof of work confirmation.
The table below summarizes this.
We hope this article will help program developers prepare for the highly anticipated transition to the POS (Proof of Stake) stage.
In the coming weeks, a long-standing testnet will be made available to the wider community for testing, as well as an upcoming merged community conference call on infrastructure, tools, and application developers’ questions, and listen to The latest technical update on the merger.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/how-will-the-transition-and-merger-of-ethereum-to-pos-affect-the-application-layer/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.