Ce qui me revient sans cesse au sujet des protocoles de confidentialité, c’est que le paramètre par défaut compte plus que l’option. Les mises à jour de durcissement de Phoenix de Dusk font de l’obfuscation la valeur par défaut pour les transferts déplaçant de la valeur, plutôt que quelque chose dans lequel l’utilisateur devrait choisir de s’engager. Cette distinction peut sembler procédurale, mais en réalité, c’est une déclaration sur la manière dont le système est conçu pour protéger : l’utilisateur moyen, pas seulement celui qui est techniquement motivé.
La confidentialité basée sur l’option tend à créer un ensemble plus restreint et plus facilement identifiable d’utilisateurs qui l’ont choisie, ce qui peut aller à l’encontre de la confidentialité exacte qu’elle est censée offrir. Une obfuscation par défaut évite ce problème de sélection défavorable, au moins en théorie. L’autre élément ici, la compatibilité inter-mises à niveau, est moins visible, mais potentiellement plus important à long terme. Les systèmes de confidentialité qui se brisent lors des mises à niveau de protocoles ont tendance à divulguer des hypothèses que personne n’avait l’intention de rendre exposées.
Ce que je ne sais pas encore, c’est dans quelle mesure ces garanties tiennent dans des conditions de mise à niveau adverses, plutôt que dans des conditions de routine. Je préférerais les voir mises à l’épreuve sous contrainte, plutôt que simplement documentées. J’observe le comportement de Phoenix pendant le prochain cycle de mise à niveau non trivial.

@Dusk #dusk $DUSK