#dusk $DUSK Las indicaciones más peligrosas en el back-end de valores: no necesariamente es un “fracaso”, sino un “ya ha sido aceptado”. Un fracaso al menos hace que la gente se detenga; “ya aceptado” se entiende con mucha facilidad como si dinero y mercancía quedaran saldados. En la cadena también es igual: que un bloque entre en el libro contable local no significa que ya haya llegado al último paso absoluto e inreemplazable.
Releí el whitepaper @Dusk sobre Rolling Finality y entendí que Dusk no mezcló todas las “confirmaciones” en una sola palabra, sino que las dividió en cuatro estados: accepted, attested, confirmed y final. Aunque un bloque accepted ya obtuvo una prueba de éxito, si proviene de una iteración más alta y en las iteraciones anteriores más bajas no existía una prueba de fallo, cuando más tarde aparezca un bloque válido de una iteración más baja, aún puede ser reemplazado; y los bloques posteriores también retrocederán.
attested es más sólido, porque proviene de la iteración 0 o porque iteraciones anteriores ya dejaron pruebas de fallo; confirmed requiere además que los bloques posteriores sigan aportando credibilidad a la cadena actual; solo final significa que el bloque padre también ya está final, toda la ruta de ancestros queda cerrada y ya no puede reemplazarse.
El whitepaper ofrece un ejemplo concreto: un bloque se genera en la quinta iteración, pero antes solo había dos iteraciones con pruebas de fallo; primero se marca como accepted. Luego hay que esperar 4 bloques consecutivos de attested o confirmed para pasar a confirmed. Es decir, entre “ya se ha producido el bloque” y “se puede considerar la entrega de valores como un hecho irrevocable” realmente puede haber varios pasos.
Aprecio esta honestidad. El sistema financiero teme más que la probabilidad se oculte tras un tilde verde. Pero también deja tarea al producto: ¿las billeteras, los lugares de intercambio y los sistemas de registro muestran de verdad qué estado es? Cuando el usuario ve accepted, ¿puede seguir transfiriendo o canjeando? Si la interfaz unifica todo bajo la palabra “éxito”, incluso un estado de consenso tan riguroso puede quedar borrado por el copy del producto.
Por eso, cuando observo la finalización por segundos de Dusk, no solo miro cuántos segundos se usan en promedio: también miro la distribución de cómo se pasa de accepted a final bajo iteraciones anómalas, y si la aplicación realmente espera hasta final para dar por cierto. La finalización no es un número de marketing, sino una disciplina que impide llamar “ya completado” a lo que en realidad es “casi completado”.
Releí el whitepaper @Dusk sobre Rolling Finality y entendí que Dusk no mezcló todas las “confirmaciones” en una sola palabra, sino que las dividió en cuatro estados: accepted, attested, confirmed y final. Aunque un bloque accepted ya obtuvo una prueba de éxito, si proviene de una iteración más alta y en las iteraciones anteriores más bajas no existía una prueba de fallo, cuando más tarde aparezca un bloque válido de una iteración más baja, aún puede ser reemplazado; y los bloques posteriores también retrocederán.
attested es más sólido, porque proviene de la iteración 0 o porque iteraciones anteriores ya dejaron pruebas de fallo; confirmed requiere además que los bloques posteriores sigan aportando credibilidad a la cadena actual; solo final significa que el bloque padre también ya está final, toda la ruta de ancestros queda cerrada y ya no puede reemplazarse.
El whitepaper ofrece un ejemplo concreto: un bloque se genera en la quinta iteración, pero antes solo había dos iteraciones con pruebas de fallo; primero se marca como accepted. Luego hay que esperar 4 bloques consecutivos de attested o confirmed para pasar a confirmed. Es decir, entre “ya se ha producido el bloque” y “se puede considerar la entrega de valores como un hecho irrevocable” realmente puede haber varios pasos.
Aprecio esta honestidad. El sistema financiero teme más que la probabilidad se oculte tras un tilde verde. Pero también deja tarea al producto: ¿las billeteras, los lugares de intercambio y los sistemas de registro muestran de verdad qué estado es? Cuando el usuario ve accepted, ¿puede seguir transfiriendo o canjeando? Si la interfaz unifica todo bajo la palabra “éxito”, incluso un estado de consenso tan riguroso puede quedar borrado por el copy del producto.
Por eso, cuando observo la finalización por segundos de Dusk, no solo miro cuántos segundos se usan en promedio: también miro la distribución de cómo se pasa de accepted a final bajo iteraciones anómalas, y si la aplicación realmente espera hasta final para dar por cierto. La finalización no es un número de marketing, sino una disciplina que impide llamar “ya completado” a lo que en realidad es “casi completado”.
