Dr Roosh

Fui a buscar cómo Citadel maneja realmente un certificado revocado. Resulta que la respuesta no es "la cadena lo verifica". El protocolo $DUSK #dusk de Citadel de Dusk Network permite que un usuario pruebe que una sesión es válida criptográficamente — que un Proveedor de Licencias real firmó una licencia real — pero según la documentación, esa prueba no decide la política de servicio.
Esa decisión corresponde al Proveedor de Servicio. Según la propia documentación de @Duskfoundation, el SP decide qué Proveedores de Licencias en los que confía, qué atributos acepta, si una sesión está vencida o revocada y si la cookie de la sesión puede reutilizarse. Nada de eso está escrito en la verificación en cadena.
Lo que cambió para mí fue darme cuenta de que "KYC que preserva la privacidad" aquí no significa que la cadena haga cumplir el cumplimiento. Los atributos personales nunca se escriben en la blockchain; esa parte es explícita en la documentación. Pero el vencimiento, la revocación y la confianza en el emisor son decisiones de política que cada Proveedor de Servicio toma de forma independiente, fuera de la cadena, sin nada en cadena que obligue a la coherencia entre ellos.
@Dusk

Espera: lo que “protege” ahora mismo tu operación en DuskEVM contra bots ni siquiera es la tecnología “sofisticada”.
Todo el mundo habla de Hedger, el motor de privacidad de DuskEVM ($DUSK #dusk @DuskFoundation): cifrado homomórfico más pruebas ZK, saldos cifrados, criptografía real. Pero eso no es lo que está impidiendo el front-running hoy.
Revisé la documentación. DuskEVM actualmente funciona solo con un secuenciador. No hay mempool público. Un solo secuenciador: nada para que los bots vigilen y se adelanten.
En realidad, hay dos historias distintas de “privacidad” superpuestas, y es fácil atribuirle crédito a la incorrecta. Hedger es una privacidad criptográfica real, diseñada para ser audit-ready. La protección contra el front-running es otra cosa: un efecto secundario de tener un único secuenciador con nada expuesto.
Esto es lo que aún no he encontrado: en algún documento o roadmap que diga si el secuenciador de DuskEVM se mantiene único o si se abre con el tiempo. Si alguna vez se vuelve multiparte o público, esta protección específica necesitaría algo que la reemplace. No hay confirmación en ningún sitio que haya visto: es solo una pregunta que plantea la configuración actual.
Me da curiosidad si alguien ha seguido el roadmap real del secuenciador de DuskEVM. Honestamente, no sé la respuesta aquí.
@Dusk

Pasé la tarde hurgando en los repos de Dusk en lugar de limitarme a leer el pitch deck. #Dusk $DUSK @DuskFoundation — "privacidad en una cadena pública" es el gancho total de TradFi, así que quería ver qué está moviéndose de verdad, no lo que se está diciendo.
Lo que me llamó la atención: duskevm-genesis, el repositorio que contiene el bloque génesis y la configuración del rollup, tuvo commits el 8 de agosto y el 10 de agosto de 2026. No código de liquidación RWA. No un contrato de valores. Génesis y plomería del rollup: lo aburrido, lo que sostiene la estructura, lo que nadie captura en una captura de pantalla.
Mientras tanto, el par más activo de DUSK, DUSK/USDT en Binance, estaba moviendo alrededor de $117k en volumen en 24 horas cuando lo revisé, frente a aproximadamente $3.07M en total a través de 51 mercados (CoinGecko). Para un proyecto cuya tesis completa es "las instituciones finalmente transaccionarán en una cadena pública", esa señal es tenue.
Me hizo replantearme el encuadre con el que entré: asumí que una privacidad compatible significaba un flujo institucional invisible zumbando en segundo plano. Lo que encontré fue que la infraestructura todavía se estaba cableando, en silencio, mientras la capitalización se mantiene por debajo de $50M.
Entonces, ¿qué viene primero aquí: las instituciones que Dusk sigue prometiendo, o la plomería finalmente poniéndose al día con el pitch?
@Dusk

Leer las restricciones del circuito Phoenix me detuvo. En Dusk $DUSK #dusk @Duskfoundation el Transfer Contract nunca mira los valores reales de la nota ni qué hoja de Merkle se gasta.
Solo comprueba una prueba PLONK de que las entradas privadas satisfacen cinco condiciones: el hash de la nota se abre frente a una raíz reciente de Merkle de notas, el probador conoce la clave secreta de la nota, el nulo es igual a Poseidon(npk′ ‖ position), los compromisos de salida se abren correctamente y la suma de los valores de entrada es igual a las salidas más la tarifa más cualquier depósito.
Los nullifiers en sí se publican para que la red pueda rechazar el reuso. Como cada uno se deriva de la clave oculta de la nota y de la posición, ningún observador puede mapear un nullifier de vuelta a una hoja específica. La validez vive enteramente dentro de la satisfacción del circuito; el contenido nunca aparece en el libro mayor.
Lo que cambió para mí fue darme cuenta de que la protección contra doble gasto y la integridad del balance están tanto dentro de la prueba como no en ningún cambio de estado visible.
Próxima comprobación: si los nullifiers publicados de cada transacción Phoenix aceptada permanecen únicos en el conjunto de nullifiers en cadena después de la finalización.
@Dusk