Hoy por la tarde desmonté el protocolo de Citadel del @Dusk ; me quedé atascado durante mucho tiempo con la palabra “license”. Al principio pensé: “¿no es simplemente poner la identidad directamente en la cadena?”. Pero después de revisar el documento varias veces, entendí que no era para nada así.

La clave es que, después de que el proveedor de credenciales haga la verificación presencial, te emite una licencia cifrada y la registra en el contrato. Lo que el usuario realmente envía es una prueba de conocimiento cero: prueba que “tengo una license válida”. Por su parte, el proveedor del servicio solo verifica la session pública y decide si te deja pasar. En todo el proceso están muy claros tres tipos de roles: el usuario, el License Provider y el Service Provider.

Esto no se siente como que tengas que entregar una copia del documento de identidad para entrar a cada edificio; más bien se parece a que en un hospital te verifican una vez, te entregan un comprobante de “aprobado en el chequeo”, y el gimnasio solo revisa que el comprobante sea válido para dejarte entrar. No ven el historial médico ni la dirección. Pero “divulgar menos” no significa “cero confianza”: que el que firma sea quien sea, cómo se revoca, cuánto dura la caducidad y si el proveedor del servicio vuelve a recopilar información fuera de la cadena—esas cosas son las que realmente delimitan la frontera de la privacidad.

También he visto que la oficial dice que el JS SDK completo todavía no está listo; el protocolo y la experiencia de desarrollo son dos mundos distintos. Luego, al analizar el modelo de transacciones: Moonlight es una cuenta pública; la dirección del saldo y los importes son totalmente transparentes. Phoenix, en cambio, oculta los cheques y usa nullifier: los importes no se exponen para los participantes, y además se puede usar una viewing key para revelar de forma selectiva. Ambos funcionan en la misma cadena; el usuario elige según el escenario.

Pero cuando los exchanges se integran, la privacidad no es necesariamente “cuanta más, mejor”. La custodia, la atribución y la auditoría tienen que venir acompañadas por operaciones; al final, lo más común para depósitos y retiros sigue siendo la ruta pública. Si el usuario quiere ocultar algunas cosas, tiene que hacer una conversión adicional, y el coste no es bajo.

Por ejemplo, en un retiro de Moonlight, la transacción que está esperando en el nodo durante media hora desaparece del mempool. La oficial lo dice de forma bastante clara: el tiempo de caducidad no se escribe en la transacción, es una estrategia propia de cada nodo. Rusk usa por defecto tres días; a veces se configura a 30 minutos. El nodo A no lo ve, y el nodo B quizá no se sincronice. transactions/removed solo indica que salió de la cola local; la causa puede ser que entre en un bloque, que sea reemplazada o que haya un conflicto. “202 Accepted” solo significa que el nodo recibió la solicitud; no hay que tomarlo como estado final. Antes de reintentar, hay que comprobar el nonce y el resultado de la ejecución: observar un nodo solo no sirve como conclusión de toda la red. #dusk

Con el diseño de doble ruta actual de $DUSK , ¿ustedes se inclinan más por cuál tipo de uso?