sigp
Feat: Supermajority fork protection in the VC
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.
"Lighthouse could be the third client a bit after." - I'm down to implement now then we can wait to merge the PR.
Ill start with looking at Vero's implementation and after I might have questions. The one ambiguity I have is how do we handle when the GHOST head across N agreed clients are not that same? Do we have a primary CL we use to get the GHOST head then we get the ffg source and target via the N agreed nodes? Another thing that is a tad confusing is "consensus between all connected CLs on the finalization checkpoint (source and target) before signing an attestation". From my understanding the finalized checkpoint is not the same thing as the source and target. My current understanding is the source checkpoint is the beacon nodes current justified checkpoint and the target is the block in its canonical chains checkpoint slot (if empty the last block in the last non empty epoch) And the finalized checkpoint is updated when the current justified and previous justified checkpoints in beacon state are in consecutive epochs
@0xmrree Eitan has already started work here:
- https://github.com/sigp/lighthouse/pull/8445
Hi @0xmrree I'm happy to work together on this. I have a branch here that has the changes a bit more isolated https://github.com/eserilev/lighthouse/pull/26
