Ayer por la noche volví a leer el whitepaper de Dusk y la sección de consenso me hizo ir más despacio. Dusk utiliza Succinct Attestation con Proof of Stake permisivo y basado en comités. Se requiere una participación mínima de 1,000 DUSK, mientras que el epoch actual es de 2,160 bloques. Cada ronda puede ejecutar hasta 50 iteraciones, y los comités tienen 64 créditos, por lo que el poder de voto se pondera en vez de “una persona, un voto”.
Lo que me pareció interesante es la estructura de umbrales: Valid requiere 2/3, mientras que Invalid, NoCandidate o NoQuorum pueden alcanzar una mayoría de 1/2 + 1. Tras 16 iteraciones fallidas, el protocolo puede entrar en modo de emergencia, lo que plantea una cuestión sobre la vivacidad frente al riesgo de bifurcación.
El diseño de incentivos también llamó mi atención: el 80% va al generador de bloques, el 10% al comité de votación y el 10% a Dusk. El 80% del generador es 70% fijo más una porción variable del 10% vinculada a los votos incluidos. Fallas mayores como el doble voto pueden activar un slashing duro.
Luego Moonlight y Phoenix me hicieron más clara la arquitectura: transacciones públicas basadas en cuentas frente a notas estilo UTXO, árboles de Merkle, nullifiers y pruebas ZK.
Todavía me pregunto: ¿la asignación de créditos ponderada por la participación crea riesgos de concentración? ¿Y qué tan robusto es el modo de emergencia ante fallos de validadores?
#dusk $DUSK @Dusk
Lo que me pareció interesante es la estructura de umbrales: Valid requiere 2/3, mientras que Invalid, NoCandidate o NoQuorum pueden alcanzar una mayoría de 1/2 + 1. Tras 16 iteraciones fallidas, el protocolo puede entrar en modo de emergencia, lo que plantea una cuestión sobre la vivacidad frente al riesgo de bifurcación.
El diseño de incentivos también llamó mi atención: el 80% va al generador de bloques, el 10% al comité de votación y el 10% a Dusk. El 80% del generador es 70% fijo más una porción variable del 10% vinculada a los votos incluidos. Fallas mayores como el doble voto pueden activar un slashing duro.
Luego Moonlight y Phoenix me hicieron más clara la arquitectura: transacciones públicas basadas en cuentas frente a notas estilo UTXO, árboles de Merkle, nullifiers y pruebas ZK.
Todavía me pregunto: ¿la asignación de créditos ponderada por la participación crea riesgos de concentración? ¿Y qué tan robusto es el modo de emergencia ante fallos de validadores?
#dusk $DUSK @Dusk
