#dusk $DUSK @Dusk
Lo interesante sobre el diseño de la privacidad de Dusk no es solo que las notas estén ocultas. Es dónde ocurre ese ocultamiento y cuántas suposiciones deben cumplirse a la vez.
Phoenix utiliza compromisos y un árbol de Merkle, mientras que los compromisos de valor agregan un factor de cegamiento. Los validadores pueden verificar la consistencia sin aprender la cantidad. Las direcciones sigilosas también dificultan el enlace entre destinatarios.
La capa de cifrado es donde miro con más detenimiento. En el Phoenix actual se expone AES como su cifrador simétrico, mientras que el stack también incluye JubJub ElGamal y Poseidon. La biblioteca de Poseidon de Dusk tiene funcionalidad de cifrado, pero decir “Poseidon proporciona confidencialidad” es demasiado simplista. La implementación ha evolucionado, y eso importa al evaluar la seguridad semántica.
Mi pregunta real es si la composición ha sido probada como un único sistema. Un compromiso puede ocultar un valor y el cifrado puede ocultar el texto plano, pero la privacidad aun así puede fallar a través de metadatos, manejo de claves, uso indebido del nonce, correlación de direcciones o una relación de prueba defectuosa. Ya lo he visto antes: primitivas fuertes no hacen automáticamente un protocolo fuerte.
Poseidon está diseñado para computación amigable con ZK, mientras que AES es maduro para cifrado general. Eso puede ayudar al rendimiento, pero hace que la frontera entre cifrar, comprometer y probar sea importante.
No estoy listo para confiar en la construcción porque se respetan los ingredientes. Quiero un argumento formal que muestre que el cifrado de notas oculta valores e identidades. Ahí es donde la afirmación de privacidad de Dusk se convierte en algo que puedo evaluar.
Lo interesante sobre el diseño de la privacidad de Dusk no es solo que las notas estén ocultas. Es dónde ocurre ese ocultamiento y cuántas suposiciones deben cumplirse a la vez.
Phoenix utiliza compromisos y un árbol de Merkle, mientras que los compromisos de valor agregan un factor de cegamiento. Los validadores pueden verificar la consistencia sin aprender la cantidad. Las direcciones sigilosas también dificultan el enlace entre destinatarios.
La capa de cifrado es donde miro con más detenimiento. En el Phoenix actual se expone AES como su cifrador simétrico, mientras que el stack también incluye JubJub ElGamal y Poseidon. La biblioteca de Poseidon de Dusk tiene funcionalidad de cifrado, pero decir “Poseidon proporciona confidencialidad” es demasiado simplista. La implementación ha evolucionado, y eso importa al evaluar la seguridad semántica.
Mi pregunta real es si la composición ha sido probada como un único sistema. Un compromiso puede ocultar un valor y el cifrado puede ocultar el texto plano, pero la privacidad aun así puede fallar a través de metadatos, manejo de claves, uso indebido del nonce, correlación de direcciones o una relación de prueba defectuosa. Ya lo he visto antes: primitivas fuertes no hacen automáticamente un protocolo fuerte.
Poseidon está diseñado para computación amigable con ZK, mientras que AES es maduro para cifrado general. Eso puede ayudar al rendimiento, pero hace que la frontera entre cifrar, comprometer y probar sea importante.
No estoy listo para confiar en la construcción porque se respetan los ingredientes. Quiero un argumento formal que muestre que el cifrado de notas oculta valores e identidades. Ahí es donde la afirmación de privacidad de Dusk se convierte en algo que puedo evaluar.