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

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

Декларації про «децентралізований AI» у 2024–2025 році бувають двох типів: маркетингові — де блокчейн використовується як таблиця лідерів, та справжні — де криптоекономічні механізми вирішують конкретну проблему AI-ринку. Проблема реальна: GPU-вичисленням сконцентровані у AWS/GCP/Azure, інференс централізован у OpenAI/Anthropic/Google, провайдери даних не монетизують свої активи напрямку. Bittensor, Akash Network, Gensyn, Ritual — різні підходи до цієї проблеми з різними компромісами.

Перш ніж проектувати протокол, потрібно відповісти: яку конкретну проблему централізації ми вирішуємо? Децентралізовані вычисленням, децентралізований ринок моделей, верифікуємий інференс, ринок даних — це різні архітектури.

Верифікація AI-вичислень: центральна проблема

Смарт-контракт не може запустити нейросеть. EVM — детерміністична machine з 256-бітною арифметикою, нейросети — floating point з non-deterministic операціями на GPU. Це фундаментальне протиріччя, яке потрібно розвязати для будь-якої децентралізованої AI-платформи.

Оптимістична верифікація

Модель як у 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");
        _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;
        _releasePayment(task.provider, task.stake);
    }
}

Проблема: для складних моделей немає простого способу верифікувати альтернативний результат on-chain. Арбітраж через комітет вводит новий вектор централізації.

ZK-верифікація інференсу

Математично строгий підхід: доказати zero-knowledge, що модель з вагами W на input X дала output Y, не розкриваючи деталі вичислень. Дозволяє верифікувати on-chain або через публічний верификатор.

Проекти: Gensyn (власний consensus для ML), EZKL (ZK proofs для ONNX-моделей), Risc Zero (general ZK-VM).

EZKL генерує ZK circuit з ONNX-моделі, дозволяючи доказати правильність forward pass. Proof generation для GPT-2 (117M параметрів) займає години на потужному залізі. Для production-моделей типу LLaMA-3 — це поки не практично. Применимо для малих спеціалізованих моделей: класифікатори, embeddings, малі трансформери.

Trusted Execution Environments (TEE)

Intel SGX, AMD SEV, AWS Nitro Enclaves — аппаратно ізольовані середовища. Код виконується в захищеному анклаві. Attestation — механізм, що дозволяє удалено верифікувати, що конкретний код виконується у TEE.

Ritual Network використовує TEE для верифікації інференсу. Провайдер запускає модель у анклаві, анклав генерує 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 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 — для мікроплатежів за інференс краще використовувати payment channels (State Channel або zkSync-style), а не on-chain транзакцію за кожен запит. Типовий інференс запит коштує доля цента — on-chain газ це убьє.

Токеноміка платформи

Двусторонній ринок вимагає збалансованої токеноміки:

Функції utility токена:

• Оплата інференсу (або ETH/USDC — залежить від аудиторії)
• Staking провайдерів (skin in game, slashing за мошенництво)
• Governance (параметри протоколу)
• Reward за надання вичислень

Проблема інфляційних наград: якщо вознаграджувати провайдерів токеном, інфляція розмиває вартість. Bittensor вирішує через emission, прив'язану до реальної утиліти (якість output оцінок). Чим краще провайдер → більше TAO.

Емісійна крива: для нової платформи — дефляційний дизайн з buyback/burn з protocol revenue більш стійкий довгостроково ніж інфляційні субсидії.

Data marketplace: монетизація тренувальних даних

Пов'язана але окрема вертикаль: провайдери даних хочуть монетизувати набори даних для fine-tuning моделей без розкриття самих даних.

Federated Learning на блокчейні

Модель обучається розподілено: кожен учасник тренує на своїх даних, відправляє лише градієнти (не дані). Градієнти агрегуються (Federated Averaging), модель покращується без централізації даних.

Блокчейн фіксує контрибуцію кожного учасника (через хеш градієнтів), смарт-контракт розподіляє rewards пропорційно вкладу.

Проблема: градієнти можна інвертувати для відновлення частини тренувальних даних (gradient inversion attacks). Для sensitive даних — додатково потрібен Differential Privacy (додавання шуму до градієнтів).

Compute-to-Data (Ocean Protocol)

Дані залишаються у власника, алгоритм «приїжджає» до даних. Смарт-контракт фіксує умови доступу, compute відбувається у TEE, результат (обучена модель або аналітика) — єдине що виходит наружу.

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

Вибір мережи деплою

Ethereum mainnet: для governance та реєстру моделей — високий рівень довіри, але дорого для часто вокликаних контрактів.

Arbitrum/Base: для payment settlement та task routing — газ на 2 порядки дешевше, EVM-сумісність.

Власна app-chain: оправдана при >100k транзакцій/день або специфічних вимогах до throughput. Cosmos SDK або OP Stack для суверенного rollup.

Сроки та етапи

MVP (3–4 місяці): централізований реєстр + оптимістична верифікація + платіж у ERC-20 + базовий провайдер SDK. Достатньо для перших 10–20 провайдерів та proof-of-concept.

Production v1 (6–9 місяців): payment channels + система репутації + dispute resolution + ZK-верифікація для малих моделей + governance токен.

Масштабуємо версія (12+ місяців): власна app-chain або L2, TEE-інтеграція, federated learning, cross-chain операції.

Ключове обмеження: ZK-верифікація великих моделей поки не готова для production. Реалістично — оптимістична верифікація з TEE як проміжний крок, ZK додається по мірі зрілості інфраструктури (Gensyn, Risc Zero).