@Dusk Estaba reproduciendo un registro de un comité y el bloque en sí no era el problema. Lo molesto era el tráfico de votos alrededor de eso. Habían llegado cuarenta firmas, y mi primera intuición fue llamar a la razón de compresión algo sencillo: cuarenta firmas entran, una agregada sale. Ese número se veía demasiado limpio.

Así que empecé a contar bytes.

Si un voto individual cuesta S bytes para la firma, I para la identidad del firmante, y V para los metadatos del voto, el punto de partida útil no es nS. Está más cerca de n(S+I+V)+H. La atestación también trae su propio equipaje: la firma agregada A, los datos de pertenencia de los firmantes M y la sobrecarga del encabezado H'.

La razón que de verdad me importa queda

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

En una ejecución ilustrativa—40 votos, firmas de 96 bytes, 4 bytes de datos de identidad, 2 bytes de metadatos del voto—el lado “crudo” llega a 4,080 bytes antes de la sobrecarga común. Si el objeto agregado completo fuera de 120 bytes, eso da una compresión de 34×, aproximadamente 97.1% menos bytes.

Número útil. Quizá.

Aun así, no lo llamaría una medición de DUSK. El denominador tiene que salir de la atestación serializada real, no de una suposición conveniente.

Esa es la prueba que ejecutaría después: capturar atestaciones reales de comité en distintos niveles de participación y ver en qué punto la bonita curva de compresión deja de ser bonita.
#dusk $DUSK