Ya no interpreto la pausa del puente de Dusk como una simple historia de tiempo de inactividad cuando vi que una transferencia de 8.91 millones de DUSK falló 15m55s después del apagado, mientras DuskDS seguía produciendo bloques.
La métrica fácil es cero tiempo de inactividad del protocolo. Es útil, pero incompleta. Cuatro transacciones de robo retiraron 10.91 millones de DUSK, pero solo 1.919 millones, o el 17.6%, lograron cruzar con éxito a BSC. El disyuntor del puente limitó la salida, no la comprometida billetera original.
Esa separación importa. DuskDS aún podía liquidar transacciones nativas mientras las rutas de liquidez externa estaban cerradas. La disponibilidad de la capa base y la disponibilidad del ecosistema no son lo mismo. Si las billeteras, los RPC, los exploradores o cada puente importante no están disponibles, ¿DUSK está operativo para los usuarios o simplemente vivo para los validadores?
Querría que Dusk publicara cinco relojes separados: disponibilidad de la cadena, RPC, explorador, billetera y puente, además de bloques producidos, finalización mediana, rendimiento, nuevas cuentas y actividad nativa versus la dependiente del puente durante la pausa. Sin esas series, “no afectado” describe el consenso, no la demanda.
No hubo fondos de usuarios ni fallo del protocolo es significativo. Aun así, la prueba más difícil es el comportamiento: si la actividad nativa se mantuvo cuando se detuvieron las entradas, y qué costo de oportunidad se acumuló en cada día fuera de línea.
El incidente mostró que la cadena podía sobrevivir al gateway. Aún no demostró que el ecosistema pudiera ignorarlo.
#dusk $DUSK @Dusk
La métrica fácil es cero tiempo de inactividad del protocolo. Es útil, pero incompleta. Cuatro transacciones de robo retiraron 10.91 millones de DUSK, pero solo 1.919 millones, o el 17.6%, lograron cruzar con éxito a BSC. El disyuntor del puente limitó la salida, no la comprometida billetera original.
Esa separación importa. DuskDS aún podía liquidar transacciones nativas mientras las rutas de liquidez externa estaban cerradas. La disponibilidad de la capa base y la disponibilidad del ecosistema no son lo mismo. Si las billeteras, los RPC, los exploradores o cada puente importante no están disponibles, ¿DUSK está operativo para los usuarios o simplemente vivo para los validadores?
Querría que Dusk publicara cinco relojes separados: disponibilidad de la cadena, RPC, explorador, billetera y puente, además de bloques producidos, finalización mediana, rendimiento, nuevas cuentas y actividad nativa versus la dependiente del puente durante la pausa. Sin esas series, “no afectado” describe el consenso, no la demanda.
No hubo fondos de usuarios ni fallo del protocolo es significativo. Aun así, la prueba más difícil es el comportamiento: si la actividad nativa se mantuvo cuando se detuvieron las entradas, y qué costo de oportunidad se acumuló en cada día fuera de línea.
El incidente mostró que la cadena podía sobrevivir al gateway. Aún no demostró que el ecosistema pudiera ignorarlo.
#dusk $DUSK @Dusk