Últimamente he estado leyendo con más profundidad el whitepaper de Dusk y la parte a la que sigo volviendo no es realmente el tema de la privacidad.

Es el diseño del consenso.

@Dusk usa Succinct Attestation con un modelo de PoS sin permisos y basado en comités. Necesitas 1.000 DUSK para hacer stake; cada época dura 2.160 bloques y el poder de voto se pondera por el stake en 64 créditos de comité.

Esa última parte captó mi atención.

Porque, una vez que el poder de voto está ponderado por el stake, la pregunta no es solo si la red puede llegar a un consenso. Es cómo se distribuye ese poder.

Los umbrales también son interesantes. Para Valid se requiere 2/3, mientras que Invalid, NoCandidate y NoQuorum necesitan 1/2 + 1. Después de 16 iteraciones fallidas, el protocolo puede entrar en modo de emergencia.

En el papel, suena a una forma sensata de proteger la vivacidad.

Pero me hizo preguntarme sobre el otro lado de ese intercambio: ¿cuánta presión puede absorber el sistema antes de que, al preservar la vivacidad, se genere un riesgo diferente?

El diseño de incentivos también es deliberado: 80% para el generador de bloques, 10% para el comité de votación y 10% para #Dusk , con conductas graves como el doble voto sujetas a un slashing estricto.

Luego está la capa de transacciones.

Moonlight es basada en cuentas y pública, mientras que Phoenix usa notas estilo UTXO, árboles de Merkle, nullifiers y pruebas ZK.

Cuanto más observo el diseño, más interesante no es si cada componente funciona de forma individual.

Sino si siguen funcionando bien juntos bajo estrés.

¿El crédito ponderado por stake crea demasiada concentración con el tiempo? ¿Y si una gran parte del conjunto de validadores falla, el modo de emergencia es lo bastante robusto sin abrir otra vía hacia forks?

Esa es la parte de la arquitectura de Dusk que todavía quiero entender mejor.
$DUSK $TMX $DEBIT #XRPRallies44%InAWeek #CryptoFearGreedIndexHits74 #USStocksCloseHigherNvidiaGains2% #USBitcoinETFsExtendInflowsToSixthDay