Ver @Dusk : otra tarea para creadores, y de paso hablemos de una “historia negra” bastante dura que encontré antes.
El informe que OtterSec sacó en abril de este año me dejó con el corazón en la mano. El problema no era la lógica de negocio habitual: venía nada menos que del núcleo del proceso de verificación de pruebas ZK (dusk-plonk). En pocas palabras, en aquel momento el atacante tuvo la oportunidad de falsificar una prueba, acuñar de forma infinita tokens “por la nada” o desviar activos 🥶🤮 Para una cadena de privacidad que se enfoca en la privacidad institucional y en finanzas con cumplimiento, que la capa de verificación quedara comprometida es un asunto gravísimo, que literalmente mueve los cimientos.
Aunque el fallo ya fue corregido hace tiempo y no causó pérdidas reales, tras revisar el informe de auditoría no puedo evitar quedarme con la sensación de nervios: la parte más crítica de pruebas de conocimiento cero, ¿las auditorías anteriores ni siquiera la cubrieron completamente? La cadena vende la confianza en la seguridad criptográfica; si el componente central no soportó pruebas y revisiones repetidas, el proceso de ingeniería y desarrollo de producto, desde luego, debe descontar puntos.
No es que la esté atacando ni me muestre pesimista, pero en proyectos que se centran en privacy, basta con un solo error en el control del código para que el coste de la confianza se dispare al doble. Por ahora, elijo seguir observando y ver si sus operaciones de seguridad y su iteración técnica en el futuro realmente son sólidas.
¿Ustedes creen que las vulnerabilidades de seguridad más críticas de una cadena pública de privacidad pueden “vetarse” con un solo voto? Si fueras tú, ¿aún considerarías invertir y plantear un plan con $DUSK ? ¡Comenta en la sección de comentarios! #dusk
El informe que OtterSec sacó en abril de este año me dejó con el corazón en la mano. El problema no era la lógica de negocio habitual: venía nada menos que del núcleo del proceso de verificación de pruebas ZK (dusk-plonk). En pocas palabras, en aquel momento el atacante tuvo la oportunidad de falsificar una prueba, acuñar de forma infinita tokens “por la nada” o desviar activos 🥶🤮 Para una cadena de privacidad que se enfoca en la privacidad institucional y en finanzas con cumplimiento, que la capa de verificación quedara comprometida es un asunto gravísimo, que literalmente mueve los cimientos.
Aunque el fallo ya fue corregido hace tiempo y no causó pérdidas reales, tras revisar el informe de auditoría no puedo evitar quedarme con la sensación de nervios: la parte más crítica de pruebas de conocimiento cero, ¿las auditorías anteriores ni siquiera la cubrieron completamente? La cadena vende la confianza en la seguridad criptográfica; si el componente central no soportó pruebas y revisiones repetidas, el proceso de ingeniería y desarrollo de producto, desde luego, debe descontar puntos.
No es que la esté atacando ni me muestre pesimista, pero en proyectos que se centran en privacy, basta con un solo error en el control del código para que el coste de la confianza se dispare al doble. Por ahora, elijo seguir observando y ver si sus operaciones de seguridad y su iteración técnica en el futuro realmente son sólidas.
¿Ustedes creen que las vulnerabilidades de seguridad más críticas de una cadena pública de privacidad pueden “vetarse” con un solo voto? Si fueras tú, ¿aún considerarías invertir y plantear un plan con $DUSK ? ¡Comenta en la sección de comentarios! #dusk
