Une chose a attiré mon attention en creusant dans Dusk : un portefeuille peut rester correctement lié à une identité et néanmoins échouer un transfert, car la décision d’éligibilité qui sous-tend ce transfert n’est plus à jour.
J’ai d’abord supposé que cela revenait essentiellement à une seule étape de validation.
Ce n’est pas le cas.
Plus j’ai examiné l’architecture, plus cela ressemblait à un problème de gestion d’état plutôt qu’à un problème de portefeuille.
Lier un portefeuille établit une relation cryptographique entre une identité et un portefeuille.
Cette relation peut rester parfaitement valide pendant que des conditions externes qui affectent l’éligibilité au transfert changent.
Imaginez un portefeuille lié un lundi. Le mardi, un paramètre de conformité hors chaîne est modifié.
L’association à l’identité n’a pas été révoquée, le portefeuille n’a pas changé, et l’utilisateur peut toujours prouver qu’il en a le contrôle.
Mais si l’état de la politique utilisé lors de l’évaluation de la transaction n’a pas été recalculé, le transfert peut aboutir à un résultat complètement différent. #dusk .
Cette nuance est facile à manquer, car l’interface regroupe plusieurs contrôles dans une seule expérience : « vérifié » ne signifie pas nécessairement « éligible à l’instant ».
En dessous, il peut y avoir plusieurs transitions d’état indépendantes : vérification de signature, association à l’identité, statut de justificatif ou de politique, puis autorisation finale du transfert. @Dusk .
La question d’ingénierie importante est de savoir comment les changements de politique externe se propagent à l’état que la transaction évalue réellement.
Pour $DUSK , cela crée un arbitrage intéressant. Maintenir un état de politique conservateur peut réduire l’exposition à la conformité, mais un état périmé entraîne des transferts rejetés et des frictions opérationnelles.
Le mettre à jour de manière plus agressive améliore la fraîcheur, mais introduit davantage de calcul, de coordination et de dépendances d’infrastructure.
Ce que j’essaie encore de comprendre, c’est la couche d’incitation : lorsqu’un portefeuille valide devient une permission obsolète, qui est responsable, sur le plan économique et opérationnel, de rafraîchir cet état ?
J’ai d’abord supposé que cela revenait essentiellement à une seule étape de validation.
Ce n’est pas le cas.
Plus j’ai examiné l’architecture, plus cela ressemblait à un problème de gestion d’état plutôt qu’à un problème de portefeuille.
Lier un portefeuille établit une relation cryptographique entre une identité et un portefeuille.
Cette relation peut rester parfaitement valide pendant que des conditions externes qui affectent l’éligibilité au transfert changent.
Imaginez un portefeuille lié un lundi. Le mardi, un paramètre de conformité hors chaîne est modifié.
L’association à l’identité n’a pas été révoquée, le portefeuille n’a pas changé, et l’utilisateur peut toujours prouver qu’il en a le contrôle.
Mais si l’état de la politique utilisé lors de l’évaluation de la transaction n’a pas été recalculé, le transfert peut aboutir à un résultat complètement différent. #dusk .
Cette nuance est facile à manquer, car l’interface regroupe plusieurs contrôles dans une seule expérience : « vérifié » ne signifie pas nécessairement « éligible à l’instant ».
En dessous, il peut y avoir plusieurs transitions d’état indépendantes : vérification de signature, association à l’identité, statut de justificatif ou de politique, puis autorisation finale du transfert. @Dusk .
La question d’ingénierie importante est de savoir comment les changements de politique externe se propagent à l’état que la transaction évalue réellement.
Pour $DUSK , cela crée un arbitrage intéressant. Maintenir un état de politique conservateur peut réduire l’exposition à la conformité, mais un état périmé entraîne des transferts rejetés et des frictions opérationnelles.
Le mettre à jour de manière plus agressive améliore la fraîcheur, mais introduit davantage de calcul, de coordination et de dépendances d’infrastructure.
Ce que j’essaie encore de comprendre, c’est la couche d’incitation : lorsqu’un portefeuille valide devient une permission obsolète, qui est responsable, sur le plan économique et opérationnel, de rafraîchir cet état ?
