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 по сравнению с "доверяй провайдеру на слово".
| Метод | Безопасность | Производительность | Применимость |
|---|---|---|---|
| Оптимистическая | Средняя (зависит от окна dispute) | Высокая (нет overhead) | MVP, малые модели |
| ZK-proof | Высокая (криптографическая гарантия) | Низкая (часы на генерацию proof) | Малые специализированные модели |
| TEE | Средняя (доверие к производителю CPU) | Средняя (overhead анклава) | Production, средние модели |
Архитектура децентрализованного рынка 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 месяца
Процесс разработки и сроки
- Аналитика и проектирование (2–4 недели): определение требований, выбор стека, архитектура.
- Разработка MVP (3–4 месяца): централизованный registry, оптимистическая верификация, платежи в ERC-20, базовый SDK провайдера.
- Production v1 (6–9 месяцев): payment channels, репутационная система, dispute resolution, ZK-верификация для малых моделей, governance token.
- Масштабирование (12+ месяцев): собственная app-chain или L2, TEE-интеграция, federated learning, cross-chain операции.
Использование децентрализованных вычислений снижает затраты на инфраструктуру до 70%. Экономия на газе при использовании L2 составляет порядка 90%.
Почему важен выбор сети деплоя?
| Критерий | Ethereum mainnet | Arbitrum/Base | App-chain (Cosmos/OP Stack) |
|---|---|---|---|
| Доверие | Высокое | Среднее | Низкое (суверенный) |
| Газ | Высокий | Низкий | Минимальный (свой) |
| Throughput | ~15 tx/s | ~1000 tx/s | Кастомизируемый |
| Когда выбирать | Governance, реестр | Payment, routing | >100k tx/день, спец. требования |
Стек разработки
| Компонент | Технология |
|---|---|
| Смарт-контракты | Solidity 0.8.x + Foundry + OpenZeppelin 5.x |
| ZK-верификация | EZKL / Risc Zero / Noir |
| TEE integration | Intel SGX + Gramine или AWS Nitro |
| Off-chain сервисы | Go или Rust (высокая конкурентность) |
| Модельный реестр | IPFS + on-chain хеш |
| Payment channels | State channels или Arbitrum/zkSync |
| Monitoring | Prometheus + Grafana + on-chain events |
Ключевое ограничение: ZK-верификация больших моделей пока не готова для production. Реалистично — оптимистическая верификация с TEE как промежуточный шаг, ZK добавляется по мере зрелости инфраструктуры (Gensyn, Risc Zero).
Свяжитесь с нами, чтобы оценить ваш проект и получить детальный план разработки. Закажите разработку под ключ с гарантией результата.