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

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

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

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

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

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

Оптимистическая верификация (Optimistic)

Модель как в 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");
        // Отправить на арбитраж — комитет или on-chain верификацию
        _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;
        // Освободить stake провайдера, оплатить задание
        _releasePayment(task.provider, task.stake);
    }
}

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

ZK-верификация inference

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

Проекты: Gensyn (own consensus для ML), EZKL (ZK proofs для ONNX-моделей), Risc Zero (general purpose ZK-VM).

EZKL генерирует ZK circuit из ONNX-модели и позволяет доказать правильность forward pass:

import ezkl
import torch
import onnx

# Экспортируем модель в ONNX
model = MyMLModel()
dummy_input = torch.randn(1, 128)
torch.onnx.export(model, dummy_input, "model.onnx")

# Генерация proof
ezkl.gen_settings("model.onnx", "settings.json")
ezkl.calibrate_settings("input.json", "model.onnx", "settings.json")
ezkl.compile_circuit("model.onnx", "compiled_model", "settings.json")
ezkl.gen_pk("compiled_model", "pk.key", "settings.json")
ezkl.gen_vk("compiled_model", "vk.key", "settings.json")
ezkl.prove("input.json", "witness.json", "compiled_model", "pk.key", "proof.json")
ezkl.verify("proof.json", "settings.json", "vk.key")  # можно делать on-chain

Ограничения: ZK-proof генерация для GPT-2 (117M параметров) занимает часы на мощном железе. Для production-моделей типа LLaMA-3 — это пока не практично. Применимо для небольших специализированных моделей: классификаторы, embeddings, малые трансформеры.

Trusted Execution Environments (TEE)

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

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

// Упрощённый одновременный payment channel
contract InferenceChannel {
    address public user;
    address public provider;
    uint256 public expiry;
    
    // Пользователь подписывает ваучеры off-chain
    // Провайдер закрывает канал с последним подписанным ваучером
    function close(
        uint256 amount,
        bytes calldata userSignature
    ) external {
        require(msg.sender == provider, "Only provider");
        bytes32 message = keccak256(abi.encodePacked(address(this), amount));
        address signer = ECDSA.recover(message.toEthSignedMessageHash(), userSignature);
        require(signer == user, "Invalid signature");
        
        payable(provider).transfer(amount);
        payable(user).transfer(address(this).balance);
    }
}

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

Двусторонний рынок требует сбалансированной токеномики:

Utility token функции:

• Оплата inference (или ETH/USDC — зависит от аудитории)
• Стейкинг провайдеров (skin in the game, slashing за мошенничество)
• Governance (параметры протокола)
• Reward за предоставление вычислений

Проблема инфляционных наград: если награждать провайдеров токеном, инфляция размывает стоимость. Bittensor решает это через emission, привязанную к реальной полезности (качество output). Чем лучше оценки от валидаторов — тем больше TAO.

Эмиссионная кривая: для новой платформы — дефляционный дизайн с buyback/burn из protocol revenue более устойчив долгосрочно, чем инфляционные субсидии.

Data marketplace: монетизация тренировочных данных

Отдельная но связанная вертикаль: провайдеры данных хотят монетизировать наборы данных для дообучения моделей без раскрытия самих данных.

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 месяца): централизованный registry + оптимистическая верификация + payment в ERC-20 + базовый провайдер SDK. Достаточно для первых 10–20 провайдеров и proof-of-concept.

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

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

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