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

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

Інференс штучного інтелекту на блокчейні — це не маркетинговий термін, це конкретна інженерна проблема з декількома частковими рішеннями, кожне з яких має свої компроміси. Клієнти зазвичай приходять з запитом: "ми хочемо, щоб результати нашої моделі були перевіряємими та неможливо було підробити". Це розумна вимога. Питання в тому, як це реалізувати без витрачання $50k на газ за один інференс.

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

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

1. ZK-доказ інференсу (zkML)

Модель виконується off-chain, на блокчейні верифікація проводиться через доказ з нульовим розголошенням коректності виконання. Це найперспективніший і технічно найскладніший підхід.

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

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

# Експорт моделі в ONNX
python -c "
import torch, ezkl
model = MyModel()
x = torch.randn(1, 784)  # приклад MNIST
torch.onnx.export(model, x, 'model.onnx', opset_version=11)
"

# Компіляція в схему
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 та ключів
ezkl get-srs --settings-path settings.json
ezkl setup -M model.compiled --vk-path vk.key --pk-path pk.key

# Генерація доказу (це повільно)
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

# Розпорядження верифікатора on-chain
ezkl create-evm-verifier --vk-path vk.key --sol-code-path verifier.sol

Обмеження EZKL: час генерації доказу для простої CNN (ResNet-18) — 5–20 хвилин на CPU, 30–120 секунд на GPU. Розмір SRS (структурована довідкова строка) — гігабайти для великих моделей. Це обмежує застосовуваність до малих моделей (< 1M параметрів) або сценаріїв, де latency генерації доказу не критична.

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

// Гостьова програма в Risc Zero
use risc0_zkvm::guest::env;

fn main() {
    let input: Vec<f32> = env::read();
    let result = run_inference(&input);  // ваша модель
    env::commit(&result);
}

Моделі придатні для zkML зараз:

• Логістична регресія, SVM — без обмежень
• Невеликі MLP (< 100k параметрів) — доказ за секунди
• CNN для класифікації зображень (< 1M параметрів) — доказ за хвилини
• LLM, diffusion моделі — нереально в 2024–2025 без спеціалізованого обладнання

2. Оптимістичний підхід (докази шахрайства)

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

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

// Спрощена схема оптимістичного AI оракула
contract OptimisticAIOracle {
    struct InferenceResult {
        bytes32 inputHash;
        int256[] outputs;
        address submitter;
        uint256 submittedAt;
        bool challenged;
        bool resolved;
    }
    
    uint256 public constant CHALLENGE_PERIOD = 7200; // ~24h в блоках
    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");
        
        // Верифікація доказу шахрайства — частковий execution
        bool isFraud = verifyFraudProof(result.inputHash, result.outputs, fraudProof);
        if (isFraud) {
            // Заборгування бонду submitter, награда претензієнту
            result.challenged = true;
        }
    }
}

Проблема: verifyFraudProof сам по собі дорогостоящи on-chain computation. Для ML-моделей часткова верифікація виконання нетривіальна.

3. Децентралізовані мережі інференсу (TEE + економічна безпека)

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

import "./interfaces/IOracle.sol";

contract AIChatbot {
    IOracle public oracle;
    
    struct Message {
        string role;
        string content;
    }
    
    mapping(uint256 => Message[]) public conversations;
    
    function startChat(string memory userMessage) external returns (uint256) {
        uint256 runId = IOracle(oracle).createLlmCall(msg.sender);
        conversations[runId].push(Message("user", userMessage));
        return runId;
    }
    
    // Callback від оракула
    function onOracleLlmResponse(
        uint256 runId,
        IOracle.LlmResponse memory response,
        string memory errorMessage
    ) public {
        require(msg.sender == address(oracle), "Only oracle");
        conversations[runId].push(Message("assistant", response.content));
    }
}

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

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

Вибір підходу

Архітектура production системи

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

[Користувач/Контракт] 
    ↓ запит інференсу + депозит
[Черга запитів інференсу (on-chain)]
    ↓ подія
[Cluster інференс-вузлів off-chain]
    ↓ запускає модель, генерує доказ
[Надання доказу + результат]
    ↓
[Контракт верифікатора on-chain]
    ↓ верифікація ZK доказу
[Callback до контракту, що запитав]

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

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

interface IInferenceOracle {
    struct InferenceRequest {
        bytes model_id;      // хеш або CID моделі
        bytes input;         // ABI-encoded або raw bytes
        address callback;    // контракт для callback
        bytes4 callbackSig;  // підпис callback функції
        uint256 maxFee;      // максимальна плата за інференс
    }
    
    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 або в inputs доказів потребують квантизації:

# Квантизація перед інференсом
import numpy as np

def quantize_input(x: np.ndarray, scale: int = 2**16) -> np.ndarray:
    """Конвертація float в Q16.16 fixed-point"""
    return (x * scale).astype(np.int32)

def dequantize_output(x: np.ndarray, scale: int = 2**16) -> np.ndarray:
    return x.astype(np.float32) / scale

Для EZKL квантизація відбувається автоматично при calibrate-settings — важливо перевірити точність після квантизації, втрати > 1% зазвичай неприйнятні для фінансових моделей.

Зберігання моделі та перевіряємість

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

Зобов'язання моделі — хеш ваг моделі зберігається on-chain. Вузол інференсу доводить (через ZK або підпис TEE), що використав модель з цим хешем.

IPFS/Filecoin для ваг — CID моделі фіксується on-chain. Будь-хто може завантажити та перевірити.

contract ModelRegistry {
    struct Model {
        bytes32 weightsHash;    // keccak256 від ваг в ONNX
        string ipfsCID;         // для завантаження
        address owner;
        bool isPublic;
    }
    
    mapping(bytes32 => Model) public models;
    
    function registerModel(
        bytes32 modelId,
        bytes32 weightsHash,
        string calldata ipfsCID
    ) external {
        models[modelId] = Model(weightsHash, ipfsCID, msg.sender, true);
    }
}

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

DeFi оцінка ризику — on-chain кредитний скоринг на основі on-chain активності. Малі моделі (логістична регресія, XGBoost) добре підходять для zkML.

Генеративні NFT — атрибути NFT визначаються ML-моделлю, результат перевіряємий. Моделі діапазоном 1–10M параметрів, прийнятний час доказу.

Автономні агенти — AI агент управляє on-chain позиціями. Тут zkML все ще нереалістичний для LLM-агентів, використовується TEE або оптимістичний підхід.

On-chain детектування шахрайства — кожен своп проходить через fraud scoring, результат впливає на fee tier або доступність. Логістична регресія — ідеальний кандидат для zkML.

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

Фаза 1 — Вибір моделі та квантизація (2–3 тижні). Підбір архітектури моделі під zkML обмеження, навчання, квантизація, перевірка точності. Часто це найскладніший етап — модель потрібно спрощувати.

Фаза 2 — Компіляція схеми (1–2 тижні). Компіляція ONNX → Halo2 схема через EZKL, калібрування параметрів, вимірювання часу доказу та розміру доказу.

Фаза 3 — On-chain верифікатор (1–2 тижні). Розпорядження Solidity-верифікатора, розробка oracle інтерфейсу, тестування end-to-end потоку.

Фаза 4 — Інфраструктура (2–3 тижні). Вузли інференсу (GPU), конвеєр генерації доказів, моніторинг, fallback механізми.

Фаза 5 — Інтеграція (1–2 тижні). Інтеграція до контракту, що запитав, тестування на testnet, оптимізація газу для верифікації.

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