UNA TRANSACCIÓN A LA SOMBRA PUEDE “ACEPTARSE” ANTES DE QUE EL INTERCAMBIO TENGA QUE TRATARLA COMO HECHA.
Estaba leyendo la API de transacciones del @Dusk y un código de estado terminó molestándome más de lo habitual en el debate sobre la finalización:
202 Accepted.
Cuando un nodo de Dusk devuelve 202 después de que una transacción se haya propagado, significa que la transacción se ha aceptado para el enrutamiento.
Aún no prueba que haya entrado al mempool real, que haya llegado a pares, que se haya ejecutado correctamente o que se haya vuelto final.
Eso suena a un detalle pequeño de la API.
Para un intercambio que procesa retiros, no creo que lo sea.
Mentalmente había estado tratando el procesamiento de retiros como algo cercano a:
enviar transacción → la red la acepta → esperar la finalidad → cerrar el retiro.
Pero hay un estado incómodo en el medio donde el intercambio ha enviado algo y aún no tiene suficiente información para llamar con seguridad a la acción económica como completada.
Eso cambia el problema.
Enviar la transacción no es lo mismo que completar la transacción.
Y reintentar una solicitud fallida de la API no necesariamente es lo mismo que decidir que el retiro original nunca existió.
La documentación de Dusk incluso advierte que un servicio de firma necesita serializar la asignación de nonces, conservar las transacciones enviadas y comprobar el estado pendiente y confirmado de la cuenta antes de reutilizar un nonce.
Esta es la parte que me resulta interesante.
La finalización determinista puede hacer que el final de una transacción sea muy claro.
No puede hacer automáticamente que cada estado antes de la finalización sea igual de fácil para que un intercambio lo gestione.
Así que, si yo estuviera evaluando una integración seria de Dusk, no solo mediría la velocidad de liquidación.
Querría saber qué ocurre durante fallas de nodos, timeouts y envíos ambiguos:
¿Cuántos retiros pueden recuperarse automáticamente sin crear instrucciones duplicadas o sin requerir que alguien decida manualmente qué pasó?
La mejor infraestructura de transacciones quizá sea aquella en la que la ruta de fallo se vuelve aburrida.
Eso parece mucho más difícil que hacer que la ruta feliz sea rápida.
#dusk $DUSK @Dusk
$GPS $TUT
Estaba leyendo la API de transacciones del @Dusk y un código de estado terminó molestándome más de lo habitual en el debate sobre la finalización:
202 Accepted.
Cuando un nodo de Dusk devuelve 202 después de que una transacción se haya propagado, significa que la transacción se ha aceptado para el enrutamiento.
Aún no prueba que haya entrado al mempool real, que haya llegado a pares, que se haya ejecutado correctamente o que se haya vuelto final.
Eso suena a un detalle pequeño de la API.
Para un intercambio que procesa retiros, no creo que lo sea.
Mentalmente había estado tratando el procesamiento de retiros como algo cercano a:
enviar transacción → la red la acepta → esperar la finalidad → cerrar el retiro.
Pero hay un estado incómodo en el medio donde el intercambio ha enviado algo y aún no tiene suficiente información para llamar con seguridad a la acción económica como completada.
Eso cambia el problema.
Enviar la transacción no es lo mismo que completar la transacción.
Y reintentar una solicitud fallida de la API no necesariamente es lo mismo que decidir que el retiro original nunca existió.
La documentación de Dusk incluso advierte que un servicio de firma necesita serializar la asignación de nonces, conservar las transacciones enviadas y comprobar el estado pendiente y confirmado de la cuenta antes de reutilizar un nonce.
Esta es la parte que me resulta interesante.
La finalización determinista puede hacer que el final de una transacción sea muy claro.
No puede hacer automáticamente que cada estado antes de la finalización sea igual de fácil para que un intercambio lo gestione.
Así que, si yo estuviera evaluando una integración seria de Dusk, no solo mediría la velocidad de liquidación.
Querría saber qué ocurre durante fallas de nodos, timeouts y envíos ambiguos:
¿Cuántos retiros pueden recuperarse automáticamente sin crear instrucciones duplicadas o sin requerir que alguien decida manualmente qué pasó?
La mejor infraestructura de transacciones quizá sea aquella en la que la ruta de fallo se vuelve aburrida.
Eso parece mucho más difícil que hacer que la ruta feliz sea rápida.
#dusk $DUSK @Dusk
$GPS $TUT