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

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

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

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.

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.

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.

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.