Разработка децентрализованной сети вычислений

Разработка децентрализованной сети вычислений

Централизованные облака — AWS, GCP, Azure — контролируют 65% мирового рынка облачных вычислений. Три компании решают, кто получает доступ к инфраструктуре, по каким ценам и на каких условиях. Для большинства приложений это приемлемо. Для AI-инференса, рендеринга, научных вычислений и любой нагрузки, где важны цена, цензуростойкость или географическое распределение — уже нет. Децентрализованная сеть вычислений строит рынок между теми, у кого есть избыточные GPU/CPU, и теми, кому они нужны.

Проблема в том, что построить такой рынок технически сложнее, чем кажется на первый взгляд. Нужно решить три фундаментальных задачи: верифицировать, что вычисление реально было выполнено правильно; защититься от нечестных провайдеров и клиентов; обеспечить производительность, сравнимую с централизованными аналогами.

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

Три подхода и их компромиссы

Провайдер утверждает, что запустил вашу задачу и получил результат 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);
}

Используется в iExec (TEE tasks), Phala Network (Phat Contracts), Marlin Protocol. Слабые стороны: Intel SGX имел несколько серьёзных уязвимостей (Spectre/Meltdown variants, SGAxe), зависимость от производителя железа, сложность supply chain для верификации оборудования.

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 секунд.

На практике большинство протоколов 2024–2025 года используют гибрид: TEE для первичной верификации (быстро, дёшево) + optimistic challenge для случаев, когда TEE attestation недоступен или скомпрометирован.

Детерминизм вычислений

Для любого метода верификации вычисление должно быть детерминированным: один и тот же код с одними и теми же входными данными должен давать точно одинаковый результат на любом железе. Это не тривиальное требование.

Проблемы: floating-point операции дают разные результаты на разных CPU архитектурах и компиляторах; GPU вычисления недетерминированы по умолчанию из-за параллелизма; многопоточность с race conditions; зависимость от системного времени или случайности.

Решения: вычисления в WebAssembly (детерминирован по спецификации); использование integer arithmetic вместо float; детерминированные ML фреймворки (с фиксированными seed и отключённым недетерминированным параллелизмом); изоляция в контейнере с фиксированным окружением (Docker image pinning по SHA256).

Архитектура протокола

Слой matching и scheduling

Рынок вычислений требует эффективного механизма сопоставления задач и провайдеров. Два основных подхода:

On-chain order book. Клиент создаёт задачу с ценой, провайдер принимает. Прозрачно, но медленно (латентность блока) и дорого (gas на каждую операцию matching). Подходит для долгих задач, где latency matching не критична.

Off-chain matching с on-chain settlement. Отдельный matching layer (централизованный или с набором операторов) сопоставляет задачи и провайдеров, результат подтверждается on-chain. Быстро, но добавляет доверенный компонент. iExec и Akash используют этот подход.

Структура задачи на уровне контракта:

struct ComputeTask {
    bytes32 taskId;
    address client;
    bytes32 appHash;          // IPFS CID docker image
    bytes32 datasetHash;      // входные данные
    uint256 maxComputePrice;  // в токенах протокола
    uint256 trust;            // требуемый уровень реплик
    uint64  category;         // размер машины (CPU/RAM/GPU)
    uint256 timeout;
    TaskStatus status;
}

enum TaskStatus { Unset, Active, Revealing, Finalizing, Completed, Failed }

Репликация для повышения доверия

Для задач, где цена ошибки высока, можно запустить одно вычисление на 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);
}

Экономический слой

Протокол токен-модели для децентрализованной сети вычислений обычно включает:

Важный нюанс: токен должен использоваться для оплаты вычислений (utility), а не только для governance. Чисто governance токены в compute рынках не создают достаточного demand-side давления.

Рабочий процесс задачи end-to-end

1. Клиент загружает Docker image приложения на IPFS, получает content hash.
2. Клиент создаёт задачу on-chain: app hash, dataset hash, параметры, депозит.
3. Matching layer или scheduler назначает провайдера(ов).
4. Провайдер скачивает image + данные, выполняет в TEE или стандартном контейнере, генерирует результат + attestation/proof.
5. Провайдер публикует commitment on-chain.
6. После reveal и consensus — результат финализируется, провайдер получает оплату.
7. Клиент скачивает результат из 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.

Разработка и запуск

Фаза проектирования (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 инженеров.