#dusk $DUSK @Dusk
Ejecuté la generación de pruebas localmente para evaluar el rendimiento del circuito y noté algo que me hizo volver a leer los informes propios del equipo de criptografía, en lugar de las páginas de marketing.
Los números reales de PLONK son los que hacen que el caso de cumplimiento funcione, no solo el ángulo de la privacidad. El tiempo de verificación se mantiene en torno a 6-9 milisegundos independientemente del tamaño del circuito: el tiempo de prueba escala con la complejidad del circuito (aprox. 5,46 segundos para un circuito de 2^16 compuertas en hardware modesto), pero el lado del verificador se mantiene rápido y constante. Esta asimetría importa más para las finanzas reguladas de lo que la gente cree: un auditor o un tercero verificando una prueba no está quemando cómputo relevante cada vez, incluso cuando la lógica subyacente de la transacción se vuelve más compleja.
Lo que no esperaba encontrar era que PLONK en sí tenía una vulnerabilidad real divulgada, no solo un riesgo teórico. El equipo de investigación de Dusk encontró un problema crítico en cómo se implementó la transformación Fiat-Shamir: la pieza que convierte una prueba interactiva en una no interactiva al hashear desafíos en lugar de que un verificador en vivo los envíe. La implementación original no hasheaba las entradas públicas lo suficientemente pronto, lo que debilitó la garantía de solidez (soundness). Trail of Bits coordinó la divulgación; Dusk lo corrigió antes de mainnet y publicó el arreglo, en vez de guardarlo.
Ese es el detalle con el que sigo quedándome: una cadena orientada al cumplimiento construida sobre un sistema de pruebas criptográficas que tuvo un fallo real de solidez en código cercano a producción, detectado y corregido antes de que importara. No sé cuántas otras implementaciones que usan PLONK en otras partes seguían siendo vulnerables cuando esto se hizo público, ni cuánto tiempo pasó entre la divulgación y el parcheo en otros proyectos de sus propios forks.
Ejecuté la generación de pruebas localmente para evaluar el rendimiento del circuito y noté algo que me hizo volver a leer los informes propios del equipo de criptografía, en lugar de las páginas de marketing.
Los números reales de PLONK son los que hacen que el caso de cumplimiento funcione, no solo el ángulo de la privacidad. El tiempo de verificación se mantiene en torno a 6-9 milisegundos independientemente del tamaño del circuito: el tiempo de prueba escala con la complejidad del circuito (aprox. 5,46 segundos para un circuito de 2^16 compuertas en hardware modesto), pero el lado del verificador se mantiene rápido y constante. Esta asimetría importa más para las finanzas reguladas de lo que la gente cree: un auditor o un tercero verificando una prueba no está quemando cómputo relevante cada vez, incluso cuando la lógica subyacente de la transacción se vuelve más compleja.
Lo que no esperaba encontrar era que PLONK en sí tenía una vulnerabilidad real divulgada, no solo un riesgo teórico. El equipo de investigación de Dusk encontró un problema crítico en cómo se implementó la transformación Fiat-Shamir: la pieza que convierte una prueba interactiva en una no interactiva al hashear desafíos en lugar de que un verificador en vivo los envíe. La implementación original no hasheaba las entradas públicas lo suficientemente pronto, lo que debilitó la garantía de solidez (soundness). Trail of Bits coordinó la divulgación; Dusk lo corrigió antes de mainnet y publicó el arreglo, en vez de guardarlo.
Ese es el detalle con el que sigo quedándome: una cadena orientada al cumplimiento construida sobre un sistema de pruebas criptográficas que tuvo un fallo real de solidez en código cercano a producción, detectado y corregido antes de que importara. No sé cuántas otras implementaciones que usan PLONK en otras partes seguían siendo vulnerables cuando esto se hizo público, ni cuánto tiempo pasó entre la divulgación y el parcheo en otros proyectos de sus propios forks.