Разработка смарт-контрактов для AI-маркетплейса

Разработка смарт-контрактов для AI-маркетплейса

AI-маркетплейс на блокчейне — это не просто «добавить крипто-оплату к SaaS». Это система, где on-chain компоненты отвечают за расчёты между разработчиками моделей и потребителями, верификацию выполненных инференсов, управление доступом к API и распределение роялти. Сложность в том, что AI-инференс происходит off-chain, а блокчейн должен это верифицировать без доверия к оператору.

Главная проблема: верификация off-chain computation

Как контракт знает, что инференс был выполнен корректно? Оператор мог вернуть мусор вместо реального ответа модели. Варианты решения, от простого к сложному:

Optimistic верификация с dispute window. Оператор заявляет о выполнении инференса, публикует хэш результата. В течение N часов потребитель может оспорить результат. При споре — арбитраж (on-chain голосование или Kleros). Это то, как работает Optimism на уровне L2. Минус: задержка оплаты, UX-трение.

Proof-of-inference через zkML. Zero-knowledge proof того, что модель дала конкретный вывод на конкретных входных данных. Технология развивается: EZKL позволяет конвертировать ONNX-модели в ZK-circuit (Halo2). Верификатор — смарт-контракт, который проверяет proof за ~500K gas. Ограничение: работает для моделей до ~50M параметров, GPT-4-класс верифицировать так невозможно пока.

TEE-based attestation. Инференс выполняется внутри Trusted Execution Environment (Intel TDX, AMD SEV). TEE генерирует аттестат — подпись, которую верифицирует on-chain оракул. Marlin Oyster, Phala Network предоставляют инфраструктуру для этого. Доверие переносится с оператора на Intel/AMD.

Для большинства проектов на старте — optimistic верификация. zkML или TEE — для систем, где на кону большие суммы.

Архитектура on-chain компонентов

Типичный AI-маркетплейс требует несколько взаимодействующих контрактов:

ModelRegistry — реестр AI-моделей. Хранит: CID модели на IPFS/Arweave, адрес владельца, pricing (per-request стоимость), метаданные (тип модели, входной/выходной формат). Владелец может обновить цену и CID (новая версия модели), но не может изменить историю запросов.

InferenceEscrow — эскроу для расчётов. Потребитель депонирует оплату + security deposit. Оператор выполняет инференс и получает оплату после подтверждения. Если подтверждения нет через timeout — автоматический рефанд.

ReputationOracle — счётчик успешных/оспоренных запросов для каждого оператора. Операторы с низким рейтингом требуют больший deposit или блокируются.

RevenueDistributor — роялти за использование модели. Если модель создана командой (несколько contributor-ов), контракт автоматически распределяет доходы пропорционально весам.

contract ModelRegistry {
    struct Model {
        address owner;
        string ipfsCID;        // модель + weights
        string metadataCID;    // описание, input/output schema
        uint256 pricePerCall;  // в USDC (6 decimals)
        bool active;
    }
    
    mapping(bytes32 => Model) public models;
    
    event ModelRegistered(bytes32 indexed modelId, address owner, string ipfsCID);
    event ModelUpdated(bytes32 indexed modelId, string newCID, uint256 newPrice);
    
    function registerModel(
        string calldata ipfsCID,
        string calldata metadataCID,
        uint256 pricePerCall
    ) external returns (bytes32 modelId) {
        modelId = keccak256(abi.encodePacked(msg.sender, ipfsCID, block.timestamp));
        models[modelId] = Model({
            owner: msg.sender,
            ipfsCID: ipfsCID,
            metadataCID: metadataCID,
            pricePerCall: pricePerCall,
            active: true
        });
        emit ModelRegistered(modelId, msg.sender, ipfsCID);
    }
}

Платёжная модель: subscription vs pay-per-use

Pay-per-use — проще для потребителя, не нужно предсказывать потребление. Сложнее on-chain: каждый запрос — это транзакция с оплатой. На mainnet газ делает это дорогим. Решение: Layer 2 (Arbitrum, Base) или state channel — потребитель открывает канал с оператором, закрывает по истечении лимита.

Subscription / credit model — потребитель покупает кредиты (ERC-20 токен протокола), списание кредитов происходит при каждом инференсе. Оператор получает кредиты, протокол периодически распределяет accumulated кредиты в stablecoin через buyback или direct claim.

API key on-chain — NFT как API ключ (ERC-721 или ERC-1155). Владелец NFT получает доступ к модели. Права можно продать/перепродать на вторичном рынке. Роялти за вторичные продажи (EIP-2981) идут разработчику модели — дополнительный источник дохода.

Governance и апгрейдируемость

Маркетплейс будет развиваться: новые типы верификации, изменения pricing logic, новые модели доступа. Используем UUPS proxy (EIP-1967) для апгрейдируемости контрактов. Governance — через Governor Bravo совместимый контракт с timelock: изменения системных параметров проходят через голосование держателей протокольного токена.

Параметры, которые НЕ должны меняться через апгрейд: балансы пользователей, исторические данные об инференсах. Они хранятся в immutable storage контрактах, которые апгрейдируемая логика только читает.

Чейн: почему не mainnet

Для AI-маркетплейса важна низкая стоимость транзакций — запросы к моделям частые. Mainnet Ethereum с $5-50 за транзакцию нежизнеспособен. Предпочтительные варианты:

Если проект ориентирован на специфическую AI Web3 экосистему — рассматриваем Ritual (L1 с нативной поддержкой AI инференса) или Gensyn (compute network для ML).

Процесс и сроки

Архитектурное проектирование (3-5 дней). Определяем модель верификации, платёжную механику, governance. Рисуем диаграммы взаимодействия контрактов.

Разработка (1.5-2 недели). Foundry, полное тест-покрытие, fuzzing для финансовых операций.

Интеграционные тесты (3-5 дней). Тестируем с реальными IPFS/Arweave CID, симулируем dispute сценарии.

Аудит. Для публичного маркетплейса — обязателен. Рекомендуем параллельный аудит двумя провайдерами для систем с ожидаемым TVL > $500K.

Итого от проектирования до готового к аудиту кода: 1-2 недели в зависимости от выбранной модели верификации и сложности governance.