Quand j’ai vu Boreas, j’ai d’abord cru qu’il s’agissait d’une mise à niveau logicielle ordinaire.@Dusk Dusk a activé Rusk 1.7.0 sur le réseau principal le 10 juin 2026, à partir du bloc 4,414,095. Les ajustements portent sur la manière dont les octets de transaction entrent dans le réseau, sont intégrés dans les blocs et comment le système rejoue l’ancien grand livre en appliquant un ensemble de règles précis. Le client peut toujours soumettre des encapsulations Aegis prises en charge ; Rusk effectue la normalisation à l’entrée, puis écrit le tout dans un bloc en utilisant le format actuel du grand livre.

J’ai interprété cette logique comme un casier à billets de type chambre de compensation. Les billets externes peuvent provenir d’anciens modèles ; avant d’être rangés dans le casier, ils doivent être traduits dans un format interne unifié. Les billets historiques conservent leur ancien décodeur : lors de l’audit, on peut les réexaminer à l’identique. Boreas verrouille les conventions d’explication entre mempool, les producteurs de blocs, la validation de consensus et la relecture historique, pour éviter que la même séquence d’octets aboutisse à deux états différents selon l’étape.

La mise à niveau trace aussi une limite : au point de redémarrage, le réseau principal cesse d’accepter de nouvelles transactions Phoenix. Moonlight devient le modèle de transaction actuellement pris en charge, tandis que les anciens blocs Phoenix restent décodables et rejouables. Les événements reverted sont conservés dans l’archive avec un marqueur ; ils ne doivent pas être comptabilisés comme état valide par un indexeur. Quand j’ai raccordé Dusk, je vérifie la hauteur du réseau, la version de Rusk et le modèle de transaction, puis je confirme que l’indexeur lit bien le marqueur reverted. Les anciens enregistrements sont consultables, mais cela ne signifie pas que les anciennes transactions peuvent encore être diffusées.

#dusk $DUSK