Pasé una hora rastreando la activación PLONK V3 de Dusk en el bloque 3,590,904 y luego una única línea de seguridad de una billetera me apartó; el repositorio dice que aún no se ha completado ninguna auditoría externa.
Eso no hace que la criptografía de Dusk sea débil. Hace que un talento criptográfico serio sea una métrica de superficie equivocada.
Un verificador de pruebas puede rechazar puntos malformados inconsistentes con las entradas públicas y circuitos comprimidos perfectamente, mientras que la transacción del usuario aún depende de la derivación de contraseñas del código de extensión, los permisos de memoria de JavaScript, el endpoint del nodo y el aviso de firma.
La extensión usa PBKDF2 con 900.000 iteraciones y AES-GCM-256; la ruta nativa usa Stronghold más Argon2. Rutas diferentes implican supuestos de confianza diferentes.
Así que yo mediría el comportamiento: ¿cuántas compilaciones independientes generan verificadores de Solidity idénticos a nivel de bytes? ¿Qué prueba malformada consume la mayor cantidad de gas antes del rechazo? ¿La CLI expone la misma advertencia al destinatario marcada que Web Wallet? ¿Y la ruta de firma ha recibido un escrutinio comparable al de PLONK?
Alguna asimetría es normal. Las billeteras del navegador no pueden garantizar la anulación de memoria de JavaScript y una implementación de verificador más simple tiene valor aunque el costo de gas no baje.
Pero la seguridad institucional de Dusk estará determinada por el componente más débil bajo la autoridad que lo respalde, no por sus matemáticas más elegantes. Estoy vigilando si las auditorías siguen el camino de la transacción de principio a fin.
#dusk $DUSK @Dusk
Eso no hace que la criptografía de Dusk sea débil. Hace que un talento criptográfico serio sea una métrica de superficie equivocada.
Un verificador de pruebas puede rechazar puntos malformados inconsistentes con las entradas públicas y circuitos comprimidos perfectamente, mientras que la transacción del usuario aún depende de la derivación de contraseñas del código de extensión, los permisos de memoria de JavaScript, el endpoint del nodo y el aviso de firma.
La extensión usa PBKDF2 con 900.000 iteraciones y AES-GCM-256; la ruta nativa usa Stronghold más Argon2. Rutas diferentes implican supuestos de confianza diferentes.
Así que yo mediría el comportamiento: ¿cuántas compilaciones independientes generan verificadores de Solidity idénticos a nivel de bytes? ¿Qué prueba malformada consume la mayor cantidad de gas antes del rechazo? ¿La CLI expone la misma advertencia al destinatario marcada que Web Wallet? ¿Y la ruta de firma ha recibido un escrutinio comparable al de PLONK?
Alguna asimetría es normal. Las billeteras del navegador no pueden garantizar la anulación de memoria de JavaScript y una implementación de verificador más simple tiene valor aunque el costo de gas no baje.
Pero la seguridad institucional de Dusk estará determinada por el componente más débil bajo la autoridad que lo respalde, no por sus matemáticas más elegantes. Estoy vigilando si las auditorías siguen el camino de la transacción de principio a fin.
#dusk $DUSK @Dusk