Estaba rastreando cómo Dusk realmente finaliza bloques, porque la frase de marketing es siempre "finalidad irreversible en segundos". Técnicamente es cierto. Pero la documentación desglosa el estado de los bloques en etapas: Aceptado, Confirmado, Estable, Final, y ahí fue donde se puso interesante.
Que un bloque esté "Aceptado" solo significa que pasó los tres pasos de consenso de la ronda actual. Aún puede reorganizarse. "Confirmado" significa que los bloques posteriores se construyen sobre él. Solo "Final" es el estado determinísticamente garantizado y criptográficamente irreversible, donde los bloques se finalizan mediante atestaciones criptográficas explícitas en lugar de confirmaciones probabilísticas
Así que la brecha no está en el diseño del consenso: Succinct Attestation realmente evita el asentamiento probabilístico al estilo Nakamoto. La brecha está en cuándo una billetera, un exchange o un integrador trata un bloque como liquidado. Si un usuario o una app lee "Aceptado" como si fuera final, eso no es una falla de protocolo: es una suposición de UX montada sobre un protocolo que en realidad se construyó para evitar exactamente ese error.
Para la liquidación de activos regulados, esa distinción no es meramente estética: es la diferencia entre un evento de compensación conforme y uno prematuro.
Aun así, me pregunto cómo los integradores más conservadores ajustan su configuración predeterminada aquí cuando el volumen de transacciones en $DUSK scales supera un puñado de comités de provisioner por ronda.
@Dusk #DUSK
Que un bloque esté "Aceptado" solo significa que pasó los tres pasos de consenso de la ronda actual. Aún puede reorganizarse. "Confirmado" significa que los bloques posteriores se construyen sobre él. Solo "Final" es el estado determinísticamente garantizado y criptográficamente irreversible, donde los bloques se finalizan mediante atestaciones criptográficas explícitas en lugar de confirmaciones probabilísticas
Así que la brecha no está en el diseño del consenso: Succinct Attestation realmente evita el asentamiento probabilístico al estilo Nakamoto. La brecha está en cuándo una billetera, un exchange o un integrador trata un bloque como liquidado. Si un usuario o una app lee "Aceptado" como si fuera final, eso no es una falla de protocolo: es una suposición de UX montada sobre un protocolo que en realidad se construyó para evitar exactamente ese error.
Para la liquidación de activos regulados, esa distinción no es meramente estética: es la diferencia entre un evento de compensación conforme y uno prematuro.
Aun así, me pregunto cómo los integradores más conservadores ajustan su configuración predeterminada aquí cuando el volumen de transacciones en $DUSK scales supera un puñado de comités de provisioner por ronda.
@Dusk #DUSK