Hay una cosa a la que sigo volviendo cuando investigo @Dusk l: si es realmente necesario que el cumplimiento (compliance) se logre a costa de la privacidad, y que gran parte de la lógica de diseño radica en cómo Citadel 2 separa "demostrar que se ha verificado" de "revelar quién es la persona detrás".

El flujo comienza con que el License Provider verifica al usuario fuera de la cadena (off-chain) y firma los atributos necesarios.

A partir de ahí, el usuario crea una prueba de conocimiento cero (zero-knowledge proof) para demostrar que posee una licencia válida que ya fue firmada y registrada en la cadena (on-chain); esta es la parte que me resulta más interesante.

La prueba ocurre mediante criptografía sin revelar la clave de la billetera, los atributos ni la licencia específica, y aquí es donde la pregunta sobre la privacidad realmente se pone a prueba.

La política del servicio siempre está detrás, esperando a que el Service Provider decida qué provider se confía, qué atributos se aceptan y si la sesión sigue siendo válida.

Finalmente, el contrato solo confirma la prueba válida y registra una sesión pública. En on-chain solo queda la evidencia de que un credencial válido se ha usado.

Lo que aún no sé es cómo funcionará este mecanismo cuando cambie la política, cuando el provider emita un credencial incorrecto o cuando una sesión antigua aún siga vigente en lugar de estar en la condición ideal.

La pregunta es si la criptografía realmente elimina la necesidad de revelar la identidad en el control de acceso o si solo traslada la confianza al emisor y a la interpretación del credencial.

Estoy siguiendo cómo #dusk x maneja el límite entre la prueba criptográfica y la política del servicio cuando las finanzas reguladas realmente empiezan a usarla. $DUSK $KII $AKE
#RedditToJoinSP500 #US30YBondAuctionYieldHighestSince2001 #GlobalStocksNearRecordHighs #ProCapFilesBitcoinTreasuryDiscountETF