Une armoire avec deux tiroirs peut sembler inutile jusqu’au moment où l’on comprend qu’on y range des choses différentes. C’est ainsi que j’ai commencé à réfléchir aux modèles Dusk Moonlight et Phoenix.
Moonlight est la partie publique, basée sur un compte : les soldes et les transferts sont visibles. Phoenix emprunte une voie différente, en utilisant des notes protégées et des preuves à connaissance nulle, de sorte que les détails des transactions puissent rester privés tout en permettant au réseau de vérifier que les règles ont bien été respectées.
Au début, avoir deux modèles semble ajouter de la complexité. Mais c’est peut-être justement le but. Toutes les transactions financières ne nécessitent pas le même niveau de visibilité. Forcer tout dans un modèle transparent expose des informations qui peuvent être sensibles ; forcer tout dans un modèle privé peut rendre le contrôle et l’intégration plus difficiles.
Dusk semble accepter que ces besoins soient réellement différents, plutôt que de faire semblant qu’une seule conception puisse résoudre les deux. @Dusk $DUSK offre au réseau un moyen de prendre en charge à la fois les transferts publics et les transferts protégés sur la même couche de règlement.
La question inconfortable est de savoir si les utilisateurs comprendront quand utiliser quel modèle. La flexibilité est utile — mais seulement si la complexité ne devient pas le nouveau problème. #dusk
Moonlight est la partie publique, basée sur un compte : les soldes et les transferts sont visibles. Phoenix emprunte une voie différente, en utilisant des notes protégées et des preuves à connaissance nulle, de sorte que les détails des transactions puissent rester privés tout en permettant au réseau de vérifier que les règles ont bien été respectées.
Au début, avoir deux modèles semble ajouter de la complexité. Mais c’est peut-être justement le but. Toutes les transactions financières ne nécessitent pas le même niveau de visibilité. Forcer tout dans un modèle transparent expose des informations qui peuvent être sensibles ; forcer tout dans un modèle privé peut rendre le contrôle et l’intégration plus difficiles.
Dusk semble accepter que ces besoins soient réellement différents, plutôt que de faire semblant qu’une seule conception puisse résoudre les deux. @Dusk $DUSK offre au réseau un moyen de prendre en charge à la fois les transferts publics et les transferts protégés sur la même couche de règlement.
La question inconfortable est de savoir si les utilisateurs comprendront quand utiliser quel modèle. La flexibilité est utile — mais seulement si la complexité ne devient pas le nouveau problème. #dusk
