Ejecuto un pequeño script de Python en mi laptop en Islamabad que hace un hashing pesado para un proyecto paralelo, y una vez intenté moverlo a un entorno aislado pensando que se ejecutaría igual de rápido ya que la lógica no cambiaba. Se ejecutó notablemente más lento, y hasta que leí sobre la VM Piecrust de Dusk nunca entendí realmente por qué pasa a nivel técnico.
Asumí que toda la ejecución de contratos inteligentes dentro de una máquina virtual WASM se ejecuta a una velocidad aproximadamente nativa, ya que WASM suele comercializarse como un rendimiento cercano al nativo.
Eso no es exacto, específicamente para operaciones criptográficas. La investigación citada en el whitepaper muestra que la ejecución en WASM puede ejecutarse entre un 45 y un 255 por ciento más lento que el código nativo para aplicaciones complejas, principalmente por la gestión de memoria virtualizada y el manejo adicional de instrucciones dentro del sandbox.
Por eso Piecrust no ejecuta en absoluto cosas como la verificación de pruebas ZK, hashing o comprobaciones de firmas dentro del sandbox WASM. En su lugar, expone funciones del host: llamadas nativas directas para operaciones como hash, verify_plonk, verify_groth16_bn254, verify_schnorr y verify_bls. El contrato llama a código nativo para el trabajo criptográfico costoso, y luego vuelve a WASM para todo lo demás. Eso es una división arquitectónica deliberada, no un recurso alternativo.
Lo que el whitepaper admite directamente es que Dusk aún no ha cuantificado el ahorro real de potencia de esta configuración. Así que no puedo decirte un número de eficiencia real, porque Dusk en sí no ha publicado uno.
La prueba real para DUSK es si este enfoque de funciones del host sigue manteniéndose a medida que crece la complejidad de los contratos en mainnet.
¿Alguien ha comparado (benchmark) las llamadas de funciones del host de Piecrust frente a la ejecución pura en WASM por cuenta propia?
@Dusk #dusk $DUSK
Asumí que toda la ejecución de contratos inteligentes dentro de una máquina virtual WASM se ejecuta a una velocidad aproximadamente nativa, ya que WASM suele comercializarse como un rendimiento cercano al nativo.
Eso no es exacto, específicamente para operaciones criptográficas. La investigación citada en el whitepaper muestra que la ejecución en WASM puede ejecutarse entre un 45 y un 255 por ciento más lento que el código nativo para aplicaciones complejas, principalmente por la gestión de memoria virtualizada y el manejo adicional de instrucciones dentro del sandbox.
Por eso Piecrust no ejecuta en absoluto cosas como la verificación de pruebas ZK, hashing o comprobaciones de firmas dentro del sandbox WASM. En su lugar, expone funciones del host: llamadas nativas directas para operaciones como hash, verify_plonk, verify_groth16_bn254, verify_schnorr y verify_bls. El contrato llama a código nativo para el trabajo criptográfico costoso, y luego vuelve a WASM para todo lo demás. Eso es una división arquitectónica deliberada, no un recurso alternativo.
Lo que el whitepaper admite directamente es que Dusk aún no ha cuantificado el ahorro real de potencia de esta configuración. Así que no puedo decirte un número de eficiencia real, porque Dusk en sí no ha publicado uno.
La prueba real para DUSK es si este enfoque de funciones del host sigue manteniéndose a medida que crece la complejidad de los contratos en mainnet.
¿Alguien ha comparado (benchmark) las llamadas de funciones del host de Piecrust frente a la ejecución pura en WASM por cuenta propia?
@Dusk #dusk $DUSK
