Розроблення системи приватних обчислень на блокчейні
Смарт-контракти є публічними за визначенням: будь-хто може прочитати стан контракту, декодувати calldata транзакції, простежити історію. Це невід'ємна властивість блокчейну — і одночасно головна перешкода для цілого класу застосунків. Закриті торги, приватні медичні дані, корпоративні розрахунки, анти-front-running механізми в DeFi — все це вимагає обчислень на блокчейні без розкриття вхідних даних. Завдання: дати смарт-контракту можливість працювати з таємними даними, зберігаючи при цьому верифіцюємість результату.
Три технологічних стеки, три набори компромісів
Перш ніж проектувати систему, потрібно чітко зрозуміти, яка технологія вирішує вашу конкретну задачу. Універсальної відповіді немає.
Zero-Knowledge Proofs (ZKP)
ZKP дозволяють довести факт без розкриття даних: "я знаю приватний ключ", "мій баланс >= 100", "ця транзакція коректна". Доказ публікується on-chain, верифікатор-контракт перевіряє його за час O(1).
Коли підходить: обчислення детерміноване, вхідні дані статичні (не змінюються під час обчислення), потрібна максимальна децентралізація — без довіри до третіх сторін.
Ключові системи доказів:
| Система | Trusted Setup | Розмір доказу | Час верифікації | Практичність |
|---|---|---|---|---|
| Groth16 | Так (per-circuit) | ~200 байт | ~1ms | Зріла, Tornado Cash, zkSNARK DeFi |
| PLONK | Так (universal) | ~800 байт | ~3ms | Один setup для всіх схем |
| STARKs | Ні | ~100KB | ~10ms | Прозорість, але дорого for on-chain verify |
| Halo2 | Ні | ~1KB | ~5ms | Використовується в Zcash Orchard, zcash |
Для Ethereum: верифікація Groth16 коштує ~250K gas, PLONK — ~300-500K. STARKs дорогі для on-chain верифікації, краще підходять для L2 (StarkEx, StarkWare).
Розроблення ZK-схем. Схеми пишуться на спеціалізованих мовах:
- Circom — найпоширеніша, компілює в R1CS, генерує верифікатор Solidity. Використовується в Tornado Cash, Semaphore, Aztec
- Noir (Aztec) — високорівневе, синтаксис близький до Rust, компілює в PLONK
- Cairo (StarkWare) — для STARKs, використовується в StarkNet
Приклад схеми на Circom для доказу знання прообразу хеша:
pragma circom 2.0.0;
include "poseidon.circom";
template HashPreimage() {
signal input preimage; // приватний вхід
signal input hash; // публічний вхід
signal output valid;
component hasher = Poseidon(1);
hasher.inputs[0] <== preimage;
hash === hasher.out;
valid <== 1;
}
component main {public [hash]} = HashPreimage();
Важна нюанс: використання SHA256 в ZK-схемах дорого (багато constraints). Poseidon — ZK-friendly хеш-функція, спеціально оптимізована для схем, на порядок ефективніша.
Операційні обмеження ZKP. Час генерації доказу залежить від розміру схеми: проста схема (~10K constraints) — 1-5 сек на звичайному залізі. Складна (~1M constraints) — хвилини. Для user-facing застосунків потрібен сервер для генерації доказу (централізований компроміс) або WASM у браузері (повільно, але децентралізовано). Рішення zkVM (RISC Zero, SP1) дозволяють генерувати ZK-докази для довільного Rust/C коду без написання схем — це значно знижує поріг входу.
Trusted Execution Environments (TEE)
TEE (Intel SGX, AMD SEV, ARM TrustZone) — апаратно ізольована середовище виконання. Код та дані в TEE недоступні навіть операційній системі та гіпервізору. Технічно: шифрування пам'яті на рівні CPU, вимірювання коду через віддалену атестацію.
Коли підходить: складні обчислення (ML inference, обробка великих даних), потрібна низька latency, припустима довіра до hardware вендора.
Інтеграція з блокчейном через атестацію:
- Код у TEE обчислює результат
- TEE генерує звіт про атестацію (підпис Intel DCAP або AMD SEV) — доказ того, що саме цей код виконувався в захищеному середовищі
- On-chain верифікатор перевіряє атестацію та приймає результат
Ключові проекти: Phala Network (TEE для смарт-контрактів на Substrate), Secret Network (TEE + Cosmos), Oasis Protocol (SGX для EVM-сумісних контрактів), Marlin Oyster (TEE compute marketplace для Ethereum).
Уразливості TEE. SGX має відомі side-channel атаки: Spectre, Meltdown, Plundervolt. Intel періодично випускає мікрокод патчі, але фундаментальна проблема залишається: довіра до виробника. Для високоризиковані фінансові застосунки TEE в одиночку недостатній — використовують комбінацію TEE + MPC.
Multi-Party Computation (MPC)
MPC дозволяє кільком учасникам спільно обчислити функцію від їх приватних вхідних даних без розкриття цих вхідних даних один одному. Класичний приклад: проблема мільйонерів — визначити, хто багатший, без розкриття реальних сум.
Ключові протоколи:
- Secret Sharing (Shamir's) — секрет ділиться на N шардів, будь-які K відновлюють секрет. Базовий примітив для більшості MPC схем
- Garbled Circuits — ефективні для булевих обчислень, використовуються в DECO (TLS оракул без розкриття даних)
- SPDZ — арифметичні схеми, практичні для фінансових обчислень з нечесними учасниками
- Threshold Signature Schemes (TSS) — децентралізоване управління ключами без однієї точки компрометації
Для блокчейну MPC найчастіше використовується для:
- Threshold custody — ключ ніколи не існує в повному вигляді в одному місці. Підпис транзакції — результат взаємодії N нод
- Private price feeds — оракули обчислюють медіану ціни без розкриття окремих значень
- Dark pool trading — матчинг ордерів без розкриття книги заявок
Практична реалізація. Бібліотеки: MP-SPDZ (академічна, підтримує багато протоколів), tss-lib (Go, використовується в tBTC, Binance Bridge), threshold-bls (Rust, використовується в Chainlink VRF та DRAND).
Архітектура гібридної системи
На практиці найбільш надійні системи приватних обчислень комбінують технології:
User (secret input)
↓
[TEE enclave]
Обчислює результат
Генерує ZK proof про коректність
↓
On-chain Verifier Contract
Перевіряє TEE attestation + ZK proof
↓
Виконує логіку на основі верифікованого результату
Така схема: TEE забезпечує конфіденційність та швидкість, ZK proof забезпечує верифіцюємість без довіри до конкретного TEE вендора.
Приклад: закриті торги (sealed-bid auction).
Проблема: у публічному смарт-контракті ставки видні всім до reveal phase. MEV-боти можуть здійснити front-run.
Рішення з Commit-Reveal + ZKP:
- Учасник хешує ставку:
commitment = Poseidon(bid_amount, salt) - Публікує commitment on-chain
- Після дедлайну публікує ZK proof: "моя ставка >= reserve price" без розкриття суми
- Переможець визначається через MPC серед учасників, які пройшли ZK-верифікацію
Більш складний варіант (повністю приватний): Aztec Connect або аналог — весь аукціон всередину ZK rollup.
Aztec Network: ZK-native приватність
Aztec — це L2 з нативною приватністю для EVM. Смарт-контракти ("Aztec contracts" / Noir) мають приватні функції (виконуються у браузері, генерують ZK proof) та публічні функції (звичайний EVM). Приватна функція може викликати публічну, але не навпаки — це фундаментальне обмеження моделі.
Aztec.js SDK для взаємодії з приватними контрактами:
import { createAztecNodeClient, Fr, AccountWallet } from '@aztec/aztec.js';
// Виклик приватної функції - proof генерується локально
const tx = await contract.methods
.private_transfer(recipient.address, amount)
.send({ from: wallet });
await tx.wait(); // on-chain перевірка доказу
Aztec Connect (застарілий, але архітектурно показовий) дозволяв приватно взаємодіяти з Ethereum DeFi протоколами через "shields" — агрегацію приватних транзакцій.
Критичні деталі реалізації
Randomness у ZK. Багато криптографічних протоколів вимагають надійного джерела випадковості. On-chain псевдорандом (blockhash, timestamp) передбачуваний. Рішення: Chainlink VRF (verifiable random function), DRAND (distributed randomness beacon), commit-reveal з кількома учасниками.
Gas costs. ZK верифікація on-chain дорога. Groth16 verifier — 250K gas на Ethereum mainnet ($5-15 при помірному gas). Для часто використовуваних операцій: batch verification (кілька доказів в одній транзакції), або розгортання на L2 (Base, Arbitrum — 10-50x дешевше).
Управління ключами в MPC. Key generation ceremony — критичний момент. Якщо всі учасники скомпрометовані одночасно під час keygen — вся схема руйнується. Практика: географічно розподілені оператори, різні технології (різні TEE вендори), threshold >= 2/3.
Аудит ZK схем. Стандартний Solidity аудит недостатній. Потрібен окремий аудит схеми (circuit): перевірка underconstrained signals (сигнал без обмеження може прийняти будь-яке значення — класична уразливість), completeness (коректний свідок завжди створює valid proof), soundness (неможливо створити proof для хибного твердження). Фірми з ZK-експертизою: Least Authority, Trail of Bits (ZK спеціалізація), ABDK.
Процес проектування та розроблення
Фаза 1 — Threat model та вибір технології (1-2 тижні). Що саме таємне? Від кого? Яка threat model — цікавий спостерігач, активний противник, скомпрометована нода? Це визначає вибір: ZKP (без довіри нікому), TEE (довіра вендору), MPC (довіра порогу учасників).
Фаза 2 — Прототип та proof of concept (2-4 тижні). ZK схема на Circom/Noir з мінімальними constraints. Benchmark: час генерації доказу, gas вартість верифікації, сумісність з цільовою мережею.
Фаза 3 — Розроблення production системи (6-12 тижнів). Схема з повною логікою, on-chain верифікатор, off-chain компоненти (сервер генерації доказу або WASM клієнт), інтеграційні тести.
Фаза 4 — Аудит (4-8 тижнів). ZK circuit аудит + аудит смарт-контракту — це різні спеціалізації. Криптографічний огляд для MPC протоколу.
Фаза 5 — Розгортання та моніторинг. Trusted setup ceremony (якщо Groth16/PLONK), параметри є публічно верифіцюємими. Моніторинг: latency генерації доказу, коефіцієнт невдалої верифікації, газові витрати.
Реалістичний термін для нетривіальної системи приватних обчислень — 4-6 місяців від проектування до mainnet, включаючи аудит.