Разработка ZK-SNARK приложений: от схемы до аудита

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка ZK-SNARK приложений: от схемы до аудита
Сложный
от 1 недели до 3 месяцев
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Мы разрабатываем ZK-SNARK приложения под ключ: от проектирования арифметической схемы до аудита и деплоя. ZK-SNARK (Zero-Knowledge Succinct Non-interactive ARgument of Knowledge) — это доказательство того, что вы знаете секрет, не раскрывая секрет. Звучит абстрактно, пока не столкнёшься с конкретной задачей: доказать, что пользователь старше 18 лет без передачи даты рождения, или подтвердить баланс кошелька без раскрытия адреса, или верифицировать исполнение программы без повторного её запуска.

Tornado Cash (до санкций) переместил ~7 млрд долларов, используя ZK-SNARK для доказательства права на вывод без связи с адресом депозита (источник: Tornado Cash whitepaper). Zcash защищает транзакции через ту же технологию. Polygon zkEVM доказывает корректность пакета из тысяч транзакций одним компактным proof. Наши инженеры имеют опыт внедрения ZK в реальные проекты — от DeFi до identity-решений.

Как работают ZK-SNARK: достаточно глубоко, чтобы строить

От задачи к схеме

Любая вычислительная задача, которую можно записать как набор арифметических ограничений (arithmetic circuit), может быть доказана через ZK-SNARK. Схема (circuit) — это не обычная программа. Это описание вычисления как системы уравнений над конечным полем.

Возьмём простую задачу: доказать, что я знаю x такое, что x² + x + 5 = y, где y — публичное значение. Схема:

signal input x;
signal output y;
signal x_squared;

x_squared <== x * x;
y <== x_squared + x + 5;

Это Circom — основной язык для описания ZK-схем (см. официальную документацию). Компилятор преобразует схему в набор ограничений R1CS, затем в QAP, который является математической основой для SNARK.

Почему Groth16 до сих пор стандарт?

Groth16 даёт наименьший proof (~200 bytes) и наименьший gas на верификацию (~250k). Недостаток: каждая схема требует отдельной церемонии trusted setup. Если схема изменилась — нужна новая церемония. Используется в Tornado Cash, Zcash, большинстве production ZK-приложений.

Как выбрать между Groth16, PLONK и FFLONK?

Выбор proof system определяет все остальные параметры: размер proof, время генерации, размер trusted setup, время верификации в контракте (и соответственно gas cost).

Система Proof size Verify gas Trusted setup Prover time
Groth16 ~200 bytes ~250k gas Per-circuit Быстрый
PLONK ~800 bytes ~450k gas Universal Медленнее
FFLONK ~800 bytes ~200k gas Universal Медленнее
STARKs >40 KB >1M gas Не нужен Быстрый

Groth16 — наименьший proof и наименьший gas на верификацию. Недостаток: каждая схема требует отдельной церемонии trusted setup. Если схема изменилась — нужна новая церемония. Использует: Tornado Cash, Zcash, большинство production ZK-приложений.

PLONK — universal trusted setup (Powers of Tau), который годится для любой схемы до определённого размера. Изменить схему можно без новой церемонии. Proof больше, но для большинства приложений это приемлемо. Использует: zkSync Era, Aztec Protocol.

FFLONK — оптимизированная версия PLONK с меньшим gas на верификацию. Используется в Polygon zkEVM.

Мы рекомендуем Groth16 для production приложений с фиксированной схемой и высоким объёмом транзакций (минимальный gas на верификацию). PLONK — для прототипов и приложений, где схема может меняться.

Trusted Setup и почему это важно

Trusted setup — это криптографическая церемония, которая генерирует параметры для доказательств. Если кто-то сохранит "токсичные отходы" (промежуточные значения) — он сможет генерировать поддельные доказательства. Это не теоретическая угроза: если setup скомпрометирован, вся система доверия рушится.

Groth16 требует двухэтапной церемонии:

  1. Powers of Tau — универсальная часть, независимая от схемы. Существуют публичные trusted setup от Ethereum Foundation (Hermez 1, 2), которые поддержали тысячи участников. Мы используем их, не генерируем свои.
  2. Phase 2 — схемо-специфичная часть. Для production систем организуем церемонию с несколькими участниками через snarkjs.

Стек и инструментарий

  • Circom 2 — язык для написания схем. Компилятор на Rust, значительно быстрее первой версии. Поддерживает шаблоны (templates) для переиспользования схем.
  • snarkjs — JavaScript библиотека для генерации и верификации доказательств, проведения trusted setup, экспорта верификатора в Solidity.
  • circomlibjs — библиотека стандартных схем: hash функции (Poseidon, MiMC, SHA256 в схеме), подпись (EdDSA, ECDSA), деревья Меркла.
  • Noir (Aztec) — альтернативный язык с более высоким уровнем абстракции, компилирует в PLONK. Проще для разработчиков, знакомых с Rust-синтаксисом.
  • SnarkVM / Leo (Aleo) — для Aleo blockchain, если задача требует privacy-first L1.

Типичный проект: ZK Age Verification

Задача: пользователь доказывает, что старше 18 лет, используя данные из верифицированного credential (например, от KYC-провайдера). Провайдер подписал дату рождения своим ключом. Пользователь не раскрывает дату рождения, только доказывает факт.

Схема (упрощённо):

template AgeVerification(merkleDepth) {
    // Публичные входы
    signal input currentDate;        // текущая дата (публичная)
    signal input issuerPubKeyHash;   // хэш публичного ключа провайдера (публичная)
    
    // Приватные входы (witness)
    signal input birthDate;          // дата рождения (приватная)
    signal input signature[2];       // подпись провайдера (приватная)
    signal input issuerPubKey[2];    // публичный ключ провайдера (приватная)
    
    // Проверяем подпись провайдера
    component sigVerifier = EdDSAVerifier();
    sigVerifier.msg <== birthDate;
    sigVerifier.pubKey <== issuerPubKey;
    sigVerifier.sig <== signature;
    
    // Проверяем, что pubKey соответствует публичному хэшу
    component hasher = Poseidon(2);
    hasher.inputs <== issuerPubKey;
    issuerPubKeyHash === hasher.out;
    
    // Проверяем возраст
    signal age;
    age <== currentDate - birthDate;
    component ageCheck = GreaterThan(32);
    ageCheck.in[0] <== age;
    ageCheck.in[1] <== 18 * 365; // 18 лет в днях
    ageCheck.out === 1;
}

Верификатор в Solidity генерируется автоматически через snarkjs и содержит precompile-вызовы для проверки elliptic curve pairing (EIP-197). Gas на верификацию — около 250k для Groth16.

Производительность и ограничения

Время генерации proof (proving time) зависит от размера схемы (количества ограничений). Ориентиры для Groth16 на современном железе:

Ограничений в схеме Prover time (CPU) Prover time (GPU)
100k ~5 сек ~0.5 сек
1M ~60 сек ~5 сек
10M ~15 мин ~60 сек

Для web-приложений прувинг в браузере реален для схем до 500k ограничений (через WASM компиляцию). Более тяжёлые схемы требуют серверного prover или специализированного prover-сервиса (Sindri, Succinct).

Poseidon hash в схеме намного эффективнее SHA256: Poseidon — ~250 ограничений на хэш, SHA256 — ~27000. Поэтому все ZK-дружественные протоколы используют Poseidon.

Что входит в работу

  • Проектирование арифметической схемы (circuit design) под вашу задачу
  • Разработка схемы на Circom/Noir с unit-тестами
  • Проведение trusted setup (test/production)
  • Генерация верификатора в Solidity (Groth16/PLONK)
  • Интеграция верификатора в смарт-контракт и TypeScript SDK
  • Аудит схемы (underconstraining, overconstraining, signal aliasing)
  • Документация и обучение вашей команды

Процесс разработки

  1. Исследование и дизайн схемы (1–2 недели). Переводим бизнес-задачу в арифметические ограничения. Оцениваем размер схемы и proving time. Выбираем proof system. Это самый важный этап — ошибка в дизайне схемы может требовать полного перепроектирования.

  2. Разработка схемы на Circom (1–2 недели). Пишем схему, покрываем unit-тестами через Jest + circomlibjs. Отдельно верифицируем математическую корректность ограничений.

  3. Trusted Setup. Для прототипа — используем тестовый entropy. Для production — организуем ceremony с несколькими участниками.

  4. Разработка верификатора и интеграция (1 неделя). Генерируем Solidity verifier через snarkjs. Интегрируем в основной смарт-контракт. Пишем TypeScript SDK для frontend.

  5. Аудит схемы. ZK-схемы имеют специфичные уязвимости: underconstraining, overconstraining, signal aliasing. Это отдельный тип аудита, который требует специализации. Мы проводим аудит с использованием Circomspect и Ecne.

Сроки: от 1 недели (простая схема, PLONK) до 3 месяцев (сложный zkApp с кастомными криптографическими примитивами). Стоимость рассчитывается после детального анализа требований. Свяжитесь с нами, чтобы получить консультацию и точную оценку вашего проекта.

Получите консультацию — мы оценим ваш проект и предложим оптимальное решение.

Разработка смарт-контрактов

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().

Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.

Как мы разрабатываем смарт-контракты под ключ

Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).

Язык Модель исполнения Типичная область Риски
Solidity 0.8.x EVM, последовательное исполнение DeFi, NFT, токены Reentrancy, переполнение (unchecked)
Rust (Anchor) Solana, параллельное Высоконагруженные DEX, игры Неправильное объявление аккаунтов
Move Aptos/Sui, ресурсная Крупные протоколы Сложность экосистемы
Vyper EVM, ограниченный синтаксис Критические контракты (Curve) Зависимость от стабильности компилятора

Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.

Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.

Почему аудит смарт-контрактов критичен для безопасности

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

  1. Статический анализSlither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
  2. Фаззинг и invariant тестыFoundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
  3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

Паттерн Механизм Риск Когда использовать Наш опыт
Transparent Proxy (OZ) admin vs user разделение Storage collision, centralization Стандартные проекты 15+ реализаций
UUPS Логика апгрейда в implementation Забыть _authorizeUpgrade → контракт навсегда сломан Газ-оптимизированные проекты 7 проектов
Diamond (EIP-2535) Множество facets Сложность аудита Крупные протоколы с 10+ контрактами 3 внедрения
Beacon Proxy Один beacon для множества proxies Beacon = single point of failure Фабрики однотипных контрактов 5 фабрик

Storage collision — главная опасность прокси. Implementation v2 не должен добавлять переменные перед существующими. OpenZeppelin Upgrades plugin для Hardhat и Foundry проверяет это автоматически, но только при использовании его API.

Как защитить контракт от MEV и front-running

На Ethereum mainnet транзакции в mempool видны всем. MEV-боты проводят sandwich-атаки на DEX, фронтраннинги минтинга и governance. Решение: commit-reveal scheme для аукционов, приватная отправка через Flashbots PROTECT RPC. EIP-7702 и PBS (proposer-builder separation) меняют картину, но пока не массово.

Процесс разработки

  1. Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
  2. Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
  3. Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
  4. Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
  5. Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
  6. Мониторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Что входит в работу

  • Документация на архитектуру и спецификацию контракта (NatSpec).
  • Исходный код с репозиторием и CI (Slither, Foundry, coverage).
  • Развёрнутая версия контракта с verify на блокчейн-эксплорере.
  • Результаты аудита (внутреннего и внешнего по запросу).
  • Доступы к мониторингу и управлению (Gnosis Safe).
  • Гарантия на код: фиксы критических багов в течение месяца после деплоя.
  • Консультация по интеграции с веб-интерфейсом (wagmi, RainbowKit).

Сроки ориентировочно

  • ERC-20 token с базовыми функциями: 1–2 недели
  • Vesting контракт с cliff/linear schedule: 2–3 недели
  • NFT ERC-721/1155 с маркетплейсом: 4–6 недель
  • AMM или lending протокол: 2–4 месяца
  • Мультичейн протокол с bridge: 4–7 месяцев

Аудит добавляет 3–6 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.