Как ZKP и ZK-Rollups помогают в решении проблемы масштабирования: обзор блокчейна zkSync

Привет, Хабр! Меня зовут Рома и я 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), направлен на поиск баланса между безопасностью, масштабируемостью и децентрализацией в блокчейн-сетях.

Три фактора трилеммы блокчейна

1. Масштабируемость: Способность системы эффективно обрабатывать растущий объем транзакций или данных, не теряя в производительности и безопасности.

2. Безопасность в блокчейне: Обеспечение надежности и защиты данных от неавторизированного доступа, подделки или внесения изменений.

3. Децентрализация: Отсутствие централизованной контролирующей структуры. В децентрализованной системе управление и принятие решений демократично распределены среди всех участников сети.

Ethereum ориентирован на безопасность и децентрализацию, подчеркивая его статус как протокола peer-to-peer с нодами, распределенными по всему миру. Для актуальной информации о распределении нод можно обратиться к NodeWatch.

Распределение Ethereum нод

Для поддержания децентрализации в сети, каждый узел должен проверять все транзакции. Это делает сеть по своей природе менее быстрой. Кроме того, при высокой нагрузке на сеть, транзакции могут обходиться весьма дорого и требовать значительного времени на обработку.

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 решений из статьи:

Сравнительная таблица основных ZKP-базированных решений

Разберем ее содержимое по пунктам.

Безопасность

• Предположение о работоспособности или "живучести" 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 может быть представлена на высоком уровне следующим образом:

1. Формирование Rollup: Транзакции упаковываются в rollup.

2. Создание ZKP: Формируется доказательство с нулевым разглашением.

3. Проверка в Ethereum: Доказательство отправляется для проверки в смарт-контракт Ethereum.

Общее представление работы ZK-Rollups

В контексте архитектуры zkSync процесс выглядит так:

1. Сбор внутренних блоков: Валидаторы zkSync собирают внутренние блоки из транзакций каждые несколько секунд.

2. Формирование пакета блоков: Из внутренних блоков каждые 30-90 секунд создается пакет блоков.

3. Фиксация состояния блокчейна: Валидаторы фиксируют текущее состояние блокчейна и передают измененные данные на L1 в виде calldata для возможности восстановления.

4. Вычисление и отправка SNARK: Валидаторы вычисляют SNARK (ZKP) для пакета и отправляют его на проверку в смарт-контракт Ethereum. После проверки, новое состояние сети становится окончательным.

Верхнеуровневая архитектура zkSync

Валидаторы в ZK-Rollups играют ключевую роль, упаковывая транзакции в блоки и генерируя для них доказательства с нулевым разглашением. Особенностью системы является то, что валидаторы физически не могут украсть средства. Самый значительный потенциальный вред, который они могут нанести, — это временная остановка сети.

Примечание: В zkSync роль валидаторов выполняют операторы.

Разработчики zkSync выделяют следующие гарантии их архитектуры:

1. Безопасность средств: Операторы никогда не могут повредить состояние сети или украсть средства, что является преимуществом по сравнению с Sidechains.

2. Возможность возврата средств: Пользователи всегда могут извлечь свои средства даже в случае, если операторы прекратят работу. Это возможно благодаря доступности данных, в отличие от системы Plasma.

3. Независимость от мониторинга: Благодаря ZKP, для предотвращения мошенничества, пользователям или доверенным третьим сторонам не требуется постоянно отслеживать блоки Rollup, что является преимуществом по сравнению с системами, основанными на доказательствах мошенничества, такими как Payment channels или Optimistic Rollups.

Транзакции в zkSync проходят через несколько ключевых состояний, отличающихся от привычных подтверждений Rollup в L1:

• Pending: Транзакция была получена оператором, но еще не обработана.

• Processed: Транзакция обрабатывается оператором и готова к включению в следующий блок.

• Committed: Данные транзакции опубликованы в Ethereum, что гарантирует доступность данных, но не подтверждает их корректное выполнение.

• Executed: Завершающий этап, на котором доказательство действительности (SNARK) для транзакции проверено смарт-контрактом Ethereum, делая транзакцию окончательной.

Пример транзакции (zkSync Era Block Explorer)

Помимо номера блока, транзакции в zkSync отображают также номер пакета. Изначально, такие параметры как block.number, block.timestamp и blockhash брались с L1. Однако, после обновления, эти значения будут теперь получаться с L2. Несмотря на это, разработчики планируют предоставить методы для доступа к данным из L1.

Отличия zkEVM от EVM

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

Совместимость L2 решений с Ethereum и EVM

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

Важно! Оптимизации в zksolc поддерживаются.

Байт-код, скомпилированный специально для EVM, не совместим с zkEVM. Это означает, что адреса идентичных смарт-контрактов в Ethereum и zkSync будут различаться. Однако, разработчики планируют решить эту проблему в будущем.

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

Принцип работы компилятора zkEVM

Проблема совместимости zk-компиляторов с существующими инструментами для разработки и отладки смарт-контрактов на Solidity и Vyper является значительной. Текущие платформы разработки, такие как Remix, Hardhat и Foundry, не поддерживают zk-компиляторы из коробки, что создает трудности при работе с ними. Однако, разрабатываются решения, которые обещают облегчить процесс миграции проектов и адаптации к новым технологиям.

В статье Виталика Бутерина упоминается, что со временем Ethereum, скорее всего, будет стремиться к улучшению совместимости с ZKP на уровне протокола. Аналогично, L2-решения с ZKP будут адаптироваться к лучшей совместимости с Ethereum. В результате, в будущем, различия между этими системами могут стать почти незаметными, обеспечивая более гладкую интеграцию и переход для разработчиков.

Особенности zkEVM

Важно! Протокол активно разрабатывается, всегда обращайтесь к актуальной версии документации!

zkEVM отличается от EVM и несмотря на то, что разработчики стараются спрятать эти отличия "под капотом", есть важные особенности. Их стоит учитывать при написании смарт-контрактов:

1. Отличия от EVM: Поведение кода, написанного на Solidity для zkEVM, может отличаться, особенно в таких аспектах, как block.timestamp и block.number. Важно регулярно проверять документацию на предмет изменений.

2. Системные контракты: В zkSync существуют системные контракты для выполнения различных функций, таких как ContractDeployer для развертывания смарт-контрактов и MsgValueSimulator для работы с ETH. Подробнее о системных контрактах можно узнать в документации.

3. Шаблон прокси для развертывания: Рекомендуется использовать шаблон прокси в течение первых нескольких месяцев после развертывания, чтобы предотвратить возможные ошибки компилятора.

4. Расчет газа: Модель расчета газа в zkEVM отличается от Ethereum, включая различный набор опкодов и зависимость цены газа от L1. Детали можно найти здесь.

5. Локальное тестирование: Стандартные инструменты, такие как Hardhat Node или Anvil, не подходят для локального тестирования zkEVM. Вместо этого используются специальные варианты, включая тестирование в режиме форка.

6. Проверка подписи: Рекомендуется использовать встроенную поддержку абстракции учетных записей вместо ecrecover.

7. Отслеживание ошибок, связанных с газом: В zkSync невозможно отследить ошибки, связанные с нехваткой газа из-за специфики выполнения внутри системного контракта DefaultAccount.

Для глубокого понимания работы с zkEVM рекомендуется изучить документацию, в том числе раздел "Security and best practices".

Account Abstraction

Абстракция аккаунтов в zkSync предлагает несколько ключевых преимуществ по сравнению с ERC-4337:

1. Уровень реализации: В zkSync абстракция аккаунтов встроена на уровне протокола, делая все учетные записи, включая внешние учетные записи (EOA), функционально аналогичными смарт-контрактам.

2. Обработка транзакций: В то время как ERC-4337 использует отдельный мемпул для бандлеров, создавая два разных потока транзакций, zkSync Era имеет единый mempool. Это означает, что транзакции, исходящие от EOA и смарт-контрактов, обрабатываются в одном потоке, обеспечивая более гладкую интеграцию и обработку.

3. Поддержка Paymasters: zkSync поддерживает paymasters для всех типов учетных записей, позволяя настроить оплату газа в токенах ERC20 для любой учетной записи.

Инфраструктура zkSync

Инфраструктура zkSync Era довольно быстро набирает обороты и уже включает десятки протоколов: Bridges, DeFi, инфраструктурные протоколы и другое. (Актуальный список смотреть тут).

Еще одним преимуществом является совместимость с кошелками Ethereum, например MetaMask или TrustWallet.

Экосистема zkSync Era

Hyperchains

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

Гиперчейны, или "фрактальное масштабирование", представляют собой сети ZKP, каждая из которых формирует свои блоки и доказательства. Эти доказательства затем собираются вместе и размещаются в основной сети L1. Каждая из этих сетей является полной копией всей системы и может рассматриваться как ее "фрактал".

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

Гиперчейны представляют собой новаторский подход к масштабированию блокчейн-сетей, позволяя снизить нагрузку на основную сеть и увеличить скорость обработки транзакций. Ключевые аспекты этого подхода включают:

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

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

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

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

Подробнее обо все этом тут.

Плюсы и минусы zkSync

Плюсы

1. Безопасность: Безопасность на уровне, близком к L1, и потенциал к децентрализации в будущем. За прогрессом в этом вопросе можно следить с помощью проекта L2Beat.

2. Совместимость с EVM: Поддержка смарт-контрактов, совместимых с EVM.

3. Web3 API и кошельки: Стандартный Web3 API и поддержка кошельков Ethereum, таких как MetaMask.

4. Абстракция учетных записей: Нативная поддержка абстракции аккаунтов.

5. Скорость транзакций: Быстрая обработка транзакций на L2 с последующим подтверждением на L1.

6. Низкие комиссии: Снижение стоимости комиссий за газ в сравнение с L1.

7. Оплата газа в ERC20: Возможность оплаты комиссий за газ в токенах ERC20.

8. Развивающаяся инфраструктура: Очень активное развитие инфраструктуры.

9. Потенциал к масштабированию: Возможности для значительного улучшения масштабируемости.

Минусы

1. Ограниченная cовместимость с EVM: По сравнению с конкурентами (например, Polygon zkEVM, Scroll) совместимость с EVM ниже.

2. Риск ошибок в смарт-контрактах: Повышенный риск ошибок, требующий тщательного тестирования и аудита.

3. Специфичность стека разработки: Необходимость адаптации стека разработки под особенности протокола.

4. Отставание от основных технологий: Задержка в принятии нововведений в компиляторах и обновлениях библиотек.

5. Централизация cети: На данный момент сеть управляется ограниченным числом операторов.

6. Необходимость обновляемых смарт-контрактов: Из всего вышесказанного вытекает необходимость на старте проекта всегда делать обновляемые смарт-контракты, чтобы иметь возможность оперативно устранить недостатки и уязвимости.

Вывод

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

P.S. Буду рад, если поделитесь своим мнением о zkSync и, надеюсь, статья была для вас полезна.