Le détail crépusculaire qui m’a fait regarder deux fois n’est pas la pile ZK — c’est ce que fait le portefeuille lorsqu’il ne sait pas si une transaction protégée a abouti.
Dans Dusk Wallet v0.1.0, les transactions Phoenix ont gagné un suivi de “pending-nullifier reservation”. Son changelog indique que ces réservations ne sont pas automatiquement libérées après un délai d’observation, un état inconnu, un état supprimé, ou encore un unique sondage manqué du mempool.
Pourquoi conserver volontairement les fonds immobilisés en cas d’incertitude ?
Parce que Phoenix dépense des notes. Si le portefeuille réutilisait immédiatement le même ensemble de notes dépensables pendant que la première transaction pourrait encore aboutir, il pourrait construire des dépenses protégées conflictuelles. Dusk a aussi ajouté un verrou de dépense (spend mutex) pour empêcher la construction simultanée d’envois Phoenix à partir des mêmes notes.
Fait : il s’agit d’une logique de sécurité côté portefeuille, pas d’une nouvelle règle de consensus. Mon interprétation : Dusk privilégie une UX conservatrice plutôt qu’une disponibilité optimiste du solde lorsque l’état de la transaction est ambigu.
Ce compromis compte. Les systèmes de confidentialité ont besoin de plus que d’une cryptographie solide ; la gestion de l’état du portefeuille doit rester sûre lorsque la visibilité réseau est incomplète.
Pour DUSK, je surveille si de futures versions du portefeuille peuvent raccourcir cette période “incertaine” sans affaiblir la protection. À quel point un portefeuille de confidentialité devrait-il déverrouiller les fonds lorsque l’état de la chaîne est incertain ?
@Dusk $DUSK #dusk
Dans Dusk Wallet v0.1.0, les transactions Phoenix ont gagné un suivi de “pending-nullifier reservation”. Son changelog indique que ces réservations ne sont pas automatiquement libérées après un délai d’observation, un état inconnu, un état supprimé, ou encore un unique sondage manqué du mempool.
Pourquoi conserver volontairement les fonds immobilisés en cas d’incertitude ?
Parce que Phoenix dépense des notes. Si le portefeuille réutilisait immédiatement le même ensemble de notes dépensables pendant que la première transaction pourrait encore aboutir, il pourrait construire des dépenses protégées conflictuelles. Dusk a aussi ajouté un verrou de dépense (spend mutex) pour empêcher la construction simultanée d’envois Phoenix à partir des mêmes notes.
Fait : il s’agit d’une logique de sécurité côté portefeuille, pas d’une nouvelle règle de consensus. Mon interprétation : Dusk privilégie une UX conservatrice plutôt qu’une disponibilité optimiste du solde lorsque l’état de la transaction est ambigu.
Ce compromis compte. Les systèmes de confidentialité ont besoin de plus que d’une cryptographie solide ; la gestion de l’état du portefeuille doit rester sûre lorsque la visibilité réseau est incomplète.
Pour DUSK, je surveille si de futures versions du portefeuille peuvent raccourcir cette période “incertaine” sans affaiblir la protection. À quel point un portefeuille de confidentialité devrait-il déverrouiller les fonds lorsque l’état de la chaîne est incertain ?
@Dusk $DUSK #dusk
