In -depth analysis of regulatory and application layer issues after Ethereum merger

As the Ethereum Merge time node is approaching, today we will discuss what regulatory issues and application layer issues will be faced after Ethereum merges.

In the first article of our “Ethereum Merger” series, we mainly introduced the reasons, route and current progress of the Ethereum upgrade. (Depth | After the “big merger” of Ethereum, can the mental internal friction of Web3 be cured?)

As the Ethereum Merge time node is approaching, today we will discuss what regulatory issues and application layer issues will be faced after Ethereum merges.

On August 16, 2022, Ethereum co-founder Vitalik Buterin (V God) participated in the discussion on Twitter “If the verifiers of certain protocols (such as Lido, Coinbase, etc.) are regulated to conduct protocol-level censorship on Ethereum , how will the ethereum community react?” said that it would view this censorship as an attack on ethereum and choose to burn these validators’ staking rights through a broader social consensus.

The trigger for this discussion is that the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC) recently added Tornado Cash-related Ethereum addresses to the list of sanctioned entities. However, the current sanctions against them are all operations at the centralized level, and technical sanctions cannot be imposed on the part of smart contracts that involve decentralization.

This shows that if the United States wants to completely sanction Tornado cash, it must control the underlying Ethereum chain. So it begs the question, if the U.S. government regulates Ethereum, what will it face?

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

If the U.S. government wants to regulate Ethereum, the biggest possibility is to require large PoS staking service providers to conduct protocol-level transaction review on Ethereum. This is not the verifier “doing evil”, but the verifier’s “targeted sanctions” on the addresses on the chain.

Simply put, it is to monitor all requests sent by the sanctioned addresses, and reject all blocks containing transactions of the sanctioned addresses. When a block fails to pass more than 66% of the equity verification vote, the block All transaction requests will be rolled back, which means that 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 accounts for about 14.7%, and Kraken accounts for about 8.5%.

If the U.S. government requires large node validators (service providers) represented by Lido, Coinabse, and Kraken to conduct protocol-level transaction review on Ethereum, it is difficult for a pledge service provider with a U.S. legal entity to refuse similar requests.

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Image courtesy of Dune Analytics

In response to the possibility of the above situation, the Ethereum community launched a voting discussion on Twitter on what to do if OFAC regulates Ethereum through validating nodes. Buterin supports viewing the above situation as an attack on Ethereum, and destroying the pledged rights of these nodes through a broader consensus.

Next, let’s talk about the application layer again.

We mentioned in the previous article: According to the plan, the Merge of Ethereum is carried out on the principle of “least disruption”, so that the original running application client can switch to PoS without feeling. That said, despite the “minimal disruption”, there are some small changes in the process that are still worth noting. 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 Ethereum’s execution layer and consensus layer (or engine). 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 verified node. The diagram below shows the complete Ethereum client architecture after the merger.

– Client Architecture

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

The merged client architecture. Image courtesy of Danny Ryan

– Block structure

When a merger occurs, beacon nodes 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 considered 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 the new PoS consensus layer of Ethereum, replacing the previous PoW consensus layer.

At the same time during consensus verification, the beacon node will communicate with its execution engine (the Ethereum client before the upgrade) and ask it to generate or verify ExecutionPayloads. ExecutionPayloads contain 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.

And for end users and application developers, these ExecutionPayloads on the original PoW chain are still where they interact directly with Ethereum, and transactions will still be handled by the execution layer client, which allows them to switch to the PoS chain without feeling . The following diagram shows this relationship:

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Image via Danny Ryan

– Execution engine

After the merger, the execution engine is mainly responsible for state management, block creation and verification functions, and no longer contains 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 fields in the original block that are only related to PoW to 0 (or their data structure equivalents), including mining related (difficulty, mixHash, nonce), uncle block reward related (ommers, ommersHash) ). In addition, the length of extraData will also be limited to 32 bytes on the mainnet.

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Second, since only the merged beacon chain can produce blocks, the execution engine will stop processing blocks and uncle block rewards. But the transaction fee is still handled by it, that is, when the execution engine creates an ExecutionPayload, it needs to ensure that the initiator 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 pre-upgrade Ethereum address, 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 users send transactions to consensus clients through local RPC requests, where they will be packaged into beacon blocks. Consensus clients will then broadcast the beacon block in their p2p network.

The following figure shows the process of Ethereum merging: first stop the PoW block, and second the beacon chain block starts to hold the ExecutionPayload after the merger.

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Image via Danny Ryan

– BLOCKHASH & DIFFICULTY opcode changes

After merging, 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 RANDOM and return the random value provided by the beacon chain. Therefore, this value will replace BLOCKHASH as a better source of randomness available to application developers (although there is still a bias).

The RANDOM value will be stored in the ExecutionPayload at the location of the original mixHash, which is related to the proof-of-work calculation. The value was renamed to random after the upgrade.

The following diagrams explain how the DIFFICULTY and RANDOM opcodes work before and after merging:

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Image via 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 on average every 13 seconds, but the actual block interval will vary considerably due to network congestion. But under PoS, the block interval is a fixed 12 seconds, unless some extreme situations occur, such as: a validator is offline or fails to submit a block in time and misses a slot.

In summary, the average block time of the network will be reduced by nearly 1 second after the upgrade, which increases the transaction rate. Note: If there is logic in the smart contract related to a specific average block time, the developer needs to take this into account when calculating.

Chengdu Lianan: In-depth analysis of the supervision and application layer problems after the merger of Ethereum

Well, today’s sharing is over. In the next article, we will discuss the security issues that will be faced after the merger of Ethereum. Welcome to continue to pay attention to our sharing.

references:

“Ethereum Community Faces Regulatory Concerns Ahead of Upgrade” https://www.defidaonews.com/media/6772646

《How The Merge Impacts Ethereum’s Application Layer 》 https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/in-depth-analysis-of-regulatory-and-application-layer-issues-after-ethereum-merger/
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.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-06 09:49
Next 2022-09-06 09:50

Related articles