#dusk $DUSK @Dusk ........J’attendais que Boreas rende Dusk plus rapide et plus propre. Le changement le plus profond était plus difficile à remarquer : il a modifié les règles que le réseau considère comme une transaction valide.
Imaginez une blockchain comme un manuel de règles d’un arbitre. Une mise à niveau logicielle n’est pas importante parce que l’arbitre court plus vite. Elle devient importante quand ce sont les règles elles-mêmes qui changent, et que chaque nœud doit interpréter la partie de la même manière.....
C’est ce que Boreas a fait.
Avec Rusk 1.7, Dusk a introduit une version explicite entre les transactions entrantes, leur forme canonique, et ce qui est finalement pris en compte dans le registre. La comptabilité du gas est aussi devenue sensible aux forks, avec des coûts en ressources pour des opérations comme le hachage et la vérification cryptographique liés aux règles du protocole actif.......
Ça a été plus loin.
Boreas a modifié l’ordre des transitions d’état, a rendu explicites pour les consommateurs d’archives les événements de contrat réverts, et a créé une frontière de protocole claire pour le comportement des transactions plus anciennes. Et surtout, les transactions Phoenix ont été désactivées sur le réseau principal de Dusk lors du redémarrage du 10 juin au bloc 4 414 095, tandis que le testnet les a conservées pendant une période d’essai avant de les désactiver au bloc 4 000 000 le 7 août. Les données historiques Phoenix restent rejouables.....
C’est ce dernier détail qui a attiré mon attention.
Un réseau mûr ne consiste pas seulement à ajouter de nouvelles fonctionnalités. Parfois, la mise à niveau importante consiste à décider ce que le protocole doit cesser de faire, tout en conservant suffisamment d’historique pour que la chaîne reste reproductible.......
Et avec Rusk v1.7.1 désormais la dernière version listée, le travail d’ingénierie de Dusk ressemble moins à une mise à niveau unique et davantage à un renforcement continu des règles en dessous de la pile financière.
Pour les marchés réglementés, le comportement de protocole prévisible n’est-il pas aussi important que l’ajout de nouvelles fonctionnalités ?

$ACE $BTW