#dusk $DUSK
Estos dos días estuve viendo la última ronda de Developer Update de @Dusk , y hay una actualización que me parece más digna de atención que “otra vez añadieron una función ZK”.
zk-tools ahora empezó a complementar la generación y las herramientas de verificación de Groth16 Solidity verifier.
A primera vista parece algo pequeño.
Pero si de verdad has escrito aplicaciones ZK, sabes que hacer el proof es solo la primera mitad.
Después hay otro problema muy real:
¿Cómo reconoce un contrato Solidity ese proof?
El circuito define las reglas, el prover genera el proof, y cuando llega al lado de EVM, todavía hace falta un contrato verifier para comprobar que el proof y los public inputs cumplen las restricciones originales.
Si esta capa de interfaz no está bien hecha, por más fuerte que sea la criptografía de abajo, para un desarrollador común de Solidity seguirá estando muy lejos.
Por eso ahora, al ver esta actualización de Dusk, lo importante no es el nombre Groth16.
Sino que está completando:
proof → verifier → aplicación Solidity
esa cadena de ingeniería intermedia.
Claro, el verifier tampoco lo puede todo.
Puede confirmar si un proof cumple con el circuito escrito de antemano, pero de dónde vienen los datos, si esa regla tiene sentido de negocio o si la elegibilidad sigue siendo válida ahora, eso todavía lo tiene que definir la aplicación.
De hecho, esto me parece normal.
La criptografía se encarga de verificar bien el “proof”, y el producto se encarga de decidir para qué usarlo.
DuskEVM todavía está en Testnet, así que no voy a decir que todo el flujo de trabajo ZK ya está maduro solo porque añadieron una herramienta de verifier.
Pero una actualización así al menos es más concreta que decir simplemente “soporta ZK”.
Lo que realmente permite que los desarrolladores lo usen, muchas veces son precisamente estas interfaces que no parecen tan atractivas.
Estos dos días estuve viendo la última ronda de Developer Update de @Dusk , y hay una actualización que me parece más digna de atención que “otra vez añadieron una función ZK”.
zk-tools ahora empezó a complementar la generación y las herramientas de verificación de Groth16 Solidity verifier.
A primera vista parece algo pequeño.
Pero si de verdad has escrito aplicaciones ZK, sabes que hacer el proof es solo la primera mitad.
Después hay otro problema muy real:
¿Cómo reconoce un contrato Solidity ese proof?
El circuito define las reglas, el prover genera el proof, y cuando llega al lado de EVM, todavía hace falta un contrato verifier para comprobar que el proof y los public inputs cumplen las restricciones originales.
Si esta capa de interfaz no está bien hecha, por más fuerte que sea la criptografía de abajo, para un desarrollador común de Solidity seguirá estando muy lejos.
Por eso ahora, al ver esta actualización de Dusk, lo importante no es el nombre Groth16.
Sino que está completando:
proof → verifier → aplicación Solidity
esa cadena de ingeniería intermedia.
Claro, el verifier tampoco lo puede todo.
Puede confirmar si un proof cumple con el circuito escrito de antemano, pero de dónde vienen los datos, si esa regla tiene sentido de negocio o si la elegibilidad sigue siendo válida ahora, eso todavía lo tiene que definir la aplicación.
De hecho, esto me parece normal.
La criptografía se encarga de verificar bien el “proof”, y el producto se encarga de decidir para qué usarlo.
DuskEVM todavía está en Testnet, así que no voy a decir que todo el flujo de trabajo ZK ya está maduro solo porque añadieron una herramienta de verifier.
Pero una actualización así al menos es más concreta que decir simplemente “soporta ZK”.
Lo que realmente permite que los desarrolladores lo usen, muchas veces son precisamente estas interfaces que no parecen tan atractivas.
