Інтеграція з 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 — вузли, які задають завдання та оцінюють відповіді miners
• Miners — вузли, які виконують завдання та отримують винагороду пропорційно якості
• Netuid — унікальний ідентифікатор підмережі

Для інтеграції в існуючий проект критично зрозуміти вашу роль участі: як споживач (використання validator APIs), майнер (надання обчислень), validator (оцінка майнерів) або розробник нової subnet.

Токеноміка та staking

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

Dynamic TAO (dTAO) — оновлення 2024 року, яке ввело subnet-специфічні токени. Тепер кожна subnet має власний токен, пов'язаний з $TAO через AMM механізм. Це суттєво змінює економіку участі: stake в subnet тепер деномінується в subnet-токені, а не в $TAO напряму.

Розробка Miner-ноди

Основний SDK — bittensor Python-бібліотека (btcli + Python API). Архітектура майнера будується навколо 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(). Частота синхронізації — компроміс між актуальністю даних та навантаженням на RPC. Рекомендується: синхронізація кожні 5–10 хвилин.

Розробка Validator-ноди

Validator принципово складніший за майнер: він повинен формувати завдання, відправляти їх набору майнерів через bt.Dendrite, оцінювати результати та встановлювати ваги через subtensor.set_weights(). Помилки в логіці встановлення ваг — прямі фінансові втрати для майнерів та репутаційні для самого validator.

class MyValidator(bt.BaseNeuron):
    async def forward(self):
        # вибір майнерів для опитування
        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 у ваги та запис on-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 натхненному підходу, але не абсолютний. 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 — майнери швидко знаходять способи отримати максимальну винагороду без реальної якості роботи. Класичний приклад: якщо reward залежить від швидкості відповіді, а не від якості, майнери повертають швидкі випадкові відповіді. Оцінкова функція повинна бути non-trivially gameable.

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

Metagraph staleness — якщо майнер оновлює metagraph рідко, він може відповідати на запити від дерегістрованих validators або не знати про нових учасників мережі.

Інфраструктура та розпорядження

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

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

Інтеграція через зовнішній API

Якщо ціль — використовувати можливості Bittensor без запуску власної ноди, деякі validators надають REST API поверх своїх subnet. Corcel.io, наприклад, надає OpenAI-сумісний API поверх subnet 1 та 18. Це найшвидший шлях до інтеграції, але з централізованою точкою відмови та залежністю від конкретного провайдера.