#dusk $DUSK @Dusk
En lisant la logique de transfert de Zedger, une règle m’a arrêté : le destinataire doit approuver un transfert avant qu’il ne soit réglé. Pas la personne qui l’envoie. La personne de l’autre côté.
J’avais supposé qu’un transfert se fait automatiquement une fois initié, comme dans la plupart des modèles de compte. Zedger ne fonctionne pas comme ça. Tant que l’acceptation n’a pas eu lieu, le solde est toujours compté du côté de l’émetteur. Il existe un chemin CLAIM lorsque l’approbation n’arrive jamais avant l’expiration du transfert, ce qui me dit que cet état en attente est prévu, qu’il doit se produire, et pas juste comme une exception rare.
Imaginez-le simplement. Quelqu’un détient une partie d’une obligation tokenisée via un montage comme NPEX. Il initie un transfert vers un autre compte autorisé. Le destinataire n’a pas encore accepté. Donc si vous vérifiiez la propriété à cet instant précis, hypothétiquement, cela indiquerait encore le détenteur initial, parce que rien n’a été finalisé côté Zedger.
La partie étrange n’est pas l’existence d’un état en attente. C’est plutôt que Zedger est par ailleurs très précis : un compte par utilisateur autorisé, un historique complet de chaque changement de solde, sans ambiguïté sur le passé. Mais la propriété actuelle peut rester non résolue pendant un certain temps, par conception, parce que le destinataire doit réellement choisir de l’accepter.
Je ne pense pas que ce soit un défaut. Exiger une acceptation plutôt qu’un règlement automatique donne probablement à une partie autorisée la possibilité de refuser un actif plutôt que de le voir imposé dans son compte. Mais cela signifie que deux personnes qui vérifient le même transfert au même moment, avant l’approbation, verraient des réponses différentes sur la personne qui en est actuellement propriétaire.
Le livre blanc précise le mécanisme. Il ne dit rien sur la fréquence à laquelle cet écart est réellement testé une fois que de vraies activités de règlement entrent en jeu.
Cette fenêtre d’attente est-elle quelque chose qu’opérateurs rencontreraient rarement, ou est-ce un état qu’ils finiraient par gérer en continu une fois que le volume de transferts augmente ?
$BTC $TUT
En lisant la logique de transfert de Zedger, une règle m’a arrêté : le destinataire doit approuver un transfert avant qu’il ne soit réglé. Pas la personne qui l’envoie. La personne de l’autre côté.
J’avais supposé qu’un transfert se fait automatiquement une fois initié, comme dans la plupart des modèles de compte. Zedger ne fonctionne pas comme ça. Tant que l’acceptation n’a pas eu lieu, le solde est toujours compté du côté de l’émetteur. Il existe un chemin CLAIM lorsque l’approbation n’arrive jamais avant l’expiration du transfert, ce qui me dit que cet état en attente est prévu, qu’il doit se produire, et pas juste comme une exception rare.
Imaginez-le simplement. Quelqu’un détient une partie d’une obligation tokenisée via un montage comme NPEX. Il initie un transfert vers un autre compte autorisé. Le destinataire n’a pas encore accepté. Donc si vous vérifiiez la propriété à cet instant précis, hypothétiquement, cela indiquerait encore le détenteur initial, parce que rien n’a été finalisé côté Zedger.
La partie étrange n’est pas l’existence d’un état en attente. C’est plutôt que Zedger est par ailleurs très précis : un compte par utilisateur autorisé, un historique complet de chaque changement de solde, sans ambiguïté sur le passé. Mais la propriété actuelle peut rester non résolue pendant un certain temps, par conception, parce que le destinataire doit réellement choisir de l’accepter.
Je ne pense pas que ce soit un défaut. Exiger une acceptation plutôt qu’un règlement automatique donne probablement à une partie autorisée la possibilité de refuser un actif plutôt que de le voir imposé dans son compte. Mais cela signifie que deux personnes qui vérifient le même transfert au même moment, avant l’approbation, verraient des réponses différentes sur la personne qui en est actuellement propriétaire.
Le livre blanc précise le mécanisme. Il ne dit rien sur la fréquence à laquelle cet écart est réellement testé une fois que de vraies activités de règlement entrent en jeu.
Cette fenêtre d’attente est-elle quelque chose qu’opérateurs rencontreraient rarement, ou est-ce un état qu’ils finiraient par gérer en continu une fois que le volume de transferts augmente ?
$BTC $TUT
