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

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

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

Вы должны прочитать и понять наши страницы о масштабировании Эфириума и уровне 2 (l2).

Что такое роллапы с нулевым разглашением?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транзакции

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

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

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

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

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

Коммитменты состояния

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

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

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

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

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

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

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

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

zk-SNARK

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

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

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

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

ZK-STARK

Как и 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 является то, что они создают доказательства большего размера, проверка которых в Эфириуме обходится дороже.

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

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

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

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

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

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

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

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

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

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

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

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

После того как схема доказательства проверяет правильность обновлений состояния, оператор L2 отправляет вычисленное доказательство достоверности в контракт верификатора на L1. Схема проверки контракта проверяет достоверность доказательства, а также проверяет открытые входные данные, которые являются частью доказательства:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Комиссии оператора L2: Это сумма, выплачиваемая оператору роллапа в качестве компенсации за вычислительные затраты, понесенные при обработке транзакций, во многом похожая на «приоритетные комиссии (чаевые)» за транзакцию в основной сети Ethereum.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Linea (opens in a new tab) — Linea — это эквивалентный Эфириуму уровень 2 (l2) zkEVM, созданный ConsenSys и полностью согласованный с экосистемой Эфириума.

Дополнительная литература о ZK-роллапах

• Что такое роллапы с нулевым разглашением? (opens in a new tab)
• Что такое роллапы с нулевым разглашением? (opens in a new tab)
• Практическое руководство по роллапам Эфириума (opens in a new tab)
• STARK против SNARK (opens in a new tab)
• Что такое zkEVM? (opens in a new tab)
• Типы ZK-EVM: эквивалентные Эфириуму, эквивалентные EVM, тип 1, тип 4 и другие загадочные модные словечки (opens in a new tab)
• Введение в zkEVM (opens in a new tab)
• Что такое L2 на базе ZK-EVM? (opens in a new tab)
• Ресурсы Awesome-zkEVM (opens in a new tab)
• Как работают zk-SNARK (opens in a new tab)
• Как возможны SNARK? (opens in a new tab)

Руководства: Приватность и нулевое разглашение в Эфириуме

• Использование нулевого разглашения для секретного состояния — Как использовать ZK-доказательства и офчейн-компоненты сервера для поддержания секретного состояния игры ончейн.
• Использование скрытых адресов — Как скрытые адреса ERC-5564 обеспечивают анонимные переводы ETH с использованием криптографического вывода ключей.
• Использование Эфириума для аутентификации Веб2 — Как интегрировать подписи кошелька Эфириума с системами аутентификации Веб2 на основе SAML.