Розробка децентралізованої 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 порівняно з "довіряй провайдеру на слово".

Архітектура децентралізованого ринку 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 місяці

Процес розробки та строки

1. Аналітика та проектування (2–4 тижні): визначення вимог, вибір стеку, архітектура.
2. Розробка MVP (3–4 місяці): централізований registry, оптимістична верифікація, платежі в ERC-20, базовий SDK провайдера.
3. Production v1 (6–9 місяців): payment channels, репутаційна система, dispute resolution, ZK-верифікація для малих моделей, governance token.
4. Масштабування (12+ місяців): власна app-chain або L2, TEE-інтеграція, federated learning, cross-chain операції.

Використання децентралізованих обчислень знижує витрати на інфраструктуру до 70%. Економія на газі при використанні L2 становить близько 90%.

Чому важливий вибір мережі деплою?

Стек розробки

Ключове обмеження: ZK-верифікація великих моделей поки не готова для production. Реалістично — оптимістична верифікація з TEE як проміжний крок, ZK додається в міру зрілості інфраструктури (Gensyn, Risc Zero).

Зв'яжіться з нами, щоб оцінити ваш проект та отримати детальний план розробки. Замовте розробку під ключ з гарантією результату.