Feat: Supermajority fork protection in the VC #8438
Description
Description
Add an opt-in feature to the VC: Require an N-of-M consensus between all connected CLs on the finalization checkpoint (source and target) before signing an attestation.
Why?
This can protect against a supermajority fork when there is a correlated bug, as seen during Holesky Pectra fork. E.g. a setup of six CL/EL pairs, all different, with a threshold of 5/6, would allow one buggy or down client and stay live, and at two clients would halt attestations but produce blocks. This means the faulty chain does not finalize (assuming > 1/3rd of chain runs in this mode), and core devs have time to find and fix the issue safely.
If Vero, Vouch and Lighthouse support this feature, we have a good chance to get above 1/3rd of stake running this feature, and then the chain itself is protected.
Implementation details
Vero is currently the only client that does this. Its design can serve as a sounding board.
Vouch does not yet, and is interested in taking their existing feature and making it robust.
You could try to come to consensus on source/target during slot 0. If there is no response within a second from N quorum (because slot 0 😅), sign with current head but last epoch’s source/targets. Keep trying for consensus and update the source/target for the next slot.
If there’s quorum response but no quorum consensus, don’t attest.
Getting consensus just during slot 0 and then using that for the rest of the epoch might not be ideal, but protects against signing when there’s a fork, while keeping performance high.
Effort
Likely medium for implementation, and substantial for ongoing testing: Lighthouse VC would need to be tested against all CLs continuously, rather than mainly Lighthouse and Teku.
Wen?
Can be held loosely. Vero works, let’s get Vouch working. Lighthouse could be the third client a bit after.