Ahora los portátiles que están siendo “explotados” por la IA están carísimos, de locura. Antes, el portátil se quedaba atascado; quería cambiarlo por uno nuevo, pero era demasiado caro. Así que busqué a alguien para que revisara por qué iba tan mal. Al mirar, resultó que un montón de software llamaban a funciones del sistema por su cuenta, compitiendo entre sí por los recursos. El técnico cambió de enfoque: convertir directamente algunas de las operaciones que más recursos consumen en aceleración por hardware, sin pasar por el típico “simulado por software”. La velocidad cambió de inmediato.
La máquina virtual Piecrust de Dusk hace algo parecido. Los smart contracts en sí corren dentro de un sandbox WASM; se busca seguridad y portabilidad, pero a costa de ser lentos. Especialmente las operaciones criptográficas como el hashing, la verificación de firmas y las pruebas de conocimiento cero: ejecutar todo eso dentro del sandbox tiene un coste enorme. La estrategia de Dusk consiste en sacar esas operaciones de alta frecuencia por separado y convertirlas en “host function”, llamando directamente al código nativo de bajo nivel para ejecutarlas, en lugar de calcularlas en el WASM.
Concretamente, extraen varias: el hashing con Blake2b y Poseidon; la verificación con verify_plonk (prueba PlonK), verify_groth16_bn254, y también dos tipos de verificación de firmas: verify_schnorr y verify_bls. Estas cubren casi todas las operaciones criptográficas que necesita el propio sistema de privacidad y consenso de Dusk. En esencia, abren una “puerta trasera” para las tareas más pesadas, evitando la ruta normal del sandbox.
El diseño trae eficiencia de ejecución, pero también significa que la corrección de la implementación de estas host function es extremadamente crítica: si estas funciones nativas tienen alguna vulnerabilidad, el impacto es más directo que el de un problema en la capa de software, porque todos los contratos comparten el mismo canal de aceleración a bajo nivel.
$DUSK
#dusk @Dusk
La máquina virtual Piecrust de Dusk hace algo parecido. Los smart contracts en sí corren dentro de un sandbox WASM; se busca seguridad y portabilidad, pero a costa de ser lentos. Especialmente las operaciones criptográficas como el hashing, la verificación de firmas y las pruebas de conocimiento cero: ejecutar todo eso dentro del sandbox tiene un coste enorme. La estrategia de Dusk consiste en sacar esas operaciones de alta frecuencia por separado y convertirlas en “host function”, llamando directamente al código nativo de bajo nivel para ejecutarlas, en lugar de calcularlas en el WASM.
Concretamente, extraen varias: el hashing con Blake2b y Poseidon; la verificación con verify_plonk (prueba PlonK), verify_groth16_bn254, y también dos tipos de verificación de firmas: verify_schnorr y verify_bls. Estas cubren casi todas las operaciones criptográficas que necesita el propio sistema de privacidad y consenso de Dusk. En esencia, abren una “puerta trasera” para las tareas más pesadas, evitando la ruta normal del sandbox.
El diseño trae eficiencia de ejecución, pero también significa que la corrección de la implementación de estas host function es extremadamente crítica: si estas funciones nativas tienen alguna vulnerabilidad, el impacto es más directo que el de un problema en la capa de software, porque todos los contratos comparten el mismo canal de aceleración a bajo nivel.
$DUSK
#dusk @Dusk