Acompáñame a la sexta sección del libro blanco
El título es muy simple: Cryptographic Primitives. Este capítulo es el verdadero cimiento de la privacidad de @Dusk
Lo que se habló antes sobre consenso y modelo de transacciones, en realidad son solo edificios construidos sobre esta base
Me di cuenta de un patrón muy claro: casi cada componente tiene una "configuración de doble vía"
Las funciones hash usan Blake2b para el cómputo general, y además Poseidon se encarga específicamente de las pruebas de conocimiento cero; las firmas usan Schnorr para el uso diario y BLS para firmas agregables; incluso las curvas se dividen en dos, JubJub para operaciones generales y BLS12-381 para emparejamientos
Mi conclusión es que esto no es simplemente apilar componentes, sino que ZK-friendly y los escenarios normales tienen requisitos de hash completamente distintos; forzarlo todo en una sola solución haría sufrir a ambos lados, así que simplemente prepararon un conjunto para cada caso
Lo que más me llamó la atención son las direcciones ocultas: no te dan una dirección fija para usar para siempre, sino que, basándose en el intercambio de claves Diffie-Hellman, generan en cada transacción una clave pública de un solo uso
El destinatario solo muestra la public spend key, el remitente usa un número aleatorio r para calcular la clave pública de un solo uso y enviar el dinero; luego el destinatario revisa la transacción con su propia view key y solo entonces reconoce "esto es para mí"; y si realmente quiere gastar esos fondos, todavía debe usar la secret spend key
Ver, recibir y gastar: tres claves, cada una con su función. Creo que esto es mucho más ingenioso que "usar una dirección hasta el fin de los tiempos"; en la cadena nadie puede encadenar tus múltiples cobros en una sola línea
El esquema de compromiso utiliza Pedersen: c = v·G + b·H, donde G y H son dos generadores cuya relación es desconocida; esto puede ocultar la cantidad y también evita que luego niegues el compromiso y la cambies por otro valor
El cifrado también se divide en herramientas: ElGamal se encarga de lo asimétrico, y Poseidon-SpongeWrap de lo simétrico
Incluso el árbol de Merkle no se toma atajos: la estructura general calcula el hash con Blake2b, y cualquier estructura que necesite alimentarse a una prueba ZK cambia uniformemente a Poseidon, llevando la misma idea hasta el final
Para ser sincero, ver un nivel tan detallado de división del trabajo me sorprendió un poco
La mayoría de los libros blancos, al llegar a este punto, se limitan a decir "adopta una solución estándar de la industria" y ya #dusk $DUSK @Dusk
El título es muy simple: Cryptographic Primitives. Este capítulo es el verdadero cimiento de la privacidad de @Dusk
Lo que se habló antes sobre consenso y modelo de transacciones, en realidad son solo edificios construidos sobre esta base
Me di cuenta de un patrón muy claro: casi cada componente tiene una "configuración de doble vía"
Las funciones hash usan Blake2b para el cómputo general, y además Poseidon se encarga específicamente de las pruebas de conocimiento cero; las firmas usan Schnorr para el uso diario y BLS para firmas agregables; incluso las curvas se dividen en dos, JubJub para operaciones generales y BLS12-381 para emparejamientos
Mi conclusión es que esto no es simplemente apilar componentes, sino que ZK-friendly y los escenarios normales tienen requisitos de hash completamente distintos; forzarlo todo en una sola solución haría sufrir a ambos lados, así que simplemente prepararon un conjunto para cada caso
Lo que más me llamó la atención son las direcciones ocultas: no te dan una dirección fija para usar para siempre, sino que, basándose en el intercambio de claves Diffie-Hellman, generan en cada transacción una clave pública de un solo uso
El destinatario solo muestra la public spend key, el remitente usa un número aleatorio r para calcular la clave pública de un solo uso y enviar el dinero; luego el destinatario revisa la transacción con su propia view key y solo entonces reconoce "esto es para mí"; y si realmente quiere gastar esos fondos, todavía debe usar la secret spend key
Ver, recibir y gastar: tres claves, cada una con su función. Creo que esto es mucho más ingenioso que "usar una dirección hasta el fin de los tiempos"; en la cadena nadie puede encadenar tus múltiples cobros en una sola línea
El esquema de compromiso utiliza Pedersen: c = v·G + b·H, donde G y H son dos generadores cuya relación es desconocida; esto puede ocultar la cantidad y también evita que luego niegues el compromiso y la cambies por otro valor
El cifrado también se divide en herramientas: ElGamal se encarga de lo asimétrico, y Poseidon-SpongeWrap de lo simétrico
Incluso el árbol de Merkle no se toma atajos: la estructura general calcula el hash con Blake2b, y cualquier estructura que necesite alimentarse a una prueba ZK cambia uniformemente a Poseidon, llevando la misma idea hasta el final
Para ser sincero, ver un nivel tan detallado de división del trabajo me sorprendió un poco
La mayoría de los libros blancos, al llegar a este punto, se limitan a decir "adopta una solución estándar de la industria" y ya #dusk $DUSK @Dusk