#dusk $DUSK @Dusk Dusk' configuración de confidencialidad en realidad se ejecuta en dos pistas separadas. En DuskDS, el modelo Phoenix representa el valor como notas comprometidas dentro de un árbol de Merkle: gastar una nota no señala qué nota se está gastando. En su lugar, el emisor publica un nullificador y una prueba de conocimiento cero que muestra que el gasto es válido, que la propiedad es real y que no se creó ningún valor de la nada, sin revelar la nota subyacente. Junto a ello, Moonlight funciona como un modelo transparente y basado en cuentas en la misma cadena.
En DuskEVM, sin embargo, la privacidad proviene de un conjunto de herramientas completamente diferente: un módulo llamado Hedger, que combina cifrado homomórfico basado en ElGamal con pruebas de conocimiento cero, además de una estructura híbrida UTXO/cuenta. Aquí, un usuario interactúa con contratos a través de una dirección EVM estándar, mientras que una dirección Hedger separada gestiona saldos cifrados, con el cumplimiento garantizado mediante listas de permitidos.
No son dos versiones de la misma idea. Phoenix es un sistema de pruebas basado en notas; Hedger calcula directamente sobre saldos cifrados, verificados mediante pruebas de conocimiento cero. La razón probable de la separación es que la privacidad basada en notas no encaja de forma natural en una estructura EVM basada en cuentas, por lo que allí se necesitó un enfoque distinto.
Ejecutar dos pilas independientes de privacidad criptográfica en paralelo significa una mayor superficie de ataque y una carga de auditoría más pesada. Además, no está claro cómo se preserva la garantía de privacidad cuando el valor se mueve entre las dos capas.
¿Mantener dos motores de confidencialidad separados multiplica la carga de auditoría de manera proporcional, o la dependencia compartida de las pruebas de conocimiento cero hace que el costo incremental del segundo motor sea, en realidad, menor de lo que parece?
En DuskEVM, sin embargo, la privacidad proviene de un conjunto de herramientas completamente diferente: un módulo llamado Hedger, que combina cifrado homomórfico basado en ElGamal con pruebas de conocimiento cero, además de una estructura híbrida UTXO/cuenta. Aquí, un usuario interactúa con contratos a través de una dirección EVM estándar, mientras que una dirección Hedger separada gestiona saldos cifrados, con el cumplimiento garantizado mediante listas de permitidos.
No son dos versiones de la misma idea. Phoenix es un sistema de pruebas basado en notas; Hedger calcula directamente sobre saldos cifrados, verificados mediante pruebas de conocimiento cero. La razón probable de la separación es que la privacidad basada en notas no encaja de forma natural en una estructura EVM basada en cuentas, por lo que allí se necesitó un enfoque distinto.
Ejecutar dos pilas independientes de privacidad criptográfica en paralelo significa una mayor superficie de ataque y una carga de auditoría más pesada. Además, no está claro cómo se preserva la garantía de privacidad cuando el valor se mueve entre las dos capas.
¿Mantener dos motores de confidencialidad separados multiplica la carga de auditoría de manera proporcional, o la dependencia compartida de las pruebas de conocimiento cero hace que el costo incremental del segundo motor sea, en realidad, menor de lo que parece?