Después de la actualización de Dusk, entré en el navegador on-chain para ver el conteo de confirmaciones y descubrí un detalle fácil de pasar por alto: en Dusk, “bloque confirmado” no es un simple interruptor, sino una escalera de estados por niveles.
La mayoría interpreta la finalidad como una elección entre dos: o no está confirmado, o está confirmado y ya no es reversible. Pero el diseño de Rolling Finality es completamente distinto. Para que un bloque pase de ser generado a quedar totalmente bloqueado, debe atravesar cuatro etapas: primero accepted (aceptado), en la que todavía puede ser reemplazado por bloques candidato producidos en iteraciones anteriores; luego attested (atestiguado), al que solo se puede llegar si fallan todas las iteraciones anteriores, y ya no se reemplaza; después confirmed (confirmado), donde se necesita que haya acumulado cierta cantidad de bloques posteriores; y finalmente final (final), siempre que su bloque padre ya sea final, entonces el propio puede convertirse en final.
Lo más contraintuitivo de este mecanismo es que la cantidad de bloques posteriores que necesita un mismo bloque para mejorar no es un número fijo. En las reglas hay una variable n que indica cuántas iteraciones “no exitosas” ocurrieron antes de este bloque. Cuanto mayor es n, más bloques de confirmación posteriores se requieren, y además se calcula como 2^n. En otras palabras: cuanto más accidentado es el nacimiento de un bloque, más tiempo tomará que realmente quede bloqueado. Así que aunque el monedero diga “confirmado”, el nivel real de bloqueo puede variar mucho.
Las ventajas de este diseño son que los nodos pueden evaluar con más precisión si un bloque “vale la pena confiar”, en lugar de todo o nada. Pero el costo también es evidente: el usuario común no puede ver en qué nivel de confirmación se encuentra su transacción. El monedero solo muestra una indicación de “confirmación” y oculta por completo estas capas. Y cuando ocurre una bifurcación extrema, no está tan claro si esta brecha de información podría aprovecharse.
¿Ustedes suelen revisar específicamente hasta qué nivel de confirmación llegó la transacción, o solo confían en lo que dice el monedero cuando indica que está confirmada? Hablemos en los comentarios.#dusk $DUSK @Dusk
La mayoría interpreta la finalidad como una elección entre dos: o no está confirmado, o está confirmado y ya no es reversible. Pero el diseño de Rolling Finality es completamente distinto. Para que un bloque pase de ser generado a quedar totalmente bloqueado, debe atravesar cuatro etapas: primero accepted (aceptado), en la que todavía puede ser reemplazado por bloques candidato producidos en iteraciones anteriores; luego attested (atestiguado), al que solo se puede llegar si fallan todas las iteraciones anteriores, y ya no se reemplaza; después confirmed (confirmado), donde se necesita que haya acumulado cierta cantidad de bloques posteriores; y finalmente final (final), siempre que su bloque padre ya sea final, entonces el propio puede convertirse en final.
Lo más contraintuitivo de este mecanismo es que la cantidad de bloques posteriores que necesita un mismo bloque para mejorar no es un número fijo. En las reglas hay una variable n que indica cuántas iteraciones “no exitosas” ocurrieron antes de este bloque. Cuanto mayor es n, más bloques de confirmación posteriores se requieren, y además se calcula como 2^n. En otras palabras: cuanto más accidentado es el nacimiento de un bloque, más tiempo tomará que realmente quede bloqueado. Así que aunque el monedero diga “confirmado”, el nivel real de bloqueo puede variar mucho.
Las ventajas de este diseño son que los nodos pueden evaluar con más precisión si un bloque “vale la pena confiar”, en lugar de todo o nada. Pero el costo también es evidente: el usuario común no puede ver en qué nivel de confirmación se encuentra su transacción. El monedero solo muestra una indicación de “confirmación” y oculta por completo estas capas. Y cuando ocurre una bifurcación extrema, no está tan claro si esta brecha de información podría aprovecharse.
¿Ustedes suelen revisar específicamente hasta qué nivel de confirmación llegó la transacción, o solo confían en lo que dice el monedero cuando indica que está confirmada? Hablemos en los comentarios.#dusk $DUSK @Dusk