La semana pasada envié un paquete por mensajería y me equivoqué de un artículo. Después de contactar al servicio de atención al cliente, me explicaron: el estado logístico no es una cosa de blanco o negro de "enviado" y "no enviado". Entre medio hay etapas como "entregado/expedido", "en tránsito" y "recibido/firmado". En cada fase, ¿se puede interceptar o solicitar la devolución/recuperación? Las reglas son completamente distintas. Colgué el teléfono y de pronto pensé que la "confirmación" en la cadena de bloques funciona con esta misma lógica: no es simplemente un "confirmado" o un "no confirmado".
Por la parte de Dusk, el estado de los bloques se divide en cuatro niveles. Un bloque recién emitido, si en la primera ronda de votación pasa directamente, se llama "attested" (ya verificado). Si antes hubo rondas de votación que fallaron y ahora recién pasa, se llama "accepted" (ya aceptado); además, este bloque todavía podría ser reemplazado por bloques de rondas inferiores. Más adelante, en el camino, los bloques "attested" pasan a ser "confirmed" (ya confirmado) con que se conecten bloques posteriores. En cambio, los bloques "accepted" tienen que esperar a que una cantidad específica de bloques posteriores sostengan el consenso para poder escalar a "confirmed". En el último paso, un bloque "confirmed" solo puede actualizarse a "final" (final) si, además, su "bloque padre" también está en estado final. Y una vez que se alcanza ese estado, se vuelve completamente irreversible.
Este diseño por niveles resuelve el problema de "qué tan rápido se puede estar tranquilo". No es necesario que todos los bloques esperen hasta el nivel más alto para poder usarse: en escenarios ligeros, con aceptar un estado "attested" ya puedes moverte; en escenarios de activos de alto valor, hay que esperar a "final" para confiar plenamente. Los diferentes niveles de tolerancia al riesgo corresponden a diferentes umbrales de confirmación; esta flexibilidad es bastante útil.
Pero el costo es la complejidad: para un usuario normal, resulta difícil saber directamente en qué nivel ha llegado realmente su transacción. En este momento, esto depende principalmente de lo que muestren el software de los nodos y la capa de la wallet; que la experiencia sea buena o no, también depende de cómo se implemente en la práctica.
$DUSK
#dusk @Dusk
Por la parte de Dusk, el estado de los bloques se divide en cuatro niveles. Un bloque recién emitido, si en la primera ronda de votación pasa directamente, se llama "attested" (ya verificado). Si antes hubo rondas de votación que fallaron y ahora recién pasa, se llama "accepted" (ya aceptado); además, este bloque todavía podría ser reemplazado por bloques de rondas inferiores. Más adelante, en el camino, los bloques "attested" pasan a ser "confirmed" (ya confirmado) con que se conecten bloques posteriores. En cambio, los bloques "accepted" tienen que esperar a que una cantidad específica de bloques posteriores sostengan el consenso para poder escalar a "confirmed". En el último paso, un bloque "confirmed" solo puede actualizarse a "final" (final) si, además, su "bloque padre" también está en estado final. Y una vez que se alcanza ese estado, se vuelve completamente irreversible.
Este diseño por niveles resuelve el problema de "qué tan rápido se puede estar tranquilo". No es necesario que todos los bloques esperen hasta el nivel más alto para poder usarse: en escenarios ligeros, con aceptar un estado "attested" ya puedes moverte; en escenarios de activos de alto valor, hay que esperar a "final" para confiar plenamente. Los diferentes niveles de tolerancia al riesgo corresponden a diferentes umbrales de confirmación; esta flexibilidad es bastante útil.
Pero el costo es la complejidad: para un usuario normal, resulta difícil saber directamente en qué nivel ha llegado realmente su transacción. En este momento, esto depende principalmente de lo que muestren el software de los nodos y la capa de la wallet; que la experiencia sea buena o no, también depende de cómo se implemente en la práctica.
$DUSK
#dusk @Dusk