EIP-3436: Expanded Clique Block Choice Rule

[shemnon]

2-5 minutes to call for comments on EIP-3436, which proposes fork choice rules for clique.

EIP - https://eips.ethereum.org/EIPS/eip-3436

Without these rules a clique network can deadlock with as few as 1 missing validator when all validators have seen all contested blocks. Goerli did so twice in early March prior to it's Berlin upgrade.

Geth has the second rule already implemented (prefer the shorter chain) but that only addresses one of the early March deadlocks, as the second deadlock had equal height on both forks. This proposes two more clique specific rules that should keep validators from deadlocking and provides an absolute ordering in the final case (lowest hash).

This does not impact any current or future hard fork for mainnet, so it can be prioritized appropriately. The goal is to move it into final call if there are no counter-proposals.

[shemnon]

@timbeiko I cannot add the "topic" label or edit any of the stuff on the side. Are the permissions cranked up for this?

[timbeiko]

@shemnon added to the agenda. I don't think non-members of the repo can add labels. I'll update the README. Thanks!

Update: done.

[tkstanczak]

makes sense, it is needed

[timbeiko]

Closing given this was discussed on ACD 110. @shemnon if you want to add links for further discussion here, I think that could be helpful.

[TbLtzk]

Is it possible to reopen and rediscuss this? We are using a modified clique consensus for our Q blockchain. We would like to implement deterministic fork choice as proposed. We can do it in our client only, but

1. we prefer to change it here as contribution, but also for peer review purpose
2. also, the rationale for not doing the proposed changed is not available. Maybe we overlook something, but deterministic fork choice appears very desireable

[shemnon]

Besu implements the EIP as written - hyperledger/besu#2084

I see Q is a Geth derivitive. Geth should implement the first and second steps already, so it's just an issue of step 3, which is intended to prevent "hash mining" for the final step. (a dedicated forker could keep generating blocks to ensure their validator's block is the next, which may matter in competitive MEV environments). Step 3 will be the most work of the 4 for geth because I don't think the validator and position in the validator list is wired into their fork choice logic. I think step 4 is fairly easy for geth derivities to implement.

Given that, I would be open to alternatives for step 3 that reduce the off-chain gamification but make it more implementable for Geth. If we finalized the EIP with an alterative rule I would go back and update Besu's implementation.

The eth-magicians forum is probably the best place to have this discussion - https://ethereum-magicians.org/t/eip-3436-expanded-clique-block-choice-rule/5809