As the Ethereum Merge time node is approaching, today we will discuss what regulatory issues and application layer issues Ethereum will face after the merger.
On August 16, 2022, Ethereum co-founder Vitalik Buterin (V God) participated in the discussion on Twitter, "If the validators who have passed certain protocols (such as Lido, Coinbase, etc.) , How will the Ethereum community react” said that it will regard this review as an attack on Ethereum, and choose to destroy the pledged rights and interests of these validators through a broader consensus (social consensus).
The trigger for this discussion is that recently, the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC) added Tornado Cash-related Ethereum addresses to its list of sanctioned entities. However, the current sanctions are all at the centralized level, and technical sanctions cannot be imposed on the part of the smart contract that involves decentralization.
This shows that if the United States wants to completely sanction Tornado cash, it must control the underlying Ethereum chain.Then it leads to a question, if the US government regulates Ethereum, what will it face?
If the U.S. government wants to regulate Ethereum, the biggest possibility is to require large PoS pledge service providers to conduct protocol-level transaction reviews on Ethereum.simply put,
simply put,It is to monitor all the requests sent by the sanctioned address and reject all blocks containing transactions of the sanctioned address. When a block fails to pass more than 66% equity verification votes, all transaction requests of the block There will be a rollback, which means sanctioned addresses will not be able to perform any operations, and validators will not face any penalties.
Up to now, the amount of ETH pledged on the entire Ethereum network is about 13 million ETH, and the amount of ETH pledged through Lido has accounted for about 30.9%, Coinbase accounted for about 14.7%, and Kraken accounted for about 8.5%.
image description
Figure from Dune Analytics
In response to the above-mentioned possible situations, the Ethereum community launched a vote on Twitter to discuss what to do if OFAC regulates Ethereum through verification nodes. V God supports treating the above situation as an attack on Ethereum, and destroying the pledged rights and interests of these nodes through a broader consensus.
Next, let's talk about the application layer.
We mentioned in the previous article: According to the plan, Ethereum’s Merge is carried out on the principle of “minimum damage”, so that the originally running application client can switch to PoS without any sense. That said, despite being "minimally disruptive," there are a few small changes along the way that are still worth our attention. This section mainly introduces the aspects that we should pay attention to after the merger from the perspective of application development.
After the merger, the current Eth1 and Eth2 clients will become the execution layer and consensus layer (or engine) of Ethereum.This means that node operators for Eth1 or beacon chain clients will need to run the "other half" of the stack to get a fully validating node.text
image description
Merged client architecture. Image courtesy of Danny Ryan
block structure
When a merge occurs, the beacon node will monitor the current PoW chain and wait for it to reach a predefined total difficulty threshold, which is called TERMINAL_TOTAL_DIFFICULTY. That is, once the PoW chain produces a block with total difficulty >= TERMINAL_TOTAL_DIFFICULTY, it will be regarded as the last PoW block on the chain.
Subsequently, the data contained in the PoW block will become the data component of the beacon chain block, and the beacon chain can be regarded as a new PoS consensus layer of Ethereum, replacing the previous PoW consensus layer.
At the same time, when performing consensus verification, the beacon node will communicate with its execution engine (Ethereum client before upgrade) and ask it to generate or verify ExecutionPayloads. ExecutionPayloads contains information such as parent hash, state root, base fee, and list of transactions to execute.
Once these data are generated or verified, beacon nodes will share them with other nodes on the p2p network.
image description
Image courtesy of Danny Ryan
execution engine
After the merger, the execution engine is mainly responsible for state management, block creation and verification functions, and no longer includes any operations related to consensus. Therefore, the execution engine has been partially modified. These modifications are described in EIP-3675, mainly including the following three points:
First, some data fields of the block are modified.Set several PoW-related fields in the original block to 0 (or their data structure equivalents), specifically related to mining (difficulty, mixHash, nonce), uncle block rewards (ommers, ommersHash ). In addition, the length of extraData will also be limited to 32 bytes on the mainnet.
Second, since only the merged Beacon Chain can produce blocks, the execution engine will stop processing blocks and uncle block rewards.However, the transaction fee is still processed by it, that is, when the execution engine creates an ExecutionPayload, it needs to ensure that the initiators of all transactions can at least pay the current baseFeePerGas fee, and send the remaining transaction fee to feeReceipient. Note that feeReceipient refers to the Ethereum address before the upgrade, not the beacon chain validator address.
Finally, once PoS replaces PoW, the execution engine will no longer be responsible for broadcasting blocks, but will still broadcast transactions through the p2p network.The specific process is that first, the user sends the transaction to the consensus client through a local RPC request, where they will be packaged into the beacon block. The consensus clients will then broadcast the beacon block in their p2p network.
image description
Image courtesy of Danny Ryan
BLOCKHASH & DIFFICULTY opcode changes
After the merger, the BLOCKHASH opcode can still be used, but since it no longer generates the corresponding Hash value through proof of work, the pseudo-randomness provided by this opcode will be greatly weakened.
At the same time, the DIFFICULTY opcode (0x44) will be renamed to RANDOM and return the random value provided by the beacon chain. Therefore, this value will replace BLOCKHASH as a better source of randomness that application developers can use (although bias is still present).
The RANDOM value will be stored in the ExecutionPayload in place of the original mixHash, which is related to the proof-of-work calculation. This value was renamed to random after the upgrade.
image description
Image courtesy of Danny Ryan
Before merging, we see that the 0x44 opcode returns the difficulty field in the block header. After merging, the RANDOM opcode responsible for generating random numbers points to the original mixHash field, which is renamed random.
block time
The merger will affect Ethereum's average block time. Currently, under PoW, a block is produced every 13 seconds on average, but the actual block interval time will vary considerably due to network congestion. But under PoS, the block interval is fixed at 12 seconds, unless some extreme situations occur, such as: the verifier is offline or fails to submit the block in time and misses a certain slot.
references:
references:
