AZTEC – очередной L2-блокчейн? Или не совсем?

История Aztec — редкий случай, когда "блокчейн‑проект" на самом деле начинается с криптографии и инженерной дисциплины, а не с маркетинга. Это путь команды, которая сначала упёрлась в фундаментальную проблему публичных сетей (всё видно всем), затем — из нужд собственного протокола — создала один из самых влиятельных доказательных механизмов десятилетия (PLONK), а после этого несколько раз смело выбрасывала "почти готовое" и строила заново, чтобы довести идею до логического конца: приватность должна быть не надстройкой, а нормой исполнения и состояния.

Ниже — подробная, выстроенная по времени история: от юридического и инженерного "нуля" в 2017‑м, через первые продукты zk.money и Aztec Connect, разворот в сторону Noir и новой архитектуры, до TGE и первых листингов $AZTEC в феврале 2026 года.

❗️Токен уже торгуется на: BYBIT (бонус до $30k)

1. В чём была ставка Aztec: приватность не как "миксер", а как слой вычислений.

К 2026 году почти каждый, кто хоть раз трогал Ethereum, знает главный факт: публичность в блокчейне тотальна. Даже если адрес псевдонимный, граф транзакций, суммы, контрагенты, связи между кошельками и поведение пользователей — открытая книга для аналитики, MEV‑ботов и любого, у кого есть терпение и графовая БД.

Большинство ZK‑роллапов (zkSync, Starknet, Polygon zk‑решения и др.) используют zero‑knowledge в первую очередь для масштабирования: доказать корректность перехода состояния компактным proof и "свернуть" вычисления в L1. Но сами транзакции обычно остаются наблюдаемыми: данные "внутри" всё равно доступны как минимум на уровне calldata/событий, а state‑переходы публичны. Иными словами, ZK‑доказательство в этих системах — инструмент компрессии, а не сокрытия.

Aztec изначально ставил на другое: ZK не только для доказательства корректности, но и для сокрытия данных и логики, чтобы приватность распространялась на состояние (что хранит контракт/кошелёк), транзакции (кто/кому/сколько) и исполнение (как именно вычисляется результат, если это нужно скрыть).

Это сразу делает задачу кратно сложнее: приватность на уровне денег (как у классических shielded‑переводов) — одно, приватность на уровне "программы" — совсем другое. Для сравнения: Tornado Cash — это миксер с фиксированными номиналами (0.1, 1, 10 или 100 ETH), который просто разрывает связь между адресом отправки и получения. Он не поддерживает произвольные суммы, не позволяет взаимодействовать с DeFi и не даёт писать программируемую логику. Zcash и другие privacy‑коины, как выразился сам Zac Williamson, "похожи на Bitcoin — возможности определены создателями и зафиксированы". Aztec же строил полноценную среду зашифрованного исполнения, где разработчики сами создают приватные приложения.

2. 2017: юридические “корни” и ранние связи с экосистемой Ethereum

Юридическая точка отсчёта хорошо фиксируется: компания Spilsbury Holdings Limited (Англия и Уэльс) зарегистрирована 4 декабря 2017 года, номер компании 11093783. В регистрационных данных видно, что директором при создании был Zac Williamson, а также Thomas Walton‑Pocock (позже он перестал быть директором в 2021). Важная ранняя деталь: в директора в 2018 году входил Joseph Lubin (ConsenSys), а в 2020‑м директором стал Joe Andrews — это довольно прямой сигнал о ранней стыковке проекта с Ethereum‑экосистемой и её институциональными игроками.

Сюжетно это выглядит так: команда в Лондоне начинает строить “что‑то на Ethereum”, быстро сталкивается с тем, что публичность — блокер для серьёзных кейсов, и начинает системно копать приватность.

3. 2018–2020: первая итерация Aztec как приватность поверх Ethereum

Первые версии Aztec решали “узкую” задачу: конфиденциальные переводы активов на Ethereum с помощью ZK‑доказательств и шифрования. Это ещё не был “полноценный приватный L2” в современном понимании, а скорее протокол/контракты, позволяющие работать с приватными представлениями активов.

Ключевые выводы из этой эпохи (которые потом будут повторяться как мотив):

• приватность без программируемости — полезно, но ограничено;
• стоимость on‑chain верификации и proving‑затраты легко убивают UX;
• без более универсальной и “девелоперской” ZK‑системы протокол становится хрупким и медленным в развитии.

Именно здесь у Aztec возникает та самая “продуктовая боль”, которая приводит к PLONK.

4. 2019: PLONK — когда протокол заставил изобрести новый стандарт доказательств

PLONK вошёл в историю ZK‑индустрии не как абстрактная академическая штука, а как ответ на практическую проблему: слишком дорого и неудобно жить в мире, где под каждую схему нужен отдельный trusted setup, а изменения в логике превращаются в месяцы церемоний и аудитов.

Главная идея, которая сделала PLONK “промышленным”:
универсальная и обновляемая настройка (universal updatable setup), пригодная для множества схем. Это радикально упрощает жизнь протоколам и разработчикам: обновлять и расширять систему можно без постоянного “перезапуска доверия”.

Aztec прямо в своей истории подчёркивает, что PLONK стал настолько влиятельным, что появился целый класс proving‑систем “PLONKish”, а сам PLONK был подхвачен и расширен другими командами (включая крупные ZK‑проекты). Для Aztec это было не просто “мы написали статью”, а поворотный момент: появилась техническая база, на которой можно думать о программируемой приватности, а не только о “приватных переводах”.

5. 2021–2022: zk.money и Aztec Connect — приватность как работающий продукт

Следующий этап — попытка доказать, что приватность может быть массовым UX, а не инструментом для узкой аудитории.

zk.money (2021)
Это был приватный платежный слой на Ethereum с ZK‑роллап‑механикой: пользователи “экранировали” активы и совершали приватные операции внутри системы. С точки зрения архитектурного мышления Aztec это был важный эксперимент: команда проверяла, можно ли сделать приватность “на фоне”, чтобы пользователь ощущал её как норму.

Aztec Connect (2022)
Это уже попытка подключить приватность к “настоящей экономике Ethereum”: DeFi, обмены, доходность, интеграции. Механически Connect строился вокруг идеи мостовых контрактов (bridge contracts) — сравнительно компактных Solidity‑интерфейсов, которые связывают L1‑протоколы с приватным роллап‑слоем, и вокруг специальных схем “депозит/вывод” для внешних взаимодействий.

В ретроспективе Aztec формулирует результат так: спрос был, на пике ранние роллапы переваливали за $20 млн TVL, но архитектура упёрлась в децентрализацию и компоновку программ.

6. 2023: закрытие Aztec Connect и zk.money — сознательный разрыв с “progressive decentralization”

13 марта 2023 года команда публично объявляет о сворачивании Aztec Connect: сеть перестаёт принимать депозиты (в официальных материалах фигурирует дата 21 марта 2023 как момент остановки депозитов для инстанса, который оперировал Aztec), а вывод средств продолжает поддерживаться ограниченное время, после чего Aztec прекращает запуск собственного секвенсора (в документации указывается срок до конца марта 2024).

Ключевой момент — почему. В интервью и публикациях команда подчёркивала: решение было не “из‑за регуляторов”, а из‑за:

• невозможности довести ту архитектуру до полностью децентрализованной модели без огромной перестройки;
• высокой операционной стоимости поддержания централизованных компонентов;
• ограничений композиции и общего состояния, которое мешало бы масштабируемой экосистеме приватных программ.

Этот момент важен для понимания Aztec: проект предпочёл сжечь мосты и строить заново вместо того, чтобы “дотянуть как‑нибудь”, а затем обещать децентрализацию “позже”.

7. Noir и Barretenberg: когда “инструменты” переживают сам протокол

Параллельно с продуктами команда развивала то, что со временем стало самостоятельным вкладом в отрасль.

Noir
Noir — язык (Rust‑подобный по стилю), созданный для того, чтобы писать ZK‑программы без необходимости быть криптографом. Его ключевая инженерная идея — компиляция в промежуточное представление ACIR, которое затем может быть “скормлено” разным proving‑бэкендам. Это делает Noir бэкенд‑агностичным: разработчик пишет программу один раз, а proving‑систему можно менять на уровне инфраструктуры.

Barretenberg (bb)
Barretenberg — высокопроизводительная C++ библиотека, которую Aztec использует как криптографический “двигатель”: реализация proving‑систем на базе PLONK‑семейства и оптимизированная работа с кривыми (в описании проекта прямо указана bn128). Важная практическая деталь: этот стек задуман так, чтобы быть совместимым с Noir и применимым не только внутри Aztec, но и шире.

Если смотреть стратегически, Noir + Barretenberg — это “инвестиция в индустриализацию ZK”: сделать ZK‑разработку похожей на обычную разработку.

8. Новая Aztec Network: программируемая приватность как архитектура (а не “надстройка”)

Aztec в документации прямо формулирует базовую модель:

• Aztec — privacy‑first Layer 2 на Ethereum.
• Он поддерживает и приватное, и публичное состояние, а также и приватное, и публичное исполнение.
• Он не EVM‑совместим: это отдельная виртуальная машина и отдельная модель исполнения.

Дальше начинается “мясо”, которое отличает Aztec от большинства L2.

8.1. Две модели состояния: public‑аккаунты + private‑UTXO (notes)
В Aztec приватное состояние устроено как UTXO‑подобные сущности, называемые notes:

• notes кладутся в append‑only дерево (UTXO‑дерево),
• когда note “тратится”, создаётся nullifier — маркер, который доказывает, что note больше нельзя использовать, не раскрывая саму note,
• для nullifiers есть отдельное дерево.

Публичное состояние хранится отдельно и концептуально ближе к привычному “аккаунтному” миру.

В глоссарии Aztec отдельно указывает, что узлы поддерживают пять деревьев состояния (включая деревья для note hash, nullifier, публичного состояния и сообщений между L1 и L2).

8.2. Приватное исполнение уходит на клиент: PXE
Одна из самых нетривиальных инженерных идей Aztec — Private Execution Environment (PXE). Это клиентская библиотека (TypeScript), которая:

• выполняет приватные операции на стороне пользователя,
• генерирует доказательства приватного исполнения,
• хранит и управляет секретами/ключами/notes локально,
• отправляет в сеть только то, что нужно для публичной части и верификации.

Критически важно: приватные входные данные не покидают PXE. Это сильно меняет модель угроз: сеть не должна “видеть” ваш приватный инпут, потому что он физически не отправляется.

При этом документация честно фиксирует компромисс: когда PXE запрашивает у ноды данные о world state (например, проверку существования nullifier), нода может понять, какие данные интересуют пользователя. Решение — запуск собственной ноды, но это, разумеется, UX‑челлендж.

8.3. Публичное исполнение на узлах и сборка блоков
Публичные функции исполняются на стороне сети (на узлах), а затем транзакции “сворачиваются” в блоки, которые отправляются в Ethereum для проверки корректности перехода состояния.

В документации это описано как цепочка:

1. пользователь взаимодействует через SDK (Aztec.js),
2. приватные функции исполняются в PXE,
3. proof и обновления деревьев идут в публичную VM на узле,
4. публичные функции исполняются там же,
5. блок и proof корректности уходят в Ethereum.

8.4. “Каждый кошелёк — смарт‑контракт”
В материалах Aztec для токен‑холдеров явно прописано: на Aztec каждый кошелёк — смарт‑контракт, а значит правила авторизации и управления могут быть гибкими (по сути, account abstraction “встроена по природе системы”). Это важно для приватности: управление ключами, просмотром данных и авторизацией можно строить программно.

9. Ignition Chain (ноябрь 2025): редкий ход — децентрализация раньше продукта

В ноябре 2025 Aztec запустил Ignition Chain — мейннет‑фазу, где ключевой целью было доказать устойчивость консенсус‑слоя до развёртывания полноценной среды исполнения приватных смарт‑контрактов.

В официальном апдейте (30 января 2026) проект фиксирует следующие факты о сети:

• к сети присоединились 185+ операторов на 5 континентах,
• работает 3 400+ sequencers,
• в permissionless prover‑сети — 50+ provers,
• сеть дошла до 75k блоков без даунтайма,
• attestation rate держится на уровне 99%+,
• в качестве топ‑перформеров по инфраструктуре упоминаются P2P.org, Nethermind, ZKV.

Это сильно нетипичная траектория для L2: большинство запускают execution и держат централизованный sequencer, а затем (иногда) пытаются “додецентрализовать”. Aztec сделал наоборот: сначала сеть, затем “продукт”.

Награды и требования к узлу
Ignition Chain уже раздаёт блок‑реварды:

• распределение идёт каждую эпоху (32 блока),
• 70% — секвенсорам, 30% — проверам,
• к началу 2026 распределено 30M+ $AZTEC как rewards.

Требования для запуска узла секвенсора описаны довольно “земные”:

• CPU: 8 cores
• RAM: 16 GB
• Storage: 1 TB NVMe SSD
• Bandwidth: 25 Mbps

Важное ограничение для экономики участия: фракционный стейкинг пока не поддерживается, а порог для стейка/делегирования указан как 200 000 $AZTEC.

10. Токен $AZTEC: почему запуск был устроен именно так

Если коротко: Aztec пытался сделать токен‑дистрибуцию крипто‑нативной, максимально onchain, с реальным price discovery и без “классического” сценария, где цена формируется на тонкой ликвидности и с преимуществом у инсайдеров.

10.1. Анонс тикера и старт аукциона
Пост “The ticker is $AZTEC” опубликован 13 ноября 2025. В нём зафиксированы ключевые параметры:

• регистрация и старт bidding для ранних участников начались 13 ноября (с указанием времени старта 3 pm CET),
• публичная часть аукциона шла 2–6 декабря 2025,
• стартовая “планка” цены опиралась на $350 млн FDV, а также отдельно подчёркивалось, что это “скидка” относительно implied valuations по equity‑раундам,
• были введены per‑user caps, чтобы у сообщества были реальные шансы на распределение,
• eligibility подтверждался через soul‑bound NFT,
• комплаенс/санкционные проверки делались с помощью ZK‑подхода: Noir‑схемы ZKPassport встроены в контрактную логику продажи.

10.2. Почему именно Uniswap CCA (Continuous Clearing Auction)
Aztec провёл продажу через механизм CCA, разработанный вместе с Uniswap Labs, и это стало первой крупной демонстрацией CCA в бою.

Смысл CCA (в практическом, не “белопейперном” изложении):

• аукцион идёт onchain и “очищается” в процессе, а не в один момент,
• уменьшается смысл “снайпинга” и гонки за последней секундой,
• участники видят формирование цены и итоговую очистку прозрачно.

Uniswap в разборе результатов подчёркивает масштаб “массового доступа”:

• около 17 000 участников прошли верификацию и сделали ставки,
• 96% внесли менее $10 000,
• средний вклад был около $4 000,
• верификация участников прошла по 191 стране.

10.3. Итог продажи: 19 476 ETH и 16.7k участников
В официальном гайде для холдеров Aztec фиксирует результат:

• участие приняли 16.7k+ человек,
• собрано 19 476 ETH,
• примерно 50% капитала пришло от сообщества пользователей/операторов/создателей.

Юридический консультант Latham & Watkins отдельно подтверждал ту же цифру и приводил оценку в долларах: 19 476 ETH ≈ $60.8 млн (по курсу на дату публикации).

10.4. Token Vault и “заморозка до голосования”
После аукциона токены не становятся мгновенно трансферабельными: участники выводили их в Token Vault (смарт‑контракт на Ethereum), который:

• хранит токены,
• делает их нетрансферабельными до TGE,
• позволяет стейкать/делегировать и участвовать в управлении ещё до листинга,
• после TGE позволяет вывести токены на обычный адрес.

10.5. TGE как onchain‑решение: кворумы, сроки, фолбэк‑дата
Aztec формализовал “разморозку” через governance:

• голосование длится 7 дней,
• нужен минимум 100 000 000 $AZTEC участия,
• проходит при 2/3 голосов “за”,
• после успешного голосования есть 7‑дневная задержка исполнения,
• если голосование не проходит, токены остаются заблокированными до фолбэк‑даты 13 ноября 2026.

Важная деталь токен‑политики: команда, фонд и инвесторы не участвуют в стейкинге и управлении в течение 12 месяцев, а их токены остаются залоченными как минимум год и затем разблокируются постепенно в течение последующих двух лет. То есть governance на старте действительно ограничен сообществом продаж и ранними участниками сети.

11. TGE и листинги (февраль 2026): момент, когда токен становится “живым”

11.1. Что происходит в TGE технически и экономически
В логике Aztec TGE — это момент, когда:

1. токены участников токенсейла становятся полностью трансферабельными,
2. становится активной торговля через AZTEC/ETH пул на Uniswap v4,
3. накопленные блок‑реварды становятся трансферабельными.

Aztec заранее указал размер пула ликвидности на Uniswap v4: 273 000 000 $AZTEC плюс соответствующее количество ETH по финальной clearing price аукциона.

11.2. Биржевые листинги: что подтверждено официальными объявлениями

На 11–12 февраля 2026 в публичных объявлениях бирж зафиксированы следующие события:

• Binance Futures
  Запуск AZTECUSDT perpetual в режиме pre‑market: 11 февраля 2026, 04:30 UTC, плечо до 5x.
• Bybit (Spot) - регистрация с бонусами
  Листинг AZTEC на споте: 12 февраля 2026, 07:00 UTC (депозиты открывались 11 февраля; вывод — 13 февраля).
• KuCoin (Spot)
  Пара AZTEC/USDT: call auction 06:00–07:00 UTC 12 февраля 2026, старт торгов 07:00 UTC, вывод 13 февраля 10:00 UTC.
• MEXC (Spot)
  Листинг в Innovation Zone: AZTEC/USDT — 12 февраля 2026, 07:00 UTC, AZTEC/USDC — 07:20 UTC, вывод 13 февраля 07:00 UTC.

Дополнительно: Kraken публично отображает AZTEC в разделе “Tokens launching soon / TGE day‑one access”, что обычно означает готовность дать доступ к торгам/получению токена в рамках их программы листинга.

12. Почему эта история важна: Aztec как “приватная вычислительная среда”, а не просто очередной L2

Если смотреть на Aztec без эмоций, то проект на самом деле строит три вещи одновременно:

1. Криптографический фундамент
   PLONK и производные — это не “маркетинговый актив”, а реальный вклад в то, как ZK‑системы применяются в индустрии.
2. Индустриальный девелоперский слой
   Noir и ACIR — попытка сделать ZK‑разработку технологией общего назначения, где инженеру не нужно каждый раз изобретать математику.
3. Сеть с другой моделью приватности
   Ключевое отличие — перенос приватного исполнения на клиент (PXE) и гибридное состояние (notes/nullifiers + public state), плюс ставка на децентрализацию секвенсоров и проверов раньше, чем на “идеальный UX”.

И вот тут появляется честная развилка, которая определит восприятие Aztec уже после листинга:
Ignition Chain к началу 2026 доказал живучесть консенсуса и распределённого участия, но полноценная среда исполнения приватных смарт‑контрактов — это та веха, которая должна превратить инфраструктуру в экосистему приложений. Без неё токен остаётся в основном “инфраструктурным деривативом ожиданий”.

Итоги

Aztec за 8 лет прошёл путь, который редко удаётся “в одном проекте”:

• старт в Лондоне с юридической фиксацией в 2017‑м и ранними связями с Ethereum‑экосистемой;
• первая попытка приватности поверх Ethereum;
• создание PLONK, который стал отраслевым стандартом и “породил” целое семейство proving‑подходов;
• работающие продукты zk.money и Aztec Connect, которые доказали спрос, но упёрлись в архитектурные ограничения децентрализации;
• сознательный “reset” в 2023 и ставка на новую сеть;
• запуск Ignition Chain в ноябре 2025 как децентрализованного консенсус‑слоя;
• community‑first токенсейл через Uniswap CCA (19 476 ETH, 16.7k участников) и governance‑управляемый unlock;
• TGE и первые листинги 11–12 февраля 2026 (DEX + крупные CEX/деривативные площадки).

Самая точная формулировка статуса на февраль 2026 такая: Aztec уже запустил сеть и экономику участия, а рынок получил токен; теперь решающим станет запуск полноценного execution‑слоя и появление приватных приложений, которые заставят приватность работать “в быту”, а не только в документации. В мире, где публичность блокчейнов стала инструментом конкурентной разведки и риском для пользователей, ставка Aztec выглядит не романтической, а прагматичной: приватность — это базовая гигиена вычислений.

❗️Почему Aztec нельзя сравнивать с другими ZK‑роллапами

Когда Aztec ставят в один ряд с zkSync, Starknet, Scroll или Polygon zkEVM — это примерно как сравнивать бронированный инкассаторский фургон со спортивным болидом на том основании, что оба ездят по дорогам. Технически — да, Aztec и перечисленные проекты используют zero‑knowledge доказательства и живут поверх Ethereum. Но на этом сходства заканчиваются. Aztec — это не "ещё один ZK‑роллап, только с приватностью сверху". Это архитектурно другая машина, построенная с нуля под другую задачу, с другой моделью состояния, другим языком программирования, другим конвейером доказательств и принципиально другим распределением работы между пользователем и сетью.

Ниже — разбор по пунктам: что именно устроено иначе, почему это важно, и почему "просто добавить приватность" к существующему ZK‑роллапу невозможно без переписывания всего с нуля.

Почему «ZK‑роллап» почти никогда не означает «приватный роллап»

Начнём с главного парадокса. В термине "zero‑knowledge" изначально заложены два свойства: succinctness (компактность — можно сжать большое вычисление в маленькое доказательство) и собственно zero‑knowledge (нулевое разглашение — верификатор убеждается в корректности, не узнавая ничего о входных данных). Так вот: практически все "ZK"‑роллапы используют только первое свойство и полностью игнорируют второе.

Вот как работает типичный ZK‑роллап (zkSync, Starknet, Scroll, Linea, Polygon zkEVM): пользователь отправляет транзакцию открытым текстом → централизованный секвенсор получает все данные (адреса, суммы, параметры вызовов) → секвенсор исполняет транзакцию в своей виртуальной машине → пруверы генерируют компактное доказательство корректности → это доказательство и state diffs публикуются на Ethereum. На каждом этапе все данные транзакции видны всем участникам конвейера. Секвенсор знает всё. Пруверы знают всё. Любой, кто читает Ethereum, может восстановить все балансы и историю.

Иными словами, "ZK" в этих системах — инструмент компрессии, а не сокрытия. Starknet даже прямо признаёт в документации и называют это validity proofs: цель — доказать корректность перехода состояния, а не скрыть транзакционные данные; приватность там не закладывается как свойство протокола.

Aztec инвертирует эту модель. Приватные данные транзакции никогда не покидают устройство пользователя. Секвенсор получает доказательства + публичные криптографические следы (commitments/nullifiers) и зашифрованные логи; приватные значения и приватная логика остаются на устройстве пользователя — секвенсор не знает, кто отправил транзакцию, кому, сколько и какая логика контракта исполнялась.

Что делает Aztec иначе

Чтобы понять, почему Aztec — это фундаментально другая архитектура, полезно проследить путь одной приватной транзакции от начала до конца.

Шаг 1: Исполнение на устройстве пользователя (PXE). PXE (Private Execution Environment, произносится "пикси") — это клиентская библиотека, встроенная в кошелёк пользователя. PXE хранит приватные ключи, зашифрованные ноты (об этом ниже) и локальную базу состояния. Допустим, Алиса хочет отправить 10 DAI Бобу. PXE выполняет функцию transfer локально на устройстве Алисы: потребляет существующие ноты Алисы, создаёт новые зашифрованные ноты — одну для Боба (10 DAI) и сдачу для Алисы — и генерирует ZK‑доказательство того, что всё выполнено корректно. Ключевой момент: исполнение приватного кода и генерация доказательства происходят на ноутбуке или телефоне пользователя, а не на сервере. Текущие замеры: ~2.5 секунды нативно на ноутбуке, ~5 секунд на мобильном, ~25 секунд в браузере, потребление ~1.3 ГБ RAM.

Для сравнения: в zkSync или Starknet пользователь просто отправляет подписанную транзакцию открытым текстом, а секвенсор делает всю работу.

Шаг 2: Отправка в сеть. После генерации доказательства PXE формирует объект транзакции, содержащий: хеши нот (коммитменты), нуллификаторы (об этом ниже), зашифрованные логи и, если нужно, поставленные в очередь вызовы публичных функций. Этот объект отправляется секвенсору. Секвенсор проверяет валидность ZK‑доказательства, но не может извлечь из него никаких данных — ни адресов, ни сумм, ни логики.

Шаг 3: Публичное исполнение (если нужно). Если транзакция включает публичную часть (например, обновление состояния AMM‑пула), секвенсор выполняет её в Aztec Virtual Machine (AVM) — по сути, обычная прозрачная виртуальная машина, похожая на EVM. Важное правило: приватные функции могут вызывать публичные, но не наоборот. Это архитектурное ограничение предотвращает утечку приватных данных через публичный контекст.

Шаг 4: Агрегация и отправка на Ethereum. Сеть пруверов агрегирует индивидуальные доказательства транзакций в древовидную иерархию роллап‑доказательств: TX Base → TX Merge → Block Root → Block Merge → Checkpoint → Root Rollup. Финальное доказательство эпохи отправляется в верифицирующий контракт на Ethereum.

Гибридная модель состояния: UTXO + аккаунты в одном контракте

Это, пожалуй, самая необычная архитектурная деталь Aztec — и именно она делает невозможным "прикрутить приватность" к стандартному роллапу.

Приватное состояние — UTXO‑модель (как в Bitcoin и Zcash). Данные хранятся как зашифрованные "ноты". Каждая нота содержит значение, информацию о владельце и метаданные. В блокчейне хранится только хеш ноты (коммитмент) в append‑only дереве Меркла (note hash tree). Чтобы "потратить" или обновить приватное состояние, пользователь создаёт нуллификатор — криптографический отпечаток, производный от данных ноты и секретного ключа владельца — и публикует его в отдельном дереве (nullifier tree). Критически важно: нуллификатор не раскрывает, какая именно нота была потреблена, что предотвращает связывание транзакций.

Аналогия с физическим миром: это как наличные. Вы платите купюрой в $5, "уничтожаете" её (нуллификатор) и получаете новую ноту на $3 (продавцу) и ноту на $2 (сдача себе). Никто не видит связи между старой и новыми купюрами.

Публичное состояние — аккаунтная модель (как в Ethereum). Sparse Merkle tree хранит пары ключ‑значение, которые можно напрямую читать и модифицировать. Публичные функции работают с этим состоянием прозрачно, как обычный Solidity‑storage.

Один и тот же смарт-контракт на Aztec может содержать и приватные, и публичные функции, работающие с разными типами состояния. Это и есть "программируемая приватность": разработчик сам решает, какие данные скрыты, а какие открыты.

Шифрование нот использует эллиптическую криптографию Диффи‑Хеллмана (ECDH) на кривой Grumpkin. Отправитель выводит эфемерный симметричный ключ из публичного ключа получателя (Incoming Viewing Key), шифрует ноту и публикует зашифрованный лог on‑chain. Расшифровать может только получатель. Все ключи изолированы по приложениям – передача viewing key для одного приложения не раскрывает активность в других. Это позволяет точечный комплаенс: пользователь может дать аудитору доступ к конкретному контракту, не раскрывая всю финансовую историю.

Noir: язык, который пришлось создать с нуля

Aztec не может использовать Solidity — не из‑за каприза, а потому что EVM‑совместимость и приватность взаимоисключающи на архитектурном уровне. Модель исполнения EVM предполагает, что вся память, storage и calldata доступны всем. Приватные вычисления требуют, чтобы код компилировался в ZK‑схемы (circuits), где все значения по умолчанию скрыты.

Noir — это domain‑specific язык с синтаксисом, вдохновлённым Rust, созданный для написания zero‑knowledge программ. Ключевое отличие от Solidity или Cairo: в Noir все значения приватны по умолчанию, а чтобы сделать что‑то публичным, нужно явно пометить это ключевым словом pub. Компилятор транслирует Noir‑код в ACIR (Abstract Circuit Intermediate Representation) — промежуточный формат, независимый от конкретного бэкенда доказательств: Barretenberg, Halo2, Plonky2, Groth16 и др. Эта развязка от конкретной proof‑системы уникальна среди ZK‑языков.

Каждая приватная функция компилируется в статическую схему с фиксированным числом гейтов — а не в трассу исполнения универсальной виртуальной машины. Именно поэтому генерация доказательств на клиенте возможна: статические схемы кратно меньше, чем схемы, симулирующие целую VM.

В бенчмарках Noir/UltraHonk часто выигрывает в proving time на тяжёлых схемах (вплоть до порядка), но цифры зависят от версии бэкенда и реализации примитива. По сравнению с Cairo (Starknet), Noir заточен под одиночные приватные доказательства, тогда как Cairo оптимизирован под батчевую пропускную способность публичных вычислений. По сравнению с Solidity — это просто разные вселенные: Solidity не имеет понятия ZK‑схем, приватного состояния или нуллификаторов.

Фреймворк Aztec.nr надстраивает поверх Noir абстракции смарт‑контрактов: хранилище, вызовы между контрактами, события, оракулы. Один контракт может содержать и #[external("public")] функции (исполняются секвенсором), и приватные (исполняются на устройстве пользователя).

Сводная таблица: Aztec vs. остальные ZK‑роллапы

Почему “прикрутить потом” = переписать протокол

Это, возможно, самый важный технический тезис для понимания уникальности Aztec: приватность невозможно "прикрутить" к публичному ZK‑роллапу без полной перестройки.

Это не вопрос инженерных ресурсов или времени — это фундаментальная архитектурная несовместимость на каждом уровне стека.

Аккаунтная модель EVM хранит состояние в публичном дереве, где каждое обновление раскрывает, какие листья изменились, их старые и новые значения. Приватность требует зашифрованной UTXO‑модели с append‑only деревьями нот и нуллификаторов — структур данных, которых просто не существует в EVM‑роллапах.

Генерация доказательств на клиенте обязательна, потому что любой сервер, исполняющий транзакции, видит все данные — а значит, приватность уничтожена по определению. Это означает, что весь конвейер — кошелёк, генерация доказательств, взаимодействие с секвенсором, управление состоянием — нужно проектировать заново.

Даже proof‑система другая. Приватные функции Aztec компилируются в статические схемы (одна схема на функцию), а не в VM‑схемы (одна универсальная схема, симулирующая все опкоды). Это не выбор, а необходимость: VM‑схемы слишком велики для генерации на пользовательском устройстве. Proof‑система Honk с ClientIVC‑фолдингом через ProtoGalaxy была специально разработана под эту двойную клиент-серверную модель.

Добавить приватность к zkSync или Starknet означало бы заменить модель состояния, среду исполнения, конвейер генерации доказательств, язык программирования, инфраструктуру кошельков и слой доступности данных — то есть построить совершенно новую систему. Что Aztec и делал восемь лет, потратив более $119 млн.

Цена приватности: на какие компромиссы идёт Aztec

Приватность — не бесплатна, и Aztec честно об этом говорит. Zac Williamson прямо заявлял: "Полностью приватная транзакция содержит больше данных, потому что всё зашифровано. Нас это устраивает. Уникальное ценностное предложение Aztec — не масштабирование."

Приватные транзакции требуют вдвое больше обновлений состояния (записи и в note hash tree, и в nullifier tree) и в 4–8 раз больший объём данных по сравнению со стандартной роллап‑транзакцией. Композируемость ограничена строгим однонаправленным потоком: приватное → публичное, но не наоборот. "Nullify‑on‑read" паттерн означает, что любая нота, к которой обращаются в приватном исполнении, должна быть потреблена и пересоздана — это может вызывать гонки состояния, если две транзакции пытаются потребить одну и ту же ноту. Нет EVM‑совместимости и поддержки Solidity — намеренно, а не по ограничению.

Как правильно думать об Aztec

Корректная рамка — не "Aztec — это лучший ZK‑роллап", а "Aztec — это зашифрованный слой исполнения", который использует роллап‑механику для расчётов на Ethereum. Его ближайший концептуальный аналог — не zkSync, а скорее Aleo или другие платформы приватных смарт‑контрактов, где основное ценностное предложение — конфиденциальность, а не пропускная способность.

Компромиссы реальны: медленнее генерация доказательств, тяжелее данные, нет EVM‑совместимости, круче кривая обучения для разработчиков. Но это неизбежная цена за то, что другие ZK‑роллапы архитектурно не способны стать — даже если захотят — без того, чтобы начать всё с чистого листа.

❗️ВСЕ СТАТЬИ В TELEGRAM: WEB3RU

Топ‑10 источников (для самостоятельной проверки)

1) Aztec Blog — History of Aztec: Pioneering Privacy in Web3
https://aztec.network/blog/history-of-aztec-pioneering-privacy-in-web3

2) Aztec Blog — The ticker is $AZTEC
https://aztec.network/blog/the-ticker-is-aztec

3) Aztec Blog — $AZTEC TGE: Next Steps For Holders
https://aztec.network/blog/aztec-tge-next-steps

4) Aztec Blog — The $AZTEC TGE Vote: What You Need to Know
https://aztec.network/blog/the-aztec-tge-vote-what-you-need-to-know

5) Aztec Blog — Aztec Ignition Chain Update (статистика сети, rewards, требования к ноде)
https://aztec.network/blog

6) Aztec Docs — Aztec Overview (архитектура private/public state & execution)
https://docs.aztec.network/developers/overview

7) Aztec Docs — Private Execution Environment (PXE)
https://docs.aztec.network/developers/docs/foundational-topics/pxe

8) UK Companies House — Spilsbury Holdings Limited (11093783)
https://find-and-update.company-information.service.gov.uk/company/11093783

9) Uniswap Blog — How Aztec Raised $59M With 17,000 Bidders Using Uniswap’s CCA
https://blog.uniswap.org/aztec-cca

10) Официальные объявления бирж (листинги/контракты):
- Binance Futures: https://www.binance.com/en/support/announcement/detail/2bf6526552a8464da4420fd0d5a412a9
- Bybit Spot: https://announcements.bybit.com/en/article/bybit-to-list-aztec-aztec-on-spot-blt8026f80582322ffb/
- KuCoin Spot: https://www.kucoin.com/announcement/en-aztec-aztec-gets-listed-on-kucoin-world-premiere
- MEXC Spot: https://www.mexc.com/announcements/article/first-in-market-17827791533641