fill: #1181 equivocation fixtures fail to generate at HEAD (fork choice disagrees with expected head)

[mananuf]

fill fails to generate the #1181 equivocation fixtures at HEAD — fork choice disagrees with the vectors' expected head

At current main (4ca7d27e46b9b978c4f0a9b7e8eb6fd06be8286d), generating the lstar fixture set fails: the three equivocation tests added in #1181 assert a head that the fork-choice implementation does not produce. fill therefore exits non-zero, which blocks generating (and consuming) the full lstar fixture set at HEAD. We hit this integrating gean against HEAD.

Reproduction

uv run fill --clean --fork=lstar --scheme=prod --output=fixtures

E   AssertionError: Step 6: head_slot = 2, expected 3
E   AssertionError: Step 6: head_slot = 3, expected 2
E   AssertionError: Step 6: head_slot = 3, expected 2
=========================== short test summary info ============================
FAILED tests/consensus/lstar/fork_choice/test_equivocation.py::test_same_slot_equivocating_attesters_count_once[fork_Lstar]
FAILED tests/consensus/lstar/fork_choice/test_equivocation.py::test_equivocation_head_independent_of_arrival_order_a_then_b[fork_Lstar]
FAILED tests/consensus/lstar/fork_choice/test_equivocation.py::test_equivocation_head_independent_of_arrival_order_b_then_a[fork_Lstar]
========== 3 failed, 551 passed, 35 deselected ==========

All other 551 tests generate cleanly; only these three fail.

What the failures suggest

The two arrival-order tests are the interesting signal:

• ..._a_then_b → head_slot = 3 (expected 2)
• ..._b_then_a → head_slot = 3 (expected 2)

Both deliveries produce the same head (3), so the order-independence property #1181 introduced is holding — the head is a pure function of store contents. But the deterministic result disagrees with the vectors' expected value (3 vs 2), and test_same_slot_equivocating_attesters_count_once disagrees in the other direction (2 vs 3).

That reads like an implementation-vs-vector mismatch introduced with #1181: the equal-slot tie-break resolves to a different branch than the test vectors encode. Either the tie-break direction in the fork-choice code and the expected head in these vectors were computed against different conventions, or one of the two is off.

For reference, test_same_slot_equivocating_attesters_count_once's own docstring states the intent as "the two votes tie on slot, so the larger attestation-data root wins … head is fork_b" — so the intent (larger canonical root wins) is clear; the disagreement is about which concrete head that yields in these fixtures.

Impact

• fill --fork=lstar cannot produce the full fixture set at HEAD, so downstream clients cannot regenerate/consume the lstar vectors until this is resolved (we worked around it by excluding test_equivocation.py to validate the rest).
• These three vectors were added in fix(fork-choice): make the equal-slot equivocation tie deterministic #1181 (closes Equivocation tie-break is insertion-order dependent (heads can diverge permanently) #1172), so this appears to be a regression contained to that change rather than pre-existing.

Question

Is this a known issue? Is the intended fix to adjust the tie-break resolution in fork_choice.py, or to regenerate/correct the expected heads in these three vectors?

Happy to provide the full fill log or a minimal repro if useful.

[mananuf]

Correction: this is scheme dependence, not a code-vs-vector bug

A CI run on the attempted fix (#1188, now closed) revealed the real cause. The three tests' heads flip between signature schemes:

• Under fill's default test scheme (what CI runs): same_slot → fork_b (3), arrival-order → fork_a (2) — matching the current vectors, so CI on main is green.
• Under --scheme=prod (which I used in the original repro, because our downstream client generates real-XMSS fixtures): the opposite — same_slot → fork_a (2), arrival-order → fork_b (3).

Cause: a different scheme means different validator keys → different genesis state_root → different block roots → different attestation-data roots → the equal-slot tie-break (larger canonical attestation-data root) resolves to the opposite fork. The fork-choice implementation is correct and deterministic under each scheme — the vectors' hard-coded expected heads just can't be valid for both.

So, to correct my original framing: this is not an implementation-vs-vector mismatch. The vectors are correct for the canonical test scheme; the three tests only fail to generate under --scheme=prod.

Note lexicographic_head_among can't express the post-vote head here — it requires the competing forks to have equal weight, which no longer holds after the equivocation votes decide the head.

Open question for maintainers: should these vectors be generatable under any scheme (so prod-crypto downstream clients can consume the full lstar set)? If so it'd need a scheme-independent assertion — e.g. a check like "head is the fork whose aggregated attestation-data root is larger", evaluated at runtime rather than hard-coded — which is a framework-level change. Happy to help if that's wanted. Otherwise this is really a downstream scheme-choice matter and can be closed.

[mananuf]

Closing — per the correction above, this isn't a fork-choice bug: the vectors are correct for the canonical test scheme (CI is green on main), and only fail to generate under --scheme=prod, which is a downstream scheme choice on our side. We're handling it downstream (excluding these 3 equivocation vectors when generating under prod; the determinism is covered by our own unit tests). Happy to reopen if you'd like the vectors made scheme-independent so prod-crypto consumers can generate the full lstar set.