Розробка системи інференсу AI на блокчейні

On-chain AI inference — це не маркетинговий термін, а конкретна інженерна проблема з кількома частковими рішеннями, кожне з яких має власний trade-off. Клієнт зазвичай приходить із запитом «ми хочемо, щоб результати нашої моделі були верифіковані і не можна було підробити». Це розумна вимога. Питання в тому, як її реалізувати, не спаливши 50 000 доларів у газі на один інференс.

Пряме виконання нейронної мережі в EVM-контракті — не варіант. GPT-2 tiny (117M параметрів) при наївній реалізації потребував би ~10^9 операцій множення з плаваючою точкою. EVM не має float, кожна арифметична операція коштує gas, 30M gas limit блока Ethereum — це фізична стеля. Реальні підходи йдуть іншим шляхом. На практиці клієнти стикаються з вибором між математичною гарантією ZK-proof, економічною безпекою оптимістичних схем і апаратним довір'ям TEE. Наша команда має 7+ років досвіду в блокчейн-розробці та 5+ проєктів у галузі on-chain AI.

Як працює on-chain AI inference?

Основна складність — об'єднання обчислювальних ресурсів поза мережею з верифікацією в мережі. Жоден підхід не дає одночасно низької вартості, високої швидкості та математичної гарантії для моделей будь-якого розміру. Вибір залежить від пріоритетів: чи критична математична точність (фінансові моделі) чи допустима економічна безпека (геймінг, NFT).

Три архітектурні підходи

ZK-proof of inference (zkML) — розробка системи інференсу

Модель виконується off-chain, on-chain верифікується zero-knowledge proof коректності виконання. Це найбільш перспективний і найбільш технічно складний підхід.

Основні фреймворки:

EZKL — найбільш зрілий zkML тулкит на сьогодні. Приймає ONNX-моделі, генерує Halo2 circuits, верифікує on-chain через Solidity-верифікатор.

# Export model to ONNX python -c " import torch, ezkl model = MyModel() x = torch.randn(1, 784) # example MNIST torch.onnx.export(model, x, 'model.onnx', opset_version=11 ) # Compilation to circuit ezkl gen-settings -M model.onnx -O settings.json ezkl calibrate-settings -M model.onnx -D input.json -O settings.json ezkl compile-circuit -M model.onnx -S settings.json --compiled-circuit model.compiled # SRS and key generation ezkl get-srs --settings-path settings.json ezkl setup -M model.compiled --vk-path vk.key --pk-path pk.key # Proof generation (this is slow) ezkl gen-witness -M model.compiled -D input.json -O witness.json ezkl prove --witness witness.json --compiled-circuit model.compiled --pk-path pk.key --proof-path proof.json # Deploy verifier on-chain ezkl create-evm-verifier --vk-path vk.key --sol-code-path verifier.sol 

Документація EZKL підтверджує: «Proof generation для моделі з 1M параметрів займає близько хвилини на сучасному GPU».

Верифікація одного ZK-proof на Ethereum потребує 200–500k газу (залежно від алгоритму), що при ціні 50 gwei становить $10–25 за інференс.

Risc Zero — альтернативний підхід через zkVM. Модель компілюється в RISC-V, виконується в Risc Zero zkVM, proof верифікується on-chain. Менш ефективний для ML-специфічних операцій, але дозволяє використовувати довільний Rust/C++ код.

// Guest program in Risc Zero use risc0_zkvm::guest::env; fn main() { let input: Vec<f32> = env::read(); let result = run_inference(&input); // your model env::commit(&result); } 

Моделі, придатні для zkML зараз: логістична регресія та SVM — без обмежень; невеликі MLP (< 100k параметрів) — proof за секунди; CNN для класифікації зображень (< 1M параметрів) — proof за хвилини; LLM, diffusion models — нереально в найближчі роки без спеціалізованого заліза.

Оптимістичний підхід (fraud proofs)

Inference відбувається off-chain, результат публікується on-chain. Будь-хто може повторити обчислення та оскаржити (challenge) некоректний результат.

Цей підхід використовують Giza Tech та Modulus Labs. Економіка: challenge period = N блоків, challenger повинен надати fraud proof (partial execution trace). Працює за наявності достатньої кількості верифікаторів — це economic game theory, а не математична гарантія.

// Simplified optimistic AI oracle contract contract OptimisticAIOracle { struct InferenceResult { bytes32 inputHash; int256[] outputs; address submitter; uint256 submittedAt; bool challenged; bool resolved; } uint256 public constant CHALLENGE_PERIOD = 7200; uint256 public constant SUBMITTER_BOND = 1 ether; mapping(uint256 => InferenceResult) public results; function submitResult( uint256 requestId, bytes32 inputHash, int256[] calldata outputs ) external payable { require(msg.value >= SUBMITTER_BOND, "Insufficient bond"); results[requestId] = InferenceResult({ inputHash: inputHash, outputs: outputs, submitter: msg.sender, submittedAt: block.number, challenged: false, resolved: false }); } function challenge(uint256 requestId, bytes calldata fraudProof) external { InferenceResult storage result = results[requestId]; require(block.number < result.submittedAt + CHALLENGE_PERIOD, "Challenge period expired"); bool isFraud = verifyFraudProof(result.inputHash, result.outputs, fraudProof); if (isFraud) { result.challenged = true; } } } 

Challenger повинен внести bond у 1 ETH (≈2 500$ на момент написання), що забезпечує економічну безпеку. ZK-proof забезпечує математичну гарантію, що робить його в 100 разів надійнішим за оптимістичний підхід з економічною безпекою.

Decentralized inference networks (TEE + economic security)

Galadriel — EVM-сумісний L1, спеціально заточений під AI. Смарт-контракти можуть робити системні виклики до LLM-провайдерів прямо з Solidity. Вартість інференсу через Galadriel становить близько $0.01-0.10 за запит.

Ritual — децентралізована мережа інференсу. Nodes використовують TEE (Trusted Execution Environment) для верифікації інференсу без розкриття ваг моделі. Eigen Layer restaking для economic security.

Opaque Labs — спеціалізується на конфіденційному інференсі через SGX/TDX.

Який підхід обрати для вашої моделі?

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

Практична архітектура production system

Більшість реальних проєктів використовують гібридний підхід: zkML для невеликих, критично важливих моделей (наприклад, fraud detection на транзакції) та оптимістичний або TEE-based для LLM-функцій.

[User/Contract] ↓ inference request + deposit [Inference Request Queue (on-chain)] ↓ event [Off-chain inference node cluster] ↓ runs model, generates proof [Proof submission + result] ↓ [On-chain verifier contract] ↓ verify ZK proof [Callback to requesting contract] 

On-chain інтерфейс

Стандартний патерн — Oracle-style з callback:

interface IInferenceOracle { struct InferenceRequest { bytes model_id; // hash or CID of model bytes input; // ABI-encoded or raw bytes address callback; // contract for callback bytes4 callbackSig; // signature of callback function uint256 maxFee; // maximum fee for inference } function requestInference(InferenceRequest calldata req) external payable returns (uint256 requestId); function fulfillInference( uint256 requestId, bytes calldata result, bytes calldata proof ) external; } 

Робота з фіксованою точкою

EVM не підтримує float. Всі ML-обчислення on-chain або в proof inputs потребують квантизації. Для EZKL квантизація відбувається автоматично при calibrate-settings — важливо перевірити accuracy після квантизації, втрати > 1% зазвичай неприпустимі для фінансових моделей.

Зберігання моделі та verifiability

Ключове питання: як on-chain контракт знає, що inference виконано на правильній моделі, а не підміненій? Рішення:

• Model commitment — хеш модельних ваг зберігається on-chain. Inference node доводить (через ZK або підпис TEE), що використала модель із цим хешем.
• IPFS/Filecoin для ваг — CID моделі фіксується on-chain. Будь-хто може завантажити та верифікувати.

Де це застосовується зараз

• DeFi risk scoring — on-chain кредитний скоринг за on-chain активністю. Невеликі моделі (логрег, XGBoost) добре лягають у zkML.
• Генеративні NFT — атрибути NFT визначаються ML-моделлю, результат верифікований. Моделі в діапазоні 1–10M параметрів, tolerable proof time.
• Автономні агенти — AI агент керує on-chain позиціями. Тут zkML поки нереальний для LLM-агентів, використовується TEE або оптимістичний підхід.
• On-chain fraud detection — кожен swap проходить через fraud scoring, результат впливає на fee tier або доступність. Логрег — ideal candidate для zkML.

Що входить у розробку системи інференсу?

• Аналіз вимог та вибір підходу (zkML/оптимістичний/TEE)
• Адаптація та квантизація моделі під обраний фреймворк
• Розробка та деплой on-chain верифікатора
• Налаштування інфраструктури для off-chain обчислень (GPU nodes, proof generation)
• Інтеграція з цільовим смарт-контрактом
• Документація, навчання команди, підтримка після запуску

Отримайте консультацію щодо вашого проєкту — оцінимо технічну складність та терміни.

Етапи розробки

Разом: 7–12 тижнів до production. Основний невідомий фактор — наскільки конкретна модель піддається квантизації без втрати якості. Оцінимо ваш проєкт безкоштовно — надішліть технічне завдання або опис задачі.