La práctica más común de la conformidad en la cadena hoy en día es la lista blanca: el equipo del proyecto recopila una ronda de documentos de KYC, y luego escribe las direcciones que pasan a un contrato. El problema es que el usuario tiene que volver a enviar información de identidad a cada protocolo: el pasaporte, la dirección y la fecha de nacimiento quedan almacenados de forma fragmentada en los servidores de distintos equipos. Cualquier filtración en cualquiera de esos puntos es irreversible. Esto no es un diseño de seguridad; es simplemente trasladar el flujo tradicional tal cual a la cadena.
@Dusk_Foundation de Citadel sigue otro camino: separar la verificación de identidad de la divulgación de identidad. El usuario realiza una verificación una sola vez en una entidad autorizada, y luego usa pruebas de conocimiento cero para mostrar a distintas aplicaciones la conclusión de “cumplo las condiciones”, sin necesidad de entregar los datos subyacentes. Lo que obtiene el protocolo no es una ficha de datos que podría ser exfiltrada en cualquier momento, sino un resultado verificable del juicio.
Esta diferencia es crucial en escenarios regulados. Un producto de tokenización orientado a inversores calificados, legalmente, debe confirmar la elegibilidad del comprador, pero técnicamente no es necesario saber quién es el comprador. En finanzas tradicionales, estas dos cosas se unen porque en el pasado no había otras herramientas disponibles, y no porque lógicamente tengan que estarlo.
Algo aún más práctico es la revocabilidad. La elegibilidad nunca es permanente: el inversor puede cambiar su residencia fiscal, perder la condición de calificado o ser incluido en listas restringidas. Un sistema de identidad en cadena verdaderamente utilizable debe permitir la caducidad y la revocación de credenciales; de lo contrario, no es más que sustituir una lista blanca desactualizada por un nombre más moderno.
Poner esta capacidad en la capa de protocolo en lugar de hacer que cada aplicación construya su propia solución significa que el emisor no tiene que asumir por sí mismo la responsabilidad de custodiar datos sensibles. Para los equipos de cumplimiento, tener menos datos personales guardados en la práctica reduce el riesgo, y en el contexto de GDPR esto es especialmente real.
A nivel de tokens, DUSK asume las funciones de Gas de la red y Staking; los incentivos económicos de los validadores y la seguridad de la red están directamente vinculados. Pero el valor de la capa de identidad no se refleja en la narrativa del token, sino en cuánto realmente está dispuesto el emisor a migrar los procesos de cumplimiento.
Me interesa más el detalle de implementación: quién emite las credenciales, si la autoridad regulatoria reconoce este tipo de prueba y si el proceso de presentación es lo suficientemente sencillo para el usuario común. Solo después de resolver estas cuestiones, la conformidad en cadena pasa de la demostración a ser utilizable.
@Dusk_Foundation $DUSK #dusk
@Dusk_Foundation de Citadel sigue otro camino: separar la verificación de identidad de la divulgación de identidad. El usuario realiza una verificación una sola vez en una entidad autorizada, y luego usa pruebas de conocimiento cero para mostrar a distintas aplicaciones la conclusión de “cumplo las condiciones”, sin necesidad de entregar los datos subyacentes. Lo que obtiene el protocolo no es una ficha de datos que podría ser exfiltrada en cualquier momento, sino un resultado verificable del juicio.
Esta diferencia es crucial en escenarios regulados. Un producto de tokenización orientado a inversores calificados, legalmente, debe confirmar la elegibilidad del comprador, pero técnicamente no es necesario saber quién es el comprador. En finanzas tradicionales, estas dos cosas se unen porque en el pasado no había otras herramientas disponibles, y no porque lógicamente tengan que estarlo.
Algo aún más práctico es la revocabilidad. La elegibilidad nunca es permanente: el inversor puede cambiar su residencia fiscal, perder la condición de calificado o ser incluido en listas restringidas. Un sistema de identidad en cadena verdaderamente utilizable debe permitir la caducidad y la revocación de credenciales; de lo contrario, no es más que sustituir una lista blanca desactualizada por un nombre más moderno.
Poner esta capacidad en la capa de protocolo en lugar de hacer que cada aplicación construya su propia solución significa que el emisor no tiene que asumir por sí mismo la responsabilidad de custodiar datos sensibles. Para los equipos de cumplimiento, tener menos datos personales guardados en la práctica reduce el riesgo, y en el contexto de GDPR esto es especialmente real.
A nivel de tokens, DUSK asume las funciones de Gas de la red y Staking; los incentivos económicos de los validadores y la seguridad de la red están directamente vinculados. Pero el valor de la capa de identidad no se refleja en la narrativa del token, sino en cuánto realmente está dispuesto el emisor a migrar los procesos de cumplimiento.
Me interesa más el detalle de implementación: quién emite las credenciales, si la autoridad regulatoria reconoce este tipo de prueba y si el proceso de presentación es lo suficientemente sencillo para el usuario común. Solo después de resolver estas cuestiones, la conformidad en cadena pasa de la demostración a ser utilizable.
@Dusk_Foundation $DUSK #dusk