Централизованные облака — AWS, GCP, Azure — контролируют 65% мирового рынка облачных вычислений. Три компании решают, кто получает доступ к инфраструктуре, по каким ценам и на каких условиях. Для большинства приложений это приемлемо. Для AI-инференса, рендеринга, научных вычислений и любой нагрузки, где важны цена, цензуростойкость или географическое распределение — уже нет. Децентрализованная сеть вычислений строит рынок между теми, у кого есть избыточные GPU/CPU, и теми, кому они нужны. Мы разрабатываем такие сети с полным циклом — от экономической модели до запуска mainnet. Получите консультацию по выбору механизма верификации уже сегодня.
Проблема в том, что построить децентрализованную сеть вычислений технически сложнее, чем кажется на первый взгляд. Нужно решить три фундаментальных задачи: верифицировать, что вычисление реально было выполнено правильно; защититься от нечестных провайдеров и клиентов; обеспечить производительность, сравнимую с централизованными аналогами. Свяжитесь с нами — мы бесплатно оценим ваш проект.
Как верифицировать вычисления без повторного запуска?
Провайдер утверждает, что запустил вашу задачу и получил результат X. Как контракт проверит это без того, чтобы самому пересчитать? Если контракт пересчитывает — вы платите двойную стоимость вычислений. Это и есть основная проблема верификации.
Три подхода и их компромиссы
Optimistic execution с challenge period. Результат принимается как верный, если в течение окна (обычно 7 дней) никто не оспорил. При оспаривании — верификационная игра: обе стороны по очереди сужают несогласие до одного шага вычисления, который верифицируется on-chain. Это подход Truebit, адаптированный вариант используется в Arbitrum для EVM споров.
Ключевые параметры: размер залога провайдера (должен превышать ожидаемую прибыль от мошенничества), длина challenge window (компромисс между безопасностью и скоростью), число верификаторов в игре. Слабое место: если клиент и провайдер в сговоре, или если challenge window выбрана неправильно для конкретного класса задач.
Trusted Execution Environment (TEE). Вычисление происходит в изолированном анклаве — Intel SGX, AMD SEV, ARM TrustZone. Аппаратный механизм attestation доказывает, что конкретный код выполнился в конкретном окружении без вмешательства оператора. Контракт верифицирует attestation quote on-chain.
interface ITEEVerifier { // mrenclave — уникальный хэш кода в анклаве // report — подписанный Intel IAS отчёт function verifyAttestation( bytes32 mrenclave, bytes calldata report, bytes calldata signature ) external view returns (bool); } Как работает TEE attestation?
Анклав генерирует подписанное свидетельство (quote), которое проверяется on-chain с помощью публичного ключа Intel. Если аттестация прошла, контракт уверен, что код выполнен в защищённой среде.Используется в iExec (TEE tasks), Phala Network (Phat Contracts), Marlin Protocol. Слабые стороны: Intel SGX имел несколько серьёзных уязвимостей (Spectre/Meltdown variants, SGAxe), зависимость от производителя железа, сложность supply chain для верификации оборудования. TEE быстрее ZK в 10-50 раз по времени верификации, но уступает в уровне гарантий.
Cryptographic verification через ZK-proofs. Провайдер генерирует ZK-proof того, что он выполнил корректное вычисление над входными данными. Верификатор on-chain проверяет proof за O(1) независимо от сложности вычисления. Это самый сильный подход с точки зрения гарантий, но самый дорогой с точки зрения overhead на генерацию proof.
Для простых детерминированных задач (хэширование, базовая арифметика) — Groth16 или PLONK через circom. Для сложных вычислений — zkVM (RISC Zero, SP1): клиент пишет программу на Rust, zkVM генерирует proof выполнения для любой Rust-программы. Стоимость proof generation на RISC Zero: от $0.01 до $1 в зависимости от сложности задачи, время 10–300 секунд.
На практике большинство протоколов последних лет используют гибрид: TEE для первичной верификации (быстро, дёшево) + optimistic challenge для случаев, когда TEE attestation недоступен или скомпрометирован. Такой подход даёт снижение стоимости на 30-50% по сравнению с чистой ZK-схемой без потери уровня безопасности.
| Метод | Скорость | Безопасность | Стоимость overhead |
|---|---|---|---|
| Optimistic | Средняя | Средняя | Низкая |
| TEE | Высокая | Средняя | Низкая |
| ZK | Низкая | Высокая | Высокая |
Детерминизм вычислений
Для любого метода верификации вычисление должно быть детерминированным: один и тот же код с одними и теми же входными данными должен давать точно одинаковый результат на любом железе. Это не тривиальное требование.
Проблемы: floating-point операции дают разные результаты на разных CPU архитектурах и компиляторах; GPU вычисления недетерминированы по умолчанию из-за параллелизма; многопоточность с race conditions; зависимость от системного времени или случайности.
Решения: вычисления в WebAssembly (детерминирован по спецификации); использование integer arithmetic вместо float; детерминированные ML фреймворки (с фиксированными seed и отключённым недетерминированным параллелизмом); изоляция в контейнере с фиксированным окружением (Docker image pinning по SHA256).
Когда нужна репликация вычислений?
Для задач, где цена ошибки высока, можно запустить одно вычисление на N провайдерах и верифицировать результаты через consensus. При 3 провайдерах с результатом большинства — вероятность успешной атаки резко падает (нужен сговор 2 из 3).
Схема commitment-reveal
Провайдеры сначала публикуют хэш результата (commitment), затем после того, как все задепонировали — раскрывают результат. Это предотвращает копирование ответа друг у друга.
// Фаза 1: Commit function submitResultHash(bytes32 taskId, bytes32 resultHash) external { require(isTaskProvider(taskId, msg.sender), "Not assigned provider"); require(task.status == TaskStatus.Active, "Wrong status"); resultCommitments[taskId][msg.sender] = resultHash; emit ResultCommitted(taskId, msg.sender); } // Фаза 2: Reveal function revealResult(bytes32 taskId, bytes calldata result) external { bytes32 commitment = resultCommitments[taskId][msg.sender]; require(keccak256(result) == commitment, "Hash mismatch"); revealedResults[taskId][msg.sender] = result; _tryFinalize(taskId); } Экономический слой
Протокол токен-модели для децентрализованной сети вычислений обычно включает:
| Параметр | Типичный диапазон | Назначение |
|---|---|---|
| Stake провайдера | 5–100 RLC / USDC | Залог против мошенничества |
| Slash при нарушении | 10–50% stake | Deterrence |
| Протокольная комиссия | 1–5% | Treasury |
| Scheduler fee | 1–3% | Matching layer |
Важный нюанс: токен должен использоваться для оплаты вычислений (utility), а не только для governance. Чисто governance токены в compute рынках не создают достаточного demand-side давления.
Рабочий процесс задачи end-to-end
- Клиент загружает Docker image приложения на IPFS, получает content hash.
- Клиент создаёт задачу on-chain: app hash, dataset hash, параметры, депозит.
- Matching layer или scheduler назначает провайдера(ов).
- Провайдер скачивает image + данные, выполняет в TEE или стандартном контейнере, генерирует результат + attestation/proof.
- Провайдер публикует commitment on-chain.
- После reveal и consensus — результат финализируется, провайдер получает оплату.
- Клиент скачивает результат из IPFS.
Сетевые компоненты вне блокчейна
Worker node — основной компонент провайдера. Daemon, который мониторит блокчейн на новые задачи, скачивает и выполняет workload, публикует результаты. Стек: Go или Rust, Docker SDK для изоляции контейнеров, SGX SDK для TEE задач.
Scheduler / Core — для протоколов с off-chain matching. Отвечает за категоризацию задач, выбор провайдеров по stake и репутации, мониторинг timeout. Может быть децентрализован через BFT consensus (набор scheduler нод).
Result storage — IPFS для хранения результатов с пиннингом. Ссылка на IPFS хранится on-chain. Альтернатива для конфиденциальных результатов: зашифрованный результат в IPFS, ключ расшифровки передаётся через TLS в TEE.
Что входит в разработку под ключ
Мы предлагаем полный цикл: от whiteboard до аудита. Среди ключевых deliverable — документация архитектуры, смарт-контракты с исходниками, worker node с интеграцией Docker и TEE, тестовый стенд с реальными провайдерами, обучение команды заказчика и пост-запусковая поддержка. При необходимости пишем формальные спецификации и проводим формальную верификацию критических модулей.
Разработка и запуск
Фаза проектирования (2–3 недели). Выбор механизма верификации (TEE / optimistic / ZK), определение категорий задач, token economics. Это решения, которые нельзя исправить после деплоя.
Смарт-контракты (6–10 недель). TaskRegistry, WorkerRegistry, Escrow, Consensus модуль, Voucher система (для спонсирования задач). Foundry для тестирования, включая fork-тесты с реальными TEE attestation данными.
Worker node (4–8 недель). Go/Rust daemon с Docker интеграцией. Если TEE — интеграция с Intel DCAP attestation API. Критично: node должен корректно обрабатывать timeout, зависшие задачи, network partitions.
Тестирование с реальным железом (4–6 недель). Testnet с реальными worker нодами, нагрузочное тестирование matching layer, проверка слэшинга на dishonest worker.
Аудит (4–8 недель). Акцент на: корректность consensus механизма при Byzantine провайдерах, возможность манипуляции challenge game, атаки через flash loans на stake механизм.
Полный цикл от проектирования до mainnet launch для MVP протокола (TEE-based, без ZK) — 6–10 месяцев командой из 3–5 инженеров. Сроки зависят от сложности и необходимости ZK-или-гибридной верификации. Получите консультацию — оценим ваш проект и предложим roadmap.