The calculation of g: The number of reports guaranteed by the validator

[YCC3741]

When testing trace/preimage_light/0000008, we found issues with pi_V[v]_g as follows.

In tiny mode, the parameters are R = 4 and E = 12, which means the cores where the guarantors for slot 7 and slot 8 reside will rotate.

What we observed

• Initially, our pi_V[v]_g was 2.
• In slot 8, we received a guarantee_extrinsic containing two elements belonging to slot 7 and slot 8, respectively.
• Core assignments:
  • slot 8 — [0,1,1,0,0,1]
  • slot 7 — [1,0,0,1,1,0]
• Based on these assignments, we confirmed that the reports received for both slots were valid.

What we did

• We incremented pi_V[v]_g twice by +1 (since kappa_v_prime ∈ G per GP 0.7.0 formula 13.5), resulting in pi_V[v]_g_prime = 4.

Where the ambiguity is

• GP 0.7.0 formula 13.5 appears to only check whether kappa_v_prime ∈ G.
• However, this seems to conflict with the description above 13.3:
  • g: The number of reports guaranteed by the validator.

Should both reports be counted toward g in this case, or should we follow formula 13.5 strictly and add +1 only once?

Proposal

This ambiguity likely requires us to rethink how we calculate g.

[davxy]

I remember we discussed this once. The conclusion was:

• It was written that way intentionally to keep the formalism simple.
• If you find a more elegant way to express it, it can be revised to count the actual number of guarantees.

[YCC3741]

Thanks for the detailed explanation. We’ll start by following GP’s formula and see if we need to make any further adjustments.