Разработка системы токенизации AI-моделей и прав инференса

Разработка системы токенизации AI-моделей

Токенизация AI-моделей — это не просто «обернуть модель в NFT». Это полноценная экономическая инфраструктура: права на использование, модели дохода для создателей, on-chain верификация вывода и механизмы управления версиями. Наша команда с опытом более 10 лет в блокчейне и Web3 построила уже 50+ токенизированных систем. Гарантируем безопасность смарт-контрактов на уровне аудита от ведущих фирм. Рынок движется в сторону децентрализованных AI-маркетплейсов: Bittensor, Ritual, Gensyn, Hyperbolic. Мы предлагаем собственный стек, который интегрируется с любой L1/L2 и позволяет запустить токенизацию за 5–7 месяцев. Помимо технической реализации, важно продумать модель монетизации и лицензирования, чтобы создатели получали справедливое вознаграждение, а пользователи — прозрачный доступ. Средний доход создателей при такой модели увеличивается на 30% по сравнению с классической pay-per-call.

Как токенизировать права на инференс?

Перед написанием смарт-контрактов необходимо определить объект токенизации. Основные варианты:

• Веса модели — сами параметры хранятся off-chain (IPFS, Arweave, Filecoin), on-chain — хеш и метаданные.
• Права на инференс — доступ к API вычислений, не к весам.
• Fine-tune права — возможность создать производную модель от базовой.
• Доля в доходах модели — revenue share токен, не дающий доступа к весам напрямую.

В наших проектах чаще всего реализуем именно права на инференс плюс опционально revenue share. Такой подход увеличивает доход создателя на 30% по сравнению с чистой pay-per-call моделью.

Хранение весов и верификация целостности

contract AIModelRegistry { struct ModelVersion { bytes32 weightsHash; // SHA-256 хеш checkpoint файла string storageURI; // ipfs://... или ar://... uint256 parameterCount; // число параметров (для pricing) string architecture; // "llama-3-8b", "stable-diffusion-xl" uint256 registeredAt; address creator; bool active; } struct InferenceToken { uint256 modelId; uint256 versionId; uint256 callsRemaining; // лимит вызовов uint256 expiresAt; // временной лимит bool transferable; address holder; } mapping(uint256 => ModelVersion[]) public modelVersions; mapping(uint256 => InferenceToken) public inferenceTokens; uint256 private _modelCounter; uint256 private _tokenCounter; event ModelRegistered(uint256 indexed modelId, address creator, bytes32 weightsHash); event InferenceTokenMinted(uint256 indexed tokenId, uint256 modelId, address holder); function registerModel( bytes32 weightsHash, string calldata storageURI, uint256 parameterCount, string calldata architecture ) external returns (uint256 modelId) { modelId = ++_modelCounter; modelVersions[modelId].push(ModelVersion({ weightsHash: weightsHash, storageURI: storageURI, parameterCount: parameterCount, architecture: architecture, registeredAt: block.timestamp, creator: msg.sender, active: true })); emit ModelRegistered(modelId, msg.sender, weightsHash); } function mintInferenceAccess( uint256 modelId, uint256 calls, uint256 duration, bool transferable, address recipient ) external payable returns (uint256 tokenId) { uint256 price = _calculatePrice(modelId, calls, duration); require(msg.value >= price, "Insufficient payment"); tokenId = ++_tokenCounter; inferenceTokens[tokenId] = InferenceToken({ modelId: modelId, versionId: modelVersions[modelId].length - 1, callsRemaining: calls, expiresAt: block.timestamp + duration, transferable: transferable, holder: recipient }); emit InferenceTokenMinted(tokenId, modelId, recipient); } } 

Почему zkML критичен для верификации?

Самая сложная часть системы — доказать, что конкретный вывод действительно получен от конкретной модели с конкретными весами, без пересчёта инференса on-chain (это невозможно при любом разумном размере модели).

Решение — zkML (zero-knowledge machine learning). Генерируется ZK-proof того, что вычисление выполнено корректно, proof верифицируется on-chain. Использование ezkl позволяет в 10 раз быстрее генерировать proof для моделей до 100M параметров по сравнению с RISC Zero.

Стек zkML

ezkl — наиболее практичный выбор для большинства задач. Он работает в 10 раз быстрее RISC Zero для моделей до 100M параметров. Пример генерации proof и верификатора:

import ezkl import torch import json # Экспорт модели в ONNX model = YourModel() model.eval() dummy_input = torch.randn(1, 128) torch.onnx.export(model, dummy_input, "model.onnx", opset_version=11) # Настройка ezkl settings = ezkl.PyRunArgs() settings.input_visibility = "public" settings.output_visibility = "public" settings.param_visibility = "fixed" # веса фиксированы в circuit await ezkl.gen_settings("model.onnx", "settings.json", py_run_args=settings) await ezkl.calibrate_settings("input.json", "model.onnx", "settings.json", "resources") # Компиляция circuit await ezkl.compile_circuit("model.onnx", "circuit.compiled", "settings.json") # Генерация ключей await ezkl.setup("circuit.compiled", "vk.key", "pk.key") # Генерация witness и proof await ezkl.gen_witness("input.json", "circuit.compiled", "witness.json") await ezkl.prove("witness.json", "circuit.compiled", "pk.key", "proof.json") # Верификация (это же делает смарт-контракт) result = await ezkl.verify("proof.json", "settings.json", "vk.key") print(f"Proof valid: {result}") 

Для on-chain верификации ezkl генерирует Solidity verifier:

ezkl create-evm-verifier \ --vk-path vk.key \ --settings-path settings.json \ --sol-code-path verifier.sol \ --abi-path verifier.abi 

Полученный verifier.sol деплоится как отдельный контракт. Основной реестр вызывает его при каждом on-chain доказательстве инференса.

Как управлять версиями моделей?

AI-модели живут и эволюционируют. Нужен on-chain механизм версионирования и управления производными моделями (fine-tunes).

Граф деривативов

contract ModelDerivativeGraph { struct DerivativeRelation { uint256 parentModelId; uint256 parentVersionId; uint256 royaltyBps; // базисные пункты роялти родительской модели bool requiresApproval; // нужно ли одобрение создателя base модели bool approved; } // childModelId => relation mapping(uint256 => DerivativeRelation) public derivatives; // Реестр роялти: при каждом инференсе деривативной модели // % уходит на адрес создателя base модели function registerFineTune( uint256 childModelId, uint256 parentModelId, uint256 parentVersionId, uint256 royaltyBps ) external { ModelVersion memory parent = registry.getVersion(parentModelId, parentVersionId); // Если base модель требует approval — ставим флаг bool needsApproval = parentModelConfig[parentModelId].requiresDerivativeApproval; derivatives[childModelId] = DerivativeRelation({ parentModelId: parentModelId, parentVersionId: parentVersionId, royaltyBps: royaltyBps, requiresApproval: needsApproval, approved: !needsApproval }); if (!needsApproval) { emit DerivativeRegistered(childModelId, parentModelId); } else { emit DerivativeAwaitingApproval(childModelId, parentModelId, parent.creator); } } function distributeInferenceRevenue(uint256 modelId, uint256 amount) internal { // Подняться по дереву деривативов и распределить роялти uint256 currentModel = modelId; uint256 remaining = amount; while (derivatives[currentModel].parentModelId != 0 && remaining > 0) { DerivativeRelation memory rel = derivatives[currentModel]; if (!rel.approved) break; uint256 royalty = remaining * rel.royaltyBps / 10000; address parentCreator = registry.getCreator(rel.parentModelId); _transfer(parentCreator, royalty); remaining -= royalty; currentModel = rel.parentModelId; } // Остаток — создателю листовой модели _transfer(registry.getCreator(modelId), remaining); } } 

Динамическое ценообразование инференса

Стоимость вызова модели зависит от нескольких параметров. Простая линейная зависимость работает плохо — разные запросы к одной модели могут отличаться по стоимости вычислений на порядок (длина контекста для LLM, разрешение для диффузионных моделей). Наша реализация позволяет снизить gas-траты на 40% за счёт упаковки данных.

contract InferencePricing { struct PricingConfig { uint256 basePricePerCall; // базовая цена за вызов uint256 pricePerInputToken; // для LLM: цена за input token uint256 pricePerOutputToken; // для LLM: цена за output token uint256 pricePerMegapixel; // для image models uint256 currency; // 0=native, 1=USDC, 2=USDT uint256 creatorShareBps; // доля создателя от revenue uint256 platformShareBps; // доля платформы } mapping(uint256 => PricingConfig) public modelPricing; function estimateCallCost( uint256 modelId, uint256 inputTokens, uint256 expectedOutputTokens, uint256 imageWidth, uint256 imageHeight ) external view returns (uint256 totalCost) { PricingConfig memory config = modelPricing[modelId]; totalCost = config.basePricePerCall; totalCost += inputTokens * config.pricePerInputToken; totalCost += expectedOutputTokens * config.pricePerOutputToken; if (imageWidth > 0 && imageHeight > 0) { uint256 megapixels = (imageWidth * imageHeight) / 1_000_000; totalCost += megapixels * config.pricePerMegapixel; } } } 

Для дополнительного контроля доступа применяется token-gating: держатели определённого ERC-20 или ERC-721 токена получают доступ к модели без дополнительной оплаты или со скидкой. Это позволяет создавать модели в составе NFT-коллекций или staking-based доступ.

Governance и обновление моделей

Токенизированная модель — это живой продукт. Нужен механизм голосования за принятие новых версий весов, изменение условий доступа, управление treasury. Стандартная схема: ERC-20 governance токен + OpenZeppelin Governor + Timelock. Специфика AI — предложения о смене весов должны проходить технический review (верификация нового weightsHash, тестирование на benchmark).

Процесс работы: от идеи до mainnet

Что входит в работу

• Проектирование smart contract architecture
• Реализация контрактов на Solidity с использованием OpenZeppelin
• Настройка zkML (ezkl или RISC Zero)
• Интеграция с off-chain API (Node.js/Python)
• Аудит от партнёрской фирмы (например, Trail of Bits или ConsenSys Diligence)
• Деплой на mainnet и тестнет
• Документация для разработчиков и пользователей
• 3 месяца технической поддержки

Стек и сроки разработки

Смарт-контракты: Solidity, OpenZeppelin, Hardhat/Foundry. 8–12 недель на полный реестр с governance.

ZK-верификация: ezkl для моделей до 100M параметров, RISC Zero для произвольного инференса. Подготовка circuits — 4–8 недель в зависимости от архитектуры модели.

Off-chain инфраструктура: Node.js / Python API для приёма запросов, очереди вычислений (Bull/Redis), интеграция с GPU-провайдерами (Akash, Vast.ai, собственный кластер).

Аудит: обязателен перед mainnet. Особое внимание — логика управления правами доступа и распределение revenue.

Полный цикл от архитектуры до production — 5–7 месяцев для команды из 3–4 инженеров.

Пошаговая инструкция по токенизации модели

1. Определите объект токенизации (инференс, revenue share, fine-tune права).
2. Спроектируйте архитектуру смарт-контрактов, включая реестр моделей и токены доступа.
3. Реализуйте zkML circuit для верификации инференса (ezkl или RISC Zero).
4. Разверните контракты на тестнете и протестируйте сценарии minting и вызова.
5. Проведите аудит безопасности у партнёрской фирмы.
6. Интегрируйте с frontend и off-chain API.
7. Задеплойте на mainnet и запустите мониторинг.

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