""Espera 12 confirmaciones"" es el consejo estándar en la mayoría de las cadenas, y honestamente nadie explica por qué 12, ni qué está pasando realmente durante esos bloques. Dusk no usa ese atajo: ejecuta una máquina de estados real para decidir cuándo un bloque es seguro.
Un bloque pasa por cuatro estados: aceptado, atestiguado, confirmado y final. El punto de partida depende de un número: cuántas iteraciones previas en esa ronda fallaron antes de que la iteración de este bloque tuviera éxito. El documento lo llama n. Si n = 0, es decir, el bloque cayó en la primera iteración con cero fallos antes de él, se marca como atestiguado inmediatamente. Si n es mayor que 0, o sea, primero fallaron iteraciones anteriores en esa misma ronda, el bloque solo se marca como aceptado, que es un estado más débil.
La diferencia importa porque un bloque aceptado todavía puede ser reemplazado por un bloque competidor de una iteración menor; aún no es seguro. Un bloque atestiguado no puede ser reemplazado de esa manera, ya que no queda ninguna iteración inferior capaz de superarlo. A partir de ahí, confirmado simplemente significa que el bloque tiene suficientes bloques sucesores correctos apilados encima, y final significa que toda su cadena de antecesores también es final, bloqueándolo de forma permanente.
La parte que me parece genuinamente infravalorada aquí es el ejemplo del propio documento: un bloque en la iteración 5, donde solo dos de las iteraciones previas tienen atestaciones de fallo, se marca como aceptado y necesita cuatro bloques más atestiguados o confirmados apilados encima antes de que se confirme. Eso no es un número arbitrario de confirmaciones sacado de la nada: es un valor calculado directamente a partir de lo enrevesada que fue esa ronda específica. Una ronda limpia se finaliza más rápido. Una ronda áspera tarda más. Es un modelo muy distinto de "simplemente espera 12 bloques sin importar lo que haya pasado".
Si soy totalmente honesto, esto se siente como un tipo de detalle de diseño que importa muchísimo más a las instituciones que evalúan la finalización del asentamiento que a los traders minoristas: nadie que cambie tokens se preocupa por los recuentos de iteración, pero un banco ejecutando un asentamiento de valores absolutamente sí.
@Dusk
$DUSK
#dusk
Un bloque pasa por cuatro estados: aceptado, atestiguado, confirmado y final. El punto de partida depende de un número: cuántas iteraciones previas en esa ronda fallaron antes de que la iteración de este bloque tuviera éxito. El documento lo llama n. Si n = 0, es decir, el bloque cayó en la primera iteración con cero fallos antes de él, se marca como atestiguado inmediatamente. Si n es mayor que 0, o sea, primero fallaron iteraciones anteriores en esa misma ronda, el bloque solo se marca como aceptado, que es un estado más débil.
La diferencia importa porque un bloque aceptado todavía puede ser reemplazado por un bloque competidor de una iteración menor; aún no es seguro. Un bloque atestiguado no puede ser reemplazado de esa manera, ya que no queda ninguna iteración inferior capaz de superarlo. A partir de ahí, confirmado simplemente significa que el bloque tiene suficientes bloques sucesores correctos apilados encima, y final significa que toda su cadena de antecesores también es final, bloqueándolo de forma permanente.
La parte que me parece genuinamente infravalorada aquí es el ejemplo del propio documento: un bloque en la iteración 5, donde solo dos de las iteraciones previas tienen atestaciones de fallo, se marca como aceptado y necesita cuatro bloques más atestiguados o confirmados apilados encima antes de que se confirme. Eso no es un número arbitrario de confirmaciones sacado de la nada: es un valor calculado directamente a partir de lo enrevesada que fue esa ronda específica. Una ronda limpia se finaliza más rápido. Una ronda áspera tarda más. Es un modelo muy distinto de "simplemente espera 12 bloques sin importar lo que haya pasado".
Si soy totalmente honesto, esto se siente como un tipo de detalle de diseño que importa muchísimo más a las instituciones que evalúan la finalización del asentamiento que a los traders minoristas: nadie que cambie tokens se preocupa por los recuentos de iteración, pero un banco ejecutando un asentamiento de valores absolutamente sí.
@Dusk
$DUSK
#dusk
