Привет, Хабр! Меня зовут Рома и я Solidity-разработчик. Вместе с коллегами мы создаем базу знаний по тематике блокчейна и web3-разработке. Меня заинтересовал блокчейн zkSync, т.к. он выделяется среди других Layer 2 решений, но сначала хочу немного рассказать, в чем суть проблемы масштабирования и какие есть особенности L2 в связке с ZK-Rollups. Эта статья будет интересна тем, кто хочет верхнеуровнево разобраться как работают такого рода решения и почему ZK-Rollups очень перспективное направление развития для блокчейнов в целом и Ethereum в частности.
zkSync — это блокчейн второго уровня (Layer 2 - L2) для Ethereum, разработанный для устранения проблем высоких комиссий и ограниченной пропускной способности (Transaction Per Second - TPS) в сети Ethereum. Эта платформа применяет технологию ZK-Rollups, которая использует доказательства с нулевым разглашением (Zero-Knowledge Proofs - ZKP) для объединения множества транзакций вне основной сети (L1). В L1 отправляются только криптографические доказательства верности транзакций и их сжатые данные, значительно повышая эффективность и снижая затраты.
Разработанный Matter Labs, zkSync заявлен как полностью открытый (100% open source) продукт, управляемый сообществом. Согласно Cryptorank, проект уже привлек внимание, собрав инвестиции на сумму 458 миллионов долларов. В долгосрочной перспективе Matter Labs стремится создать обширную экосистему. На текущий момент в эксплуатации находятся два блокчейна: zkSync Lite, который обрабатывает платежи в ETH и ERC20-токенах, и zkSync Era, поддерживающий полноценные смарт-контракты. Будущие планы включают запуск системы гиперчейнов (L3), обеспечивающих высокую безопасность. Цель Matter Labs – масштабировать технологию до уровня, который позволит привлечь следующий миллиард пользователей блокчейна.
Предпосылки
zkSync представляет собой новый подход к решению проблемы масштабирования, известной как трилемма блокчейна. Этот проект, как и другие решения второго уровня (L2), направлен на поиск баланса между безопасностью, масштабируемостью и децентрализацией в блокчейн-сетях.

Масштабируемость: Способность системы эффективно обрабатывать растущий объем транзакций или данных, не теряя в производительности и безопасности.
Безопасность в блокчейне: Обеспечение надежности и защиты данных от неавторизированного доступа, подделки или внесения изменений.
Децентрализация: Отсутствие централизованной контролирующей структуры. В децентрализованной системе управление и принятие решений демократично распределены среди всех участников сети.
Ethereum ориентирован на безопасность и децентрализацию, подчеркивая его статус как протокола peer-to-peer с нодами, распределенными по всему миру. Для актуальной информации о распределении нод можно обратиться к NodeWatch.

Для поддержания децентрализации в сети, каждый узел должен проверять все транзакции. Это делает сеть по своей природе менее быстрой. Кроме того, при высокой нагрузке на сеть, транзакции могут обходиться весьма дорого и требовать значительного времени на обработку.
Layer 2
Основной задачей для увеличения TPS сети Ethereum без повышения нагрузки на ноды изначально было внедрение Sharding в сочетании с переходом на PoS (Proof of Stake) консенсус. Это предполагало разделение валидаторов на подгруппы для обработки отдельных сегментов сети, тем самым уменьшая общую нагрузку и увеличивая пропускную способность. Однако, сообщество сместило свой фокус на Layer 2 решения, учитывая их бурное развитие.
Помимо идеи осуществить Sharding в Ethereum, появились другие решения проблемы масштабируемости, такие как:
Payment and State Channels
Sidechains
Plasma
Optimistic Rollup
А также технологии, основанные на доказательствах с нулевым разглашением (ZKP), включая:
Validium
zkRollup
Volition
Более подробную информацию можно найти здесь.
Хотя Sharding еще находится в разработке, уже совсем скоро (март 2024 г.) планируется хардфорк Dencun, который внедрит Proto-Danksharding. Этот промежуточный этап направлен на улучшение Layer 2 решений, делая хранение данных на L1 более экономичным. Таким образом, Proto-Danksharding обещает снизить стоимость транзакций на L2, являясь шагом к полноценному решению Sharding.
На первый взгляд, L2-блокчейны могут казаться схожими, так как их основная задача — увеличение количества транзакций за пределами L1, при этом делегируя L1 роль гаранта безопасности. Разработчики таких блокчейнов часто утверждают, что их решения являются самыми быстрыми, надежными и простыми. На деле, каждый подход к масштабированию имеет свои нюансы, и неизбежны компромиссы, касающиеся скорости транзакций, уровня безопасности или степени децентрализации. Нередко встречаются и полностью централизованные решения. Все эти аспекты возвращают нас к основным вопросам трилеммы блокчейна.
В этой статье, предложены ключевые критерии для оценки протоколов, используемых в Layer-2 решениях. Они включают в себя:
безопасность,
производительность и экономическую эффективность,
удобство использования,
дополнительные аспекты, такие как поддержка смарт-контрактов, совместимость с EVM-байткодом и опции конфиденциальности.
Важно! Статья написана Matter Labs и на мой взгляд некоторые вещи "притянуты за уши" в пользу zkRollup (т.к. тут явный конфликт интересов), но это не так важно, главное посмотреть какие вообще различия существуют между Layer-2 протоколами.
Это сравнительная таблица различных L2 решений из статьи:

Разберем ее содержимое по пунктам.
Безопасность
Предположение о работоспособности или "живучести" Layer-2. Предполагается, что для поддержания работоспособности Layer-2 некоторые участники всегда будут ончейн на уровне Layer-1, чтобы реагировать на возможные случаи мошенничества. Это либо валидаторы, которые стейкают какое-то количество средств (в таблице отмечено статусом "Bonded") на L1, либо третьи стороны которые обеспечивают безопасность протокола за вознаграждение. Как видно из таблицы у решений испльзующих ZKP (Validium и zkRollup) такой необходимости нет.
Проблема массового выхода. Проблема которая возникает если в целях безопасности нужно инициировать вывод средств всеми пользователями с L2 на L1 . Как видно из таблицы такая проблема есть только у протокола Plasma, подробнее об этом можно почитать тут.
Кастодиальность. Вопрос о том, могут ли валидаторы L2 временно заблокировать или конфисковать средства пользователей.
Экономические уязвимости. Включает в себя различные атаки на L2 валидаторов, включая подкуп майнеров L1, создание "теневых" DAO и другие экономически мотивированные атаки.
Криптография. Различие между стандартными и новыми криптографическими примитивами. Стандартные более изучены и потенциально уязвимы, в то время как новые (например, SNARK и STARK) обеспечивают большую надежность, но требуют от разработчиков дополнительных знаний и аудитов.
Производительность и экономика
С производительностью все просто. TPS (Transaction Per Second) показывает пропускную способность сети, в контексте масштабирования это самый главный параметр.
Экономические аспекты:
Эффективность капитала: Этот аспект особенно важен для платежных каналов (Payment Channels). В них необходимо замораживать средства, равные среднему объему операций в канале, что делает их менее эффективными в плане капиталовложений.
Транзакция на L1 для создания аккаунта на L2. Также камень в огород платежных каналов, т.к во всех остальных решениях аккаунт созданный в L1 работает в L2 по умолчанию.
Цена транзакции: Вместе с TPS, это один из важнейших факторов масштабируемости, определяющий экономическую привлекательность решения.
Удобство использования
Время вывода средств с L2 на L1: Этот период может варьироваться от нескольких минут до нескольких недель. Optimistic Rollups и Plasma особенно неудобны в этом плане, так как требуют более длительного времени для вывода средств.
Время до субъективной необратимости транзакции: Определяет, как быстро транзакция становится неотменяемой на L1 с точки зрения внешних наблюдателей. Например, в Optimistic Rollups для достижения необратимости на L1 требуется всего одно подтверждение на Ethereum, но полная окончательность транзакции занимает около недели.
Верифицируемость субъективной необратимости с помощью клиентского кода: Определяет, можно ли проверить время до субъективной необратимости легкими клиентами (браузеры/мобильные кошельки). Продолжая пример с Optimistic Rollups, для подтверждения окончательности транзакции пользователь должен загрузить и проверить весь стейт роллапа за последнюю неделю.
Мгновенные подтверждения транзакций. Может ли протокол обеспечить мгновенные подтверждения транзакций с полной гарантией? Либо же он может гарантировать это только на уровне консенсуса L2.
Мгновенная видимая окончательность: может быть реализована поверх большинства протоколов L2, то есть транзакции будут мгновенно подтверждены в пользовательском интерфейсе. Только платежные каналы (каналы состояний) предлагают полные гарантии безопасности для этих подтверждений, в то время как в других протоколах эти транзакции все еще могут быть отменены в течение определенного времени, прежде чем они будут подтверждены в L1.
Другие аспекты
Смарт-контракты: Рассматривается, поддерживает ли L2-решение полностью программируемые смарт-контракты, или только ограниченное подмножество функций через предикаты.
Совместимость с EVM-байткодом: Оценивается возможность переноса существующих EVM-байт-кодов контрактов Ethereum на L2 без значительных изменений.
Встроенная поддержка конфиденциальности: Рассмотрение эффективности защиты конфиденциальности в решениях L2, особенно в контексте доступности и экономичности конфиденциальных транзакций.
Для более детального понимания Zero-Knowledge Proofs (ZKP), рекомендую обратиться к этой статье в нашей blockchain-wiki, которую создают разработчики для разработчиков с любовью к пруфам и глубокому погружению в детали.
Жизненный цикл транзакций в zkSync
Работа ZK-Rollups может быть представлена на высоком уровне следующим образом:
Формирование Rollup: Транзакции упаковываются в rollup.
Создание ZKP: Формируется доказательство с нулевым разглашением.
Проверка в Ethereum: Доказательство отправляется для проверки в смарт-контракт Ethereum.

В контексте архитектуры zkSync процесс выглядит так:
Сбор внутренних блоков: Валидаторы zkSync собирают внутренние блоки из транзакций каждые несколько секунд.
Формирование пакета блоков: Из внутренних блоков каждые 30-90 секунд создается пакет блоков.
Фиксация состояния блокчейна: Валидаторы фиксируют текущее состояние блокчейна и передают измененные данные на L1 в виде
calldata
для возможности восстановления.Вычисление и отправка SNARK: Валидаторы вычисляют SNARK (ZKP) для пакета и отправляют его на проверку в смарт-контракт Ethereum. После проверки, новое состояние сети становится окончательным.

Валидаторы в ZK-Rollups играют ключевую роль, упаковывая транзакции в блоки и генерируя для них доказательства с нулевым разглашением. Особенностью системы является то, что валидаторы физически не могут украсть средства. Самый значительный потенциальный вред, который они могут нанести, — это временная остановка сети.
Примечание: В zkSync роль валидаторов выполняют операторы.
Разработчики zkSync выделяют следующие гарантии их архитектуры:
Безопасность средств: Операторы никогда не могут повредить состояние сети или украсть средства, что является преимуществом по сравнению с Sidechains.
Возможность возврата средств: Пользователи всегда могут извлечь свои средства даже в случае, если операторы прекратят работу. Это возможно благодаря доступности данных, в отличие от системы Plasma.
Независимость от мониторинга: Благодаря ZKP, для предотвращения мошенничества, пользователям или доверенным третьим сторонам не требуется постоянно отслеживать блоки Rollup, что является преимуществом по сравнению с системами, основанными на доказательствах мошенничества, такими как Payment channels или Optimistic Rollups.
Транзакции в zkSync проходят через несколько ключевых состояний, отличающихся от привычных подтверждений Rollup в L1:
Pending: Транзакция была получена оператором, но еще не обработана.
Processed: Транзакция обрабатывается оператором и готова к включению в следующий блок.
Committed: Данные транзакции опубликованы в Ethereum, что гарантирует доступность данных, но не подтверждает их корректное выполнение.
Executed: Завершающий этап, на котором доказательство действительности (SNARK) для транзакции проверено смарт-контрактом Ethereum, делая транзакцию окончательной.

Помимо номера блока, транзакции в zkSync отображают также номер пакета. Изначально, такие параметры как block.number
, block.timestamp
и blockhash
брались с L1. Однако, после обновления, эти значения будут теперь получаться с L2. Несмотря на это, разработчики планируют предоставить методы для доступа к данным из L1.
Отличия zkEVM от EVM
Совместимость L2 решений, основанных на ZKP с Ethereum представляет собой сложную задачу. Это связано с тем, что Ethereum изначально не был разработан для оптимального взаимодействия с ZKP. В результате, при разработке таких систем приходится искать компромисс между производительностью и потенциалом к масштабированию с одной стороны и совместимостью с Ethereum и EVM с другой. В статье Виталика Бутерина "The different types of ZK-EVMs" подробно обсуждаются эти аспекты и выделяются различные уровни совместимости.

zkSync выбрал один из самых сложных путей, ориентируясь на высокую производительность, но с ограниченной совместимостью как с Ethereum, так и с EVM. Для получения байт-кода, совместимого с zkEVM, используется проект LLVM с комплексом собственных компиляторов и оптимизаторов. В случае с Solidity и Yul, после стандартного компилятора solc, код проходит еще несколько стадий, прежде чем перейти в состояние байт-кода zkEVM. Ниже представлена схема, иллюстрирующая все этапы этого процесса (более подробно описанные здесь):

Важно! Оптимизации в zksolc поддерживаются.
Байт-код, скомпилированный специально для EVM, не совместим с zkEVM. Это означает, что адреса идентичных смарт-контрактов в Ethereum и zkSync будут различаться. Однако, разработчики планируют решить эту проблему в будущем.
Одним из значительных преимуществ такого подхода является независимость от конкретных языков программирования. Разработчики zkSync в перспективе обещают добавить поддержку таких языков, как Rust и C++. Важно, чтобы задержка в обновлениях и интеграции нововведений между верхнеуровневыми компиляторами (например, solc) и компиляторами платформы (например, zksolc) была минимальной. Изначально упоминалась идея о создании собственного языка программирования Zinc, но на данный момент команда сконцентрирована на поддержке более популярных языков программирования.

Проблема совместимости zk-компиляторов с существующими инструментами для разработки и отладки смарт-контрактов на Solidity и Vyper является значительной. Текущие платформы разработки, такие как Remix, Hardhat и Foundry, не поддерживают zk-компиляторы из коробки, что создает трудности при работе с ними. Однако, разрабатываются решения, которые обещают облегчить процесс миграции проектов и адаптации к новым технологиям.
В статье Виталика Бутерина упоминается, что со временем Ethereum, скорее всего, будет стремиться к улучшению совместимости с ZKP на уровне протокола. Аналогично, L2-решения с ZKP будут адаптироваться к лучшей совместимости с Ethereum. В результате, в будущем, различия между этими системами могут стать почти незаметными, обеспечивая более гладкую интеграцию и переход для разработчиков.
Особенности zkEVM
Важно! Протокол активно разрабатывается, всегда обращайтесь к актуальной версии документации!
zkEVM отличается от EVM и несмотря на то, что разработчики стараются спрятать эти отличия "под капотом", есть важные особенности. Их стоит учитывать при написании смарт-контрактов:
Отличия от EVM: Поведение кода, написанного на Solidity для zkEVM, может отличаться, особенно в таких аспектах, как
block.timestamp
иblock.number
. Важно регулярно проверять документацию на предмет изменений.Системные контракты: В zkSync существуют системные контракты для выполнения различных функций, таких как
ContractDeployer
для развертывания смарт-контрактов иMsgValueSimulator
для работы с ETH. Подробнее о системных контрактах можно узнать в документации.Шаблон прокси для развертывания: Рекомендуется использовать шаблон прокси в течение первых нескольких месяцев после развертывания, чтобы предотвратить возможные ошибки компилятора.
Расчет газа: Модель расчета газа в zkEVM отличается от Ethereum, включая различный набор опкодов и зависимость цены газа от L1. Детали можно найти здесь.
Локальное тестирование: Стандартные инструменты, такие как Hardhat Node или Anvil, не подходят для локального тестирования zkEVM. Вместо этого используются специальные варианты, включая тестирование в режиме форка.
Проверка подписи: Рекомендуется использовать встроенную поддержку абстракции учетных записей вместо
ecrecover
.Отслеживание ошибок, связанных с газом: В zkSync невозможно отследить ошибки, связанные с нехваткой газа из-за специфики выполнения внутри системного контракта
DefaultAccount
.
Для глубокого понимания работы с zkEVM рекомендуется изучить документацию, в том числе раздел "Security and best practices".
Account Abstraction
Абстракция аккаунтов в zkSync предлагает несколько ключевых преимуществ по сравнению с ERC-4337:
Уровень реализации: В zkSync абстракция аккаунтов встроена на уровне протокола, делая все учетные записи, включая внешние учетные записи (EOA), функционально аналогичными смарт-контрактам.
Обработка транзакций: В то время как ERC-4337 использует отдельный мемпул для бандлеров, создавая два разных потока транзакций, zkSync Era имеет единый mempool. Это означает, что транзакции, исходящие от EOA и смарт-контрактов, обрабатываются в одном потоке, обеспечивая более гладкую интеграцию и обработку.
Поддержка Paymasters: zkSync поддерживает paymasters для всех типов учетных записей, позволяя настроить оплату газа в токенах ERC20 для любой учетной записи.
Инфраструктура zkSync
Инфраструктура zkSync Era довольно быстро набирает обороты и уже включает десятки протоколов: Bridges, DeFi, инфраструктурные протоколы и другое. (Актуальный список смотреть тут).
Еще одним преимуществом является совместимость с кошелками Ethereum, например MetaMask или TrustWallet.

Hyperchains
Протокол zkSync начал свое развитие с запуска zkSync Lite, ориентированного только на переводы эфира и токенов ERC-20, без возможности развертывания полноценных протоколов. Этот этап был важным шагом в разработке, но только предварял появление zkSync Era — полноценного L2 решения для Ethereum, который теоретически может быть адаптирован и для других блокчейнов L1. Однако, амбиции zkSync не ограничиваются этим, ведь в планах развития стоит запуск так называемых гиперчейнов.
Гиперчейны, или "фрактальное масштабирование", представляют собой сети ZKP, каждая из которых формирует свои блоки и доказательства. Эти доказательства затем собираются вместе и размещаются в основной сети L1. Каждая из этих сетей является полной копией всей системы и может рассматриваться как ее "фрактал".

Особенность гиперчейнов в том, что они могут быть созданы и развернуты независимо. Для сохранения согласованности и совместимости, каждый гиперчейн должен использовать общий движок zkEVM, который является частью стека ZK (где zkSync Era выступает в роли первого гиперчейна). Это позволяет гиперчейнам наследовать свою безопасность от L1, обеспечивая их надежность и устраняя необходимость в дополнительных мерах по обеспечению доверия и безопасности.
Гиперчейны представляют собой новаторский подход к масштабированию блокчейн-сетей, позволяя снизить нагрузку на основную сеть и увеличить скорость обработки транзакций. Ключевые аспекты этого подхода включают:
Передача доказательств между гиперчейнами: Гиперчейны будут передавать доказательства блоков друг другу, увеличивая расстояние, которое должна пройти транзакция до достижения основной сети L1. Это способствует распределению нагрузки и избеганию проблемы узкого горлышка.

Прозрачность для пользователей: Пользователи не замечают разницу – их транзакции обрабатываются в гиперчейнах и могут проходить через несколько уровней перед достижением основной сети, создавая асинхронность в обработке.
Преимущества над существующими решениями: В отличие от нынешних L2 решений, которые быстрее, но все еще ограничены в количестве транзакций и иногда идут на компромиссы в безопасности, гиперчейны обещают значительно большее масштабирование.
Гибкость в создании кастомных блокчейнов: Гиперчейны позволяют создавать кастомные блокчейны и аккаунты с различными уровнями безопасности и приватности. При этом, даже с более низким уровнем безопасности, в худшем случае предполагается лишь временная заморозка средств.
Подробнее обо все этом тут.
Плюсы и минусы zkSync
Плюсы
Безопасность: Безопасность на уровне, близком к L1, и потенциал к децентрализации в будущем. За прогрессом в этом вопросе можно следить с помощью проекта L2Beat.
Совместимость с EVM: Поддержка смарт-контрактов, совместимых с EVM.
Web3 API и кошельки: Стандартный Web3 API и поддержка кошельков Ethereum, таких как MetaMask.
Абстракция учетных записей: Нативная поддержка абстракции аккаунтов.
Скорость транзакций: Быстрая обработка транзакций на L2 с последующим подтверждением на L1.
Низкие комиссии: Снижение стоимости комиссий за газ в сравнение с L1.
Оплата газа в ERC20: Возможность оплаты комиссий за газ в токенах ERC20.
Развивающаяся инфраструктура: Очень активное развитие инфраструктуры.
Потенциал к масштабированию: Возможности для значительного улучшения масштабируемости.
Минусы
Ограниченная cовместимость с EVM: По сравнению с конкурентами (например, Polygon zkEVM, Scroll) совместимость с EVM ниже.
Риск ошибок в смарт-контрактах: Повышенный риск ошибок, требующий тщательного тестирования и аудита.
Специфичность стека разработки: Необходимость адаптации стека разработки под особенности протокола.
Отставание от основных технологий: Задержка в принятии нововведений в компиляторах и обновлениях библиотек.
Централизация cети: На данный момент сеть управляется ограниченным числом операторов.
Необходимость обновляемых смарт-контрактов: Из всего вышесказанного вытекает необходимость на старте проекта всегда делать обновляемые смарт-контракты, чтобы иметь возможность оперативно устранить недостатки и уязвимости.
Вывод
Протокол zkSync выглядит очень многообещающе и имеет большой потенциал, хотя на данный момент запуск проекта в этом блокчейне все еще сопряжен с рядом рисков, которые нужно учитывать. Разрабатывать для zkSync на данный момент сложнее, чем для блокчейнов, которые гораздо больше совместимы с EVM и стеком для разработки под EVM. Но, возможно в будущем, эта разница станет несущественной либо совсем будет отсутствовать.
P.S. Буду рад, если поделитесь своим мнением о zkSync и, надеюсь, статья была для вас полезна.