#dusk $DUSK
Estos días sigo mirando el Hedger de @Dusk y encontré un punto que antes había entendido demasiado a la ligera.
Al principio pensaba: ¿no basta con tener ZK?
Si ZK puede demostrar “que esta transacción es correcta”, ¿por qué Hedger necesita añadir otra capa de Homomorphic Encryption?
Después de revisar la documentación de un lado a otro, entendí que en realidad están resolviendo dos cosas diferentes.
ZK se parece más a responder:
“¿Cómo demuestras que no estás haciendo trampa?”
HE responde:
“Sin revelar los datos, ¿se puede seguir usando esa información para hacer cálculos?”
Esta diferencia en finanzas es muy clara.
El saldo es confidential, la posición también es confidential, y el estado que queda de la transacción anterior también es confidential.
Pero la siguiente transacción tiene que seguir usando esos estados.
Si antes de cada actualización primero descifras, entonces la privacidad no tiene sentido.
Por eso la idea de Hedger no es simplemente “poner una capa de ZK a la transacción”.
La idea es permitir que una parte del state cifrado pueda seguir participando en los cálculos posteriores y, luego, usar ZK para demostrar que los cambios de estado cumplen las reglas.
Creo que ese es el motivo por el que Hedger vale más la pena que muchas narrativas de “ZK Privacy”.
No busca una anonimidad total.
Incluso el propio equipo oficial admite que el modelo de cuenta de EVM tiene límites.
Lo que realmente quiere hacer es:
Que el state confidential permanezca dentro del flujo financiero de EVM, sin perder la verificación y la auditoría.
Por supuesto, tampoco conviene pensar que HE es una llave maestra.
Hedger no es, por ahora, una FHE VM en la que toda la lógica de Solidity pueda ejecutarse sin más dentro del cifrado; todavía está en Testnet.
Así que lo que realmente voy a mirar a partir de ahora no es “cuántos términos criptográficos usa”, sino hasta qué punto estos balances, ownership y transfers cifrados pueden funcionar en una aplicación real.
Esto importa mucho más que una frase como “privacy EVM”.
Estos días sigo mirando el Hedger de @Dusk y encontré un punto que antes había entendido demasiado a la ligera.
Al principio pensaba: ¿no basta con tener ZK?
Si ZK puede demostrar “que esta transacción es correcta”, ¿por qué Hedger necesita añadir otra capa de Homomorphic Encryption?
Después de revisar la documentación de un lado a otro, entendí que en realidad están resolviendo dos cosas diferentes.
ZK se parece más a responder:
“¿Cómo demuestras que no estás haciendo trampa?”
HE responde:
“Sin revelar los datos, ¿se puede seguir usando esa información para hacer cálculos?”
Esta diferencia en finanzas es muy clara.
El saldo es confidential, la posición también es confidential, y el estado que queda de la transacción anterior también es confidential.
Pero la siguiente transacción tiene que seguir usando esos estados.
Si antes de cada actualización primero descifras, entonces la privacidad no tiene sentido.
Por eso la idea de Hedger no es simplemente “poner una capa de ZK a la transacción”.
La idea es permitir que una parte del state cifrado pueda seguir participando en los cálculos posteriores y, luego, usar ZK para demostrar que los cambios de estado cumplen las reglas.
Creo que ese es el motivo por el que Hedger vale más la pena que muchas narrativas de “ZK Privacy”.
No busca una anonimidad total.
Incluso el propio equipo oficial admite que el modelo de cuenta de EVM tiene límites.
Lo que realmente quiere hacer es:
Que el state confidential permanezca dentro del flujo financiero de EVM, sin perder la verificación y la auditoría.
Por supuesto, tampoco conviene pensar que HE es una llave maestra.
Hedger no es, por ahora, una FHE VM en la que toda la lógica de Solidity pueda ejecutarse sin más dentro del cifrado; todavía está en Testnet.
Así que lo que realmente voy a mirar a partir de ahora no es “cuántos términos criptográficos usa”, sino hasta qué punto estos balances, ownership y transfers cifrados pueden funcionar en una aplicación real.
Esto importa mucho más que una frase como “privacy EVM”.