#dusk $DUSK Hoy estuve revisando el documento del modelo de transacciones Phoenix para @Dusk y me quedé atascado en un concepto básico pero que suele pasarse por alto: en la capa de protocolo de $DUSK , en realidad no existe eso de "cuentas".
En una cadena transparente como Ethereum, cada dirección es una cuenta y el saldo junto con el historial de transacciones es visible para toda la red. Pero Phoenix utiliza un enfoque basado en UTXO: la capa de protocolo no guarda cuentas, solo guarda un montón de cosas llamadas "notes". Cada note incluye una cantidad y una condición de gasto, y una transacción consiste en consumir notes antiguas y producir nuevas notes. El hash de la nueva note se añade a un árbol de Merkle; las hojas del árbol guardan las huellas dactilares de todas las notes en la red.
El diseño para prevenir doble gasto aquí se vuelve especialmente interesante. Cada transacción lleva un conjunto de valores deterministas llamados "nullifier"; cada nullifier corresponde a una note consumida y la marca como inválida. Pero la forma de generar los nullifier pasa por procesamiento criptográfico: un observador externo, al ver que aparece un nullifier, sabe que "se ha gastado una note", pero no puede relacionar ese nullifier con ninguna note específica. La red confirma la anulación (nullification), pero no sabe de quién fue la anulación.
Lo comparo: esto no es como revisar las cuentas de un banco, donde al abrir una página puedes ver todo el movimiento de una persona. Es más bien como triturar cada recibo y tirarlo a una trituradora; luego, de manera cifrada, le dices al sistema "este recibo ya fue anulado". El sistema confirma que la anulación es válida, pero quien se mete en la trituradora no puede recomponer el recibo original ni saber a quién pertenecía.
Pero este diseño no tiene costo cero. A medida que el número de notes crece, el árbol de Merkle crece y cada nodo completo necesita mantener la estructura completa del árbol; además, la generación de nullifier depende de supuestos criptográficos subyacentes y si la elección de parámetros falla, la protección de la privacidad queda prácticamente anulada. La documentación oficial publica los detalles del protocolo, pero en un entorno de producción, habrá que comparar continuamente en la red principal la tasa de colisiones de nullifier y la velocidad de expansión del árbol.
Al observar la capa de privacidad de #dusk , no me limitaría a fijarme solo en la etiqueta de "usar UTXO". Lo que realmente hay que rastrear es la curva de crecimiento del número de notes, el tamaño del conjunto de nullifier y la carga de almacenamiento de los nodos de validación. $DUSK incrusta la privacidad en la base del protocolo, pero el costo de mantener el libro contable subyacente finalmente se reflejará en el rendimiento de toda la red.
#dusk @Dusk