Seis cosas que una sesión de Citadel nunca pone en la cadena: la clave de tu wallet, la licencia que usaste, las claves del emisor y del servicio, los atributos firmados y la ruta de prueba de Merkle. Lo que sí va onchain es una sola sesión. Pública, verificable, aburrida.
@Dusk lo clasifica como divulgación selectiva, y no es un interruptor de privacidad. Un Proveedor de Licencias te revisa off-chain, firma tus atributos, publica una licencia cifrada y la registra en un contrato de Citadel. Luego demuestras en conocimiento cero que tienes una licencia registrada. No cuál licencia. Solo que existe. El contrato verifica, registra una sesión y tú le das una cookie de sesión al servicio.
Luego los documentos trazan una línea, sin rodeos. Citadel prueba que la sesión es válida criptográficamente. No decide la política del servicio. El servicio sigue eligiendo qué emisores confía, qué atributos acepta, si la sesión fue revocada y si esa cookie funciona dos veces.
Mi trabajo diario es probar una app de trading de valores, y esa separación suena como algo copiado de mi escritorio. Nadie allí ve el panorama completo, a propósito. El usuario ve su propia orden. Back office ve el lote. El depositario ve una instrucción de liquidación. El supervisor saca un reporte bajo demanda. Cuatro vistas de una sola operación, resueltas mucho antes de que alguien escribiera un circuito de prueba.
Mi postura: la parte valiosa de Citadel no es la criptografía, es la negativa. Una cadena que decida la elegibilidad para ti es una que ningún venue podría adoptar. La elegibilidad es jurisdicción, términos del producto y la tolerancia al riesgo del emisor. Nada de eso debería necesitar un hard fork.
¿Eso hace que una app en Dusk sea compatible? No. Todavía tiene que existir un Proveedor de Licencias, ejecutar las verificaciones off-chain y responder cuando una verificación estuvo mal. Herramientas de hoy: una librería en Rust, el contrato de licencia, una CLI de wallet y un SDK de JavaScript aún listados como “en camino”. $DUSK paga gas y asegura la red mediante staking.
Entonces, ¿quién debería asumir el rol de Proveedor de Licencias para un activo regulado: el venue, el emisor o un tercero cuyo único trabajo es verificar? Me sigue llevando al tercero, sin una razón clara.
#dusk
@Dusk lo clasifica como divulgación selectiva, y no es un interruptor de privacidad. Un Proveedor de Licencias te revisa off-chain, firma tus atributos, publica una licencia cifrada y la registra en un contrato de Citadel. Luego demuestras en conocimiento cero que tienes una licencia registrada. No cuál licencia. Solo que existe. El contrato verifica, registra una sesión y tú le das una cookie de sesión al servicio.
Luego los documentos trazan una línea, sin rodeos. Citadel prueba que la sesión es válida criptográficamente. No decide la política del servicio. El servicio sigue eligiendo qué emisores confía, qué atributos acepta, si la sesión fue revocada y si esa cookie funciona dos veces.
Mi trabajo diario es probar una app de trading de valores, y esa separación suena como algo copiado de mi escritorio. Nadie allí ve el panorama completo, a propósito. El usuario ve su propia orden. Back office ve el lote. El depositario ve una instrucción de liquidación. El supervisor saca un reporte bajo demanda. Cuatro vistas de una sola operación, resueltas mucho antes de que alguien escribiera un circuito de prueba.
Mi postura: la parte valiosa de Citadel no es la criptografía, es la negativa. Una cadena que decida la elegibilidad para ti es una que ningún venue podría adoptar. La elegibilidad es jurisdicción, términos del producto y la tolerancia al riesgo del emisor. Nada de eso debería necesitar un hard fork.
¿Eso hace que una app en Dusk sea compatible? No. Todavía tiene que existir un Proveedor de Licencias, ejecutar las verificaciones off-chain y responder cuando una verificación estuvo mal. Herramientas de hoy: una librería en Rust, el contrato de licencia, una CLI de wallet y un SDK de JavaScript aún listados como “en camino”. $DUSK paga gas y asegura la red mediante staking.
Entonces, ¿quién debería asumir el rol de Proveedor de Licencias para un activo regulado: el venue, el emisor o un tercero cuyo único trabajo es verificar? Me sigue llevando al tercero, sin una razón clara.
#dusk
