Estos dos días he estado probando en <a>@Dusk </a> la implementación en una red de un contrato ERC-20 estándar con restricciones de cumplimiento, y me topé con algunos problemas que me dieron dolor de cabeza 🤕. La compilación salió bien, pero al llamar directamente a la función de verificación de privacidad me arrojó el error GasLimitExceeded.
Al principio pensé que era un bug en la lógica de estimación de gas de DuskEVM, así que revisé el código de la capa puente (Bridge Layer) que hay entre dusk-evm y Piecrust. Ahí me di cuenta de que había supuesto de manera demasiado obvia cómo se mapeaban el estado de la EVM y el de la máquina ZK.
En una cadena EVM normal, la privacidad normalmente se logra forzando en Solidity el uso de librerías de pruebas de conocimiento cero (por ejemplo, el precompilado Alt_bn128). Cada verificación en cadena revienta la capacidad de cómputo del Execution Context de Solidity.
Pero el enfoque de Dusk para la compatibilidad con EVM es completamente distinto: no se pone a pelear con el cómputo ZK dentro de la EVM. En su lugar, convierte a DuskEVM en un intérprete “espejo” montado sobre Piecrust (Host-driven Subsystem) #dusk .
En el flujo de llamadas a contratos, la EVM se encarga de procesar la lógica de estado y las interfaces de cuenta con las que los desarrolladores de Ethereum ya están familiarizados en Solidity. En cuanto entra en juego el cómputo de privacidad o las validaciones de cumplimiento, la capa inferior dispara directamente un controlador de HostCall: desacopla el cómputo del cifrado y lo envía para ejecutarlo dentro de los circuitos criptográficos nativos del intérprete de Piecrust.
Al investigar el error, miré las trazas del registro: mi contrato consumía demasiado gas porque, en la capa de Solidity, escribí una validación de hash en un bucle redundante. En el diseño nativo de Dusk, esa acción debería llamar directamente a la interfaz de precompilado de DuskEVM (DuskEVM Precompile) para que la ejecute la capa inferior en código Rust nativo.
Después de cambiarlo a la interfaz de precompilado, el mismo conjunto de lógica de verificación redujo el consumo de gas de un orden de magnitud.
Para desarrolladores de Solidity, la elegancia de este diseño arquitectónico es que no necesitas aprender de nuevo un lenguaje complejo como Circom o Noir. Puedes seguir escribiendo contratos inteligentes con el framework familiar de Hardhat/Foundry. Sin embargo, por debajo disfrutas del poder de cómputo de pruebas ZK a nivel de milisegundos que aporta Rust + Piecrust.
Al usar este puente de arquitectura, ata de forma muy estrecha el enorme ecosistema de desarrolladores de Ethereum con su propia infraestructura nativa de privacidad RWA. Y, tanto para la gestión del estado en la capa EVM como para el consumo del HostCall en la base de Piecrust, la unidad de facturación final sigue siendo $DUSK .
Al principio pensé que era un bug en la lógica de estimación de gas de DuskEVM, así que revisé el código de la capa puente (Bridge Layer) que hay entre dusk-evm y Piecrust. Ahí me di cuenta de que había supuesto de manera demasiado obvia cómo se mapeaban el estado de la EVM y el de la máquina ZK.
En una cadena EVM normal, la privacidad normalmente se logra forzando en Solidity el uso de librerías de pruebas de conocimiento cero (por ejemplo, el precompilado Alt_bn128). Cada verificación en cadena revienta la capacidad de cómputo del Execution Context de Solidity.
Pero el enfoque de Dusk para la compatibilidad con EVM es completamente distinto: no se pone a pelear con el cómputo ZK dentro de la EVM. En su lugar, convierte a DuskEVM en un intérprete “espejo” montado sobre Piecrust (Host-driven Subsystem) #dusk .
En el flujo de llamadas a contratos, la EVM se encarga de procesar la lógica de estado y las interfaces de cuenta con las que los desarrolladores de Ethereum ya están familiarizados en Solidity. En cuanto entra en juego el cómputo de privacidad o las validaciones de cumplimiento, la capa inferior dispara directamente un controlador de HostCall: desacopla el cómputo del cifrado y lo envía para ejecutarlo dentro de los circuitos criptográficos nativos del intérprete de Piecrust.
Al investigar el error, miré las trazas del registro: mi contrato consumía demasiado gas porque, en la capa de Solidity, escribí una validación de hash en un bucle redundante. En el diseño nativo de Dusk, esa acción debería llamar directamente a la interfaz de precompilado de DuskEVM (DuskEVM Precompile) para que la ejecute la capa inferior en código Rust nativo.
Después de cambiarlo a la interfaz de precompilado, el mismo conjunto de lógica de verificación redujo el consumo de gas de un orden de magnitud.
Para desarrolladores de Solidity, la elegancia de este diseño arquitectónico es que no necesitas aprender de nuevo un lenguaje complejo como Circom o Noir. Puedes seguir escribiendo contratos inteligentes con el framework familiar de Hardhat/Foundry. Sin embargo, por debajo disfrutas del poder de cómputo de pruebas ZK a nivel de milisegundos que aporta Rust + Piecrust.
Al usar este puente de arquitectura, ata de forma muy estrecha el enorme ecosistema de desarrolladores de Ethereum con su propia infraestructura nativa de privacidad RWA. Y, tanto para la gestión del estado en la capa EVM como para el consumo del HostCall en la base de Piecrust, la unidad de facturación final sigue siendo $DUSK .