#dusk $DUSK @Dusk Pasé la tarde hurgando en el informe del incidente de Dusk de principios de este año, en particular en la pausa del puente de enero. Ya sabes cómo es: empiezas con la publicación oficial del blog y terminas a tres commits de profundidad en el repositorio intentando averiguar qué fue lo que realmente se rompió.
Dusk se presenta como una capa 1 lista para regulación y centrada en la privacidad para las finanzas institucionales. Pero en enero, el equipo tuvo que deshabilitar las direcciones del puente y reciclar una billetera porque perdieron el control de ella. El relato es que "los fondos de los usuarios no se vieron afectados" y que "no fue un problema del protocolo". Está bien.
pero esa distinción está haciendo un trabajo enorme. Un puente es la puerta de entrada a la red; si el portero deja caer las llaves, no importa lo seguro que sea el cofre. La lista negra de Web Wallet que sacaron con rapidez es también un recordatorio contundente de que, aunque Dusk habla de cumplimiento descentralizado, la arquitectura sigue inclinándose hacia controles administrativos impulsados por multisig.
y para ser justos, los desarrolladores no están durmiendo. Estaban empujando mejoras en la UX del bridging de DuskEVM casi de inmediato, compitiendo para volver a poner el testnet en línea antes de que la liquidez se dispersara. El enfoque del desarrollo ha cambiado claramente del consenso del nodo central de Rusk hacia la capa de compatibilidad con EVM y la UX segura del bridging.
cuando lo comparo con el ethos de Ethereum, cuando un contrato inteligente tiene un problema, es inmutable; a menudo resulta en pérdidas catastróficas para los usuarios, pero con cero intervención administrativa. Dusk eligió el camino contrario: contención centralizada mediante contratos inteligentes actualizables para proteger a los usuarios, pero a costa de la narrativa de "imparable".
Así que, si una cadena de privacidad conforme requiere controles multisig para pausar fondos y poner en lista negra direcciones en el momento en que se filtra una clave, ¿qué exactamente estamos comprando? ¿Es solo TradFi con pasos extra, o el control administrativo es el producto, no el fallo?
Dusk se presenta como una capa 1 lista para regulación y centrada en la privacidad para las finanzas institucionales. Pero en enero, el equipo tuvo que deshabilitar las direcciones del puente y reciclar una billetera porque perdieron el control de ella. El relato es que "los fondos de los usuarios no se vieron afectados" y que "no fue un problema del protocolo". Está bien.
pero esa distinción está haciendo un trabajo enorme. Un puente es la puerta de entrada a la red; si el portero deja caer las llaves, no importa lo seguro que sea el cofre. La lista negra de Web Wallet que sacaron con rapidez es también un recordatorio contundente de que, aunque Dusk habla de cumplimiento descentralizado, la arquitectura sigue inclinándose hacia controles administrativos impulsados por multisig.
y para ser justos, los desarrolladores no están durmiendo. Estaban empujando mejoras en la UX del bridging de DuskEVM casi de inmediato, compitiendo para volver a poner el testnet en línea antes de que la liquidez se dispersara. El enfoque del desarrollo ha cambiado claramente del consenso del nodo central de Rusk hacia la capa de compatibilidad con EVM y la UX segura del bridging.
cuando lo comparo con el ethos de Ethereum, cuando un contrato inteligente tiene un problema, es inmutable; a menudo resulta en pérdidas catastróficas para los usuarios, pero con cero intervención administrativa. Dusk eligió el camino contrario: contención centralizada mediante contratos inteligentes actualizables para proteger a los usuarios, pero a costa de la narrativa de "imparable".
Así que, si una cadena de privacidad conforme requiere controles multisig para pausar fondos y poner en lista negra direcciones en el momento en que se filtra una clave, ¿qué exactamente estamos comprando? ¿Es solo TradFi con pasos extra, o el control administrativo es el producto, no el fallo?