Vous envoyez une transaction, elle est confirmée, mais votre wallet affiche toujours le solde ancien. Vous actualisez, il apparaît. Vous actualisez à nouveau, il a disparu. Rien ne s’est cassé. Vous venez simplement de tomber sur une réplica qui n’avait pas encore été synchronisée. Rialo a publié un guide sur les modèles de cohérence qui explique exactement cela, et cette explication est plus utile que la plupart des conseils d’UX pour wallets. Les systèmes distribués répliquent les données sur plusieurs serveurs, et ces serveurs reçoivent les mises à jour à des moments différents. Une lecture effectuée sur une réplica en retard renvoie un état ancien déjà validé. Un comportement correct selon la plupart des modèles de cohérence, mais profondément déroutant à observer. La solution a un nom : read my writes. Une fois qu’un client a validé une écriture au sein d’une session, chaque lecture ultérieure dans cette session reflète cette écriture. Vous voyez toujours votre propre transaction, même si les autres utilisateurs ne la voient pas encore. Associée à des lectures monotones, votre vue ne fait que progresser, donc un solde ne recule jamais au cours d’une même session. La documentation de @RialoHQ indique que les wallets doivent implémenter cela au niveau de l’application, et cartographie séparément quel modèle convient à quelle partie d’une chaîne : cohérence forte pour les points de contrôle de finalité, préfixe cohérent pour l’ordre des blocs pendant la synchronisation, obsolescence bornée pour les clients légers. La plupart des chaînes laissent la cohérence non documentée et laissent les développeurs la découvrir via des rapports de bugs. Écrire clairement quelle garantie s’applique où est un travail peu glamour qui permet d’économiser une semaine à quelqu’un qui cherchait un problème qui n’était jamais un bug.