@Dusk_Foundation #dusk
Solía pensar que la privacidad de Dusk era principalmente un problema de diseño de transacciones. Cuanto más observo la red, más destaca la capa de pruebas.

Phoenix necesita pruebas de conocimiento cero, pero alguien todavía tiene que hacer el cómputo pesado detrás de esas pruebas. Dusk separa ese trabajo mediante una infraestructura de Prover dedicada en lugar de hacer que cada parte de la red cargue con la misma carga computacional. 🔐

Lo que llamó mi atención es que la generación de pruebas ZK es intensiva en cómputo y en gran medida de un solo hilo, así que la documentación de Dusk enfatiza un rendimiento sólido de un solo núcleo para los Provers. Una configuración básica de Prover comienza alrededor de 4 núcleos, 8 GB de RAM y 20 Mbps, mientras que trabajadores adicionales pueden ejecutarse en paralelo.

Eso crea un interesante equilibrio arquitectónico.

El consenso tiene que mantenerse receptivo, mientras que las pruebas de privacidad necesitan suficiente cómputo para terminar de manera eficiente.

Así que la privacidad aquí no es solo “ocultar la transacción”.

También se convierte en una pregunta sobre dónde ocurre el cómputo, quién lo realiza y si esa carga de trabajo puede escalar sin convertirse en el cuello de botella.

Esa es la parte que encuentro más interesante que la etiqueta de privacidad en sí.

¿Crees que la capacidad de verificación ZK podría convertirse en una de las restricciones reales de rendimiento para Dusk a medida que crezca el uso?
$DUSK $PORTAL $DOLO
¿Qué podría convertirse en el mayor cuello de botella de Dusk a medida que crece el uso?