zkSync Era — это сеть уровня 2 (Layer-2) для Ethereum, использующая модель ZK-rollup: транзакции исполняются на L2, а в L1 публикуются компактные данные и криптографические доказательства корректности (zero-knowledge proofs).
Страница crypto:zksync описывает экосистему и токен ZK; здесь фокус — на технической архитектуре zkSync Era: слоях протокола, жизненном цикле транзакции, роли секвенсера и безопасности.
zkSync Era как ZK-rollup над Ethereum
По архитектуре zkSync Era — это ZK-роллап:
- состояние L2 хранится в формате, позволяющем компактно «сжать» множество балансов и записей в один корневой хэш (Merkle-дерево и его обобщения);
- для каждого батча транзакций вычисляется validity proof — zk-доказательство корректности перехода состояния;
- доказательство и коммитмент состояния публикуются в контракты на Ethereum (L1), где проходят проверку;
- до проверки доказательства пользователи уже получают быстрые подтверждения на L2, но окончательная финальность привязана к L1.
По сравнению с optimistic-роллапами это даёт:
- более предсказуемую финальность (без challenge-периода),
- жёсткое криптографическое ограничение на произвольные изменения состояния,
- но требует сложной инфраструктуры prover’ов и продуманного режима доступности данных.
Слои архитектуры zkSync Era
Удобно рассматривать zkSync Era как набор уровней (слоёв), аналогично общей схеме Layer-2 и обзору роллапов на Ethereum.
1. Execution layer (исполнение на L2)
- EVM-совместимая среда (zkEVM), в которой выполняются смарт-контракты.
- Состояние L2 представлено деревом (Merkle/версия), корень которого публикуется в L1-контракты.
- Разработчик пишет контракты на Solidity и использует привычные EVM-инструменты.
2. Sequencer (упорядочивание транзакций)
- Секвенсер принимает транзакции от пользователей, формирует L2-блоки и батчи.
- Даёт пользователям «мгновенные» L2-подтверждения до публикации на L1.
- Является операционно критичной и пока во многом централизованной ролью: от его поведения зависит UX, приоритизация транзакций и возможная цензура.
3. Prover и ZK-доказательства
- Специализированные узлы (prover’ы) строят zk-доказательства того, что переход состояния из Sₙ в Sₙ₊₁ корректен.
- Доказательства проверяются в смарт-контрактах на Ethereum; только после этого новое состояние считается экономически финальным.
4. Data Availability (доступность данных)
- В классическом режиме ZK-роллапа существенная часть данных транзакций публикуется на L1 (calldata/блобы), чтобы любой мог восстановить состояние.
- Режим DA, степень компрессии и fallback-процедуры определяют компромисс между безопасностью, стоимостью и сложностью — см. Data Availability и модель рисков L2.
5. Settlement и мост L1↔L2
- Набор контрактов на Ethereum:
- принимают батчи и доказательства;
- хранят корни состояния L2;
- реализуют логику депозитов и выводов через канонический мост.
- Архитектурно мост zkSync вписывается в общую схему кросс-чейн мостов и несёт типичные риски мостов.
Жизненный цикл транзакции в zkSync Era
1. Формирование и подписание
- Пользователь формирует транзакцию в кошельке и подписывает её своей криптографической подписью.
- Для защиты от повторной отправки используется счётчик nonce.
2. Отправка секвенсеру и L2-подтверждение
- Транзакция отправляется секвенсеру.
- Секвенсер упорядочивает транзакции, включает их в блок L2 и возвращает пользователю быстрое подтверждение (soft finality).
3. Батчинг, доказательство и публикация на L1
- Через определённые интервалы блоки собираются в батч.
- Prover строит zk-доказательство корректности батча.
- Батч и доказательство отправляются в контракт роллапа на Ethereum и проходят проверку.
4. Финальная фиксация и вывод средств
- После успешной верификации доказательства новое состояние становится экономически окончательным.
- Вывод средств в L1 идёт через мост:
- запрос вывода фиксируется на L2,
- после подтверждения соответствующего батча и доказательства в L1 актив становится доступен на Ethereum.
Если секвенсер временно недоступен, пользователь теоретически должен сохранять возможность инициировать операции вывода через взаимодействие с L1-контрактами (форс-выход).
Account Abstraction по умолчанию
Одна из ключевых особенностей zkSync Era — account abstraction (AA) по умолчанию (account abstraction):
- каждый аккаунт — это смарт-контракт;
- логика верификации подписи и оплаты газа задаётся самим аккаунтом.
Это позволяет:
- реализовывать социальное восстановление, мультиподписи и кастомные политики безопасности;
- оплачивать газ не только ETH, но и другими токенами через paymaster’ов (если это поддерживает dApp);
- строить «невидимые» для пользователя кошельки внутри приложений.
При этом базовые принципы self-custody остаются в силе:
- для долгосрочного хранения разумно использовать аппаратный кошелёк и продуманное самостоятельное хранение,
- для частых операций — аккуратно настроенный горячий кошелёк с лимитами и разделением рисков.
Комиссии и экономическая модель
Комиссия транзакции в zkSync Era состоит из двух основных частей:
- L2-компонент
Оплата работы секвенсера и prover’ов: вычисления, хранение и внутренняя инфраструктура L2.
- L1-компонент (DA + проверка доказательств)
Затраты на публикацию сжатых данных и проверку доказательств в Ethereum:
- зависят от текущей цены газа в L1,
- особенно чувствительны к пикам нагрузки в сети Ethereum.
Для пользователя это проявляется как относительно низкая комиссия (обычно кратно меньше, чем в L1), но:
- при росте цен на газ в Ethereum дешевизна L2 тоже ухудшается;
- сложные взаимодействия с DeFi-контрактами стоят дороже, чем простые переводы.
Комиссии и единицы газа описаны в термине о комиссиях в Ethereum и L2 и gwei. Для платёжных сценариев часто используются USDC и USDT как расчётные токены, иногда совместно с paymaster-механиками.
Безопасность и доверительная модель zkSync
ZK-роллап снижает часть рисков традиционных L2, но не убирает их полностью.
На что важно смотреть:
- Секвенсер и центр управления.
Пока секвенсер централизован, возможны:
- задержки включения транзакций,
- MEV-приоритизация,
- временная цензура отдельных адресов или операций.
Подробнее — в термине про sequencer и обзоре рисков L2.
- Режим Data Availability.
Важно, какие данные публикуются на L1 и можно ли восстановить состояние L2 при отказе отдельных компонентов:
- on-chain DA (полный роллап) даёт максимальную независимость,
- гибридные/validium-режимы требуют доверия к внешним хранилищам данных.
- Мосты и вывод средств.
Канонический мост L1↔L2 и сторонние мосты — критические точки:
- ошибки в коде или конфигурации,
- компрометация ключей операторов,
- риски ликвидности при быстрых (ликвидити) мостах.
См. кросс-чейн мосты и риски мостов.
- Апгрейды протокола.
Важно, кто и как может:
- обновлять L1/L2-контракты,
- изменять параметры DA,
- управлять prover-инфраструктурой.
Здесь стоит ориентироваться на принципы credible neutrality: чем сложнее изменить правила «по звонку», тем устойчивее протокол.
ZK-rollup vs Optimistic-rollup (высокоуровнево)
Ключевые отличия ZK-роллапов (как zkSync) от optimistic-роллапов:
- Финальность.
- ZK-роллап: финальность после проверки доказательства на L1 (обычно предсказуемое время).
- Optimistic-роллап: финальность после окончания challenge-периода, если никто не оспорил состояние.
- Модель доверия.
- ZK: невозможно «нарисовать» произвольное состояние без корректного доказательства.
- Optimistic: корректность нужно опровергать через challenge-механику.
- Стоимость и масштабирование.
- ZK: дорогие вычисления prover’а, но хорошо масштабируются с ростом числа транзакций в батче.
- Optimistic: дешевле prover, но часть затрат уходит на хранение «сырых» данных и challenge-процессы.
- Совместимость с EVM.
Современные zkEVM (как в zkSync Era) стремятся к эквивалентности EVM, но нюансы опкодов и окружения нужно проверять в документации конкретного стека.
Практика: на что смотреть пользователям и разработчикам
Пользователям zkSync Era стоит:
- проверять сети и адреса перед переводами;
- планировать вывод на L1 с учётом времени и стоимости публикации батчей;
- не держать критические суммы только на L2, а распределять риск между L1 и несколькими L2 (см. обзор рисков L2);
- выбирать кошельки и AA-схемы с понятной моделью восстановления и безопасности.
Разработчикам на zkSync Era полезно:
- проектировать dApp с учётом DA-стоимости: оптимизировать объём данных, частоту транзакций и batched-операций;
- учитывать особенности account abstraction: paymaster’ы, кастомные политики подписей, лимиты и т.п.;
- продумывать сценарии деградации:
- временная недоступность секвенсера,
- рост комиссий на L1,
- экстренные выводы и остановка протокола;
- внимательно работать с оракулами (оракулы) и взаимодействием L1↔L2 для финансовых приложений (DeFi (технически)).
Частые вопросы (FAQ)
ZKsync Era — это отдельный блокчейн или «надстройка» над Ethereum? Это L2-сеть (роллап), которая живёт поверх Ethereum: состояние и доказательства фиксируются контрактами на L1. Общую рамку даёт обзор блокчейна и страницы Layer-1 / Layer-2.
Кто упорядочивает транзакции и может ли их цензурировать? Транзакции упорядочивает sequencer. Теоретически он может задерживать или временно игнорировать транзакции отдельных адресов, но не может окончательно изменить состояние без корректного zk-доказательства. Риски роли секвенсера описаны в соответствующем термине и модели рисков L2.
Почему комиссии иногда растут, хотя это L2? Потому что значимая часть комиссии — это публикация данных и верификация доказательств в Ethereum. Когда газ в L1 дорог, дорожает и «квант» публикации батчей.
Можно ли платить комиссию не ETH? Базовый газовый токен — ETH. Однако через AA и paymaster-механики отдельные dApp могут позволять платить комиссию другими токенами (например, USDC), перекладывая расходы на свою экономику.
Подходит ли zkSync Era для долгосрочного хранения активов? Технически zkSync наследует безопасность Ethereum, но остаются риски сложного кода, мостов, секвенсера и апгрейдов. Для крупных сумм обычно рекомендуют распределять активы между L1 и несколькими независимыми L2, опираясь на собственный профиль риска и горизонт инвестиций.