EIP-3675: Upgrade consensus to Proof-of-Stake

EIPs
,
1

This is the discussion topic for EIP-3675: Upgrade consensus to Proof-of-Stake.
This EIP introduces the specification of the consensus mechanism upgrade to the Proof-of-Stake (a.k.a. The Merge).

Edit
EIP-3675 got merged you can find it here:

7 Likes
2

For the health of the network under this kind of attack it makes sense for clients to stop propagating any blocks upon receiving the first POS_BLOCK_FINALIZED and remove handlers with the corresponding penalty upon receiving the second POS_BLOCK_FINALIZED. So, the updated spec should look like:

The networking stack SHOULD NOT send the following messages if they advertise the descendant of any terminal PoW block:

Beginning with the first POS_BLOCK_FINALIZED event, the networking stack MUST discard the following ingress messages:

Beginning with the second POS_BLOCK_FINALIZED event, the networking stack MUST remove the handlers corresponding to the following messages:

Peers that keep sending these messages after the handlers have been removed SHOULD be disconnected.

According to the current spec honest peers that keep propagating maliciously produced terminal PoW blocks maybe accidentally disconnected because of the racing in receiving the POS_BLOCK_FINALIZED event by between different nodes.

cc @MicahZoltu

3

If you fork out PoW using TD instead of block number, miners will be incentivized to maximize the number of blocks until that TD, and the easiest way to do that would be a MASF that adjusts tip selection. While some clients will still use TD, the majority hashpower would not, and the reorgs would be chaotic. I’ve suggested they use min(NEXT_BASE_FEE) for tip selection, and with 1559 that may be an easier, more profitable way to break ties than TD. Using TD for PoS timing would make collusion against TD more beneficial.

4

Another concern with TD is that an increase or decrease in MEV given liquid hashrate may make TD less predictable than block number; if the hashrate increased the fork could happen sooner than expected. This would require a later fork date than if block number was used, to account for possible variability.

5

We have discussed this vector previously, and at least it requires a 51% attack by miners (effectively) where it is profitable to defect up until 51% is reached. This is not really any different than our current situation, where a 51% attack is viable but it is profitable to defect up until 51% is actually reached. The problems introduced by using block number create new attack vectors beyond 51% attacks, which is why TD was chosen instead.

I recommend checking out EIP-3675: Upgrade consensus to Proof-of-Stake for details on the problems with using the block number.

6

A high-level introduction of the system after the merge, terminal total difficulty, transition block diagram, and more are explained on the PEEPanEIP with @mkalinin.

7

EIP-2124 fork identifier section in the specification currently has the following statement:

Starting with TRANSITION_POS_BLOCK that has block number N, nodes MUST update FORK_HASH by appending uint64(N) to the sequence of hashes used to calculate FORK_HASH as per EIP-2124.
FORK_NEXT can remain 0 after the transition.

Suppose the local node is syncing and haven’t reached the TRANSITION_POS_BLOCK yet while the transition has already happened in the network and the TRANSITION_POS_BLOCK is known to the remote peer the node tries to connect to. The remote peer has updated its FORK_HASH with TRANSITION_POS_BLOCK according to the aforementioned statement, and, thus, local node will disconnect the peer because of incompatible FORK_HASH values.

A straightforward way to prevent the network from falling apart because of uncertainty around TRANSITION_POS_BLOCK is to keep FORK_HASH unaffected by the Merge. The question is: can and should we do better?

8

Continuing on the EIP-2124 topic.

There was a suggestion made by @djrtwo on ACD#126 to set the FORK_NEXT to a block height lower, e.g. by a week worth of block numbers, than the height of TRANSITION_BLOCK. This would force those users that haven’t upgraded their client software yet to do so because they will start loosing peers. In the case if TTD override with the value that is closer in time, the FORK_NEXT value could be overridden as well for the same purposes. This behaviour around FORK_NEXT looks pretty valuable in the context of the Merge.