El pequeño icono de “confirmado” en la cartera parece bastante común; solo después de leer los documentos definitivos finales de Dusk entendí que, detrás de esta discreta indicación, se comprimen cuatro niveles de credibilidad completamente distintos.
Primero, un bloque recién creado atraviesa la etapa de “aceptado”; en ese punto, si en la misma ronda aparece un bloque candidato más temprano, en cualquier momento podría reemplazarlo. Superar esa fase y ascender al nivel de “verificado” es lo que te libra del destino de ser desplazado; más arriba está el “bloqueado”, que se va construyendo con la acumulación de bloques posteriores; y en el nivel de “resuelto completamente”, hay que esperar a que su bloque padre termine todo el proceso.
Lo clave está en esto: desde que nace hasta que queda totalmente resuelto, depende de cuántos bloques posteriores necesite para ser respaldado, y no hay una respuesta única. Ese número se relaciona con cuántas tentativas fallidas atravesó el bloque en el momento de su nacimiento: cuanto más accidentado fue al nacer, más confirmaciones se requieren después para compensar esa incertidumbre innata. Incluso con la misma etiqueta de “confirmación”, la calidad real puede variar enormemente.
Siguiendo esta lógica, al mirar otros módulos encontré que la misma filosofía de estratificación aparece también en otros lugares. El contrato central responsable de enrutar distintos tipos de transacciones las clasifica en los canales de validación correspondientes según sus atributos; luego, al completar cada flujo, se registra de manera unificada en el libro de contabilidad de la cadena. Las transferencias visibles, las transferencias cifradas, las de tipo cuenta y las de tipo vale, todas deben asentarse de forma coherente.
Si cambio la perspectiva al escenario de emparejamiento, se pone aún más interesante: para que el mercado acepte cada operación, hay que dejar en la cadena rastros que puedan ser revisados. La finalidad graduada le da a la aplicación una regla con marcas para decidir con criterio cuándo puede prometerse externamente y cuándo solo se puede hacer un registro contable temporal; el propio nodo ajusta ese juicio.
El costo es que esta complejidad no es visible para el usuario común. En una bifurcación de red extrema, a quién afecta esa brecha de información y cómo, todavía requiere seguir observando.
#dusk @Dusk $DUSK
Primero, un bloque recién creado atraviesa la etapa de “aceptado”; en ese punto, si en la misma ronda aparece un bloque candidato más temprano, en cualquier momento podría reemplazarlo. Superar esa fase y ascender al nivel de “verificado” es lo que te libra del destino de ser desplazado; más arriba está el “bloqueado”, que se va construyendo con la acumulación de bloques posteriores; y en el nivel de “resuelto completamente”, hay que esperar a que su bloque padre termine todo el proceso.
Lo clave está en esto: desde que nace hasta que queda totalmente resuelto, depende de cuántos bloques posteriores necesite para ser respaldado, y no hay una respuesta única. Ese número se relaciona con cuántas tentativas fallidas atravesó el bloque en el momento de su nacimiento: cuanto más accidentado fue al nacer, más confirmaciones se requieren después para compensar esa incertidumbre innata. Incluso con la misma etiqueta de “confirmación”, la calidad real puede variar enormemente.
Siguiendo esta lógica, al mirar otros módulos encontré que la misma filosofía de estratificación aparece también en otros lugares. El contrato central responsable de enrutar distintos tipos de transacciones las clasifica en los canales de validación correspondientes según sus atributos; luego, al completar cada flujo, se registra de manera unificada en el libro de contabilidad de la cadena. Las transferencias visibles, las transferencias cifradas, las de tipo cuenta y las de tipo vale, todas deben asentarse de forma coherente.
Si cambio la perspectiva al escenario de emparejamiento, se pone aún más interesante: para que el mercado acepte cada operación, hay que dejar en la cadena rastros que puedan ser revisados. La finalidad graduada le da a la aplicación una regla con marcas para decidir con criterio cuándo puede prometerse externamente y cuándo solo se puede hacer un registro contable temporal; el propio nodo ajusta ese juicio.
El costo es que esta complejidad no es visible para el usuario común. En una bifurcación de red extrema, a quién afecta esa brecha de información y cómo, todavía requiere seguir observando.
#dusk @Dusk $DUSK