Розробка децентралізованої мережи вичислень
Централізовані хмари — AWS, GCP, Azure — контролюють 65% світового ринку хмарних вичислень. Три компанії вирішують, хто отримує доступ до інфраструктури, по яких цінах та на яких умовах. Для більшості приложень це прийнятно. Для AI-інференсу, рендерингу, наукових вичислень та будь-якого навантаження, де важливі ціна, цензуростійкість або географічне розподілення — вже ні. Децентралізована мережа вичислень будує ринок між тими, у кого є надлишкові GPU/CPU, та тими, кому вони потрібні.
Проблема у тому, що побудувати такий ринок технічно складніше, ніж здається. Потрібно вирішити три фундаментальні завдання: верифікувати, що вычисленням реально було виконано правильно; захиститися від нечесних провайдерів та клієнтів; забезпечити продуктивність, порівнювану з централізованими аналогами.
Верифікація вичислень: центральна технічна проблема
Три підходи та їх компроміси
Провайдер стверджує, що запустив вашу завдання та отримав результат X. Як контракт перевірить це без того, щоб самому пересчитати? Якщо контракт пересчитує — ви платите подвійну вартість вичислень. Це й є основна проблема верифікації.
Оптимістичне виконання з challenge period. Результат приймається як верний, якщо протягом вікна (зазвичай 7 днів) ніхто не оспорив. При оспаруванні — верифікаційна гра: обидві сторони по черзі звужують незгоду до одного кроку вычисленням, який верифікується on-chain. Це підхід Truebit, адаптований варіант використовується у Arbitrum для EVM спорів.
Ключові параметри: розмір залогу провайдера (повинен перевищувати прибуток від мошенництва), довжина challenge window (компромісс між безпекою та швидкістю), кількість верифікаторів у грі. Слабе місце: якщо клієнт та провайдер у змові, або якщо challenge window вибрана неправильно для класу завдань.
Trusted Execution Environment (TEE). Вычисленням відбувається у ізольованому анклаві — Intel SGX, AMD SEV, ARM TrustZone. Аппаратний механізм attestation доказує, що конкретний код виконується у конкретному оточенні без втручання оператора. Контракт верифікує attestation 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 для верифікації обладнання.
Криптографічна верифікація через 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 для первинної верифікації (швидко, дешево) + оптимістичний challenge для випадків, коли TEE недоступен або скомпрометований.
Детерміризм вичислень
Для будь-якого методу верифікації вычисленням повинно бути детерміністичним: один і той же код з одними й тими ж вхідними даними повинен давати точно одинаковий результат на будь-якому залізі. Це не тривіальне вимога.
Проблеми: floating-point операції дають різні результати на різних CPU архітектурах та компіляторах; GPU вичисленням недетерміністичні за замовчуванням з-за паралелізму; багатопоточність з race conditions; залежність від системного часу або випадковості.
Рішення: вичисленням у WebAssembly (детерміністичні по специфікації); використання integer arithmetic замість float; детерміністичні ML фреймворки (з фіксованими seed та відключеним недетерміністичним паралелізмом); ізоляція у контейнері з фіксованим окруженням (Docker image pinning по SHA256).
Архітектура протоколу
Слой matching та scheduling
Ринок вычислень вимагає ефективного механізму сопоставлення завдань та провайдерів. Два основних підходи:
On-chain order book. Клієнт створює завдання з ціною, провайдер приймає. Прозраченне, але повільно (latency блоку) та дорого (gas на кожну операцію matching). Підходить для довгих завдань, де latency matching не критична.
Off-chain matching з on-chain settlement. Окремий matching layer (централізований або з набором операторів) сопоставляє завдання та провайдерів, результат підтверджується on-chain. Швидко, але додає dovir компонент. 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);
}
Економічний слой
Токен-модель для децентралізованої мережи вычислень зазвичай включає:
| Параметр | Типовий діапазон | Назначения |
|---|---|---|
| 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.
Розробка та запуск
Фаза проектування (2–3 тижні). Вибір механізму верифікації (TEE / оптимістичний / 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 для MVP протоколу (TEE-based, без ZK) — 6–10 місяців командою з 3–5 інженерів.