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

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

On-chain AI inference — это не маркетинговый термин, это конкретная инженерная проблема с несколькими частичными решениями, каждое из которых имеет собственный trade-off. Клиент обычно приходит с запросом «мы хотим, чтобы результаты нашей модели были верифицируемы и нельзя было подделать». Это разумное требование. Вопрос в том, как его реализовать не сжигая $50k в gas на один inference.

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

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

1. ZK-proof of inference (zkML)

Модель исполняется off-chain, on-chain верифицируется zero-knowledge proof корректности исполнения. Это наиболее перспективный и наиболее технически сложный подход.

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

EZKL — самый зрелый zkML тулкит на сегодня. Принимает ONNX-модели, генерирует Halo2 circuits, верифицирует 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)
"

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

# Proof generation (это медленно)
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: время генерации proof для простой CNN (ResNet-18) — 5–20 минут на CPU, 30–120 секунд на GPU. Размер SRS (structured reference string) — гигабайты для больших моделей. Это ограничивает применимость к малым моделям (< 1M параметров) или к сценариям где latency proof generation не критична.

Риго (Risc Zero) + Boundless — альтернативный подход через zkVM. Модель компилируется в RISC-V, исполняется в Risc Zero zkVM, proof верифицируется on-chain. Менее эффективен для ML-специфичных операций чем специализированные zkML circuits, но позволяет использовать произвольный Rust/C++ код.

// Гость (guest) программа в 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 параметров) — proof за секунды
• CNN для классификации изображений (< 1M параметров) — proof за минуты
• LLM, diffusion models — нереально в 2024–2025 без специализированного железа

2. Оптимистичный подход (fraud proofs)

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

Этот подход используют Giza Tech и Modulus Labs. Экономика: challenge period = N блоков, challenger должен предоставить fraud proof (partial execution trace). Работает при наличии достаточного числа верификаторов — это economic game theory, а не математическая гарантия.

// Упрощённая схема оптимистичного 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");
        
        // Верификация fraud proof — partial execution
        bool isFraud = verifyFraudProof(result.inputHash, result.outputs, fraudProof);
        if (isFraud) {
            // Слэш бонд submitter, наградить challenger
            result.challenged = true;
        }
    }
}

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

3. Decentralized inference networks (TEE + economic security)

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 от oracle
    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 — децентрализованная сеть инференса. Nodes используют TEE (Trusted Execution Environment) для верификации инференса без раскрытия весов модели. Eigen Layer restaking для economic security.

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

Выбор подхода

Практическая архитектура production системы

Большинство реальных проектов используют гибридный подход: 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;      // хеш или CID модели
        bytes input;         // ABI-encoded или raw bytes
        address callback;    // контракт для callback
        bytes4 callbackSig;  // сигнатура callback функции
        uint256 maxFee;      // максимальная плата за 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 требуют quantization:

# Quantization перед inference
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 — важно проверить accuracy после квантизации, потери > 1% обычно недопустимы для финансовых моделей.

Хранение модели и verifiability

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

Model commitment — хеш модельных весов хранится on-chain. Inference node доказывает (через 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 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.

Этапы разработки

Фаза 1 — Model selection & quantization (2–3 нед). Подбор архитектуры модели под zkML constraints, обучение, quantization, проверка accuracy. Часто это самый болезненный этап — модель приходится упрощать.

Фаза 2 — Circuit compilation (1–2 нед). Компиляция ONNX → Halo2 circuit через EZKL, калибровка настроек, измерение proof time и размера proof.

Фаза 3 — On-chain verifier (1–2 нед). Деплой Solidity-верификатора, разработка oracle интерфейса, тестирование end-to-end flow.

Фаза 4 — Infrastructure (2–3 нед). Inference nodes (GPU), proof generation pipeline, мониторинг, fallback mechanisms.

Фаза 5 — Integration (1–2 нед). Интеграция в requesting контракт, тестирование на testnet, оптимизация gas для верификации.

Итого: 7–12 недель до production. Основной неизвестный фактор — насколько конкретная модель поддаётся квантизации без потери качества.