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

Розробка смарт-контрактів для AI-маркетплейсу: ключові виклики

Ми розробляємо смарт-контракти для AI-маркетплейсів під ключ. AI-маркетплейс на блокчейні — це не просто «додати крипто-оплату до SaaS». Це система, де on-chain компоненти відповідають за розрахунки між розробниками моделей та споживачами, верифікацію виконаних інференсів, керування доступом до API та розподіл роялті. Складність у тому, що AI-інференс відбувається off-chain, а блокчейн повинен це верифікувати без довіри до оператора. Наша команда з 5+ років досвіду (15+ проєктів) вирішує це завдання за допомогою комбінації оптимістичних, zkML та TEE-підходів, обираючи оптимальний для вашого бюджету та вимог. Вже на етапі проєктування ми оцінюємо газові витрати та обираємо L2-мережу з мінімальними комісіями: L2 транзакції дешевші за mainnet в 100–1000 разів. Економія на транзакціях порівняно з mainnet може сягати 99% — з $50 за інференс до $0.05 на L2. Наприклад, при 1000 інференсах на день економія складе $49,950 на місяць.

Як контракт верифікує off-chain обчислення?

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

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

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

Якщо ви хочете дізнатися, який метод верифікації підійде вашому проєкту, замовте консультацію.

Які 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);
    }
}

Платіжна модель

Pay-per-use — простіше для споживача, але кожна транзакція на mainnet коштує дорого. Рішення: Layer 2 (Arbitrum, Base) або state channel.

Subscription / credit model — споживач купує кредити (ERC-20 токен протоколу), списання при інференсі. Оператор отримує кредити, протокол періодично розподіляє їх у stablecoin.

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

Governance та оновлюваність

Використовуємо UUPS proxy (EIP-1967) для оновлення. Governance — через Governor Bravo з timelock. Параметри, які не змінюються: баланси користувачів, історичні дані. Вони зберігаються в immutable storage.

Який L2 обрати для AI-маркетплейсу?

Mainnet Ethereum з $5-50 за транзакцію нежиттєздатний. Переважні варіанти:

Якщо проєкт орієнтований на AI Web3 — розглядаємо Ritual або Gensyn.

Що входить у роботу

• Повний набір смарт-контрактів (реєстр, ескроу, розподіл доходів)
• Юніт- та інтеграційні тести (Foundry, fuzzing)
• Розгортання та верифікація контрактів у блокчейн-оглядачі
• Документація API та архітектури
• Підтримка протягом місяця після запуску

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

1. Архітектурне проєктування (3-5 днів)
2. Розробка смарт-контрактів (1.5-2 тижні)
3. Інтеграційне тестування (3-5 днів)
4. Аудит безпеки (7-10 днів паралельно)
5. Розгортання та документування (2-3 дні)

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

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

Розробка смарт-контрактів

Ми зіткнулися з ситуацією: контракт задеплоєно, за два тижні приходить повідомлення — пул дреновано на значну суму. Дивимося транзакцію в Tenderly: атакуючий викликав deposit(), всередині callback на ERC-777 повторно викликав withdraw() — баланс оновився тільки після другого виходу. Класична reentrancy, але не через ETH transfer, а через хук ERC-777. ReentrancyGuard стояв тільки на withdraw().

Такі випадки — не рідкість. Смарт-контракт — це фінансова логіка без можливості пропатчити її вночі. Наша команда розробляє контракти під ключ, вбудовуючи захист від reentrancy, MEV та gas-атак на ранніх етапах. Reentrancy attack — одна з найпоширеніших вразливостей, що потребує глибокого розуміння EVM.

Як ми розробляємо смарт-контракти під ключ?

Починаємо з аудиту бізнес-логіки та вибору стеку. Solidity 0.8.x — стандарт для EVM-сумісних чейнів: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana використовуємо Rust та Anchor: модель акаунтів і програм вимагає явного оголошення всіх ресурсів. Для проектів з формальною верифікацією підходить Move (Aptos, Sui) — лінійні типи мови виключають копіювання ресурсів на рівні компілятора. Vyper обираємо для контрактів, де критична простота аудиту (Curve Finance).

Gas optimization — не передчасна оптимізація, а архітектурне рішення. На Ethereum mainnet деплой погано спроектованого контракту може коштувати значну суму тільки через неоптимальний storage layout. Переупаковка структури Proposal з 7 слотів до 4 заощадила 18k gas на кожному голосуванні — економія на масштабі протоколу з тисячами голосувань на день дає відчутну річну вигоду.

Типові помилки в gas: передача масивів через memory замість calldata в external функціях (дорожче в 2-3 рази); використання require з довгими рядками замість custom error error InsufficientBalance(...). Кастомні помилки дешевші на 50-200 gas на revert і передають структуровані дані фронтенду.

Чому аудит смарт-контрактів критичний для безпеки?

Аудит — не разова перевірка, а вбудований етап розробки. Використовуємо три рівні:

1. Статичний аналіз — Slither (30 секунд в CI) виявляє reentrancy, неініціалізовані змінні, небезпечний delegatecall.
2. Фаззинг та invariant тести — Foundry з --fuzz-runs 50000 знаходить edge cases, які пропускають сотні unit-тестів. Echidna перевіряє інваріанти («сума всіх балансів ≤ totalSupply»).
3. Ручний code review — наші інженери з досвідом 10+ років у блокчейні виявляють логічні помилки, які не ловлять інструменти. Для протоколів з високим TVL обов'язковий зовнішній аудит з боку Trail of Bits, Consensys Diligence або OpenZeppelin. Термін — 2-4 тижні.

Будь-який апгрейдуємий протокол повинен мати timelock. TimelockController з OpenZeppelin: операція пропонується → чекає мінімальний delay (48-72 години) → виконується. Без timelock один скомпрометований deployer wallet = втрата всього пулу.

OpenZeppelin Security Audits підтверджують, що 80% вразливостей, знайдених у деплоїних контрактах, пов'язані з відсутністю перевірок доступу або reentrancy. Ми включаємо ці перевірки в CI ще до першого деплою.

Які патерни апгрейду обираємо?

Storage collision — головна небезпека проксі. Implementation v2 не повинен додавати змінні перед існуючими. OpenZeppelin Upgrades plugin для Hardhat та Foundry перевіряє це автоматично, але тільки при використанні його API.

Як захистити контракт від MEV та front-running?

На Ethereum mainnet транзакції в mempool видно всім. MEV-боти проводять sandwich-атаки на DEX, фронтраннінги мінтингу та governance. Рішення: commit-reveal scheme для аукціонів, приватна відправка через Flashbots PROTECT RPC. EIP-7702 та PBS (proposer-builder separation) змінюють картину, але поки не масово.

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

1. Аналітика — специфікація функцій, діаграма викликів, аналіз edge cases. Без цього кодинг починається даремно.
2. Розробка — Solidity/Rust з тестами паралельно. Тест → код → рефакторинг. Використовуємо Foundry для fuzz та invariant тестів.
3. Внутрішній аудит — Slither + Echidna + ручний code review. Foundry invariant tests для протокольних інваріантів.
4. Зовнішній аудит — для проектів з реальними грошима. Термін: 2-4 тижні.
5. Деплой — Foundry scripts або Hardhat Ignition з verify на Etherscan. Gnosis Safe для ownership transfer одразу після деплою.
6. Моніторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Що входить в роботу

• Документація на архітектуру та специфікацію контракту (NatSpec).
• Вихідний код з репозиторієм та CI (Slither, Foundry, coverage).
• Розгорнута версія контракту з verify на блокчейн-експлорері.
• Результати аудиту (внутрішнього та зовнішнього за запитом).
• Доступи до моніторингу та управління (Gnosis Safe).
• Гарантія на код: фікси критичних багів протягом місяця після деплою.
• Консультація щодо інтеграції з веб-інтерфейсом (wagmi, RainbowKit).

Терміни орієнтовно

• ERC-20 token з базовими функціями: 1-2 тижні
• Vesting контракт з cliff/linear schedule: 2-3 тижні
• NFT ERC-721/1155 з маркетплейсом: 4-6 тижнів
• AMM або lending протокол: 2-4 місяці
• Мультичейн протокол з bridge: 4-7 місяців

Аудит додає 3-6 тижнів і йде паралельно з фінальним тестуванням де можливо. Вартість розраховується індивідуально — зв'яжіться з нами, і ми оцінимо ваш проект безкоштовно. Економія на газі завдяки нашій оптимізації може сягати 30% на рік для високонавантажених протоколів.

Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку смарт-контракту — отримайте консультацію з архітектури та захисту від reentrancy, MEV та gas-атак. Напишіть нам — ми підберемо оптимальний стек під вашу задачу.