Розробка системи токенізації 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 та запустіть моніторинг.

Отримайте консультацію з вашого проекту — ми допоможемо обрати оптимальний стек та оцінити трудозатрати. Зв'яжіться з нами для попередньої оцінки.