#dusk $DUSK @Dusk
Ayer estaba leyendo la documentación de integración de intercambios de Dusk cuando me quedé atascado en una situación que parecía casi trivial: se había enviado un retiro, pero la solicitud agotó el tiempo de espera. Mi primera intuición fue enviarlo de nuevo. Luego me detuve: ¿y si la primera transacción ya había llegado a la red?
Dusk cubre exactamente ese punto ciego. Cada retiro se construye y firma una sola vez, con los bytes firmados exactos y el ID de transacción almacenados antes de la difusión. Si ocurre un tiempo de espera en el transporte, el intercambio vuelve a difundir la misma transacción en lugar de crear una nueva a ciegas.
Ese detalle me hizo reflexionar. “No ha ocurrido” y “no sé si ocurrió” son dos estados completamente distintos. Si un sistema los trata como lo mismo, lo que parece un reintento puede convertirse en otra transacción que el sistema luego tiene que distinguir de la primera. Con el reemplazo de nonce (misma cuenta), Dusk exige que se registren ambos IDs de transacción sin debitar dos veces.
Eso me llevó a una idea más grande: la infraestructura financiera no solo necesita distinguir entre éxito y fallo. También tiene que mantenerse segura durante el periodo en el que todavía no sabe en qué estado se encuentra.
Así que esto es lo que me intriga sobre Dusk: a medida que más sistemas financieros se conectan a la red, ¿cuál será la prueba más difícil: gestionar una transacción que claramente ha fallado, o gestionar una cuando el remitente aún no puede estar seguro de si ocurrió o no?
Ayer estaba leyendo la documentación de integración de intercambios de Dusk cuando me quedé atascado en una situación que parecía casi trivial: se había enviado un retiro, pero la solicitud agotó el tiempo de espera. Mi primera intuición fue enviarlo de nuevo. Luego me detuve: ¿y si la primera transacción ya había llegado a la red?
Dusk cubre exactamente ese punto ciego. Cada retiro se construye y firma una sola vez, con los bytes firmados exactos y el ID de transacción almacenados antes de la difusión. Si ocurre un tiempo de espera en el transporte, el intercambio vuelve a difundir la misma transacción en lugar de crear una nueva a ciegas.
Ese detalle me hizo reflexionar. “No ha ocurrido” y “no sé si ocurrió” son dos estados completamente distintos. Si un sistema los trata como lo mismo, lo que parece un reintento puede convertirse en otra transacción que el sistema luego tiene que distinguir de la primera. Con el reemplazo de nonce (misma cuenta), Dusk exige que se registren ambos IDs de transacción sin debitar dos veces.
Eso me llevó a una idea más grande: la infraestructura financiera no solo necesita distinguir entre éxito y fallo. También tiene que mantenerse segura durante el periodo en el que todavía no sabe en qué estado se encuentra.
Así que esto es lo que me intriga sobre Dusk: a medida que más sistemas financieros se conectan a la red, ¿cuál será la prueba más difícil: gestionar una transacción que claramente ha fallado, o gestionar una cuando el remitente aún no puede estar seguro de si ocurrió o no?