8 ноября 2026 года TrajectoryRL выпустила валидатор v0.7.8, включив в объединённом pull request настройку BURN ALL emission по умолчанию. В Bittensor Subnet 11 (SN11) при каждом обновлении весов 100% веса майнеров теперь направляется владельцу UID 74, игнорируя победителя fusion-policy, занявшего место. Поскольку SN11 сжигает переработанную эмиссию майнеров, эта доля уничтожается, а не выплачивается.

Изменение вошло в публичный репозиторий trajectoryRL как релиз-тег v0.7.8, и тот же коммит обновляет версию валидатора. Вернуть стандартные веса победителей операторы могут только установив BURN_ALL=0.

Как BURN ALL меняет обновления весов

При обычном механизме стимулирования SN11 валидаторы считывают канонического победителя платформы и вызывают set_weights. Занявший место майнер получает всю долю майнеров. Согласно документации механизма стимулирования проекта, механизм уже сжигал эмиссию в адрес UID владельца, когда место не было занято. Новый флаг BURN_ALL расширяет этот путь сжигания на каждый tempo — повторяющийся интервал, в котором валидаторы записывают веса в цепочку, — даже когда победитель остаётся на месте.

В коде значение по умолчанию задано явно. Флаг сжигания по умолчанию включён, а загрузчик окружения трактует неустановленный BURN_ALL как "1". Когда флаг включён, обновление весов устанавливает UID 74 с весом 1.0 и пропускает ветку победителя. Юнит-тесты в объединённом pull request фиксируют это поведение: режим сжигания записывает только UID 74 владельца, выключенный режим записывает победителя, а значение по умолчанию остаётся включённым.

Разработчики утверждают, что сжигание должно быть коллективным. Yuma Consensus — механизм Bittensor для агрегации весов валидаторов — игнорирует вес валидатора на самого себя, поэтому собственная строка UID 74 не может обеспечить сжигание в одиночку. Каждый валидатор, запускающий новый образ, должен устанавливать одинаковые веса. После публикации образа ожидается, что Watchtower подтянет его для валидаторов сообщества с автоматическим обновлением.

Почему сжигание в цепочке важно для соревнования ИИ

Bittensor — децентрализованная ИИ-сеть, чьи специализированные подсети конкурируют за доли TAO, нативного токена сети. TrajectoryRL — это Bittensor Subnet 11. Майнеры отправляют fusion-политики, которые распределяют работу агентов между моделями с открытыми весами на Engy, а валидаторы оценивают эти пакеты в песочницах. Продуктовое заявление второго сезона состоит в том, что занявшая место политика становится разворачиваемым автоматическим роутингом. Роль цепочки в этом цикле узка и экономична: это слой весов и эмиссии, определяющий, чей альфа — собственный токен подсети — получает выплаты.

Предметом конкуренции является ИИ, а не само сжигание. Fusion-политики решают, какие модели отвечают, в каком порядке и в рамках лимитированной стоимости. Валидаторы по-прежнему оценивают сценарии и могут по-прежнему назначать победителя на платформе. Что меняет v0.7.8 — это канал выплат после того, как место занято. Победа в fusion-гонке больше не приносит, по умолчанию, поток эмиссии майнеров.

Проследим один tempo при новых настройках по умолчанию. Платформа по-прежнему назначает победителя, и демон валидатора по-прежнему тикает. Вместо записи UID победителя в веса цепочки он записывает UID 74 владельца со 100%. Поскольку в SN11 режим recycle-or-burn установлен на Burn, доля майнеров уничтожается. В pull request также указан побочный эффект, который команда, по её словам, уже наблюдала на SN53 до запуска: при полном сжигании доли майнеров доля SN11 в общей эмиссии TAO стремится к нулю, включая инъекции в пулы и покупки на цепочке. Дивиденды валидаторов и доля владельца, по словам авторов, остаются незатронутыми.

Что продемонстрировано, а что нет

Из первоисточника продемонстрированы программное значение по умолчанию и заявленная настройка сжигания подсети. Релиз, флаг конфигурации, ветка цикла весов и константа UID владельца находятся в публичном дереве. Утверждения о том, что валидаторы сойдутся на новых настройках, что Watchtower завершит развёртывание, и любые точные данные о падении доли TAO следует рассматривать как операционные результаты, поскольку они зависят от того, кто обновится и что покажет цепочка после записи весов.

Мотивация остаётся рамкой проекта. В pull request объясняется проблема координации (маскировка собственного веса) и приводится прецедент SN53. Сам по себе он не доказывает, как долго будет включено сжигание, будут ли валидаторы с включённой оценкой продолжать тратить средства на песочницы, пока выплаты майнерам отключены, и когда вернётся BURN_ALL=0. Это последующие факты.

Для читателей, интересующихся ИИ и блокчейном, ключевой вопрос — разделение между ранжированием и вознаграждением. Подсеть может продолжать оценивать политики агентов, направляя путь эмиссии майнеров в сжигатель. Соревнование, оценка и назначение продуктов могут продолжаться, но выплата занявшему место победителю fusion — при этих настройках по умолчанию — не может, пока операторы не выключат флаг или флот не разойдётся. Этот эксперимент находится рядом с другими проектами децентрализованного ИИ, переосмысляющими роль стейка или клиента, например переходом 0G от застейканных активов к кредитам ИИ-вычислений.

Ментальная модель проста: BURN ALL emission в TrajectoryRL — это не новое правило оценки. Это политика весов по умолчанию, перенаправляющая долю майнеров владельцу UID 74, чтобы цепочка её сожгла. Далее следует наблюдать, сойдутся ли валидаторы сообщества действительно на v0.7.8, сократится ли доля SN11 в TAO, как заявлено, и останется ли занявшая место автоматическая политика Engy заслуживающей защиты, когда чек майнера намеренно пуст.

Источник: Live Bitcoin News