Antes pensaba que “la pausa automática por saldo insuficiente” era una mala experiencia, pero después de leer el informe de reconstrucción del incidente de puente con el código de enlace @Dusk entendí que, si se pausa antes, tal vez sea más bien una forma de hacerse responsable de los activos.
El informe está escrito de manera muy directa: el nuevo puente deja el saldo mínimo operativo únicamente en el extremo del firmante; si baja del umbral, se detiene, y solo se reanuda después de que la billetera fría se reponga manualmente. El puente anterior ponía la firma, el manejo de eventos y la conexión de red en la misma ruta; tras un acceso no autorizado a la billetera de firma, el atacante no necesitaba tocar el consenso de Dusk para poder usar el dinero dentro del puente.
Este umbral no es un simple interruptor de límites. Si el servicio entre cadenas se encarga de transportar los activos del usuario, no puede poner “que el servicio no se detenga” por delante de “poner más dinero en caliente”. La parte operativa obtiene una ventana de pérdidas menor; para los usuarios que esperan la migración, el costo que pagan es un tiempo real.
Cuando hay volatilidad de mercado, muchos usuarios migran al mismo tiempo. Si el puente se pausa por tener un saldo bajo, la transacción del usuario quizá no falle, pero podría quedar atascada en una cola mientras espera el reabastecimiento. Si la página solo muestra “en mantenimiento”, el usuario no puede distinguir si el dinero no llegó, si la solicitud no se procesó, o si el sistema activó de forma proactiva un control de riesgos.
Estoy de acuerdo con que $DUSK haya cedido parte de la disponibilidad a la separación y la contención, pero eso no significa que el riesgo del puente ya haya desaparecido. Para comprobar si esta reconstrución funcionó, hay que ver si @Dusk puede seguir publicando el número de pausas, cuánto tiempo tarda en reanudar y cómo se terminan limpiando las solicitudes acumuladas.#dusk