Support IB equivocations

[SupernaviX]

Adds the first adversarial behavior to the rust simulation: IB equivocation attacks.

This adversarial behavior is configured at the level of individual nodes in the topology file. To configure a node to follow this behavior,

  node-4:
    stake: 10000000
    location:
      - -30.0
      - 170.0
    producers:
      node-11:
        latency-ms: 13.0
    behaviours:
      - behaviour: "ib-equivocation"

(the British spelling is for Haskell compatibility)

Nodes configured to perform IB equivocation have the following behaviors:

• When winning an IB lottery, they will produce two separate IBs with the same VRF result/"lottery number" and send both of them to peers.
• When receiving an IB header, they will not check for equivocation and will forward the same IB to all peers.

Nodes not configured with the new behavior now guard against IB equivocations. They will relay the second header they receive with the same VRF (as proof of equivocation), but will not relay other headers, or download IBs which are known to be equivocated.

[pagio]

@SupernaviX Did you also implement the rest of the defenses described in the Leios paper: https://eprint.iacr.org/2025/1115.pdf, sec. 6 ? I.e., delaying voting for EBs or including IBs in EBs a bit to detect if there is an equivocation?

[SupernaviX]

@pagio I didn't implement that, and I'll add it in, but it wouldn't affect our simulations anyway. We've had ∆hdr set to 1 second since it was implemented, so 5∆hdr is at worst a single stage.

Which, reading the paper more, looks like a fundamental assumption of the protocol. So this must have some impact I'm not noticing.