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

В этой статье мы объясним, что такое технология доказательства нулевого знания и поговорим о популярном блокчейне — zkSync: как работают транзакции в zkSync и основные различия от виртуальной машины Ethereum (EVM). Также обсудим преимущества и недостатки этого блокчейна, который, на наш взгляд, может иметь перспективное будущее.

ZkSync - это блокчейн второго уровня (Уровень 2 — L2) для Ethereum, созданный для решения проблем высоких комиссий и ограниченной пропускной способности (транзакции в секунду — TPS) в сети Ethereum. На этой платформе используется технология ZK-Rollup, которая использует доказательства с нулевым разглашением (ZKP) для пакетной обработки множества транзакций вне главной сети (L1). На L1 отправляются только криптографические доказательства правильности транзакций и их сжатые данные, что значительно повышает эффективность и снижает затраты.

Разработано Matter Labs, zkSync объявлен как полностью открытый продукт (100% открытый исходный код), управляемый сообществом. В соответствии с Cryptorank, проект уже привлек внимание, привлекая инвестиции в размере $458 миллионов. В долгосрочной перспективе Matter Labs стремится создать обширную экосистему. В настоящее время функционируют две блокчейн-сети: zkSync Lite, обрабатывающая платежи в ETH и токенах ERC20, и zkSync Era, поддерживающая полноценные смарт-контракты. В планах на будущее - запуск гиперцепи (L3), обеспечивающий высокий уровень безопасности. Цель Matter Labs - масштабировать технологию до уровня, который привлечет следующий миллиард пользователей блокчейна.

Фон

ZkSync представляет собой новый подход к решению проблемы масштабируемости, известной как трилемма блокчейнаЭтот проект, как и другие решения уровня 2 (L2), стремится найти баланс между безопасностью, масштабируемостью и децентрализацией в блокчейн-сетях.

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

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

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

Уровень 2

Основной задачей увеличения TPS сети Ethereum без увеличения нагрузки на узлы было введение Шардингв сочетании с переходом к консенсусу PoS (Proof of Stake). Это включало разделение валидаторов на подгруппы для обработки отдельных сегментов сети, тем самым снижая общую нагрузку и увеличивая пропускную способность. Однако сообщество сосредоточилось на решениях уровня 2, учитывая их быстрое развитие.

Помимо идеи внедрения Шардинга в Ethereum появились и другие решения масштабируемости, такие как:

• Платежи и каналы состояния
• Боковые цепочки
• Плазма
• Оптимистичный Rollup

А также технологии, основанные на доказательствах с нулевым разглашением (ZKP), включая:

• Validium
• zkRollup
• Воля

Более подробную информацию можно найтиздесь.

Хотя Шардинг все еще находится в стадии разработки, хардфорк Dencun запланирован на начало 2024 года, который будет реализованпро-Danksharding. Этот промежуточный этап направлен на улучшение решений уровня 2, сделав хранение данных на L1 более экономичным. Таким образом, Proto-Danksharding обещает снизить затраты на транзакции на L2 как шаг к полноценному решению Sharding.

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

В эта статья, предлагаются ключевые критерии для оценки протоколов, используемых в решениях уровня 2. Они включают:

• безопасность,
• производительность и экономическая эффективность,
• удобство использования,
• дополнительные аспекты, такие как поддержка смарт-контрактов, совместимость байт-кода EVM и варианты конфиденциальности.

Важно! Статья написана Matter Labs и, на мой взгляд, некоторые вещи "перегнаны" в пользу zkRollup (поскольку имеется явный конфликт интересов), но это не так важно, главное - увидеть, какие различия существуют между протоколами Layer-2.

Ниже я предоставлю таблицу, а здесь кратко опишу ее содержание.

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

• Предположение о жизнеспособности или «жизнеспособности» уровня 2. Предполагается, что для поддержания функциональности уровня 2 некоторые участники всегда будут на цепи на уровне 1, чтобы реагировать на потенциальные случаи мошенничества. Это либо валидаторы, которые ставят определенную сумму средств (обозначенную как «Bonded» в таблице) на L1, либо третьи стороны, которые обеспечивают безопасность протокола за вознаграждение. Как видно из таблицы, решения, использующие ZKP (Validium и zkRollup), не имеют такой необходимости.
• Проблема массового выхода. Проблема, возникающая, если по соображениям безопасности необходимо инициировать вывод средств всеми пользователями с уровня L2 на уровень L1. Как видно из таблицы, эта проблема существует только с протоколом Plasma, о котором можно прочитать больше здесь.
• Опека. Вопрос о том, могут ли L2 валидаторы временно блокировать или конфисковывать средства пользователей.
• Экономические уязвимости. Включают в себя различные атаки на L2-валидаторов, включая подкуп L1-майнеров, создание «теневых» DAO и другие экономически мотивированные атаки.
• Криптография. Разница между стандартными и новыми криптографическими примитивами. Стандартные изучены более подробно и потенциально уязвимы, в то время как новые (такие как SNARK и STARK) обеспечивают большую надежность, но требуют дополнительных знаний и проверок со стороны разработчиков.

Производительность и Экономика

С производительностью все просто. TPS (транзакций в секунду) указывает пропускную способность сети и в контексте масштабирования является наиболее важным параметром.

Экономические аспекты:

• Эффективность капитала: Этот аспект особенно важен для Платежных каналов. Они требуют замораживания средств в размере среднего объема операций в канале, что делает их менее эффективными с точки зрения капиталовложений.
• Транзакция L1 для создания учетной записи L2. Также недостаток для платежных каналов, так как во всех других решениях учетная запись, созданная в L1, по умолчанию работает в L2.
• Стоимость транзакции: Вместе с TPS это один из наиболее критических факторов масштабируемости, определяющий экономическую привлекательность решения.

Простота использования

• Время вывода с L2 на L1: Этот период может варьироваться от нескольких минут до нескольких недель. Оптимистичные Rollups и Plasma особенно неудобны в этом отношении, поскольку требуют больше времени для вывода средств.
• Время до Субъективной Окончательности Транзакции: Определяет, насколько быстро транзакция становится необратимой на уровне L1 с точки зрения внешних наблюдателей. Например, в Оптимистических Роллапах достижение окончательности на уровне L1 требует только одного подтверждения на Ethereum, но полная окончательность транзакции занимает около недели.
• Проверяемость субъективной окончательности с клиентским кодом: Определяет, можно ли проверить время субъективной окончательности с помощью легких клиентов (браузеров/мобильных кошельков). Продолжая пример с Оптимистическими Роллапами, чтобы подтвердить окончательность транзакции, пользователь должен скачать и проверить весь стейт-роллап за прошлую неделю.
• Может ли протокол обеспечить мгновенное подтверждение транзакции с полной гарантией? Или это гарантируется только на уровне консенсуса L2.
• Мгновенная видимая окончательность: может быть реализована поверх большинства протоколов L2, что означает, что транзакции мгновенно подтверждаются в пользовательском интерфейсе. Только платежные каналы (каналы состояния) предлагают полные гарантии безопасности для этих подтверждений, в то время как в других протоколах эти транзакции все еще могут быть отменены в течение определенного времени до их подтверждения в L1.

Другие аспекты

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

Ниже приведена сравнительная таблица основных решений на основе ZKP:

Для более детального понимания доказательств с нулевым разглашением (ZKP) рекомендую обратиться кэта статьяв нашемблокчейн-викисозданный разработчиками для разработчиков с любовью к доказательствам и глубокими погружениями в детали.

Жизненный цикл транзакции в zkSync

Операция ZK-Rollups может быть представлена на высоком уровне следующим образом:

1. Формирование Rollup: Транзакции упаковываются в rollup.
2. Создание ZKP: A Zero-Knowledge Proof сформировано.
3. Проверка в Ethereum: Доказательство отправляется на проверку в смарт-контракт Ethereum.

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

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

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

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

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

1. Безопасность фонда: Операторы никогда не могут повредить состояние сети или украсть средства, что является преимуществом по сравнению с боковыми цепями.
2. Возможность восстановления средств: Пользователи всегда могут извлечь свои средства, даже если операторы прекратят свою деятельность. Это возможно благодаря доступности данных, в отличие от системы Plasma.
3. Независимость от мониторинга: Благодаря ZKP пользователи или доверенные стороны не должны непрерывно контролировать блоки Rollup, чтобы предотвратить мошенничество, что является преимуществом по сравнению с системами на основе доказательств мошенничества, такими как Платежные каналы или Оптимистичные Rollups.

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

• В ожидании: Транзакция была получена оператором, но еще не была обработана.
• Обработано: Транзакция обрабатывается оператором и готова к включению в следующий блок.
• Зафиксировано: Данные транзакции публикуются в Ethereum, обеспечивая доступность данных, но не подтверждают их правильное выполнение.
• Выполнено: Финальная стадия, на которой доказательство корректности (SNARK) для транзакции проверяется смарт-контрактом Ethereum, делая транзакцию окончательной.

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

Различия между zkEVM и EVM

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

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

1. Отличия от EVM: Поведение кода, написанного на Solidity для zkEVM, может отличаться, особенно в аспектах, таких как block.timestamp и block.number. Важно регулярно проверятьдокументациядля изменений.
2. Системные контракты: В zkSync есть системные смарт-контракты для различных функций, такие как ContractDeployer для развертывания смарт-контрактов и MsgValueSimulator для работы с ETH. Больше информации о системных смарт-контрактах можно найти в документация.
3. Шаблон прокси-паттерна для развертывания: Рекомендуется использовать шаблон прокси в течение первых нескольких месяцев после развертывания, чтобы предотвратить возможные ошибки компилятора.
4. Расчет газа: Модель расчета газа в zkEVM отличается от Ethereum, включая другой набор опкодов и зависимость цены газа от L1. Подробности можно найтиздесь.
5. Локальное тестирование: Стандартные инструменты, такие как узел Hardhat или Anvil, не подходят для локального тестирования zkEVM. Вместо этого, специальные опциииспользуются, включая тестирование в режиме вилки.
6. Проверка подписи: Рекомендуется использовать встроенную поддержку абстрагирования учетной записи вместо ecrecover.
7. Отслеживание ошибок, связанных с газом: В zkSync невозможно отследить ошибки, связанные с нехваткой газа из-за особенностей выполнения в рамках смарт-контракта системы DefaultAccount.

Для глубокого понимания работы с zkEVM рекомендуется изучить документацию, включая раздел «Безопасность и лучшие практики».

Абстракция учётной записи

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

1. Уровень реализации: В zkSync абстракция учетной записи встроена на уровне протокола, что делает все учетные записи, включая внешние управляемые учетные записи (EOA), функционально аналогичными смарт-контрактам.
2. Обработка транзакций: В то время как ERC-4337 использует отдельный мемпул для бандлеров, создавая два разных потока транзакций, у zkSync Era есть один общий мемпул. Это означает, что транзакции, исходящие от EOAs и смарт-контрактов, обрабатываются в одном потоке, обеспечивая более плавную интеграцию и обработку.
3. Поддержка платежных управляющих: zkSync поддерживает платежных управляющих для всех типов счетов, что позволяет настраивать комиссии за газ в токенах ERC20 для любого счета.

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

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

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

Гиперцепи

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

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

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

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

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

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

Больше обо всем этом можно узнатьздесь.

Преимущества и недостатки zkSync

про

1. Безопасность: Безопасность близка к уровню L1 и потенциал для децентрализации в будущем.
2. Совместимость с EVM: Поддержка смарт-контрактов, совместимых с EVM.
3. Web3 API и кошельки: стандартный Web3 API и поддержка кошельков Ethereum, таких как MetaMask.
4. Абстрагирование учетной записи: Нативная поддержка абстрагирования учетной записи.
5. Скорость транзакции: Быстрая обработка транзакции на уровне L2 с последующим подтверждением на уровне L1.
6. Низкие комиссии: Снижение газовых сборов по сравнению с L1.
7. Возможность оплаты комиссий за газ в токенах ERC20.
8. Развивающаяся инфраструктура: Очень активное развитие инфраструктуры.
9. Потенциал масштабируемости: Возможности значительного увеличения масштабируемости.

Про

1. Ограниченная совместимость EVM: по сравнению с конкурентами (например, Polygon zkEVM, Scroll), у него ниже совместимость с EVM.
2. Риск ошибок в смарт-контрактах: увеличенный риск ошибок, требующий тщательного тестирования и аудита.
3. Необходимость адаптации стека разработки под специфику протокола.
4. Отставание от основных технологий: Задержка в принятии инноваций в компиляторах и обновлении библиотек.
5. Централизация сети: В настоящее время сетью управляет ограниченное количество операторов.
6. Необходимость обновляемых смарт-контрактов: Из всего вышесказанного следует, что существует необходимость всегда создавать обновляемые контракты в начале проекта, чтобы можно было оперативно устранить недостатки и уязвимости.

Заключение

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

Оговорка：

1. Эта статья перепечатана из [MetaLamp]. Пересылка оригинального заголовка «Как ZKP и ZK-Rollups помогают решить проблему масштабируемости: обзор блокчейна zkSync». Все авторские права принадлежат оригинальному автору [MetaLamp]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда и они оперативно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.