Интеграция с Bittensor

Интеграция с Bittensor

Bittensor — это не очередной "AI на блокчейне" проект. Это попытка создать децентрализованный рынок машинного интеллекта, где нейронные сети соревнуются за вознаграждение, а качество ответов верифицируется самой сетью через механизм Yuma Consensus. Интегрироваться с Bittensor сложнее, чем с io.net или любым другим DePIN, потому что это не просто API для GPU — это экономический протокол со своими правилами участия, и нарушение этих правил ведёт к финансовым потерям (снижение stake, дерегистрация).

Архитектура Bittensor: что нужно понять до начала разработки

Структура сети

Bittensor состоит из subnet — специализированных подсетей, каждая из которых реализует конкретную задачу: текстовый инференс (subnet 1 — Prompting), генерация изображений (subnet 18 — Cortex.t), хранение данных (subnet 21 — FileTao), финансовые предсказания (subnet 8 — Proprietary Trading Network) и так далее. На момент 2024–2025 года существует более 60 активных subnet.

Каждая subnet имеет:

• Validators — нодs, которые задают задачи и оценивают ответы miners
• Miners — ноды, которые выполняют задачи и получают вознаграждение пропорционально качеству
• Netuid — уникальный идентификатор подсети

Для интеграции в существующий проект важно понять, в каком качестве вы участвуете: потребителя (используете API validators), miners (предоставляете вычисления), validators (оцениваете miners) или разработчика новой subnet.

Токеномика и стейкинг

$TAO — native token Bittensor на базе Substrate. Stake распределяется между subnet через механизм root network (subnet 0). Validators должны иметь достаточный stake для работы — минимальный порог постоянно меняется в зависимости от общего объёма stake в подсети. Miners с недостаточным stake или низким рейтингом вытесняются из сети каждые ~360 блоков (tempo).

Dynamic TAO (dTAO) — обновление 2024 года, которое ввело subnet-specific токены. Теперь каждая subnet имеет собственный токен, привязанный к $TAO через AMM-механизм. Это существенно меняет экономику участия: stake в subnet теперь denominates в subnet-токене, а не в $TAO напрямую.

Разработка Miner-ноды

Основной SDK — bittensor Python-библиотека (btcli + Python API). Архитектура miner строится вокруг bt.Axon — gRPC-сервер, который получает синаптические запросы от validators.

import bittensor as bt
from neurons.protocol import MyTask

class MyMiner(bt.BaseNeuron):
    def __init__(self):
        super().__init__()
        self.axon = bt.Axon(wallet=self.wallet)
        self.axon.attach(
            forward_fn=self.forward,
            blacklist_fn=self.blacklist,
            priority_fn=self.priority,
        )
    
    async def forward(self, synapse: MyTask) -> MyTask:
        # основная логика обработки задачи
        result = await self.process(synapse.input_data)
        synapse.output = result
        return synapse
    
    async def blacklist(self, synapse: MyTask) -> tuple[bool, str]:
        # защита от спама: проверяем что validator имеет достаточный stake
        if synapse.dendrite.hotkey not in self.metagraph.hotkeys:
            return True, "Unrecognized hotkey"
        uid = self.metagraph.hotkeys.index(synapse.dendrite.hotkey)
        if self.metagraph.stake[uid] < self.config.blacklist.min_stake:
            return True, "Insufficient stake"
        return False, "OK"
    
    async def priority(self, synapse: MyTask) -> float:
        # приоритизация запросов от validators с большим stake
        uid = self.metagraph.hotkeys.index(synapse.dendrite.hotkey)
        return float(self.metagraph.stake[uid])

Обновление metagraph

metagraph — снимок состояния сети (hotkeys, stake, веса). Он не обновляется автоматически и должен обновляться явно через self.metagraph.sync(). Частота обновления — компромисс между актуальностью данных и нагрузкой на subtensor RPC. Рекомендуется sync каждые 5–10 минут.

Разработка Validator-ноды

Validator принципиально сложнее miner: он должен формировать задачи, отправлять их набору miners через bt.Dendrite, оценивать результаты и выставлять веса через subtensor.set_weights(). Ошибки в логике выставления весов — прямые финансовые потери для miners и репутационные для самого validator.

class MyValidator(bt.BaseNeuron):
    async def forward(self):
        # выбор miners для опроса
        miner_uids = get_random_uids(self, k=self.config.neuron.sample_size)
        
        # формирование и отправка задач
        responses = await self.dendrite(
            axons=[self.metagraph.axons[uid] for uid in miner_uids],
            synapse=MyTask(input_data=generate_challenge()),
            deserialize=True,
            timeout=self.config.neuron.timeout,
        )
        
        # оценка ответов и обновление scores
        rewards = get_rewards(self, responses=responses, uids=miner_uids)
        self.update_scores(rewards, miner_uids)
    
    def set_weights(self):
        # конвертация scores в веса и запись на chain
        weights = torch.nn.functional.normalize(self.scores, p=1, dim=0)
        result, msg = self.subtensor.set_weights(
            wallet=self.wallet,
            netuid=self.config.netuid,
            uids=torch.arange(len(weights)),
            weights=weights,
            wait_for_inclusion=False,  # не блокируем основной loop
        )

Yuma Consensus и манипуляции

Yuma Consensus — механизм агрегации весов всех validators в единый вектор вознаграждений. Алгоритм устойчив к малым группам сговорившихся validators благодаря Shapley-value inspired подходу, но не абсолютен. Validator с диспропорционально большим stake может оказывать значительное влияние. При разработке validator-логики нужно понимать: ваша оценочная функция должна быть объективной и воспроизводимой, иначе другие validators ваши веса "срежут" через consensus-механизм.

Разработка новой Subnet

Создание собственной subnet — наиболее сложный сценарий. Требует:

1. Регистрации subnet через btcli subnet create с оплатой в $TAO (стоимость динамическая, зависит от спроса)
2. Определения протокола — структуры synapse для обмена данными между miners и validators
3. Реализации логики miners — что именно они вычисляют
4. Реализации логики validators — как они оценивают качество ответов miners (это самое сложное — оценочная функция должна быть объективной и устойчивой к gamification)
5. Экономической модели — как привлечь stake в новую subnet, чтобы она получила значимую долю эмиссии $TAO

Типичные проблемы при разработке subnet

Gameable reward function — miners быстро найдут способ получить максимальное вознаграждение без реального качества работы. Классический пример: если reward зависит от скорости ответа, а не только от качества, miners будут возвращать быстрые случайные ответы. Оценочная функция должна быть non-trivially gameable.

Tempo и latency — validators опрашивают miners в течение tempo (~12 минут). Задачи, требующие больше времени, не укладываются в этот цикл без специальных ухищрений (callback-based архитектура, async validation).

Metagraph staleness — если miner обновляет metagraph редко, он может отвечать на запросы от дерегистрированных validators или не знать о новых участниках сети.

Инфраструктура и деплой

Для production Bittensor-ноды необходимо:

Особое внимание — разделение coldkey и hotkey. Coldkey содержит stake и не должен быть на сервере. Hotkey используется для подписи сообщений и может быть скомпрометирован без потери stake, если coldkey надёжно защищён. Это фундаментальное правило безопасности в Bittensor.

Интеграция через внешний API

Если цель — использовать возможности Bittensor без запуска собственной ноды, ряд validators предоставляет REST API поверх своих subnet. Corcel.io, для example, предоставляет OpenAI-совместимый API поверх subnet 1 и 18. Это самый быстрый путь к интеграции, но с централизованной точкой отказа и зависимостью от конкретного провайдера.