Vi a un validador de DUSK eliminarse del conjunto activo en la red de pruebas (testnet). No fue hackeado. No lo sancionaron con slashing. Simplemente lo retiraron. La razón fue la vivacidad: se perdieron demasiados votos de finalidad (finality) dentro de una ventana de 28 horas.
El sistema funcionó exactamente como estaba diseñado. Eso es lo que me inquietó.
El validador no perdió su saldo en garantía (bonded stake). No hubo castigo criptográfico. No hubo clave privada expuesta. Solo una salida silenciosa de la ronda de consenso. Y aquí está la parte que se me quedó grabada: la ventana de encarcelamiento (jailing) se mide en relación con un valor StartHeight que se restablece cada vez que el proveedor vuelve a unirse. Sale brevemente, vuelve, resetea el reloj y repite. Un operador crónicamente poco fiable puede eludir la eliminación permanente para siempre si no permanece desconectado el tiempo suficiente como para activar la penalización completa. La vía de la aplicación flexible (soft enforcement) es la que tiene el resquicio.
Seguí pensando en ese resquicio mientras veía cómo la comunidad de DUSK debatía si los proveedores de finalidad (finality providers) deberían tratarse como infraestructura o como socios. Alguien en el chat dijo: "Si el castigo por ser poco fiable es un tiempo de espera (timeout), entonces la poca fiabilidad es solo una estrategia con pasos extra". Nadie se rió. Porque todos sabían que un validador que restablece su propio reloj de encarcelamiento no está rompiendo las reglas. Está jugando con el ritmo de la aplicación.
Esa es la brecha entre seguridad técnica y seguridad práctica. El disparador criptográfico para el doble firmado es absoluto, implacable y automático. El disparador social para la pereza es una máquina de estados con un botón de reinicio. Uno protege la red del malice (malicia). El otro la protege del descuido. Y ahora mismo, el botón de reinicio pertenece al propio operador que debería estar limitado.
#dusk $DUSK @Dusk $EDEN $AKE
El sistema funcionó exactamente como estaba diseñado. Eso es lo que me inquietó.
El validador no perdió su saldo en garantía (bonded stake). No hubo castigo criptográfico. No hubo clave privada expuesta. Solo una salida silenciosa de la ronda de consenso. Y aquí está la parte que se me quedó grabada: la ventana de encarcelamiento (jailing) se mide en relación con un valor StartHeight que se restablece cada vez que el proveedor vuelve a unirse. Sale brevemente, vuelve, resetea el reloj y repite. Un operador crónicamente poco fiable puede eludir la eliminación permanente para siempre si no permanece desconectado el tiempo suficiente como para activar la penalización completa. La vía de la aplicación flexible (soft enforcement) es la que tiene el resquicio.
Seguí pensando en ese resquicio mientras veía cómo la comunidad de DUSK debatía si los proveedores de finalidad (finality providers) deberían tratarse como infraestructura o como socios. Alguien en el chat dijo: "Si el castigo por ser poco fiable es un tiempo de espera (timeout), entonces la poca fiabilidad es solo una estrategia con pasos extra". Nadie se rió. Porque todos sabían que un validador que restablece su propio reloj de encarcelamiento no está rompiendo las reglas. Está jugando con el ritmo de la aplicación.
Esa es la brecha entre seguridad técnica y seguridad práctica. El disparador criptográfico para el doble firmado es absoluto, implacable y automático. El disparador social para la pereza es una máquina de estados con un botón de reinicio. Uno protege la red del malice (malicia). El otro la protege del descuido. Y ahora mismo, el botón de reinicio pertenece al propio operador que debería estar limitado.
#dusk $DUSK @Dusk $EDEN $AKE