el detalle del Fénix es fácil de pasar por alto:
las notas gastadas permanecen en el árbol de Merkle.
primero traté ese árbol como si fuera un conjunto UTXO privado. una vez que se gasta una nota, asumí que desaparecería.
el whitepaper dice lo contrario.
cuando se gasta una nota de Fénix, su propietario deriva un nullifier a partir de la clave secreta de la nota. la red registra ese nullifier para que la nota no pueda gastarse de nuevo.
pero no aprende a qué nota pertenece el nullifier.
así que la nota se queda. el árbol sigue creciendo.
eso crea una distinción en la que no había pensado:
registrado no es lo mismo que gastable.
un Merkle root reciente permite a la red verificar que una nota de entrada pertenece al árbol. solo la pertenencia no significa que el valor siga estando vigente.
esa respuesta está en la lista de nullifiers.
y Fénix mantiene el vínculo público entre ambos oculto.
en Moonlight, Dusk asigna una cuenta a un saldo público.
Fénix funciona de manera distinta. la red verifica una prueba ZK que comprueba que las notas de entrada se han nullificado correctamente y que tienen suficiente valor para nuevas notas, depósitos y gas máximo, sin exponer las cantidades.
así que una nota de Fénix puede permanecer registrada incluso después de que haya desaparecido su utilidad económica.
el registro sobrevive.
el derecho de gasto no.
luego hay otra división.
una view key puede entregarse a una parte confiable para escanear la red e identificar transacciones dirigidas al usuario. pero aun así no puede gastar esas notas, porque la clave secreta de la nota requiere la clave secreta completa del usuario.
así que “puede ver mi estado privado” y “puede controlar mi estado privado” son permisos distintos.
aparecen dos límites:
registrado / gastable
visible / controlable
el caso límite al que sigo volviendo es una aplicación que reconstruye lo que un usuario tiene ahora mismo.
que la nota esté presente no basta.
reconocerla tampoco basta.
necesitas historial, estado de nullificación y el material secreto correcto.
lo que me hace preguntarme:
en un ledger privado, ¿el “estado actual” es un objeto en sí mismo, o es la intersección de registros intencionalmente incompletos cuando se leen solo?
@Dusk #dusk $DUSK $VELVET $APR
las notas gastadas permanecen en el árbol de Merkle.
primero traté ese árbol como si fuera un conjunto UTXO privado. una vez que se gasta una nota, asumí que desaparecería.
el whitepaper dice lo contrario.
cuando se gasta una nota de Fénix, su propietario deriva un nullifier a partir de la clave secreta de la nota. la red registra ese nullifier para que la nota no pueda gastarse de nuevo.
pero no aprende a qué nota pertenece el nullifier.
así que la nota se queda. el árbol sigue creciendo.
eso crea una distinción en la que no había pensado:
registrado no es lo mismo que gastable.
un Merkle root reciente permite a la red verificar que una nota de entrada pertenece al árbol. solo la pertenencia no significa que el valor siga estando vigente.
esa respuesta está en la lista de nullifiers.
y Fénix mantiene el vínculo público entre ambos oculto.
en Moonlight, Dusk asigna una cuenta a un saldo público.
Fénix funciona de manera distinta. la red verifica una prueba ZK que comprueba que las notas de entrada se han nullificado correctamente y que tienen suficiente valor para nuevas notas, depósitos y gas máximo, sin exponer las cantidades.
así que una nota de Fénix puede permanecer registrada incluso después de que haya desaparecido su utilidad económica.
el registro sobrevive.
el derecho de gasto no.
luego hay otra división.
una view key puede entregarse a una parte confiable para escanear la red e identificar transacciones dirigidas al usuario. pero aun así no puede gastar esas notas, porque la clave secreta de la nota requiere la clave secreta completa del usuario.
así que “puede ver mi estado privado” y “puede controlar mi estado privado” son permisos distintos.
aparecen dos límites:
registrado / gastable
visible / controlable
el caso límite al que sigo volviendo es una aplicación que reconstruye lo que un usuario tiene ahora mismo.
que la nota esté presente no basta.
reconocerla tampoco basta.
necesitas historial, estado de nullificación y el material secreto correcto.
lo que me hace preguntarme:
en un ledger privado, ¿el “estado actual” es un objeto en sí mismo, o es la intersección de registros intencionalmente incompletos cuando se leen solo?
@Dusk #dusk $DUSK $VELVET $APR
