Роллапы с нулевым разглашением

Ролл-апы с нулевым разглашением (ZK-rollups) — это решения для масштабирования второго уровня, которые увеличивают пропускную способность основной сети Ethereum за счет переноса вычислений и хранения состояния вне сети. ZK-Rollups могут обрабатывать тысячи транзакций в пакете, а затем публиковать только минимальные сводные данные в основной сети. Эти сводные данные определяют изменения, которые необходимо внести в состояние Ethereum, и некоторые криптографические доказательства правильности этих изменений.

Предварительные условия

Вам следует прочитать и понять нашу страницу о масштабировании Ethereum и уровне 2.

Что такое zero-knowledge rollups?

Ролл-апы с нулевым разглашением (ZK-rollups) объединяют (или «сворачивают») транзакции в пакеты, которые выполняются вне сети. Вычисления вне сети уменьшают объем данных, которые необходимо публиковать в блокчейне. Операторы ZK-ролл-апов отправляют сводку изменений, необходимых для представления всех транзакций в пакете, вместо того чтобы отправлять каждую транзакцию по отдельности. Они также создают , чтобы доказать правильность своих изменений.

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

При переводе средств из ZK-ролл-апа в Ethereum нет задержек, поскольку транзакции выхода выполняются сразу после того, как контракт ZK-ролл-апа проверяет доказательство валидности. И наоборот, вывод средств из оптимистических ролл-апов происходит с задержкой, чтобы у любого была возможность оспорить транзакцию выхода с помощью .

ZK-ролл-апы записывают транзакции в Ethereum как calldata. calldata — это место, где хранятся данные, включенные во внешние вызовы функций смарт-контракта. Информация в calldata публикуется в блокчейне, что позволяет любому самостоятельно восстановить состояние ролл-апа. ZK-ролл-апы используют методы сжатия для уменьшения данных транзакций — например, аккаунты представляются индексом, а не адресом, что экономит 28 байт данных. Публикация данных в сети — это значительная статья расходов для ролл-апов, поэтому сжатие данных может снизить комиссии для пользователей.

Как ZK-ролл-апы взаимодействуют с Ethereum?

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

Основная архитектура ZK-ролл-апа состоит из следующих компонентов:

1. Контракты в сети. Как уже упоминалось, протокол ZK-ролл-апа контролируется смарт-контрактами, работающими в Ethereum. К ним относится основной контракт, который хранит блоки ролл-апа, отслеживает депозиты и наблюдает за обновлениями состояния. Другой контракт в сети (контракт-верификатор) проверяет доказательства с нулевым разглашением, представленные производителями блоков. Таким образом, Ethereum служит базовым уровнем или «уровнем 1» для ZK-ролл-апа.

2. Виртуальная машина вне сети (VM). Хотя протокол ZK-ролл-апа существует в Ethereum, выполнение транзакций и хранение состояния происходят на отдельной виртуальной машине, независимой от EVM. Эта VM вне сети является средой выполнения транзакций в ZK-ролл-апе и служит вторичным уровнем или «уровнем 2» для протокола ZK-ролл-апа. Доказательства валидности, проверяемые в основной сети Ethereum, гарантируют правильность переходов состояний в VM вне сети.

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

ZK-ролл-апы полагаются на основной протокол Ethereum в следующих аспектах:

Доступность данных

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

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

Взаимодействие в сети необходимо пользователям для работы с ролл-апом. Без доступа к данным о состоянии пользователи не могут запрашивать баланс своего аккаунта или инициировать транзакции (например, вывод средств), которые зависят от информации о состоянии.

Финальность транзакций

Ethereum выступает в качестве уровня расчетов для ZK-ролл-апов: транзакции Уровня 2 финализируются только в том случае, если контракт Уровня 1 принимает доказательство валидности. Это устраняет риск того, что злонамеренные операторы повредят сеть (например, украдут средства ролл-апа), поскольку каждая транзакция должна быть одобрена в основной сети. Кроме того, Ethereum гарантирует, что операции пользователя не могут быть отменены после их финализации на Уровне 1.

Устойчивость к цензуре

Большинство ZK-ролл-апов используют «суперузел» (оператора) для выполнения транзакций, создания пакетов и отправки блоков на Уровень 1. Хотя это обеспечивает эффективность, это увеличивает риск цензуры: злонамеренные операторы ZK-ролл-апов могут подвергать цензуре пользователей, отказываясь включать их транзакции в пакеты.

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

Как работают ZK-ролл-апы?

Транзакции

Пользователи в ZK-ролл-апе подписывают транзакции и отправляют их операторам Уровня 2 для обработки и включения в следующий пакет. В некоторых случаях оператор является централизованной сущностью, называемой секвенсором, который выполняет транзакции, объединяет их в пакеты и отправляет на Уровень 1. Секвенсор в этой системе — единственная сущность, которой разрешено создавать блоки Уровня 2 и добавлять транзакции ролл-апа в контракт ZK-ролл-апа.

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

Как ZK-ролл-апы публикуют данные транзакций в Ethereum

Как объяснялось ранее, данные транзакций публикуются в Ethereum как calldata. calldata — это область данных в смарт-контракте, используемая для передачи аргументов в функцию, которая ведет себя аналогично памяти. calldata не хранится как часть состояния Ethereum, но она сохраняется в сети как часть журналов истории (opens in a new tab) сети Ethereum. calldata не влияет на состояние Ethereum, что делает ее дешевым способом хранения данных в сети.

Ключевое слово calldata часто идентифицирует метод смарт-контракта, вызываемый транзакцией, и содержит входные данные для метода в виде произвольной последовательности байтов. ZK-ролл-апы используют calldata для публикации сжатых данных транзакций в сети; оператор ролл-апа просто добавляет новый пакет, вызывая необходимую функцию в контракте ролл-апа и передавая сжатые данные в качестве аргументов функции. Это помогает снизить затраты для пользователей, так как большая часть комиссий ролл-апа идет на хранение данных транзакций в сети.

Обязательства по состоянию

Состояние ZK-ролл-апа, которое включает аккаунты и балансы Уровня 2, представлено в виде дерева Меркла. Криптографический хэш корня дерева Меркла (корень Меркла) хранится в контракте в сети, что позволяет протоколу ролл-апа отслеживать изменения в состоянии ZK-ролл-апа.

Ролл-ап переходит в новое состояние после выполнения нового набора транзакций. Оператор, инициировавший переход состояния, обязан вычислить новый корень состояния и отправить его в контракт в сети. Если доказательство валидности, связанное с пакетом, аутентифицировано контрактом-верификатором, новый корень Меркла становится каноническим корнем состояния ZK-ролл-апа.

Помимо вычисления корней состояния, оператор ZK-ролл-апа также создает корень пакета — корень дерева Меркла, включающего все транзакции в пакете. Когда отправляется новый пакет, контракт ролл-апа сохраняет корень пакета, что позволяет пользователям доказать, что транзакция (например, запрос на вывод средств) была включена в пакет. Пользователям необходимо будет предоставить детали транзакции, корень пакета и доказательство Меркла, показывающее путь включения.

Доказательства валидности

Новый корень состояния, который оператор ZK-ролл-апа отправляет в контракт Уровня 1, является результатом обновлений состояния ролл-апа. Допустим, Алиса отправляет 10 токенов Бобу, оператор просто уменьшает баланс Алисы на 10 и увеличивает баланс Боба на 10. Затем оператор хэширует обновленные данные аккаунта, перестраивает дерево Меркла ролл-апа и отправляет новый корень Меркла в контракт в сети.

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

Доказательства валидности позволяют сторонам доказывать правильность утверждения, не раскрывая само утверждение, — отсюда и их второе название «доказательства с нулевым разглашением». ZK-ролл-апы используют доказательства валидности для подтверждения правильности переходов состояния вне сети без необходимости повторного выполнения транзакций в Ethereum. Эти доказательства могут быть в форме ZK-SNARK (opens in a new tab) (краткий неинтерактивный аргумент знания с нулевым разглашением) или ZK-STARK (opens in a new tab) (масштабируемый прозрачный аргумент знания с нулевым разглашением).

И SNARK, и STARK помогают подтвердить целостность вычислений вне сети в ZK-ролл-апах, хотя каждый тип доказательства имеет свои отличительные особенности.

ZK-SNARKs

Для работы протокола ZK-SNARK необходимо создать общую эталонную строку (CRS): CRS предоставляет публичные параметры для доказывания и проверки доказательств валидности. Безопасность системы доказывания зависит от настройки CRS; если информация, используемая для создания публичных параметров, попадет в руки злоумышленников, они смогут генерировать ложные доказательства валидности.

Некоторые ZK-ролл-апы пытаются решить эту проблему, используя церемонию многосторонних вычислений (MPC) (opens in a new tab) с участием доверенных лиц для генерации публичных параметров для схемы ZK-SNARK. Каждая сторона вносит некоторую случайность (называемую «токсичными отходами») для создания CRS, которую они должны немедленно уничтожить.

Доверенные настройки используются, потому что они повышают безопасность настройки CRS. Пока хотя бы один честный участник уничтожает свои входные данные, безопасность системы ZK-SNARK гарантирована. Тем не менее, этот подход требует доверия к участникам в том, что они удалят свою выборку случайности и не подорвут гарантии безопасности системы.

Несмотря на допущения о доверии, ZK-SNARKs популярны благодаря своим малым размерам доказательств и проверке за постоянное время. Поскольку проверка доказательств на Уровне 1 составляет большую часть затрат на эксплуатацию ZK-ролл-апа, Уровни 2 используют ZK-SNARKs для генерации доказательств, которые можно быстро и дешево проверить в основной сети.

ZK-STARKs

Как и ZK-SNARK, ZK-STARK доказывают валидность вычислений вне сети, не раскрывая входных данных. Однако ZK-STARK считаются усовершенствованием ZK-SNARK из-за их масштабируемости и прозрачности.

ZK-STARK являются «прозрачными», поскольку они могут работать без доверенной настройки общей эталонной строки (CRS). Вместо этого ZK-STARK полагаются на публично проверяемую случайность для настройки параметров генерации и проверки доказательств.

ZK-STARK также обеспечивают большую масштабируемость, поскольку время, необходимое для доказывания и проверки доказательств валидности, увеличивается квазилинейно по отношению к сложности базового вычисления. В случае ZK-SNARK время доказывания и проверки масштабируется линейно по отношению к размеру базового вычисления. Это означает, что ZK-STARK требуют меньше времени, чем ZK-SNARK, для доказывания и проверки при работе с большими наборами данных, что делает их полезными для приложений с большим объемом операций.

ZK-STARK также устойчивы к атакам квантовых компьютеров, в то время как криптография на эллиптических кривых (ECC), используемая в ZK-SNARK, как широко считается, уязвима для атак квантовых компьютеров. Недостатком ZK-STARK является то, что они создают доказательства большего размера, проверка которых в Ethereum обходится дороже.

Как работают доказательства валидности в ZK-ролл-апах?

Генерация доказательства

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

• Аккаунты отправителя и получателя являются частью дерева состояний.
• У отправителя достаточно средств для обработки транзакции.
• Транзакция корректна и соответствует публичному ключу отправителя в ролл-апе.
• Нонс отправителя корректен и т. д.

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

• Корень дерева Меркла, включающий все транзакции в пакете.
• Доказательства Меркла для транзакций, чтобы доказать их включение в пакет.
• Доказательства Меркла для каждой пары отправитель-получатель в транзакциях, чтобы доказать, что эти аккаунты являются частью дерева состояний ролл-апа.
• Набор промежуточных корней состояния, полученных путем обновления корня состояния после применения обновлений состояния для каждой транзакции (т. е. уменьшение балансов аккаунтов отправителей и увеличение балансов аккаунтов получателей).

Схема доказывания вычисляет доказательство валидности, «проходя» по каждой транзакции и выполняя те же проверки, которые оператор завершил перед обработкой транзакции. Во-первых, она проверяет, является ли аккаунт отправителя частью существующего корня состояния, используя предоставленное доказательство Меркла. Затем она уменьшает баланс отправителя, увеличивает его нонс, хэширует обновленные данные аккаунта и объединяет их с доказательством Меркла для генерации нового корня Меркла.

Этот корень Меркла отражает единственное изменение в состоянии ZK-ролл-апа: изменение баланса и нонса отправителя. Это возможно, потому что доказательство Меркла, используемое для подтверждения существования аккаунта, используется для получения нового корня состояния.

Схема доказывания выполняет тот же процесс для аккаунта получателя. Она проверяет, существует ли аккаунт получателя под промежуточным корнем состояния (используя доказательство Меркла), увеличивает его баланс, повторно хэширует данные аккаунта и объединяет их с доказательством Меркла для генерации нового корня состояния.

Процесс повторяется для каждой транзакции; каждый «цикл» создает новый корень состояния из обновления аккаунта отправителя и последующий новый корень из обновления аккаунта получателя. Как объяснялось, каждое обновление корня состояния представляет собой изменение одной части дерева состояний ролл-апа.

Схема ZK-доказывания итерирует по всему пакету транзакций, проверяя последовательность обновлений, которые приводят к конечному корню состояния после выполнения последней транзакции. Последний вычисленный корень Меркла становится новейшим каноническим корнем состояния ZK-ролл-апа.

Проверка доказательства

После того как схема доказывания проверит правильность обновлений состояния, оператор Уровня 2 отправляет вычисленное доказательство валидности в контракт-верификатор на Уровне 1. Схема верификации контракта проверяет валидность доказательства, а также проверяет публичные входные данные, которые являются частью доказательства:

• Корень предыдущего состояния: старый корень состояния ZK-ролл-апа (т. е. до выполнения пакетных транзакций), отражающий последнее известное валидное состояние сети Уровня 2.

• Корень последующего состояния: новый корень состояния ZK-ролл-апа (т. е. после выполнения пакетных транзакций), отражающий новейшее состояние сети Уровня 2. Корень последующего состояния — это конечный корень, полученный после применения обновлений состояния в схеме доказывания.

• Корень пакета: корень Меркла пакета, полученный путем мерклизации транзакций в пакете и хэширования корня дерева.

• Входные данные транзакций: данные, связанные с транзакциями, выполненными в рамках отправленного пакета.

Если доказательство удовлетворяет схеме (т. е. является валидным), это означает, что существует последовательность валидных транзакций, которые переводят ролл-ап из предыдущего состояния (криптографически отмеченного корнем предыдущего состояния) в новое состояние (криптографически отмеченное корнем последующего состояния). Если корень предыдущего состояния совпадает с корнем, хранящимся в контракте ролл-апа, и доказательство валидно, контракт ролл-апа берет корень последующего состояния из доказательства и обновляет свое дерево состояний, чтобы отразить измененное состояние ролл-апа.

Входы и выходы

Пользователи входят в ZK-ролл-ап, внося токены в контракт ролл-апа, развернутый в сети Уровня 1. Эта транзакция ставится в очередь, так как только операторы могут отправлять транзакции в контракт ролл-апа.

Если очередь ожидающих депозитов начинает заполняться, оператор ZK-ролл-апа возьмет транзакции депозитов и отправит их в контракт ролл-апа. Как только средства пользователя оказываются в ролл-апе, они могут начать совершать транзакции, отправляя их оператору на обработку. Пользователи могут проверять балансы в ролл-апе, хэшируя данные своего аккаунта, отправляя хэш в контракт ролл-апа и предоставляя доказательство Меркла для проверки относительно текущего корня состояния.

Вывод средств из ZK-ролл-апа на Уровень 1 прост. Пользователь инициирует транзакцию выхода, отправляя свои активы в ролл-апе на указанный аккаунт для сжигания. Если оператор включит транзакцию в следующий пакет, пользователь может отправить запрос на вывод средств в контракт в сети. Этот запрос на вывод средств будет включать следующее:

• Доказательство Меркла, подтверждающее включение транзакции пользователя на аккаунт сжигания в пакет транзакций

• Данные транзакции

• Корень пакета

• Адрес Уровня 1 для получения депонированных средств

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

ZK-ролл-апы и совместимость с EVM

В отличие от оптимистических ролл-апов, ZK-ролл-апы не являются легко совместимыми с виртуальной машиной Ethereum (EVM). Доказывание вычислений EVM общего назначения в схемах сложнее и более ресурсоемко, чем доказывание простых вычислений (например, перевод токенов, описанный ранее).

Однако достижения в технологии с нулевым разглашением (opens in a new tab) вызывают возобновленный интерес к обертыванию вычислений EVM в доказательства с нулевым разглашением. Эти усилия направлены на создание реализации EVM с нулевым разглашением (zkEVM), которая может эффективно проверять правильность выполнения программы. zkEVM воссоздает существующие опкоды EVM для доказывания/проверки в схемах, что позволяет выполнять смарт-контракты.

Как и EVM, zkEVM переходит между состояниями после выполнения вычислений над некоторыми входными данными. Разница в том, что zkEVM также создает доказательства с нулевым разглашением для проверки правильности каждого шага выполнения программы. Доказательства валидности могут проверять правильность операций, затрагивающих состояние ВМ (память, стек, хранилище), и само вычисление (т. е. вызвала ли операция правильные опкоды и выполнила ли их корректно?).

Ожидается, что внедрение ZK-ролл-апов, совместимых с EVM, поможет разработчикам использовать масштабируемость и гарантии безопасности доказательств с нулевым разглашением. Что еще более важно, совместимость с нативной инфраструктурой Ethereum означает, что разработчики могут создавать дружественные к ZK децентрализованные приложения, используя знакомые (и проверенные в боях) инструменты и языки.

Как работают комиссии ZK-ролл-апов?

Сколько пользователи платят за транзакции в ZK-ролл-апах, зависит от комиссии за газ, так же как и в основной сети Ethereum. Однако комиссии за газ на Уровне 2 работают по-другому и зависят от следующих затрат:

1. Запись состояния: существует фиксированная стоимость записи в состояние Ethereum (т. е. отправки транзакции в блокчейн Ethereum). ZK-ролл-апы снижают эту стоимость, объединяя транзакции в пакеты и распределяя фиксированные затраты между несколькими пользователями.

2. Публикация данных: ZK-ролл-апы публикуют данные о состоянии для каждой транзакции в Ethereum в виде calldata. Стоимость calldata в настоящее время регулируется EIP-1559 (opens in a new tab), который устанавливает стоимость в 16 единиц газа за ненулевые байты и 4 единицы газа за нулевые байты calldata соответственно. Стоимость, уплачиваемая за каждую транзакцию, зависит от того, сколько calldata для нее необходимо опубликовать в сети.

3. Комиссии оператора Уровня 2: это сумма, выплачиваемая оператору ролл-апа в качестве компенсации за вычислительные затраты, понесенные при обработке транзакций, подобно «приоритетным комиссиям (чаевым)» за транзакции в основной сети Ethereum.

4. Генерация и проверка доказательств: операторы ZK-ролл-апов должны создавать доказательства валидности для пакетов транзакций, что является ресурсоемким процессом. Проверка доказательств с нулевым разглашением в основной сети также требует газа (~ 500 000 единиц газа).

Помимо объединения транзакций в пакеты, ZK-ролл-апы снижают комиссии для пользователей за счет сжатия данных транзакций. Вы можете увидеть обзор в реальном времени (opens in a new tab), сколько стоит использование ZK-ролл-апов Ethereum.

Как ZK-ролл-апы масштабируют Ethereum?

Сжатие данных транзакций

ZK-ролл-апы увеличивают пропускную способность базового уровня Ethereum, вынося вычисления за пределы сети, но настоящий прирост в масштабировании достигается за счет сжатия данных транзакций. Размер блока Ethereum ограничивает объем данных, который может содержать каждый блок, и, следовательно, количество транзакций, обрабатываемых в каждом блоке. Сжимая данные, связанные с транзакциями, ZK-ролл-апы значительно увеличивают количество транзакций, обрабатываемых в каждом блоке.

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

Рекурсивные доказательства

Преимущество доказательств с нулевым разглашением заключается в том, что доказательства могут проверять другие доказательства. Например, один ZK-SNARK может проверять другие ZK-SNARK. Такие «доказательства доказательств» называются рекурсивными доказательствами и значительно увеличивают пропускную способность ZK-ролл-апов.

В настоящее время доказательства валидности генерируются для каждого блока и отправляются в контракт Уровня 1 для проверки. Однако проверка доказательств для одного блока ограничивает пропускную способность, которую могут достичь ZK-ролл-апы, поскольку только один блок может быть финализирован, когда оператор отправляет доказательство.

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

Плюсы и минусы ZK-ролл-апов

Визуальное объяснение ZK-ролл-апов

Посмотрите объяснение ZK-ролл-апов от Finematics:

Кто работает над zkEVM?

Проекты, работающие над zkEVM, включают:

• zkEVM (opens in a new tab) — zkEVM — это проект, финансируемый Ethereum Foundation, для разработки ZK-ролл-апа, совместимого с EVM, и механизма для генерации доказательств валидности для блоков Ethereum.

• Polygon zkEVM (opens in a new tab) — это децентрализованный ZK-ролл-ап в основной сети Ethereum, работающий над виртуальной машиной Ethereum с нулевым разглашением (zkEVM), которая прозрачно выполняет транзакции Ethereum, включая смарт-контракты с валидацией через доказательства с нулевым разглашением.

• Scroll (opens in a new tab) — Scroll — это технологическая компания, работающая над созданием нативного решения Уровня 2 zkEVM для Ethereum.

• Taiko (opens in a new tab) — Taiko — это децентрализованный, эквивалентный Ethereum ZK-ролл-ап (Тип 1 ZK-EVM (opens in a new tab)).

• ZKsync (opens in a new tab) — ZKsync Era — это ZK-ролл-ап, совместимый с EVM, созданный Matter Labs и работающий на собственном zkEVM.

• Starknet (opens in a new tab) — StarkNet — это решение для масштабирования второго уровня, совместимое с EVM, созданное StarkWare.

• Morph (opens in a new tab) — Morph — это гибридное решение для масштабирования ролл-апов, которое использует zk-доказательства для решения проблемы с состоянием на Уровне 2.

• Linea (opens in a new tab) — Linea — это эквивалентный Ethereum zkEVM Уровня 2, созданный Consensys и полностью согласованный с экосистемой Ethereum.

Дополнительные материалы для чтения о ZK-ролл-апах

• Что такое ролл-апы с нулевым разглашением? (opens in a new tab)
• Что такое ролл-апы с нулевым разглашением? (opens in a new tab)
• Практическое руководство по ролл-апам Ethereum (opens in a new tab)
• STARKs против SNARKs (opens in a new tab)
• Что такое zkEVM? (opens in a new tab)
• Типы ZK-EVM: эквивалентные Ethereum, эквивалентные EVM, Тип 1, Тип 4 и другие загадочные модные словечки (opens in a new tab)
• Введение в zkEVM (opens in a new tab)
• Что такое ZK-EVM Уровня 2? (opens in a new tab)
• Потрясающие ресурсы по zkEVM (opens in a new tab)
• ZK-SNARKS под капотом (opens in a new tab)
• Как возможны SNARKs? (opens in a new tab)