POR QUÉ UN EVENTO DE BLOCKCHAIN NO ES LO MISMO QUE LA FINALIDAD
Antes pensaba que un exchange principalmente necesitaba saber cuándo ocurría una transacción en blockchain. Pero al ver Dusk, me hizo cuestionarlo. Si una transacción aún puede cambiar, no estoy seguro de que un exchange deba tratar ese evento como si fuera dinero final.
Por eso RUES (Rusk Universal Event System) llamó mi atención. Dusk específicamente lista RUES para infraestructura, indexadores y exchanges. Para mí, lo interesante es lo que hace el exchange después de recibir el evento.
El ciclo de vida de las transacciones de Dusk separa incluidas, ejecutadas, confirmadas y finalizadas. Su documentación dice que hay que supervisar las transacciones ejecutadas, comprobar si hay errores, confirmar que el bloque está finalizado y volver a escuchar si un bloque se revierte. Veo por qué esto importa: acreditar a un exchange demasiado pronto podría convertir un estado temporal en un saldo real.
Sigo pensando en el seguimiento de paquetería. Si mi paquete dice “en camino para la entrega”, sé que se está moviendo, pero no lo marcaría como entregado todavía. Quizá estoy siendo demasiado prudente, pero entiendo por qué un exchange querría esa misma brecha entre “en movimiento” y “entregado”.
El detalle de la idempotencia me hizo detenerme de nuevo. Dusk indica a los scanners de depósitos que usen el ID de transacción de Dusk como clave de idempotencia, no el memo, y que escriban el crédito y el checkpoint del bloque de forma atómica. Así, si el scanner falla y vuelve a escanear el mismo rango, esa transacción no debería convertirse en un segundo depósito.
Y ahora me pregunto si estaba mirando RUES de forma demasiado simple. Si un exchange tiene que pensar por separado en el evento, la finalidad, las reversiones y el procesamiento duplicado, ¿cuánto del trabajo real está ocurriendo en verdad después de que la blockchain dice que “pasó algo”? @Dusk #dusk $DUSK
Antes pensaba que un exchange principalmente necesitaba saber cuándo ocurría una transacción en blockchain. Pero al ver Dusk, me hizo cuestionarlo. Si una transacción aún puede cambiar, no estoy seguro de que un exchange deba tratar ese evento como si fuera dinero final.
Por eso RUES (Rusk Universal Event System) llamó mi atención. Dusk específicamente lista RUES para infraestructura, indexadores y exchanges. Para mí, lo interesante es lo que hace el exchange después de recibir el evento.
El ciclo de vida de las transacciones de Dusk separa incluidas, ejecutadas, confirmadas y finalizadas. Su documentación dice que hay que supervisar las transacciones ejecutadas, comprobar si hay errores, confirmar que el bloque está finalizado y volver a escuchar si un bloque se revierte. Veo por qué esto importa: acreditar a un exchange demasiado pronto podría convertir un estado temporal en un saldo real.
Sigo pensando en el seguimiento de paquetería. Si mi paquete dice “en camino para la entrega”, sé que se está moviendo, pero no lo marcaría como entregado todavía. Quizá estoy siendo demasiado prudente, pero entiendo por qué un exchange querría esa misma brecha entre “en movimiento” y “entregado”.
El detalle de la idempotencia me hizo detenerme de nuevo. Dusk indica a los scanners de depósitos que usen el ID de transacción de Dusk como clave de idempotencia, no el memo, y que escriban el crédito y el checkpoint del bloque de forma atómica. Así, si el scanner falla y vuelve a escanear el mismo rango, esa transacción no debería convertirse en un segundo depósito.
Y ahora me pregunto si estaba mirando RUES de forma demasiado simple. Si un exchange tiene que pensar por separado en el evento, la finalidad, las reversiones y el procesamiento duplicado, ¿cuánto del trabajo real está ocurriendo en verdad después de que la blockchain dice que “pasó algo”? @Dusk #dusk $DUSK