Централізовані хмари — 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.