Разработка децентрализованной 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 (own 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
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).

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