Antes de estar lidiando con el contrato inteligente de @Dusk , tenía una duda: si lo que ejecuta es una capa compatible con EVM, en teoría hacer en cadena una prueba ZK de conocimiento cero compleja debería disparar las tarifas de Gas. ¿Cómo es que logra validación a nivel de milisegundos y con costos tan bajos?
Hoy, al revisar el código fuente de la máquina virtual Piecrust y la implementación subyacente en Rust, entendí que me había planteado la lógica de forma demasiado simple.
Al principio pensé que era como los zkEVM convencionales: empacar toda la lógica de circuitos de las pruebas de conocimiento cero dentro del bytecode WASM para que la VM la calcule “por software”. Hasta que vi el conjunto de “ofuscación nativa criptográfica (Cryptographic Native Offloading)” que implementa en la capa de Host: entonces comprendí que no se trata para nada de un enfoque de otra escala.
En el diseño de Piecrust, extraen directamente primitivas criptográficas que consumen muchísimo cómputo, como el hash Poseidon y la verificación de pruebas Plonk (Primitives), de la interpretación y ejecución dentro de la VM, y las implementan en Rust para entregarlas a un acelerador a nivel de Host (el sistema anfitrión). La VM solo se encarga de pasar manejadores (Handles) y de las transiciones de estado.
Esto es como jugar un videojuego 3D: la solución antigua era hacer que la CPU renderizara píxel por píxel de forma puramente software, con lo que el cómputo se dispara al instante. En cambio, Dusk lanza los cálculos gráficos directamente a la GPU de bajo nivel, y la CPU solo emite instrucciones.
También comparé su manejo de snapshots de memoria (Memory Snapshots) en la etapa de compilación, y descubrí que incluso admite deserializar el estado de conocimiento cero sin tener que recargar todo el estado de memoria. Con esto queda totalmente explicado por qué puede mantener validaciones criptográficas sobre estados privados sin hacer que los costos de Gas de los nodos de validación colapsen.
Antes me parecía algo vacío el “nivel de privacidad institucional” con el que promocionan, pensando que solo estaban escribiendo código pegamento de alto nivel. Hoy, al entender este recorte “físico” a nivel de la base de Piecrust, me di cuenta de que su equipo de ingeniería realmente está exprimiendo al máximo el hardware y el cómputo para el escenario de “privacidad financiera de alta frecuencia”.
Y todo esto—la aceleración criptográfica en Host y la coordinación de instrucciones de la VM—termina convirtiéndose en DUSK como recurso de cómputo unificado y como vara de medir el Gas en la liquidación.
#dusk $DUSK
Hoy, al revisar el código fuente de la máquina virtual Piecrust y la implementación subyacente en Rust, entendí que me había planteado la lógica de forma demasiado simple.
Al principio pensé que era como los zkEVM convencionales: empacar toda la lógica de circuitos de las pruebas de conocimiento cero dentro del bytecode WASM para que la VM la calcule “por software”. Hasta que vi el conjunto de “ofuscación nativa criptográfica (Cryptographic Native Offloading)” que implementa en la capa de Host: entonces comprendí que no se trata para nada de un enfoque de otra escala.
En el diseño de Piecrust, extraen directamente primitivas criptográficas que consumen muchísimo cómputo, como el hash Poseidon y la verificación de pruebas Plonk (Primitives), de la interpretación y ejecución dentro de la VM, y las implementan en Rust para entregarlas a un acelerador a nivel de Host (el sistema anfitrión). La VM solo se encarga de pasar manejadores (Handles) y de las transiciones de estado.
Esto es como jugar un videojuego 3D: la solución antigua era hacer que la CPU renderizara píxel por píxel de forma puramente software, con lo que el cómputo se dispara al instante. En cambio, Dusk lanza los cálculos gráficos directamente a la GPU de bajo nivel, y la CPU solo emite instrucciones.
También comparé su manejo de snapshots de memoria (Memory Snapshots) en la etapa de compilación, y descubrí que incluso admite deserializar el estado de conocimiento cero sin tener que recargar todo el estado de memoria. Con esto queda totalmente explicado por qué puede mantener validaciones criptográficas sobre estados privados sin hacer que los costos de Gas de los nodos de validación colapsen.
Antes me parecía algo vacío el “nivel de privacidad institucional” con el que promocionan, pensando que solo estaban escribiendo código pegamento de alto nivel. Hoy, al entender este recorte “físico” a nivel de la base de Piecrust, me di cuenta de que su equipo de ingeniería realmente está exprimiendo al máximo el hardware y el cómputo para el escenario de “privacidad financiera de alta frecuencia”.
Y todo esto—la aceleración criptográfica en Host y la coordinación de instrucciones de la VM—termina convirtiéndose en DUSK como recurso de cómputo unificado y como vara de medir el Gas en la liquidación.
#dusk $DUSK