#dusk $DUSK @Dusk
Me metí en un agujero de conejo de Khovratovich mientras investigaba Dusk Argon2 Equihash PLONK y la criptografía que está debajo de la red. Todo eso es interesante.
Pero entonces miré lo que ocurrió realmente recientemente, y el detalle más importante no fue la matemática.
El 16 de agosto Dusk pausó los servicios de puente después de que la monitorización detectara actividad que no coincidía con el comportamiento normal de los puentes. Lo que llamó la atención es que el propio DuskDS siguió produciendo bloques, por lo que el incidente se gestionó en torno a las operaciones del puente en lugar de convertirse en una detención a nivel de protocolo.
Luego llegó la parte sobre la que seguí pensando.
La mitigación no fue otro sistema de pruebas ni un cambio de consenso. La Web Wallet añadió una lista de destinatarios bloqueados que advierte a los usuarios antes de que envíen fondos a una dirección marcada.
Eso es un tipo de seguridad muy diferente.
Protege al usuario predeterminado justo en el punto en el que está por ocurrir una transacción riesgosa. Y, como respuesta práctica que tiene sentido, una advertencia desde la wallet puede llegar rápidamente a los usuarios sin esperar un cambio de protocolo más profundo.
Pero existe un intercambio.
Alguien que use herramientas personalizadas, la CLI u otra interfaz, puede no recibir la misma advertencia. La protección depende de dónde interactúan con Dusk.
Eso me hizo mirar el modelo de seguridad de Dusk de manera distinta. Una criptografía sólida puede proteger el sistema subyacente, pero el riesgo operativo aún puede aparecer en los bordes.
Para una red que apunta a mercados financieros regulados, la pregunta que vigilaría es simple:
¿Los controles de seguridad adicionales eventualmente se acercarán más al protocolo, o la protección a nivel de aplicación seguirá siendo la capa preferida?
Me metí en un agujero de conejo de Khovratovich mientras investigaba Dusk Argon2 Equihash PLONK y la criptografía que está debajo de la red. Todo eso es interesante.
Pero entonces miré lo que ocurrió realmente recientemente, y el detalle más importante no fue la matemática.
El 16 de agosto Dusk pausó los servicios de puente después de que la monitorización detectara actividad que no coincidía con el comportamiento normal de los puentes. Lo que llamó la atención es que el propio DuskDS siguió produciendo bloques, por lo que el incidente se gestionó en torno a las operaciones del puente en lugar de convertirse en una detención a nivel de protocolo.
Luego llegó la parte sobre la que seguí pensando.
La mitigación no fue otro sistema de pruebas ni un cambio de consenso. La Web Wallet añadió una lista de destinatarios bloqueados que advierte a los usuarios antes de que envíen fondos a una dirección marcada.
Eso es un tipo de seguridad muy diferente.
Protege al usuario predeterminado justo en el punto en el que está por ocurrir una transacción riesgosa. Y, como respuesta práctica que tiene sentido, una advertencia desde la wallet puede llegar rápidamente a los usuarios sin esperar un cambio de protocolo más profundo.
Pero existe un intercambio.
Alguien que use herramientas personalizadas, la CLI u otra interfaz, puede no recibir la misma advertencia. La protección depende de dónde interactúan con Dusk.
Eso me hizo mirar el modelo de seguridad de Dusk de manera distinta. Una criptografía sólida puede proteger el sistema subyacente, pero el riesgo operativo aún puede aparecer en los bordes.
Para una red que apunta a mercados financieros regulados, la pregunta que vigilaría es simple:
¿Los controles de seguridad adicionales eventualmente se acercarán más al protocolo, o la protección a nivel de aplicación seguirá siendo la capa preferida?
