#dusk $DUSK
Recientemente seguí revisando el documento sobre el ciclo de vida de las transacciones de @Dusk , y recién entonces me di cuenta de que antes había simplificado demasiado una cuestión:
Que una transacción se ejecute correctamente no significa que ese estado ya pueda tratarse como “un hecho” por el sistema financiero.
En DuskDS, una transacción primero se recibe, se propaga y se ejecuta; luego todavía debe pasar por la confirmación final.
La documentación oficial incluso lo advierte específicamente:
included, accepted y confirmed no pueden tomarse directamente como payment finality.
La razón no es complicada.
Una transacción entra en un bloque “accepted”, pero ese bloque todavía podría revertirse.
Solo cuando llega a finalized es cuando el estado entra en una finality determinista.
En la Succinct Attestation de Dusk, se continúa por:
Proposal
→ Validation
→ Ratification
Hasta que se completa la Ratification, el bloque realmente finaliza.
Creo que este detalle vale más la pena que mirar “cuántos TPS”.
Porque lo que más temen los exchanges o los sistemas financieros no es ver una transacción unos segundos tarde.
Lo que temen es:
Que yo haya abonado al usuario en función de ese estado, y luego el estado subyacente cambie.
Por eso, la documentación de integración para exchanges de Dusk también es clara: no se debe contabilizar anticipadamente el registro de la contabilidad solo por mempool, el evento included o un bloque accepted-but-unfinalized.
En realidad, esto explica la finality de manera muy práctica.
No es una palabra de rendimiento.
Sino que responde a:
¿En qué momento exacto empieza el sistema a no tener que preocuparse de que se revoque ese estado?
En el sitio oficial de Dusk, la métrica de finality que se da es de aproximadamente 10 segundos.
No me preocupa tanto si este número luce bien.
Lo que más me importa es que, una vez que la red principal soporte carga real, el límite entre accepted y finalized pueda mantenerse siempre claro y estable.
Al final, lo que de verdad depende el sistema financiero sigue siendo esto.
Recientemente seguí revisando el documento sobre el ciclo de vida de las transacciones de @Dusk , y recién entonces me di cuenta de que antes había simplificado demasiado una cuestión:
Que una transacción se ejecute correctamente no significa que ese estado ya pueda tratarse como “un hecho” por el sistema financiero.
En DuskDS, una transacción primero se recibe, se propaga y se ejecuta; luego todavía debe pasar por la confirmación final.
La documentación oficial incluso lo advierte específicamente:
included, accepted y confirmed no pueden tomarse directamente como payment finality.
La razón no es complicada.
Una transacción entra en un bloque “accepted”, pero ese bloque todavía podría revertirse.
Solo cuando llega a finalized es cuando el estado entra en una finality determinista.
En la Succinct Attestation de Dusk, se continúa por:
Proposal
→ Validation
→ Ratification
Hasta que se completa la Ratification, el bloque realmente finaliza.
Creo que este detalle vale más la pena que mirar “cuántos TPS”.
Porque lo que más temen los exchanges o los sistemas financieros no es ver una transacción unos segundos tarde.
Lo que temen es:
Que yo haya abonado al usuario en función de ese estado, y luego el estado subyacente cambie.
Por eso, la documentación de integración para exchanges de Dusk también es clara: no se debe contabilizar anticipadamente el registro de la contabilidad solo por mempool, el evento included o un bloque accepted-but-unfinalized.
En realidad, esto explica la finality de manera muy práctica.
No es una palabra de rendimiento.
Sino que responde a:
¿En qué momento exacto empieza el sistema a no tener que preocuparse de que se revoque ese estado?
En el sitio oficial de Dusk, la métrica de finality que se da es de aproximadamente 10 segundos.
No me preocupa tanto si este número luce bien.
Lo que más me importa es que, una vez que la red principal soporte carga real, el límite entre accepted y finalized pueda mantenerse siempre claro y estable.
Al final, lo que de verdad depende el sistema financiero sigue siendo esto.