`single_validator_resign_attestation.json`: Issue in minimal slashing DB?

[nalepae]

EIP-3076 states:

5. Refuse to sign any attestation with target epoch less than or equal to the minimum target epoch present in that signer’s attestations (as seen in data.signed_attestations), except if it is a repeat signing as determined by the signing_root.

In test single_validator_resign_attestation.json, for block proposals for pubkey 0xa99a..., we have in the interchange file:

   Source: 5 -------------> Target: 15 (Signing root: ...203)

The minimal anti-slashing DB retains only the unique attestation.

Later, in steps[0].attestations[2], we want to import:

        {
          "pubkey": "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c",
          "source_epoch": "5",
          "target_epoch": "15",
          "signing_root": "0x0000000000000000000000000000000000000000000000000000000000000203",
          "should_succeed": false,
          "should_succeed_complete": true
        },

We try to import a attestation, corresponding to the minimal proposed slot for this pubkey (which is actually the maximum one as well if consider a minimal anti-slashing DB), with the same source, epoch and signing root.
==> This import should be both valid for minimal anti-slashing DB (should_succeed) as well as for complete anti-slashing DB (should_succeed_complete)

[michaelsproul]

Hmmm usually in minimal implementations we don't remember the signing root either. Will double check that is what is happening here

[nalepae]

If minimal implementation does not remember the signing root, is is slightly off-spec regarding the

except if it is a repeat signing as determined by the signing_root.

(Both for attestations and proposals)

I did not looked into Teku code, but according to Ben's book:

Teku takes a very robust, minimalist approach to this. For each validator managed by a Teku node, it maintains a text file with the epoch numbers of the validator's highest source vote and highest target vote to date. For a new attestation to be signed, its source must not be lower than the stored source, and its target must be higher than the stored target. This is sufficient to guarantee that a single instance of a Teku validator will not make a double vote for the same target epoch, and will not make a surround vote.

it does not seem to take into account the case where signing_rootare the same.

If I understand well, changing false to true here may possibly break Teku and Lighthouse minimal anti-slashing DB implemention. I'm not against keeping tests as they are today (and so change the Prysm minimal DB as well). Maybe in this case it could be useful to add a note in the EIP about this edge case for minimal anti-slashing DB.