Ми, команда блокчейн-інженерів, бачимо дві фундаментальні проблеми централізованого навчання ML-моделей. Перша: дані стікаються в одному сховищі, створюючи ризики витоків та юридичні складнощі (GDPR, HIPAA). Друга: оператор compute бачить усі дані та може впливати на навчання. Федеративне навчання (FL) вирішує першу проблему частково, але не другу. Децентралізована система на блокчейні закриває обидві — ціною значної інженерної складності. Нижче розбираємо архітектуру, протоколи та практичні trade-offs, з якими ми стикалися в 15+ проектах. Зв'яжіться з нами для оцінки вашого проекту — бюджет розраховується індивідуально.
Архітектура: три шари системи
Compute Layer: верифікація обчислень
Найскладніша частина. Смарт-контракт повинен переконатися, що compute-провайдер чесно навчив модель, а не підсунув випадкові ваги. Ми використовуємо чотири підходи, кожен зі своїми компромісами.
Optimistic execution — провайдер публікує результат (градієнти або ваги); challenger-період дає час на оскарження. Для оскарження потрібно відтворити обчислення. Проблема: детермінізм. GPU-обчислення недетерміновані за замовчуванням через паралельні операції з плаваючою точкою. Ми форсуємо детермінізм через cuDNN deterministic mode — це коштує 10–30% продуктивності.
ZK-proof для ML inference — математично елегантно, практично поки дорого. EZKL дозволяє генерувати ZK-proof для ONNX-моделей. Невеликі моделі (до 10M параметрів) — реалістично. GPT-4 — ні. Для верифікації inference в production вже застосовується (Modulus Labs, Giza), для training — поки R&D.
TEE (Trusted Execution Environment) — навчання всередині Intel SGX або AMD SEV. Remote attestation доводить, що конкретний код запущено на конкретному залізі. Обмеження: SGX має ліміт захищеної пам'яті (~256 MB EPC), що обмежує розмір моделі. AMD SEV працює на рівні VM — більше пам'яті, менше гарантій. Марлин та інші compute DePIN використовують TEE як прагматичний компроміс.
Proof of Useful Work — гібридний підхід: challenge-response система, де верифікатори вибірково перевіряють частини обчислення. Використовується в Bittensor. Економічно ефективніше повної верифікації, але має статистичний характер.
Data Layer: privacy-preserving навчання
Federated Learning (FL) — дані не покидають пристрої власників. Кожен учасник навчає модель локально, надсилає лише градієнти. Сервер агрегує (FedAvg, FedProx). Проблема: з градієнтів можна відновити дані через gradient inversion атаки. Рішення — диференційна приватність.
Differential Privacy (DP) — додавання каліброваного шуму до градієнтів перед відправкою. Параметр ε-differential privacy: чим менше ε, тим краще privacy, але гірше якість. Практичні значення ε від 1 до 10. TensorFlow Privacy та Opacus (PyTorch) — стандартні бібліотеки.
# Opacus: додавання DP до PyTorch training loop from opacus import PrivacyEngine privacy_engine = PrivacyEngine() model, optimizer, train_loader = privacy_engine.make_private_with_epsilon( module=model, optimizer=optimizer, data_loader=train_loader, epochs=EPOCHS, target_epsilon=5.0, target_delta=1e-5, max_grad_norm=1.2, ) Secure Multi-Party Computation (MPC) для агрегації градієнтів — кілька серверів бачать лише зашифровані shares, результат розкривається при кворумі. SCALE-MAMBA, MP-SPDZ — зрілі бібліотеки. Overhead: 10–100x порівняно зі звичайною агрегацією. Застосовно, коли privacy критична та раундів навчання мало.
Homomorphic Encryption (HE) — обчислення над зашифрованими даними. Microsoft SEAL, OpenFHE. Overhead: 1000–10000x. Для навчання нейромереж — поки нереалістично в production. Для inference невеликих моделей застосовується.
Coordination Layer: смарт-контракти та токеноміка
Блокчейн координує учасників, не виконуючи саме навчання. Функції: Job Registry — постановка завдань: CID датасету, архітектура моделі, гіперпараметри, reward, verification scheme, deadline; Staking та Slashing — провайдери стейкають токени; slashing за нечесну поведінку; Payment Escrow — клієнт депонує оплату; авто-release після верифікації; Result Attestation — кілька незалежних валідаторів атестують результат через threshold signature (наприклад, 5 з 9).
Як забезпечити детермінізм обчислень?
Детермінізм — критична вимога для on-chain верифікації. Що порушує: cuDNN non-deterministic алгоритми (особливо atomicAdd в reduction), multi-GPU без explicit synchronization, деякі операції трансформерів при mixed precision. Рішення: torch.use_deterministic_algorithms(True) + CUBLAS_WORKSPACE_CONFIG=:4096:8. Overhead 15–30%. Використовуємо deterministic mode в cuDNN — це гарантує відтворюваність результатів при тих самих вхідних даних, але знижує продуктивність на 15-30%. Для критичних завдань застосовуємо TEE, де детермінізм не потрібен.
Що таке Bittensor і яку архітектуру він пропонує?
Bittensor — найбільш зрілий приклад децентралізованого ML marketplace. Варто вивчити: Subnet model — кожен subnet для конкретного типу завдань (text generation, image, embeddings); Validator-Miner розділення — miners виконують роботу, validators оцінюють якість. Validators стейкають TAO, можуть бути покарані за некорректні оцінки; Yuma Consensus — агрегація оцінок з вагами по стейку (PageRank-like). Стійкий до змови малої кількості validators.
Gradient Marketplace vs Federated Training
Два архітектурних паттерни on-chain координації.
Gradient Marketplace — учасники продають градієнти, агрегатор купує. Проблема: gradient poisoning атаки — захист через Byzantine-robust aggregation (Krum, Trimmed Mean, FLTrust).
Federated Training з on-chain coordination — smart contract координує раунди, учасники надсилають агреговані градієнти.
# Byzantine-robust aggregation: Trimmed Mean def trimmed_mean(gradients, beta=0.1): n = len(gradients) k = int(n * beta) stacked = torch.stack(gradients) sorted_grads, _ = torch.sort(stacked, dim=0) trimmed = sorted_grads[k:n-k] return trimmed.mean(dim=0) Практичні обмеження та trade-offs
- Детермінізм: використовуємо
torch.use_deterministic_algorithms, overhead 15–30%. - Latency vs Security: низька вартість завдання → optimistic; висока → partial ZK або TEE.
- On-chain vs Off-chain: сирі дані не пишемо в блокчейн, лише хеші (Merkle root) та proof. Дані зберігаємо в Filecoin/Arweave, CID в контракті.
Інфраструктура розробки
| Платформа | Тип | Особливості |
|---|---|---|
| Lilypad | Decentralized compute | Docker-контейнери, примітиви для ML jobs, добре для PoC |
| Akash Network | Decentralized cloud | Kubernetes, немає вбудованої верифікації ML |
| Gensyn | Спеціалізована ML-мережа | Власний proof system для gradient descent |
Етапи розробки
| Фаза | Зміст | Термін |
|---|---|---|
| Protocol design | Verification scheme, FL архітектура, tokenomics | 4–6 тиж |
| Compute infrastructure | Training pipeline, determinism, TEE | 6–8 тиж |
| Privacy layer | DP, MPC, gradient poisoning захист | 4–6 тиж |
| Smart contracts | Job registry, staking, payments, attestation | 4–6 тиж |
| Validator network | Децентралізована верифікація | 4–6 тиж |
| Integration testing | E2E з реальними ML завданнями | 3–4 тиж |
| Testnet | Обмежений запуск, bug bounty | 4–8 тиж |
Повний цикл — 8–14 місяців. Вартість проекту розраховується індивідуально і залежить від складності verification scheme та вимог до privacy. Замовте розробку під ключ з поетапною здачею.
Що входить в роботу
- Архітектурна документація та вибір verification scheme.
- Реалізація смарт-контрактів з урахуванням gas-оптимізації (понад 5000 рядків коду).
- Інтеграція privacy-шару (DP, MPC).
- Налаштування compute-інфраструктури (TEE, determinism).
- Розгортання валідаторської мережі.
- Тестування на testnet та bug bounty.
- Навчання команди замовника та технічна підтримка 3 місяці.
У нас 5+ років досвіду в блокчейн-розробці, 20+ проектів в DeFi та ML. Зв'яжіться для оцінки часу та бюджету — розрахуємо індивідуально. Отримайте консультацію по вашому проекту вже сьогодні.
Більшість проектів у цьому просторі жертвують децентралізацією, верифікацією або privacy. Честна система без компромісів — складна R&D задача. Ми готові її вирішити.