Розробка децентралізованої AI-платформи
GPU-обчислення зосереджені у хмарних гігантів — AWS, GCP, Azure. Інференс моделей — у OpenAI, Anthropic, Google. Це створює ризики vendor lock-in, цінової диктатури та цензури. Децентралізовані AI-платформи пропонують альтернативу: маркетплейс обчислювальних ресурсів, ринок моделей та даних на блокчейні. Але ключова технічна проблема — як верифікувати результати AI-обчислень без довіри до провайдера? Смарт-контракт не може запустити нейромережу: EVM детермінований, а нейромережі використовують floating point та GPU. Це фундаментальне протиріччя, і його вирішення визначає архітектуру всієї платформи.
У цій статті ми розберемо основні підходи до верифікації (оптимістична, ZK, TEE), архітектуру децентралізованого ринку, токеноміку та процес розробки. Ви дізнаєтесь, як спроектувати платформу, що вирішує реальні проблеми централізації AI, і які компроміси неминучі. Наша команда має 10+ років досвіду в блокчейн-розробці та 50+ реалізованих проектів у сфері DeFi, NFT та AI.
Як верифікувати AI-обчислення в децентралізованій мережі?
Оптимістична верифікація (Optimistic)
Модель як в Optimistic Rollups: припускаємо, що провайдер чесний. Результат приймається без верифікації, але є вікно для dispute. Challenger може оскаржити результат, представивши альтернативне обчислення. При оскарженні запускається on-chain арбітраж або залучається комітет верифікаторів.
Застосування: Bittensor використовує мережу валідаторів, які оцінюють якість output через міру схожості. Це не криптографічно строга верифікація, але достатньо стійка проти випадкових провайдерів.
Реалізація dispute механізму:
contract OptimisticAIVerifier {
struct Task {
bytes32 requestHash;
bytes32 responseHash;
address provider;
uint256 stake;
uint256 deadline; // коли можна фіналізувати
bool disputed;
bool finalized;
}
mapping(bytes32 => Task) public tasks;
uint256 public constant DISPUTE_WINDOW = 7200; // ~24 години на Ethereum
function submitResult(bytes32 taskId, bytes32 responseHash) external {
Task storage task = tasks[taskId];
require(msg.sender == task.provider, "Not provider");
task.responseHash = responseHash;
task.deadline = block.number + DISPUTE_WINDOW;
}
function dispute(bytes32 taskId, bytes calldata alternativeResponse) external {
Task storage task = tasks[taskId];
require(block.number < task.deadline, "Dispute window closed");
// Відправити на арбітраж — комітет або on-chain верифікацію
_initiateArbitration(taskId, alternativeResponse);
}
function finalize(bytes32 taskId) external {
Task storage task = tasks[taskId];
require(block.number >= task.deadline, "Still in dispute window");
require(!task.disputed, "Under dispute");
require(!task.finalized, "Already finalized");
task.finalized = true;
// Звільнити stake провайдера, оплатити завдання
_releasePayment(task.provider, task.stake);
}
}
Проблема: для складних моделей немає простого способу верифікувати альтернативний результат on-chain. Арбітраж через комітет вводить новий вектор централізації.
ZK-верифікація inference
ZK-верифікація — математично строгий підхід: довести zero-knowledge, що модель з вагами W на вході X дала вихід Y, не розкриваючи деталі обчислень. Це дозволяє верифікувати inference on-chain або через публічний верифікатор.
Проекти: Gensyn (власний consensus для ML), EZKL (ZK proofs для ONNX-моделей), Risc Zero (general purpose ZK-VM).
EZKL генерує ZK circuit з ONNX-моделі та дозволяє довести правильність forward pass:
import ezkl
import torch
import onnx
# Експортуємо модель в ONNX
model = MyMLModel()
dummy_input = torch.randn(1, 128)
torch.onnx.export(model, dummy_input, "model.onnx")
# Генерація proof
ezkl.gen_settings("model.onnx", "settings.json")
ezkl.calibrate_settings("input.json", "model.onnx", "settings.json")
ezkl.compile_circuit("model.onnx", "compiled_model", "settings.json")
ezkl.gen_pk("compiled_model", "pk.key", "settings.json")
ezkl.gen_vk("compiled_model", "vk.key", "settings.json")
ezkl.prove("input.json", "witness.json", "compiled_model", "pk.key", "proof.json")
ezkl.verify("proof.json", "settings.json", "vk.key") # можна робити on-chain
Обмеження: ZK-proof генерація для GPT-2 (117M параметрів) займає години на потужному обладнанні. Для production-моделей типу LLaMA-3 це поки не практично. Застосовне для невеликих спеціалізованих моделей: класифікатори, embeddings, малі трансформери.
Trusted Execution Environments (TEE)
TEE, такі як Intel SGX, AMD SEV, AWS Nitro Enclaves, — апаратно ізольовані середовища, де код виконується в захищеному анклаві. Attestation — механізм, який дозволяє віддалено верифікувати, що конкретний код виконується в TEE.
Ritual Network використовує TEE для верифікації inference. Провайдер запускає модель в анклаві, анклав генерує attestation report, який верифікується on-chain.
Компроміс: вимагає довіри до виробника CPU (Intel, AMD). Це не "trustless", але значно знижує attack surface порівняно з "довіряй провайдеру на слово".
| Метод | Безпека | Продуктивність | Застосовність |
|---|---|---|---|
| Оптимістична | Середня (залежить від вікна dispute) | Висока (немає overhead) | MVP, малі моделі |
| ZK-proof | Висока (криптографічна гарантія) | Низька (години на генерацію proof) | Малі спеціалізовані моделі |
| TEE | Середня (довіра до виробника CPU) | Середня (overhead анклаву) | Production, середні моделі |
Архітектура децентралізованого ринку AI
Реєстр моделей та провайдерів
Registry контракт — реєстр провайдерів і моделей:
contract ModelRegistry {
struct Model {
address provider;
bytes32 modelHash; // IPFS CID або хеш ваг
string endpoint; // де запущена модель
uint256 pricePerToken; // ціна за 1k tokens в wei
uint256 stake; // stake провайдера (skin in the game)
uint256 reputationScore;
bool active;
}
mapping(bytes32 => Model) public models;
function registerModel(
bytes32 modelId,
bytes32 modelHash,
string calldata endpoint,
uint256 pricePerToken
) external payable {
require(msg.value >= MIN_STAKE, "Insufficient stake");
models[modelId] = Model({
provider: msg.sender,
modelHash: modelHash,
endpoint: endpoint,
pricePerToken: pricePerToken,
stake: msg.value,
reputationScore: 0,
active: true
});
}
}
Task Router — off-chain сервіс, що маршрутизує запити до провайдерів за критеріями: ціна, latency, репутація, спеціалізація моделі.
Payment Channel — для мікроплатежів за inference краще використовувати payment channels (State Channel або zkSync-style), а не on-chain транзакцію за кожен запит. Типовий inference запит коштує частки цента — on-chain gas це вб'є.
// Спрощений односторонній payment channel
contract InferenceChannel {
address public user;
address public provider;
uint256 public expiry;
// Користувач підписує ваучери off-chain
// Провайдер закриває канал з останнім підписаним ваучером
function close(
uint256 amount,
bytes calldata userSignature
) external {
require(msg.sender == provider, "Only provider");
bytes32 message = keccak256(abi.encodePacked(address(this), amount));
address signer = ECDSA.recover(message.toEthSignedMessageHash(), userSignature);
require(signer == user, "Invalid signature");
payable(provider).transfer(amount);
payable(user).transfer(address(this).balance);
}
}
Токеноміка платформи
Двосторонній ринок вимагає збалансованої токеноміки:
Utility token функції:
- Оплата inference (або ETH/USDC — залежить від аудиторії)
- Стейкінг провайдерів (skin in the game, slashing за шахрайство)
- Governance (параметри протоколу)
- Reward за надання обчислень
Проблема інфляційних нагород: якщо нагороджувати провайдерів токеном, інфляція розмиває вартість. Bittensor вирішує це через emission, прив'язану до реальної корисності (якість output). Чим кращі оцінки від валідаторів — тим більше TAO.
Емісійна крива: для нової платформи дефляційний дизайн з buyback/burn з protocol revenue більш стійкий довгостроково, ніж інфляційні субсидії.
Data marketplace: монетизація тренувальних даних
Окрема, але пов'язана вертикаль: провайдери даних хочуть монетизувати набори даних для донавчання моделей без розкриття самих даних.
Federated Learning на блокчейні
Модель навчається розподілено: кожен учасник тренує на своїх даних, надсилає лише градієнти (не дані). Градієнти агрегуються (Federated Averaging), модель покращується без централізації даних.
Блокчейн фіксує контрибуцію кожного учасника (через хеш градієнтів), смарт-контракт розподіляє rewards пропорційно внеску.
Проблема: градієнти можна інвертувати для відновлення частини тренувальних даних (gradient inversion attacks). Для sensitive даних додатково потрібен Differential Privacy (додавання шуму до градієнтів).
Compute-to-Data (підхід Ocean Protocol)
Дані залишаються у власника, алгоритм "приїжджає" до даних. Смарт-контракт фіксує умови доступу, compute відбувається в TEE, результат (навчена модель або аналітика) — єдине, що виходить назовні.
Що входить в роботу
- Аудит вимог та проектування архітектури платформи
- Розробка смарт-контрактів на Solidity 0.8.x з використанням Foundry та OpenZeppelin
- Інтеграція з ZK-інструментами (EZKL, Risc Zero) або TEE (Intel SGX, AWS Nitro)
- Розгортання в обраній мережі (Ethereum, Arbitrum, Base або app-chain)
- Документація API та смарт-контрактів
- Навчання команди замовника роботі з платформою
- Технічна підтримка на 3 місяці
Процес розробки та строки
- Аналітика та проектування (2–4 тижні): визначення вимог, вибір стеку, архітектура.
- Розробка MVP (3–4 місяці): централізований registry, оптимістична верифікація, платежі в ERC-20, базовий SDK провайдера.
- Production v1 (6–9 місяців): payment channels, репутаційна система, dispute resolution, ZK-верифікація для малих моделей, governance token.
- Масштабування (12+ місяців): власна app-chain або L2, TEE-інтеграція, federated learning, cross-chain операції.
Використання децентралізованих обчислень знижує витрати на інфраструктуру до 70%. Економія на газі при використанні L2 становить близько 90%.
Чому важливий вибір мережі деплою?
| Критерій | Ethereum mainnet | Arbitrum/Base | App-chain (Cosmos/OP Stack) |
|---|---|---|---|
| Довіра | Висока | Середня | Низька (суверенна) |
| Газ | Високий | Низький | Мінімальний (свій) |
| Throughput | ~15 tx/s | ~1000 tx/s | Кастомізований |
| Коли вибирати | Governance, реєстр | Payment, routing | >100k tx/день, спец. вимоги |
Стек розробки
| Компонент | Технологія |
|---|---|
| Смарт-контракти | Solidity 0.8.x + Foundry + OpenZeppelin 5.x |
| ZK-верифікація | EZKL / Risc Zero / Noir |
| TEE integration | Intel SGX + Gramine або AWS Nitro |
| Off-chain сервіси | Go або Rust (висока конкурентність) |
| Модельний реєстр | IPFS + on-chain хеш |
| Payment channels | State channels або Arbitrum/zkSync |
| Monitoring | Prometheus + Grafana + on-chain events |
Ключове обмеження: ZK-верифікація великих моделей поки не готова для production. Реалістично — оптимістична верифікація з TEE як проміжний крок, ZK додається в міру зрілості інфраструктури (Gensyn, Risc Zero).
Зв'яжіться з нами, щоб оцінити ваш проект та отримати детальний план розробки. Замовте розробку під ключ з гарантією результату.