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

GPU-вычисления сконцентрированы у облачных гигантов — AWS, GCP, Azure. Инференс моделей — у OpenAI, Anthropic, Google. Это создаёт риски vendor lock-in, ценовой диктатуры и цензуры. Децентрализованные AI-платформы предлагают альтернативу: маркетплейс вычислительных ресурсов, рынок моделей и данных на блокчейне. Но ключевая техническая проблема — как верифицировать результаты AI-вычислений без доверия к провайдеру? Смарт-контракт не может запустить нейросеть: EVM детерминирован, а нейросети используют floating point и GPU. Это фундаментальное противоречие, и его решение определяет архитектуру всей платформы.

В этой статье мы разберём основные подходы к верификации (оптимистическая, ZK, TEE), архитектуру децентрализованного рынка, токеномику и процесс разработки. Вы узнаете, как спроектировать платформу, которая решает реальные проблемы централизации AI, и какие компромиссы неизбежны. Наша команда имеет 10+ лет опыта в блокчейн-разработке и 50+ реализованных проектов в сфере DeFi, NFT и AI.

Как верифицировать 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

ZK-верификация — математически строгий подход: доказать zero-knowledge, что модель с весами W на входе X дала выход 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)

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, результат (обученная модель или аналитика) — единственное, что выходит наружу.

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

• Аудит требований и проектирование архитектуры платформы
• Разработка смарт-контрактов на Solidity 0.8.x с использованием Foundry и OpenZeppelin
• Интеграция с ZK-инструментами (EZKL, Risc Zero) или TEE (Intel SGX, AWS Nitro)
• Развёртывание в выбранной сети (Ethereum, Arbitrum, Base или app-chain)
• Документация API и смарт-контрактов
• Обучение команды заказчика работе с платформой
• Техническая поддержка на 3 месяца

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

1. Аналитика и проектирование (2–4 недели): определение требований, выбор стека, архитектура.
2. Разработка MVP (3–4 месяца): централизованный registry, оптимистическая верификация, платежи в ERC-20, базовый SDK провайдера.
3. Production v1 (6–9 месяцев): payment channels, репутационная система, dispute resolution, ZK-верификация для малых моделей, governance token.
4. Масштабирование (12+ месяцев): собственная app-chain или L2, TEE-интеграция, federated learning, cross-chain операции.

Использование децентрализованных вычислений снижает затраты на инфраструктуру до 70%. Экономия на газе при использовании L2 составляет порядка 90%.

Почему важен выбор сети деплоя?

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

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

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