#dusk $DUSK @Dusk
‎
‎He estado comparando la ruta de verificación criptográfica de Dusk con lo que requeriría una alternativa totalmente aislada en sandbox, desde que “se mueve fuera de WASM” se menciona en muchos lugares que he leído, sin mucha base numérica.
‎
‎Los propios materiales de Dusk confirman que Piecrust expone funciones de hash, verificación PLONK, verificación Groth16 y comprobaciones de firmas como funciones host: código nativo que el runtime llama directamente, eludiendo por completo la máquina virtual WASM para estas operaciones específicas. Por separado, encontré que Phoenix utiliza específicamente una variante de firma Schnorr doble, descrita en el propio repositorio de Dusk como una introducción novedosa que delega el cómputo de pruebas sin exponer la clave secreta del firmante; es decir, incluso la capa de firmas, no solo la capa de la prueba ZK, estaba diseñada para ejecutarse a través de esta ruta nativa.
‎
‎Hagan las cuentas de lo que permanece dentro de WASM frente a lo que no. La lógica general del contrato — cambios de estado, reglas de negocio — se ejecuta en sandbox. Cada primitica criptográfica de la que depende realmente una transacción de Phoenix se ejecuta de forma nativa en su lugar.
‎
‎Eso sigue siendo una hipótesis que vale la pena plantear con precisión: no he encontrado un benchmark publicado que cuantifique específicamente cuánto más lento sería el proceso de verificación de Phoenix si estas comprobaciones permanecieran dentro de WASM en lugar de ejecutarse como funciones host en la configuración actual de Dusk.
‎
‎Lo que cambió en mi lectura: había supuesto que esto era únicamente una elección de optimización. También es una elección de límite de seguridad: el código nativo conlleva propiedades de superficie de ataque distintas a las del código WASM aislado en sandbox, que el encuadre de rendimiento por sí solo no captura.
‎