Ce qui a retenu mon attention aujourd’hui, c’est quelque chose que j’ai failli manquer en lisant la documentation de Dusk : l’abandon des transactions Phoenix dans le cadre de la mise à niveau Boreas.
Ma première hypothèse était qu’il s’agissait d’une maintenance protocolaire de routine. Mais en regardant de plus près, j’ai réalisé à quel point les changements de modèle de transaction peuvent être importants pour un réseau orienté vers des cas d’usage financiers.
Dusk a pris en charge différentes façons de transférer de la valeur, notamment Moonlight pour les transferts publics basés sur un compte et Phoenix pour les transferts chiffrés. Boreas modifie cette conception en retirant les transactions Phoenix au niveau du réseau.
Cela m’a amené à me demander : si la confidentialité est si importante pour Dusk, pourquoi supprimer un modèle de transaction chiffrée natif plutôt que simplement l’améliorer ?
La réponse semble liée à l’évolution de l’architecture de Dusk. Au lieu de s’appuyer sur un seul type générique de transaction privée, sa documentation met désormais l’accent sur des outils de confidentialité au niveau de l’application, tels que des flux d’actifs confidentiels, des capacités à preuve à connaissance nulle, la divulgation sélective, et Hedger sur DuskEVM.
Je trouve ce changement intéressant car il soulève une question plus vaste sur la conception d’une blockchain.
La confidentialité doit-elle être intégrée à chaque transaction de base, ou bien les applications devraient-elles choisir le mécanisme de confidentialité dont elles ont réellement besoin ?
La deuxième approche pourrait offrir davantage de flexibilité aux développeurs, mais elle implique aussi plus de responsabilités dans la conception des applications.
J’essaie encore de comprendre ce que cela signifie pour l’architecture de confidentialité à long terme de Dusk. Si la confidentialité s’oriente davantage vers des mécanismes propres aux applications, comment les développeurs peuvent-ils utiliser correctement ces outils sans rendre le système inutilement compliqué ?
Pour moi, c’est plus intéressant que de simplement qualifier Boreas de mise à niveau de protocole.
Cela montre que Dusk continue de travailler sur un problème difficile : rendre la confidentialité concrètement utilisable sans rendre le réseau plus difficile à employer.
Quelle approche vous semble la plus logique ? #dusk $DUSK @Dusk
Ma première hypothèse était qu’il s’agissait d’une maintenance protocolaire de routine. Mais en regardant de plus près, j’ai réalisé à quel point les changements de modèle de transaction peuvent être importants pour un réseau orienté vers des cas d’usage financiers.
Dusk a pris en charge différentes façons de transférer de la valeur, notamment Moonlight pour les transferts publics basés sur un compte et Phoenix pour les transferts chiffrés. Boreas modifie cette conception en retirant les transactions Phoenix au niveau du réseau.
Cela m’a amené à me demander : si la confidentialité est si importante pour Dusk, pourquoi supprimer un modèle de transaction chiffrée natif plutôt que simplement l’améliorer ?
La réponse semble liée à l’évolution de l’architecture de Dusk. Au lieu de s’appuyer sur un seul type générique de transaction privée, sa documentation met désormais l’accent sur des outils de confidentialité au niveau de l’application, tels que des flux d’actifs confidentiels, des capacités à preuve à connaissance nulle, la divulgation sélective, et Hedger sur DuskEVM.
Je trouve ce changement intéressant car il soulève une question plus vaste sur la conception d’une blockchain.
La confidentialité doit-elle être intégrée à chaque transaction de base, ou bien les applications devraient-elles choisir le mécanisme de confidentialité dont elles ont réellement besoin ?
La deuxième approche pourrait offrir davantage de flexibilité aux développeurs, mais elle implique aussi plus de responsabilités dans la conception des applications.
J’essaie encore de comprendre ce que cela signifie pour l’architecture de confidentialité à long terme de Dusk. Si la confidentialité s’oriente davantage vers des mécanismes propres aux applications, comment les développeurs peuvent-ils utiliser correctement ces outils sans rendre le système inutilement compliqué ?
Pour moi, c’est plus intéressant que de simplement qualifier Boreas de mise à niveau de protocole.
Cela montre que Dusk continue de travailler sur un problème difficile : rendre la confidentialité concrètement utilisable sans rendre le réseau plus difficile à employer.
Quelle approche vous semble la plus logique ? #dusk $DUSK @Dusk
