Разработка системы приватных вычислений на блокчейне

Разработка системы приватных вычислений на блокчейне

Смарт-контракты публичны по определению: любой может прочитать состояние контракта, декодировать calldata транзакции, проследить историю. Это неотъемлемое свойство блокчейна — и одновременно главное препятствие для целого класса приложений. Закрытые торги, приватные медицинские данные, корпоративные расчёты, anti-front-running механизмы в DeFi — всё это требует вычислений на блокчейне без раскрытия входных данных. Задача: дать смарт-контракту возможность работать с секретными данными, сохранив при этом верифицируемость результата.

Три технологических стека, три набора компромиссов

Прежде чем проектировать систему, нужно чётко понять, какая технология решает вашу конкретную задачу. Универсального ответа нет.

Zero-Knowledge Proofs (ZKP)

ZKP позволяют доказать факт без раскрытия данных: "я знаю приватный ключ", "мой баланс >= 100", "эта транзакция корректна". Доказательство публикуется on-chain, верификатор-контракт проверяет его за O(1) время.

Когда подходит: вычисление детерминированное, входные данные статичны (не меняются в ходе вычисления), нужна максимальная децентрализация — никакого доверия к третьим сторонам.

Ключевые системы доказательств:

Для Ethereum: Groth16 верификация стоит ~250K gas, PLONK — ~300-500K. STARKs дороги для on-chain verify, лучше подходят для 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. Время генерации proof зависит от размера схемы: simple схема (~10K constraints) — 1-5 сек на обычном железе. Сложная (~1M constraints) — минуты. Для user-facing приложений нужен сервер для генерации proof (centralized tradeoff) или WASM в браузере (медленно, но децентрализованно). zkVM решения (RISC Zero, SP1) позволяют генерировать ZK-доказательства для произвольного Rust/C кода без написания схем — это значительно снижает порог входа.

Trusted Execution Environments (TEE)

TEE (Intel SGX, AMD SEV, ARM TrustZone) — аппаратно изолированная среда выполнения. Код и данные в TEE недоступны даже операционной системе и гипервизору. Технически: шифрование памяти на уровне CPU, измерение кода через remote attestation.

Когда подходит: сложные вычисления (ML inference, обработка больших данных), низкая latency требуется, допустимо доверие к hardware вендору.

Интеграция с блокчейном через attestation:

1. Код в TEE вычисляет результат
2. TEE генерирует attestation report (подпись Intel DCAP или AMD SEV) — доказательство, что именно этот код выполнился в защищённой среде
3. On-chain верификатор проверяет attestation и принимает результат

Ключевые проекты: 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 периодически выпускает microcode патчи, но фундаментальная проблема остаётся: доверие к производителю. Для high-stakes финансовых приложений TEE в одиночку недостаточен — используют комбинацию TEE + MPC.

Multi-Party Computation (MPC)

MPC позволяет нескольким участникам совместно вычислить функцию от их приватных входов без раскрытия этих входов друг другу. Классический пример: millionaires problem — определить, кто богаче, без раскрытия реальных состояний.

Ключевые протоколы:

• Secret Sharing (Shamir's) — секрет делится на N шардов, любые K восстанавливают секрет. Базовый примитив для большинства MPC схем
• Garbled Circuits — эффективны для булевых вычислений, используются в DECO (TLS oracle без раскрытия данных)
• SPDZ — арифметические схемы, практичен для финансовых вычислений с нечестными участниками
• Threshold Signature Schemes (TSS) — децентрализованное управление ключами без единой точки компромисса

Для блокчейна MPC чаще всего используется для:

1. Threshold custody — ключ никогда не существует в полном виде в одном месте. Подпись транзакции — результат взаимодействия N нод
2. Private price feeds — оракулы вычисляют медиану цены без раскрытия отдельных значений
3. 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:

1. Участник хешируeт ставку: commitment = Poseidon(bid_amount, salt)
2. Публикует commitment on-chain
3. После дедлайна публикует ZK proof: "моя ставка >= reserve price" без раскрытия суммы
4. Победитель определяется через MPC среди участников, прошедших ZK-верификацию

Более сложный вариант (полностью приватный): Aztec Connect или аналог — весь аукцион inside 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 proof verification

Aztec Connect (deprecated, но архитектурно показателен) позволял приватно взаимодействовать с 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). Для частых операций: батчевая верификация (несколько proof в одной транзакции), или деплой в 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. Bench: время генерации proof, gas стоимость верификации, совместимость с целевой сетью.

Фаза 3 — Разработка production системы (6-12 недель). Схема с полной логикой, on-chain верификатор, off-chain компоненты (proof generation server или WASM client), интеграционные тесты.

Фаза 4 — Аудит (4-8 недель). ZK circuit аудит + смарт-контракт аудит — это разные специализации. Cryptographic review для MPC протокола.

Фаза 5 — Deployment и мониторинг. Trusted setup ceremony (если Groth16/PLONK), параметры публично верифицируемы. Мониторинг: proof generation latency, failed verification rate, gas consumption.

Реалистичный срок для non-trivial системы приватных вычислений — 4-6 месяцев от проектирования до mainnet, включая аудит.