He desarmado la arquitectura de privacidad del @Dusk y he encontrado varios problemas que quedan ocultos bajo ciertas narrativas de “privacidad L1 conforme”.
Primera capa: dos vías, dos tipos de costos $DUSK ; la red principal ejecuta Moonlight (transparente) y Phoenix (privado) al mismo tiempo. Moonlight ofrece una experiencia EVM convencional; pero en Phoenix, cada operación requiere que el cliente genere pruebas zk-SNARK. wallet-core permite externalizar la generación de pruebas a un Prover externo; por sí solo, ese diseño ya demuestra que el dispositivo local no aguanta la carga computacional de circuitos a alta frecuencia.
Segunda capa: KYC como umbral previo
El modelo de licencia que usa RWA, Citadel, exige completar KYC primero. No está mal, pero eso deja el tráfico actual de la red principal atrapado en el rango de “pequeños lotes institucionales, alto valor y liquidación”. La “estabilidad” que ves es el resultado en escenarios de baja concurrencia.
Tercera capa: las limitaciones distorsionan la verificación
Ahora mismo la proporción de transacciones en Phoenix no es alta, así que la carga de pruebas es limitada. El sistema se mantiene estable en un entorno controlado, pero eso no significa que, tras escalar a una concurrencia masiva minorista, la capacidad de cómputo del cliente, la cola del Prover y el rendimiento de los validadores puedan mantener la eficiencia. La red principal puede demostrar que “la privacidad es viable”, pero no puede demostrar que “la privacidad aguanta el volumen”.
Cuarta capa: el usuario podría atascarse en el último paso
Cuando el usuario termina el KYC, bloquea los activos e inicia una transacción en Phoenix, si la capacidad de cómputo local no alcanza o si la cola del Prover está congestionada, la transacción no sale en el último instante. Si DUSK quiere conectar DeFi de privacidad al mercado minorista, el escalado del Prover y la retroalimentación de fallos no pueden estar únicamente en las actualizaciones técnicas.
Mi opinión
No voy a negar #dusk ni los costos de ZK ni el KYC. La privacidad L1 y las blockchains sin licencia son, de hecho, dos caminos distintos. Pero “puede funcionar el proceso” y “puede soportar el volumen” son cosas diferentes. Cuando la proporción de Phoenix suba, la red del Prover madure y la optimización de circuitos de contratos complejos esté lista, recién entonces podremos observar la tasa de fallos, el tiempo de generación de pruebas y la fluidez al convertir entre modelos para saber si es “privacidad que funciona” o “privacidad que aguanta el volumen”.
Primera capa: dos vías, dos tipos de costos $DUSK ; la red principal ejecuta Moonlight (transparente) y Phoenix (privado) al mismo tiempo. Moonlight ofrece una experiencia EVM convencional; pero en Phoenix, cada operación requiere que el cliente genere pruebas zk-SNARK. wallet-core permite externalizar la generación de pruebas a un Prover externo; por sí solo, ese diseño ya demuestra que el dispositivo local no aguanta la carga computacional de circuitos a alta frecuencia.
Segunda capa: KYC como umbral previo
El modelo de licencia que usa RWA, Citadel, exige completar KYC primero. No está mal, pero eso deja el tráfico actual de la red principal atrapado en el rango de “pequeños lotes institucionales, alto valor y liquidación”. La “estabilidad” que ves es el resultado en escenarios de baja concurrencia.
Tercera capa: las limitaciones distorsionan la verificación
Ahora mismo la proporción de transacciones en Phoenix no es alta, así que la carga de pruebas es limitada. El sistema se mantiene estable en un entorno controlado, pero eso no significa que, tras escalar a una concurrencia masiva minorista, la capacidad de cómputo del cliente, la cola del Prover y el rendimiento de los validadores puedan mantener la eficiencia. La red principal puede demostrar que “la privacidad es viable”, pero no puede demostrar que “la privacidad aguanta el volumen”.
Cuarta capa: el usuario podría atascarse en el último paso
Cuando el usuario termina el KYC, bloquea los activos e inicia una transacción en Phoenix, si la capacidad de cómputo local no alcanza o si la cola del Prover está congestionada, la transacción no sale en el último instante. Si DUSK quiere conectar DeFi de privacidad al mercado minorista, el escalado del Prover y la retroalimentación de fallos no pueden estar únicamente en las actualizaciones técnicas.
Mi opinión
No voy a negar #dusk ni los costos de ZK ni el KYC. La privacidad L1 y las blockchains sin licencia son, de hecho, dos caminos distintos. Pero “puede funcionar el proceso” y “puede soportar el volumen” son cosas diferentes. Cuando la proporción de Phoenix suba, la red del Prover madure y la optimización de circuitos de contratos complejos esté lista, recién entonces podremos observar la tasa de fallos, el tiempo de generación de pruebas y la fluidez al convertir entre modelos para saber si es “privacidad que funciona” o “privacidad que aguanta el volumen”.