Lorsque je re-vérifie les dernières notes de mise à niveau du réseau @Dusk , je découvre un changement encore plus important que la version “standard” : après la mise à niveau de Boreas, le réseau principal de Dusk a cessé de recevoir et d’exécuter de nouvelles transactions Phoenix.
Boreas a été déployé avec Rusk 1.7, et le réseau principal a fixé sa limite de redémarrage au 10 juin 2026, au bloc 4,414,095. Lors du redémarrage du réseau principal, Phoenix a été désactivé ; pour le réseau de test, Phoenix s’est arrêté après avoir atteint le niveau 4,000,000 le 7 août. À l’heure actuelle, les nouvelles transactions utilisent principalement le modèle Moonlight.
Mais “arrêter de créer de nouvelles transactions” ne signifie pas supprimer Phoenix. Les nœuds conservent toujours la capacité de décoder les anciennes transactions Phoenix, d’exécuter leur historique et de synchroniser l’état de la chaîne, car un Archive Node doit pouvoir rejouer d’anciens blocs. En langage courant : si une banque cesse d’ouvrir un ancien type de compte, cela ne veut pas dire que les anciens mouvements peuvent être supprimés du grand livre.
Boreas introduit aussi un traitement des transactions versionné, des règles de facturation VM déterministes, un indicateur d’événement Reverted, et modifie l’ordre d’exécution du Slash pour qu’il se fasse avant les transactions ordinaires. Cela montre que l’objectif de la mise à niveau ne consiste pas seulement à remplacer le modèle de transfert, mais à resserrer les frontières d’interprétation d’une même transaction entre différents nœuds.
La vraie question à creuser est : quelle trajectoire de confidentialité assurera la suite sur Dusk ? Moonlight est un modèle de comptes publics, tandis que DuskEVM décrit Hedger comme la voie future de la confidentialité. Par la suite, il faut surveiller la livraison de Hedger, la migration des portefeuilles, le traitement des soldes Phoenix existants et la mise à jour cohérente de la documentation.
Le plus dangereux, dans un projet de confidentialité, n’est pas le changement technique, mais le fait d’expliquer le nouveau réseau avec l’ancienne architecture. #dusk $DUSK
Boreas a été déployé avec Rusk 1.7, et le réseau principal a fixé sa limite de redémarrage au 10 juin 2026, au bloc 4,414,095. Lors du redémarrage du réseau principal, Phoenix a été désactivé ; pour le réseau de test, Phoenix s’est arrêté après avoir atteint le niveau 4,000,000 le 7 août. À l’heure actuelle, les nouvelles transactions utilisent principalement le modèle Moonlight.
Mais “arrêter de créer de nouvelles transactions” ne signifie pas supprimer Phoenix. Les nœuds conservent toujours la capacité de décoder les anciennes transactions Phoenix, d’exécuter leur historique et de synchroniser l’état de la chaîne, car un Archive Node doit pouvoir rejouer d’anciens blocs. En langage courant : si une banque cesse d’ouvrir un ancien type de compte, cela ne veut pas dire que les anciens mouvements peuvent être supprimés du grand livre.
Boreas introduit aussi un traitement des transactions versionné, des règles de facturation VM déterministes, un indicateur d’événement Reverted, et modifie l’ordre d’exécution du Slash pour qu’il se fasse avant les transactions ordinaires. Cela montre que l’objectif de la mise à niveau ne consiste pas seulement à remplacer le modèle de transfert, mais à resserrer les frontières d’interprétation d’une même transaction entre différents nœuds.
La vraie question à creuser est : quelle trajectoire de confidentialité assurera la suite sur Dusk ? Moonlight est un modèle de comptes publics, tandis que DuskEVM décrit Hedger comme la voie future de la confidentialité. Par la suite, il faut surveiller la livraison de Hedger, la migration des portefeuilles, le traitement des soldes Phoenix existants et la mise à jour cohérente de la documentation.
Le plus dangereux, dans un projet de confidentialité, n’est pas le changement technique, mais le fait d’expliquer le nouveau réseau avec l’ancienne architecture. #dusk $DUSK