TrajectoryRL a déployé le validateur v0.7.8 le 8 novembre 2026, activant par défaut son paramètre d'émission BURN ALL dans une pull request fusionnée. Sur Bittensor Subnet 11 (SN11), chaque tick de poids attribue désormais 100 % du poids des mineurs à l'UID propriétaire 74, en ignorant le vainqueur désigné de la politique de fusion. Comme SN11 brûle l'émission recyclée des mineurs, cette part est détruite plutôt que versée.

Le changement a été intégré dans le dépôt public trajectoryRL sous le tag de version v0.7.8, et le même commit met à jour la version du validateur. Les opérateurs ne peuvent rétablir les poids normaux du vainqueur qu'en définissant BURN_ALL=0.

Comment BURN ALL modifie les ticks de poids

Dans le chemin d'incitation normal de SN11, les validateurs lisent le vainqueur canonique de la plateforme et appellent set_weights. Le mineur désigné reçoit alors l'intégralité de la part des mineurs. Selon la documentation du mécanisme d'incitation du projet, le mécanisme brûlait déjà au profit de l'UID propriétaire en l'absence de siège occupé. Le nouveau flag BURN_ALL étend ce chemin de combustion à chaque tempo, la fenêtre récurrente durant laquelle les validateurs écrivent les poids sur la chaîne, même lorsqu'un vainqueur reste désigné.

Dans le code, le défaut est explicite. Le flag de combustion est activé par défaut, et le chargeur d'environnement traite un BURN_ALL non défini comme "1". Lorsque le flag est activé, le tick de poids attribue l'UID 74 avec un poids de 1.0 et ignore la branche du vainqueur. Les tests unitaires de la pull request fusionnée verrouillent ce comportement : le mode combustion écrit uniquement l'UID propriétaire 74, le mode désactivé écrit le vainqueur, et le défaut reste activé.

Les mainteneurs indiquent que la combustion doit être collective. Yuma Consensus, le mécanisme de Bittensor pour agréger les poids des validateurs, ignore le poids d'un validateur sur lui-même, de sorte que la propre ligne de l'UID 74 ne peut porter la combustion seule. Chaque validateur exécutant la nouvelle image doit définir les mêmes poids. Une fois l'image publiée, Watchtower devrait la récupérer pour les validateurs communautaires qui se mettent à jour automatiquement.

Pourquoi une combustion sur la chaîne compte pour une compétition d'IA

Bittensor est un réseau d'IA décentralisé dont les subnets spécialisés se disputent des parts de TAO, le token natif du réseau. TrajectoryRL est Bittensor Subnet 11. Les mineurs soumettent des politiques de fusion qui acheminent le travail des agents à travers des modèles à poids ouverts sur Engy, et les validateurs notent ces paquets en bac à sable. La revendication produit de la Saison 2 est que la politique désignée devient un routage automatique déployable. Le rôle de la chaîne dans cette boucle est étroit et économique : c'est la couche poids-et-émission qui décide quel alpha, le token propre du subnet, est rémunéré.

L'IA est l'objet de la compétition, pas la combustion elle-même. Les politiques de fusion déterminent quels modèles répondent, dans quel ordre, et sous un plafond de coût mesuré. Les validateurs évaluent toujours les scénarios et peuvent toujours désigner un vainqueur sur la plateforme. Ce que v0.7.8 change, c'est le circuit de paiement une fois ce siège attribué. Remporter la course de fusion ne permet plus, par défaut, de collecter le flux d'émission des mineurs.

Suivons un tempo sous le nouveau défaut. La plateforme désigne toujours un vainqueur, et le démon du validateur tick toujours. Au lieu d'écrire l'UID de ce vainqueur dans les poids de la chaîne, il écrit l'UID propriétaire 74 à 100 %. Avec le mode recycler-ou-brûler de SN11 réglé sur Burn, cette part des mineurs est détruite. La pull request indique également un effet secondaire que l'équipe affirme avoir déjà observé sur SN53 avant le lancement : lorsque la part des mineurs est entièrement brûlée, la part de SN11 dans l'émission globale de TAO tend vers zéro, y compris l'injection de pool et les achats sur la chaîne. Les dividendes des validateurs et la part du propriétaire, selon les auteurs, restent inchangés.

Ce qui est démontré, et ce qui ne l'est pas

Ce que la source primaire démontre, ce sont un défaut logiciel et un paramètre de combustion de subnet déclaré. La version, le flag de configuration, la branche de la boucle de poids et la constante de l'UID propriétaire sont tous dans l'arbre public. Les affirmations selon lesquelles les validateurs convergeront, que Watchtower achèvera le déploiement, et toute chute exacte de la part TAO en direct doivent être traitées comme des résultats opérationnels, car elles dépendent de qui effectue la mise à niveau et de ce que montre la chaîne après l'écriture des poids.

La motivation reste un cadrage du projet. La pull request explique le problème de coordination (masquage de l'auto-poids) et cite le précédent SN53. Elle ne prouve pas, en soi, combien de temps la combustion restera active, si les validateurs dotés d'évaluation continueront à dépenser pour les bac à sable pendant que la rémunération des mineurs est éteinte, ou quand BURN_ALL=0 reviendra. Ce sont des faits à venir.

Pour les lecteurs de l'IA et de la blockchain, l'enjeu clé est la séparation entre classement et récompense. Un subnet peut continuer à noter les politiques d'agents pendant que le chemin d'émission des mineurs pointe vers un puits de combustion. La compétition, l'évaluation et la désignation produit peuvent se poursuivre, mais le paiement au vainqueur désigné de la fusion ne le peut pas, sous ce défaut, tant que les opérateurs ne désactivent pas le flag ou que la flotte ne diverge pas. L'expérience s'inscrit aux côtés d'autres projets d'IA décentralisée qui redéfinissent la fonction d'un stake ou d'un client, comme le passage de 0G des actifs mis en stake aux crédits de calcul IA.

Le modèle mental est simple : l'émission BURN ALL de TrajectoryRL n'est pas une nouvelle règle de notation. C'est une politique de poids par défaut qui redirige la part des mineurs vers l'UID propriétaire 74 afin que la chaîne la brûle. Ce qu'il faut observer ensuite : si les validateurs communautaires convergent réellement vers v0.7.8, si la part TAO de SN11 se comprime comme annoncé, et si la politique automatique Engy désignée reste défendable lorsque le salaire des mineurs est intentionnellement vide.

Source : Live Bitcoin News