client setting for overriding `TOTAL_TRANSITION_DIFFICULTY`

[lsankar4033]

The current mechanism for the merge fork involves setting an epoch (MERGE_FORK_EPOCH) from which nodes expect to wait 1 week before the terminal total difficulty is hit (via TARGET_SECONDS_TO_MERGE/SECONDS_PER_ETH1_BLOCK).

SECONDS_PER_ETH1_BLOCK is controllable by miners and the possibility exists that in a fit of griefing, they cartelize to slow down the subsequent merge process by a factor. While it's effectively impossible for the PoW chain to halt, such a slowdown could cause coordination headaches for a few days to weeks around merge time. Much of the ensuing uncertainty may also trickle down to entities that rely on sending Eth1x transactions for business/livelihood.

Not to mention that there may be some unknown unknowns about attacks/issues here.

I propose adding a TOTAL_TRANSITION_DIFFICULTY_OVERRIDE parameter that serves as an override of the merge point to ease coordination during this period. This parameter would be accessible via a beacon node client setting (--total-transition-difficulty-override) that's unused by default. Setting this would trigger an alternate code path during TransitionStore initialization that just uses this value for the transition difficulty.

If we detect PoW block times slowing after setting TARGET_SECONDS_TO_MERGE, we have a lever we can use to change the point of transition. Furthermore, the mere existence of this option may be enough to dissuade miners from any griefing attack in the first place.

Curious of others' thoughts here.

(related: https://github.com/ethereum/EIPs/pull/3698)

[djrtwo]

I agree that a manual override is valuable in event of unexpected events near the merge. Other than a slow down, you could also see a repeated 51% attack/reorg that never get us to terminal total difficultly (TTD).

Being able to set TTD manually and coordinate out of band seems very reasonable, especially for the mining slow-down case. I would also consider an override that just sets the terminal PoW blockhash which would be much safer than setting TTD in the event of an ongoing 51% attack. Setting terminal blockhash would likely result in a downtime but is a good absolute emergency backup.

Setting blockhash is probably a more complicated control path than just a TTD override so we should consider it before adding it here and a related event on execution-layer (eip) side.

I do agree that specifying some security focused "client settings" or common cli args to be able to utilize in event of attack is worthwhile. Maybe a merge/client-settings.md file. We specified such params a while back in EIP 1011 so at least some precedent to go off of.

[mkalinin]

I am in support of manual override of the terminal difficulty. Along with the corresponding API that returns terminal difficulty that has been computed by the beacon node this CLI parameter should also aid recovery from imperfect computation when the locally computed value doesn't correspond to the one that has been found by the majority of network participants.

I do also see a lot of value in enforcing the transition process by specifying the hash of a terminal PoW block in the case of 51% attack where overridden terminal total difficulty might not result in the desired effect.

So, I see two similar options for beacon chain clients:

• --terminal-total-difficulty-override=TD
• --terminal-pow-block-hash-override=Hash

Both options should come with the corresponding POS_ event in EIP-3675 that introduces these overrides to the spec and will be reflected in the Consensus API.

UPD As noted by @djrtwo, --terminal-pow-block-hash-override should come with the corresponding epoch number from which this override takes and effect to allow for coordination. It would also require a corresponding fix to the beacon chain fork choice.

[lsankar4033]

Didn't seem to be any major dissent on the eth2.0 call so can draft a PR for the ttd override.

Personally agreed also on the point that being able to specify a block hash is necessary for clear coordination on past history. That being said, this seems like much more work to implement, so let's wait a few days to see if there are any other opinions there.

[zilm13]

I don't see any reason for some majority to fork several chains as any difficulty increase in any fork will get the chain closer to transition total difficulty. Also it will weaken future NotSoClassic Ethereum PoW coin, the thing any miner should avoid. The best thing they could do, to step off after anchor difficulty is used in calculation. This way they could slow down transition in proportion of the missed mining power share: 50% - 2 times, 66% - 3 times etc. Though I doubt such a kind of collusion could ever exist. Btw, we have finished and posted our analysis on this topic: https://ethresear.ch/t/using-total-difficulty-threshold-for-hardfork-anchor-what-could-go-wrong/10357 But it doesn't contain such kind of simulation, I guess we could do it next.

[lsankar4033]

I don't see any reason for some majority to fork several chains as any difficulty increase in any fork will get the chain closer to transition total difficulty. Also it will weaken future NotSoClassic Ethereum PoW coin, the thing any miner should avoid. The best thing they could do, to step off after anchor difficulty is used in calculation. This way they could slow down transition in proportion of the missed mining power share: 50% - 2 times, 66% - 3 times etc. Though I doubt such a kind of collusion could ever exist.

There are two reasons miners may do something that I think are worth considering:

1. use an attack and the ensuing chaos to 'demonstrate' that PoS ethereum is 'not a sure thing'. obviously not true, but they may be able to win some PR battles here in the short-term
2. just a plain old griefing attack. there may still be feelings of disenfranchisement

Whatever the case, having a public mechanism for coming to consensus on a new fork may in itself dissuade miners from doing anything.

[mkalinin]

A couple of things to consider if we end up with TERMINAL_TOTAL_DIFFICULTY as a hardcoded value in both clients:

• If one of this override settings introduces the transition at the total difficulty that is lower than hardcoded TTD then there is a risk for a node to follow the wrong chain due to misconfiguration, e.g. not restarting a node with communicated value for one of the override settings.
• Overriding the transition flow with one of these settings would require subsequent releases of consensus and execution client software with the corresponding changes. Otherwise, users will have to pass the corresponding setting to the CLI string of a fresh node even though the Merge has already happened.