Antes veía la confirmación en bloques como algo muy simple: metes una transacción en un bloque, cuentas unos cuantos bloques hacia adelante y ya casi la das por segura. Pero esta noche, al revisar el documento del ciclo de vida de la transacción @Dusk , una sola frase me dejó bloqueado: "accepted blocks can still be reverted". Si ya fue aceptado, ¿por qué aún se puede revertir?
Luego, al revisar el Whitepaper de 2024, lo entendí. El consenso de una ronda en Dusk pasa por varias iteraciones; en la misma ronda pueden aparecer bloques en competencia. Los bloques de iteración más alta, aunque ya estén aceptados, si existe un bloque competitivo de iteración más baja que cumple las condiciones, todavía puede activarse el mecanismo de fallback.
Rolling Finality es aún más contraintuitivo. El whitepaper usa n para indicar la cantidad de iteraciones cuyo proceso de attestation aún no está completado y define determinación. Para que un bloque aceptado pase a "confirmed", debe esperar 2×n bloques consecutivos posteriores que estén attested o confirmed. Supongamos n=3: entonces hay que observar los 6 bloques posteriores que cumplan las condiciones.
Ahí fue cuando descubrí que "número de confirmaciones" no es una medida universal. Aunque algo esté en cadena, historias diferentes del consenso significan niveles de estabilidad distintos.
El consejo que dan los Docs actuales es incluso más directo: no tomes included, accepted ni confirmed como una señal de que el pago ya está hecho; hay que esperar a que sea realmente finalized.
Las transferencias pequeñas pueden diferir solo por unos segundos; pero si se trata de una entrega de tipo DvP en OTC de gran importe o en RWA, "ver la transacción" y "liquidación irrevocable" son cosas completamente distintas. En adelante, al mirar transacciones grandes en Dusk, solo pregunta: ¿ya está finalized?
#dusk $DUSK @Dusk
Luego, al revisar el Whitepaper de 2024, lo entendí. El consenso de una ronda en Dusk pasa por varias iteraciones; en la misma ronda pueden aparecer bloques en competencia. Los bloques de iteración más alta, aunque ya estén aceptados, si existe un bloque competitivo de iteración más baja que cumple las condiciones, todavía puede activarse el mecanismo de fallback.
Rolling Finality es aún más contraintuitivo. El whitepaper usa n para indicar la cantidad de iteraciones cuyo proceso de attestation aún no está completado y define determinación. Para que un bloque aceptado pase a "confirmed", debe esperar 2×n bloques consecutivos posteriores que estén attested o confirmed. Supongamos n=3: entonces hay que observar los 6 bloques posteriores que cumplan las condiciones.
Ahí fue cuando descubrí que "número de confirmaciones" no es una medida universal. Aunque algo esté en cadena, historias diferentes del consenso significan niveles de estabilidad distintos.
El consejo que dan los Docs actuales es incluso más directo: no tomes included, accepted ni confirmed como una señal de que el pago ya está hecho; hay que esperar a que sea realmente finalized.
Las transferencias pequeñas pueden diferir solo por unos segundos; pero si se trata de una entrega de tipo DvP en OTC de gran importe o en RWA, "ver la transacción" y "liquidación irrevocable" son cosas completamente distintas. En adelante, al mirar transacciones grandes en Dusk, solo pregunta: ¿ya está finalized?
#dusk $DUSK @Dusk
