Revisé otra vez, este año, el informe de la re-ejecución del puente entre cadenas, con el número de revisión @Dusk . Lo más valioso que se puede ver no son las dos palabras “fue robado”, sino en qué capa ocurrió exactamente la falla. El 16 de enero el problema estuvo en la wallet de firmas usada por el servicio del puente: el atacante, después de obtener permisos para liberar préstamos, transfirió los activos desde el lado de Dusk y luego envió una parte hacia BSC. La versión oficial es clara: esto no fue un fallo de consenso ni una brecha del protocolo de la capa L1.
Pero eso no significa que la capa base esté bien y que los usuarios deban ignorar el riesgo del puente. La arquitectura antigua concentraba la recepción de eventos, las firmas y la liberación de fondos en una sola ruta: es rápida, sí, pero si el lado de las firmas cae, los permisos quedan demasiado centralizados. El rediseño posterior separó esas tres cosas: primero el evento se guarda como una tarea y el worker la procesa según la máquina de estados; las transacciones originales firmadas se guardan primero y, si falla, se reejecuta la misma; la wallet caliente solo conserva el saldo necesario para el periodo reciente, si baja del umbral se pausa, y la wallet fría se completa manualmente.
Antes yo también era fácil caer en la frase de “el puente no es un protocolo” como si fuera una excusa. Ahora prefiero verlo al revés: siempre que el usuario lo trate como una puerta de liquidez, el puente ya está entrando en el límite real de seguridad $DUSK . La seguridad del consenso on-chain y la seguridad de las entradas/salidas de activos son dos exámenes que deben aprobarse al mismo tiempo.
La dirección de la mitigación en esta ocasión es correcta, pero el punto de riesgo no desaparece: hay que seguir vigilando si el aislamiento de claves se ejecuta a largo plazo, si el umbral es razonable, y si el apagado y el reabastecimiento pueden auditarse. #dusk En la comunidad, la pregunta que más deberían hacer no es “¿la cadena fue hackeada?”, sino “¿cuál de esas llaves todavía tiene un poder que excede lo necesario?”. Ustedes, cuando miren un puente entre cadenas: ¿primero miran la auditoría del código o primero miran cómo se recortan los permisos operativos?
$TREE $ETH
Pero eso no significa que la capa base esté bien y que los usuarios deban ignorar el riesgo del puente. La arquitectura antigua concentraba la recepción de eventos, las firmas y la liberación de fondos en una sola ruta: es rápida, sí, pero si el lado de las firmas cae, los permisos quedan demasiado centralizados. El rediseño posterior separó esas tres cosas: primero el evento se guarda como una tarea y el worker la procesa según la máquina de estados; las transacciones originales firmadas se guardan primero y, si falla, se reejecuta la misma; la wallet caliente solo conserva el saldo necesario para el periodo reciente, si baja del umbral se pausa, y la wallet fría se completa manualmente.
Antes yo también era fácil caer en la frase de “el puente no es un protocolo” como si fuera una excusa. Ahora prefiero verlo al revés: siempre que el usuario lo trate como una puerta de liquidez, el puente ya está entrando en el límite real de seguridad $DUSK . La seguridad del consenso on-chain y la seguridad de las entradas/salidas de activos son dos exámenes que deben aprobarse al mismo tiempo.
La dirección de la mitigación en esta ocasión es correcta, pero el punto de riesgo no desaparece: hay que seguir vigilando si el aislamiento de claves se ejecuta a largo plazo, si el umbral es razonable, y si el apagado y el reabastecimiento pueden auditarse. #dusk En la comunidad, la pregunta que más deberían hacer no es “¿la cadena fue hackeada?”, sino “¿cuál de esas llaves todavía tiene un poder que excede lo necesario?”. Ustedes, cuando miren un puente entre cadenas: ¿primero miran la auditoría del código o primero miran cómo se recortan los permisos operativos?
$TREE $ETH
