Anoche volví a revisar la documentación de Dusk y me quedé con más interés en las preguntas de diseño que en las afirmaciones técnicas.

Lo primero que me llamó la atención fue la división entre Moonlight y Phoenix. Moonlight es basado en cuentas, con una clave pública, un nonce y un saldo, mientras que Phoenix usa UTXOs como “notas” dentro de un árbol de Merkle. Los campos de transacción de Moonlight incluyen from, to, value, nonce, deposit, data, gas_limit, gas_price y signature, con el gas máximo calculado como gas_limit × gas_price.

Phoenix se pone interesante. Usa la curva Jubjub, con claves públicas (A,B), claves secretas (a,b) y una clave de vista (a,B). La estructura de la nota incluye type, com, enc, npk, R y encsender. La clave de nota de un solo uso se deriva como npk = H(rA)G + B, mientras que la clave de gasto es nsk = H(aR) + b.

Todavía estoy intentando entender el límite de confianza en torno a la generación de pruebas ZK y el escaneo delegado. La documentación dice que terceros pueden generar pruebas o escanear usando claves de vista sin obtener autoridad de gasto, pero ¿dónde están los puntos de fallo?

Y con nullifiers, raíces de Merkle recientes y el gas gestionado dentro de la prueba, ¿cómo se comporta esto bajo condiciones de red adversarias? ¿Qué partes están descentralizadas y qué supuestos deberían examinar los usuarios?

#dusk $DUSK @Dusk