#dusk $DUSK @Dusk
Volví a consultar la documentación de Citadel después de notar que NPEX ya tiene más de $300M en activos reales tokenizados activos en Dusk. Ya no es un ejemplo de testnet, así que me hizo querer comprobar si la afirmación de privacidad se sostiene en un entorno regulado real, y no solo en un diagrama de whitepaper.
Resulta que el protocolo en realidad tiene dos flujos separados, no uno.
Primero, un usuario solicita una licencia a un Proveedor de Licencias, usando una dirección stealth, de modo que la licencia emitida no pueda vincularse a la solicitud.
Segundo, cuando el usuario quiere usar un servicio, no vuelve a enviar la licencia. Envía una prueba de conocimiento cero que demuestra que posee una licencia válida. El Proveedor de Servicio solo ve esa prueba, y es la política propia del PS la que decide qué cuenta como suficiente.
Aquí está la parte que me hizo dudar. Esa prueba no es gratuita. El circuito propio de Citadel para demostrar la titularidad de la licencia se ejecuta aproximadamente con 34,800 constraints, y cerca de la mitad de eso es solo recorrer un árbol de Merkle con 17 niveles de profundidad para confirmar que la licencia está realmente registrada.
Así que "probar sin revelar" tiene un costo computacional real incorporado en cada solicitud de servicio, no solo como principio de diseño en una diapositiva.
Es un modelo distinto al de "muestra tu ID y deja que la plataforma verifique todo".
Está más cerca de: pagar un costo fijo de prueba una vez por interacción, a cambio de que el recinto nunca vea nada más que un sí o un no.
Lo que todavía no puedo determinar es si ese costo es invisible para un usuario real de NPEX hoy, si el monedero lo maneja en segundo plano, o si es un retraso real y palpable entre alguien y una operación regulada.
Volví a consultar la documentación de Citadel después de notar que NPEX ya tiene más de $300M en activos reales tokenizados activos en Dusk. Ya no es un ejemplo de testnet, así que me hizo querer comprobar si la afirmación de privacidad se sostiene en un entorno regulado real, y no solo en un diagrama de whitepaper.
Resulta que el protocolo en realidad tiene dos flujos separados, no uno.
Primero, un usuario solicita una licencia a un Proveedor de Licencias, usando una dirección stealth, de modo que la licencia emitida no pueda vincularse a la solicitud.
Segundo, cuando el usuario quiere usar un servicio, no vuelve a enviar la licencia. Envía una prueba de conocimiento cero que demuestra que posee una licencia válida. El Proveedor de Servicio solo ve esa prueba, y es la política propia del PS la que decide qué cuenta como suficiente.
Aquí está la parte que me hizo dudar. Esa prueba no es gratuita. El circuito propio de Citadel para demostrar la titularidad de la licencia se ejecuta aproximadamente con 34,800 constraints, y cerca de la mitad de eso es solo recorrer un árbol de Merkle con 17 niveles de profundidad para confirmar que la licencia está realmente registrada.
Así que "probar sin revelar" tiene un costo computacional real incorporado en cada solicitud de servicio, no solo como principio de diseño en una diapositiva.
Es un modelo distinto al de "muestra tu ID y deja que la plataforma verifique todo".
Está más cerca de: pagar un costo fijo de prueba una vez por interacción, a cambio de que el recinto nunca vea nada más que un sí o un no.
Lo que todavía no puedo determinar es si ese costo es invisible para un usuario real de NPEX hoy, si el monedero lo maneja en segundo plano, o si es un retraso real y palpable entre alguien y una operación regulada.
