#dusk $DUSK
La frase "funciones host" seguía apareciendo en el whitepaper de Dusk, y yo la seguía tratando como un detalle de implementación. Cuando en realidad leí la sección de rendimiento, resultó ser una decisión arquitectónica más deliberada que eso.
Ejecutar ZK dentro de una VM WASM: el whitepaper cita investigaciones que muestran que la ejecución en WASM puede ser un 45-255% más lenta en comparación con el código nativo para aplicaciones complejas. La sobrecarga proviene de la gestión de memoria virtualizada y del manejo adicional de instrucciones dentro de un entorno aislado (sandbox). Para el hashing y la validación de firmas eso es molesto. Para la verificación de pruebas ZK que se ejecuta en cada transacción, un 45-255% más lento es un problema importante de rendimiento.
Funciones host: Dusk expone un conjunto de funciones que se ejecutan de forma nativa en la máquina anfitriona, fuera del sandbox WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls y hash. El contrato inteligente las llama directamente; el trabajo criptográfico pesado se ejecuta a velocidad nativa. El resultado se replica entre nodos de la misma manera que cualquier otra computación.
Entonces, ¿por qué no lo hace cada cadena que ejecuta ZK?
Trasladar el cómputo fuera de la VM reduce la garantía de aislamiento del sandbox. En un modelo de ejecución puro en WASM, un contrato defectuoso o malicioso queda aislado dentro del límite de la VM. Cuando agregas funciones host, estás exponiendo acceso a nivel nativo a operaciones específicas; y un error o una mala configuración en la capa de funciones host podría tener consecuencias que un contrato aislado por sí solo no podría producir. Estás cambiando aislamiento por rendimiento.
En realidad, me parece más interesante el argumento de eficiencia energética que el de la velocidad: el whitepaper plantea las funciones host en parte como una forma de reducir los costos de energía por nodo, no solo la latencia. Es un planteamiento poco habitual para un documento de diseño de una blockchain.
Lo que no he visto explicado es cómo Dusk maneja el versionado de las funciones host: si un cambio en el comportamiento de una función host constituye un cambio de protocolo que requiere consenso, o si los operadores pueden actualizar implementaciones de forma independiente. @Dusk
$DUSK #dusk
La frase "funciones host" seguía apareciendo en el whitepaper de Dusk, y yo la seguía tratando como un detalle de implementación. Cuando en realidad leí la sección de rendimiento, resultó ser una decisión arquitectónica más deliberada que eso.
Ejecutar ZK dentro de una VM WASM: el whitepaper cita investigaciones que muestran que la ejecución en WASM puede ser un 45-255% más lenta en comparación con el código nativo para aplicaciones complejas. La sobrecarga proviene de la gestión de memoria virtualizada y del manejo adicional de instrucciones dentro de un entorno aislado (sandbox). Para el hashing y la validación de firmas eso es molesto. Para la verificación de pruebas ZK que se ejecuta en cada transacción, un 45-255% más lento es un problema importante de rendimiento.
Funciones host: Dusk expone un conjunto de funciones que se ejecutan de forma nativa en la máquina anfitriona, fuera del sandbox WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls y hash. El contrato inteligente las llama directamente; el trabajo criptográfico pesado se ejecuta a velocidad nativa. El resultado se replica entre nodos de la misma manera que cualquier otra computación.
Entonces, ¿por qué no lo hace cada cadena que ejecuta ZK?
Trasladar el cómputo fuera de la VM reduce la garantía de aislamiento del sandbox. En un modelo de ejecución puro en WASM, un contrato defectuoso o malicioso queda aislado dentro del límite de la VM. Cuando agregas funciones host, estás exponiendo acceso a nivel nativo a operaciones específicas; y un error o una mala configuración en la capa de funciones host podría tener consecuencias que un contrato aislado por sí solo no podría producir. Estás cambiando aislamiento por rendimiento.
En realidad, me parece más interesante el argumento de eficiencia energética que el de la velocidad: el whitepaper plantea las funciones host en parte como una forma de reducir los costos de energía por nodo, no solo la latencia. Es un planteamiento poco habitual para un documento de diseño de una blockchain.
Lo que no he visto explicado es cómo Dusk maneja el versionado de las funciones host: si un cambio en el comportamiento de una función host constituye un cambio de protocolo que requiere consenso, o si los operadores pueden actualizar implementaciones de forma independiente. @Dusk
$DUSK #dusk
