Empecé a cuestionar la narrativa del conteo de compuertas de DUSK cuando un XOR de 8 bits modelado pasó de 31 compuertas a una sola búsqueda PlonKup. La compresión se ve sorprendente: 96,8%. Pero eso refleja aritmética del circuito, no la velocidad real de prueba.
Una búsqueda aun así implica manejar tablas, ordenar compromisos y generar presión de memoria. Entonces, 31× menos compuertas no significa 31× más rápido el proceso de prueba. El costo podría simplemente trasladarse a la RAM.
Esto importa porque la guía para operadores de DUSK presupone alrededor de 1 GB por trabajador de prueba y 8 GB para un servidor mínimo. Esas son cifras de dimensionamiento, no memoria máxima medida. La métrica que falta es pruebas por GB en carga P50 y P99, especialmente con trabajadores concurrentes.
Luego está la accesibilidad. ¿Qué sucede en un teléfono de gama media después del calor, las apps en segundo plano y pruebas repetidas? Si P50 es aceptable pero P99 se estanca, la privacidad se convierte en fricción para el usuario, no solo en una victoria criptográfica.
También estoy vigilando pruebas malformadas. ¿Cuánto CPU puede consumir una entrada inválida antes del rechazo y cuánto ahorra el filtrado temprano? Algo de sobrecarga es normal. La amplificación ilimitada no lo es.
DUSK puede tener éxito si la compresión por búsqueda mejora el rendimiento real sin concentrar la generación de pruebas en hardware de alta memoria. Hasta que DUSK publique el tiempo de prueba, el uso máximo de RAM, el consumo de energía y puntos de referencia de rechazo de pruebas inválidas, más rápido que incompleto sigue siendo incompleto.
#dusk $DUSK @Dusk
Una búsqueda aun así implica manejar tablas, ordenar compromisos y generar presión de memoria. Entonces, 31× menos compuertas no significa 31× más rápido el proceso de prueba. El costo podría simplemente trasladarse a la RAM.
Esto importa porque la guía para operadores de DUSK presupone alrededor de 1 GB por trabajador de prueba y 8 GB para un servidor mínimo. Esas son cifras de dimensionamiento, no memoria máxima medida. La métrica que falta es pruebas por GB en carga P50 y P99, especialmente con trabajadores concurrentes.
Luego está la accesibilidad. ¿Qué sucede en un teléfono de gama media después del calor, las apps en segundo plano y pruebas repetidas? Si P50 es aceptable pero P99 se estanca, la privacidad se convierte en fricción para el usuario, no solo en una victoria criptográfica.
También estoy vigilando pruebas malformadas. ¿Cuánto CPU puede consumir una entrada inválida antes del rechazo y cuánto ahorra el filtrado temprano? Algo de sobrecarga es normal. La amplificación ilimitada no lo es.
DUSK puede tener éxito si la compresión por búsqueda mejora el rendimiento real sin concentrar la generación de pruebas en hardware de alta memoria. Hasta que DUSK publique el tiempo de prueba, el uso máximo de RAM, el consumo de energía y puntos de referencia de rechazo de pruebas inválidas, más rápido que incompleto sigue siendo incompleto.
#dusk $DUSK @Dusk