El detalle de Dusk que me hizo mirar dos veces no es la pila ZK — es lo que hace el monedero cuando no sabe si una transacción protegida (shielded) tuvo éxito.
En Dusk Wallet v0.1.0, las transacciones Phoenix obtuvieron un seguimiento de “pending-nullifier reservation”. Su registro de cambios indica que esas reservas no se liberan automáticamente tras un tiempo de espera del watcher, un estado desconocido, un estado eliminado o una única encuesta (poll) del mempool que faltó.
¿Por qué mantener deliberadamente los fondos retenidos después de la incertidumbre?
Porque Phoenix gasta notas. Si el monedero reutilizara de inmediato el mismo conjunto de notas gastables mientras la primera transacción todavía podría llegar, podría construir gastos protegidos en conflicto. Dusk también añadió un mutex de gasto para impedir que se construyan envíos Phoenix concurrentes contra las mismas notas.
Dato: esto es lógica de seguridad del lado del monedero, no una nueva regla de consenso. Mi interpretación: Dusk está eligiendo una UX conservadora en lugar de priorizar la disponibilidad optimista del saldo cuando el estado de la transacción es ambiguo.
Ese intercambio importa. Los sistemas de privacidad necesitan más que una criptografía sólida; el manejo del estado del monedero debe mantenerse seguro cuando la visibilidad de la red es incompleta.
Para DUSK, estoy observando si futuras versiones del monedero pueden acortar ese período “incierto” sin debilitar la protección. ¿Con qué agresividad debería un monedero de privacidad desbloquear fondos cuando el estado de la cadena no está claro?
@Dusk $DUSK #dusk
En Dusk Wallet v0.1.0, las transacciones Phoenix obtuvieron un seguimiento de “pending-nullifier reservation”. Su registro de cambios indica que esas reservas no se liberan automáticamente tras un tiempo de espera del watcher, un estado desconocido, un estado eliminado o una única encuesta (poll) del mempool que faltó.
¿Por qué mantener deliberadamente los fondos retenidos después de la incertidumbre?
Porque Phoenix gasta notas. Si el monedero reutilizara de inmediato el mismo conjunto de notas gastables mientras la primera transacción todavía podría llegar, podría construir gastos protegidos en conflicto. Dusk también añadió un mutex de gasto para impedir que se construyan envíos Phoenix concurrentes contra las mismas notas.
Dato: esto es lógica de seguridad del lado del monedero, no una nueva regla de consenso. Mi interpretación: Dusk está eligiendo una UX conservadora en lugar de priorizar la disponibilidad optimista del saldo cuando el estado de la transacción es ambiguo.
Ese intercambio importa. Los sistemas de privacidad necesitan más que una criptografía sólida; el manejo del estado del monedero debe mantenerse seguro cuando la visibilidad de la red es incompleta.
Para DUSK, estoy observando si futuras versiones del monedero pueden acortar ese período “incierto” sin debilitar la protección. ¿Con qué agresividad debería un monedero de privacidad desbloquear fondos cuando el estado de la cadena no está claro?
@Dusk $DUSK #dusk