#dusk $DUSK @Dusk
Phoenix mantiene pruebas de doble gasto en un árbol de Merkle de notas, en lugar de un libro mayor de cuentas. Todavía no hay balances visibles, pero nadie puede gastar la misma salida dos veces. Quería ver cómo se sostiene eso en la práctica.
Phoenix trata cada unidad de @Dusk como un UTXO llamado nota. Cada nota vive como un hash dentro de un árbol de Merkle. Gastar una nota no la borra; eso no es así como funcionan estos árboles. En su lugar, gastarla produce un anulador (nullifier): un valor derivado de la clave secreta de la nota que aparece públicamente una vez que se usa. La red nunca aprende de qué nota proviene el anulador, solo que ahora es inválido. Intenta reutilizar la misma nota y el anulador duplicado la delata al instante.
Ese diseño es lo que permite que Phoenix se mantenga protegido y aun así sea verificable. Las finanzas reguladas no pueden tolerar una liquidación ambigua, y los anuladores dan una finalidad determinista sin exponer al emisor, al receptor ni el monto. Una clave de vista permite que un propietario pruebe selectivamente qué contenía una nota, de modo que la auditabilidad no se pierde por completo: se pospone para el titular de la clave.
Lo que no pude resolver del todo a partir de la documentación: cómo se gestiona a largo plazo el crecimiento del conjunto de anuladores y cuál es el costo de generación/verificación (proving) a medida que el árbol de notas escala bajo un volumen institucional sostenido, en vez de condiciones de prueba.
Realmente curioso: ¿alguien ha visto números de rendimiento para la generación de pruebas de Phoenix bajo carga real de liquidación, no solo los puntos de referencia de testnet?
$DUSK #dusk
Phoenix mantiene pruebas de doble gasto en un árbol de Merkle de notas, en lugar de un libro mayor de cuentas. Todavía no hay balances visibles, pero nadie puede gastar la misma salida dos veces. Quería ver cómo se sostiene eso en la práctica.
Phoenix trata cada unidad de @Dusk como un UTXO llamado nota. Cada nota vive como un hash dentro de un árbol de Merkle. Gastar una nota no la borra; eso no es así como funcionan estos árboles. En su lugar, gastarla produce un anulador (nullifier): un valor derivado de la clave secreta de la nota que aparece públicamente una vez que se usa. La red nunca aprende de qué nota proviene el anulador, solo que ahora es inválido. Intenta reutilizar la misma nota y el anulador duplicado la delata al instante.
Ese diseño es lo que permite que Phoenix se mantenga protegido y aun así sea verificable. Las finanzas reguladas no pueden tolerar una liquidación ambigua, y los anuladores dan una finalidad determinista sin exponer al emisor, al receptor ni el monto. Una clave de vista permite que un propietario pruebe selectivamente qué contenía una nota, de modo que la auditabilidad no se pierde por completo: se pospone para el titular de la clave.
Lo que no pude resolver del todo a partir de la documentación: cómo se gestiona a largo plazo el crecimiento del conjunto de anuladores y cuál es el costo de generación/verificación (proving) a medida que el árbol de notas escala bajo un volumen institucional sostenido, en vez de condiciones de prueba.
Realmente curioso: ¿alguien ha visto números de rendimiento para la generación de pruebas de Phoenix bajo carga real de liquidación, no solo los puntos de referencia de testnet?
$DUSK #dusk
