@Dusk Je rejouais une trace de comité et le bloc lui-même n’était pas le problème. La partie agaçante, c’était le trafic de votes autour. Quarante signatures étaient arrivées, et ma première instinct a été d’appeler le taux de compression facile : quarante signatures entrent, une signature agrégée sort. Ce nombre paraissait trop “propre”.

Alors j’ai commencé à compter les octets.

Si un vote individuel coûte S octets pour la signature, I pour l’identité du signataire, et V pour les métadonnées du vote, la base utile n’est pas nS. Elle s’approche plutôt de n(S+I+V)+H. L’attestation a aussi ses propres bagages : la signature agrégée A, les données d’appartenance des signataires M, et le surcoût d’en-tête H'.

Le ratio qui m’intéresse réellement devient

[
CR=\frac{n(S+I+V)+H}{A+M+H'}.
]

Sur un test illustratif — 40 votes, signatures de 96 octets, 4 octets de données d’identité, 2 octets de métadonnées de vote — le “côté brut” atteint 4 080 octets avant les frais généraux communs. Si l’objet agrégé complet faisait 120 octets, cela donne une compression de 34×, soit environ 97,1% d’octets en moins.

Nombre utile. Peut-être.

Je n’en ferais quand même pas une mesure de DUSK. Le dénominateur doit venir de l’attestation sérialisée réelle, pas d’une hypothèse commode.

C’est le test que je lancerais ensuite : capturer des attestations réelles de comités à différents niveaux de participation et voir à quel point la courbe de compression “bien nette” cesse de l’être. #dusk $DUSK