#dusk $DUSK @Dusk
He estado investigando recientemente la configuración de Dusk Network y un detalle ha estado llamando mi atención más que el habitual discurso de la “cadena de privacidad”. Es la forma en que Piecrust, su VM basada en WASM, maneja lo costoso.
Va algo sobre la ejecución de contratos inteligentes que la gente no habla lo suficiente. Cada instrucción tiene un costo real de cómputo, y en la mayoría de las cadenas, si un contrato necesita hashear algo o verificar una prueba, hace ese trabajo dentro de la propia VM, línea por línea, en bytecode de WASM. Eso está bien para lógica sencilla. Se vuelve brutal cuando estás tratando con pruebas de conocimiento cero, que básicamente es la razón de existir de Dusk. Lo que me llamó la atención fue el enfoque de Piecrust: en vez de hacer que el contrato lo compute en WASM, desplaza ese trabajo pesado—hashing, verificaciones de firmas, validación de pruebas PLONK y Groth16—hacia funciones nativas del host. El host lo ejecuta una vez, de forma nativa, y devuelve el resultado.
Sigo preguntándome cuánto importa esto en la práctica frente a lo que se ve sobre el papel. Pero la lógica encaja. El código nativo para operaciones criptográficas es simplemente más rápido que interpretar la misma matemática con WASM, a veces por un margen amplio, dependiendo de la operación. Para una cadena construida alrededor de transacciones confidenciales y el modelo de privacidad UTXO de Phoenix, donde la verificación de pruebas no es opcional sino constante, esa brecha se acumula rápido a través de cada bloque.
Lo que todavía me queda como duda es cómo escala cuando la complejidad del contrato crece más allá de los casos de uso actuales. Las funciones nativas del host resuelven el cuello de botella de hoy, pero no estoy del todo convencido de que siga siendo tan elegante cuando se soliciten más primitivas criptográficas personalizadas. ¿Alguien que esté construyendo sobre Piecrust ya ha notado fricción ahí?
$ONG
$AMP
He estado investigando recientemente la configuración de Dusk Network y un detalle ha estado llamando mi atención más que el habitual discurso de la “cadena de privacidad”. Es la forma en que Piecrust, su VM basada en WASM, maneja lo costoso.
Va algo sobre la ejecución de contratos inteligentes que la gente no habla lo suficiente. Cada instrucción tiene un costo real de cómputo, y en la mayoría de las cadenas, si un contrato necesita hashear algo o verificar una prueba, hace ese trabajo dentro de la propia VM, línea por línea, en bytecode de WASM. Eso está bien para lógica sencilla. Se vuelve brutal cuando estás tratando con pruebas de conocimiento cero, que básicamente es la razón de existir de Dusk. Lo que me llamó la atención fue el enfoque de Piecrust: en vez de hacer que el contrato lo compute en WASM, desplaza ese trabajo pesado—hashing, verificaciones de firmas, validación de pruebas PLONK y Groth16—hacia funciones nativas del host. El host lo ejecuta una vez, de forma nativa, y devuelve el resultado.
Sigo preguntándome cuánto importa esto en la práctica frente a lo que se ve sobre el papel. Pero la lógica encaja. El código nativo para operaciones criptográficas es simplemente más rápido que interpretar la misma matemática con WASM, a veces por un margen amplio, dependiendo de la operación. Para una cadena construida alrededor de transacciones confidenciales y el modelo de privacidad UTXO de Phoenix, donde la verificación de pruebas no es opcional sino constante, esa brecha se acumula rápido a través de cada bloque.
Lo que todavía me queda como duda es cómo escala cuando la complejidad del contrato crece más allá de los casos de uso actuales. Las funciones nativas del host resuelven el cuello de botella de hoy, pero no estoy del todo convencido de que siga siendo tan elegante cuando se soliciten más primitivas criptográficas personalizadas. ¿Alguien que esté construyendo sobre Piecrust ya ha notado fricción ahí?
$ONG
$AMP
