Переслать оригинальное название '[ZK series - 1] ZK Rollups: Elephant In the Room'
Рисунок 1: ZK — хорошее модное словечко
(Источник: imgflip)
Нынешнее состояние блокчейн-индустрии можно сравнить с эпохой Zero-Knowledge (ZK). Куда ни глянь, везде ЗК на виду... Становится все более редким найти блокчейн-проекты нового поколения, которые не включают ZK в свои названия. С технической точки зрения нельзя отрицать, что ZK является многообещающей технологией, способной внести свой вклад в более масштабируемую и частную экосистему блокчейна. Тем не менее, из-за сложного технического бэкграунда ZK, многие инвесторы, как розничные, так и институциональные, часто вкладывают средства в проекты ZK, основываясь на «вере» в то, что они выглядят круто, новы и могут решить трилемму блокчейна, не понимая в полной мере, какую пользу приносит технология ZK.
В этой серии статей мы рассмотрим как неудобные истины (недостатки и недостатки), так и полезные приложения ZK-роллапов. Во-первых, мы раскроем два основных свойства ZK-доказательств (ZKP) для блокчейнов: «нулевое разглашение» и «лаконичность»; Затем мы обсудим, почему большое количество ZK-роллапов, находящихся в настоящее время в сервисе, на самом деле не используют аспект «нулевого разглашения». Далее мы рассмотрим области, в которых применение ZK-роллапа скорее вредно, чем полезно, избегая общеизвестных проблем, таких как сложность реализации. Наконец, мы выделим образцовые проекты, которые эффективно воплощают принципы ZK и на самом деле демонстрируют ощутимую выгоду от использования технологии ZK.
Роллапы — это решение для масштабирования, которое устраняет ограничения пропускной способности L1 путем выполнения пакетов транзакций вне сети, а затем хранения сводных данных о последнем состоянии L2 на L1. Среди них ZK-роллапы выделяются своей способностью быстро выводить средства, предоставляя доказательства действительности для внесетевых вычислений в сети. Прежде чем мы углубимся в проблемы с ZK-роллапами, давайте кратко подведем итоги их жизненного цикла транзакций.
Рисунок 2: Жизненный цикл транзакций в ZK-роллапах
(Источник: Presto Reserach)
(Обратите внимание, что это объяснение является упрощенной версией полного процесса свертки ZK, и каждая из реализаций может варьироваться в зависимости от протокола. Сущностей в L2 может быть больше, если мы разделим роли; таких как агрегаторы, исполнители и инициаторы. Уровни блоков данных также могут различаться, такие как блоки, блоки и пакеты, в зависимости от их использования. Приведенное выше объяснение предполагает ситуацию, когда централизованный секвенсор имеет строгие полномочия, которые выполняют транзакции, а также создают унифицированный формат фрагментов данных в виде пакетов.
В отличие от оптимистичных роллапов, благодаря ZKP (например, ZK-SNARK или ZK-STARK), ZK-роллапы могут проверять правильность выполнения тысяч транзакций, просто проверяя простое доказательство, не воспроизводя их все. Итак, что же это за ЗКП, и какими характеристиками он обладает?
Как следует из названия, ZKP в основном является доказательством. Доказательством может быть все, что может в достаточной степени подтвердить утверждение доказывателя. Допустим, Боб (доказатель) хочет убедить Алису (верификатор) в авторитетности своего портативного компьютера. Самый простой способ доказать это — Боб просто сообщает Алисе пароль, а Алиса вводит пароль на ноутбуке и проверяет, есть ли у Боба полномочия. Однако этот процесс проверки неудовлетворителен как для Алисы, так и для Боба. Если Боб установил очень длинный и запутанный пароль, Алисе будет очень сложно правильно его ввести (предположим, что Алиса не может копировать и вставлять). Более реалистично, Боб может не захотеть раскрывать свой пароль Алисе, чтобы доказать свою власть.
Что делать, если существует процесс проверки, в котором Алиса может быстро проверить полномочия компьютера, не раскрывая Бобу свой пароль? Например, Боб может просто коснуться пальцем, чтобы разблокировать ноутбук с сенсорным идентификатором перед Алисой, как показано на рисунке 3 (обратите внимание, что это не идеальный пример для ZKP). Именно здесь и Алиса, и Боб могут извлечь выгоду из обоих ключевых свойств ZKP: свойства нулевого разглашения и свойства краткости.
Рисунок 3: Высокоуровневая интуиция нулевого разглашения и лаконичности
(Источник: imgflip)
Свойство «нулевое разглашение» относится к случаю, когда доказательство, сгенерированное доказывающим, ничего не раскрывает о секретном свидетеле (т.е. о личных данных), в результате чего проверяющий ничего не знает о данных, кроме достоверности доказательства. В блокчейне это свойство может быть использовано для сохранения конфиденциальности отдельных пользователей. Если ZKP применяются для каждой транзакции, пользователи могут доказать законность своих действий (т.е. доказать, что у пользователя достаточно средств для совершения транзакции), не раскрывая детали своих транзакций (например, переводы, обновления баланса счета, развертывание смарт-контрактов и выполнение смарт-контрактов) общественности.
Другое свойство, «краткость», относится к способности ZK генерировать короткие и быстро проверяемые доказательства из утверждения большого размера. Другими словами, это консолидация чего-то большого во что-то компактное. В блокчейне это особенно используется в роллапах. С помощью ZKP проверяющие в L2 могут претендовать на правильное выполнение транзакций, отправив краткое доказательство верификатору в L1 (действительность терабайт транзакций может быть представлена 10~100 КБ доказательства). Затем верификаторы могут легко подтвердить действительность исполнений за короткое время (т.е. 10 мс ~ 1 с), проверив краткое доказательство вместо того, чтобы воспроизводить все транзакции.
Вышеупомянутые характеристики ZKP хорошо используются в ZK-роллапах. Несмотря на то, что верификаторы не могут вывести исходные данные транзакции из ZKP, полученных от доказывающего, проверка краткого доказательства позволяет им эффективно проверить утверждение проверяющего (т. е. новое состояние L2). Тем не менее, утверждение о том, что свертки ZK в их текущей итерации полностью соответствуют свойствам нулевого разглашения и краткости, вводит в заблуждение. Это может быть верно, если сосредоточено исключительно на взаимодействии между проверяющим и верификатором, но в ZK-роллапах также существуют и другие компоненты, такие как узлы секвенсора, прувера и свертки. Гарантирован ли принцип «нулевого разглашения» и для них?
Проблема достижения полной конфиденциальности с помощью ZKP в любых ZK-роллапах возникает из-за потенциальной компрометации, если другие части остаются общедоступными, в то время как некоторые становятся частными ZK. Подумайте о жизненном цикле транзакций в ZK-роллапах — сохраняется ли конфиденциальность, когда транзакция отправляется от пользователя в секвенсоры? А как насчет пруверов? Или конфиденциальность информации об отдельной учетной записи сохраняется при отправке пакета L2 на уровень DA? Ни один из сценариев в настоящее время не верен.
Рисунок 4: Утечка конфиденциальности в ZK-роллапах
(Источник: Presto Research)
В большинстве основных ZK-роллапов секвенсор или прувер (или некоторые другие централизованные организации с сильными полномочиями) имеет четкое представление о деталях транзакции, включая суммы переводов, обновления баланса счета, развертывание и исполнение контрактов. В качестве простого примера, вы можете легко увидеть все упомянутые детали, посетив любой из обозревателей блоков ZK rollup. Кроме того, рассмотрим ситуацию, когда централизованный секвенсор каким-то образом не работает, а другой узел объединения пытается восстановить состояние свертки. Он соберет публично опубликованные данные L2 с уровня DA (которым в большинстве случаев является L1 Ethereum) и реконструирует состояние L2. В этом процессе любой узел, способный воспроизводить транзакции L2, хранящиеся на уровне DA, может восстановить информацию о состоянии учетной записи каждого пользователя.
Таким образом, термин «нулевое разглашение» реализован в фрагментарном виде в текущих ZK-роллапах. Хотя это нельзя считать неверным, очевидно, что это отличается от общепринятого представления о том, что «ZK означает нулевое разглашение и приравнивается к полной конфиденциальности». Новизна текущих ZK-роллапов заключается в использовании свойства «краткости», а не «нулевого разглашения», которое заключается в выполнении транзакций вне блокчейна, и создании кратких доказательств для верификаторов, чтобы проверить действительность выполнения быстрым и масштабируемым способом без их повторного выполнения.
По этой причине некоторые ZK-роллапы, такие как Starknet, называют себя «Валидными роллапами», чтобы избежать путаницы, в то время как другие, обеспечивающие истинную конфиденциальность ZK, такие как Aztec, помечают себя как ZK-ZK роллапы.
Как упоминалось выше, конфиденциальность ZK не полностью реализована в большинстве ZK-роллапов. Итак, какой должна быть наша следующая цель? Достижение полной конфиденциальности транзакций за счет полного развертывания ZK в каждой части накопительного пакета? На самом деле это непростая проблема. Помимо необходимости значительного технологического прогресса для дальнейшего совершенствования технологии, для ZK остаются спорные вопросы с точки зрения идеологии (например, незаконное использование частных транзакций) и практичности (например, полезно ли это на самом деле?). Учитывая, что обсуждение моральности полной конфиденциальности транзакций выходит за рамки этой статьи, давайте сосредоточим наше внимание на двух практических моментах ZK-роллапов, с которыми сталкиваются блокчейн-проекты.
Давайте сначала поговорим о практичности самих ZK-роллапов. Наиболее привлекательным преимуществом роллапов ZK является короткая задержка вывода активов из-за «быстрого завершения» транзакций благодаря ZKP. Бонусом являются улучшенные TPS и низкие комиссии за транзакции. Сектором, который наиболее эффективно использует характеристики ZK-роллапов, является гейминг, поскольку ввод и вывод внутриигровой валюты происходит очень часто, и каждую секунду генерируется большой объем внутриигровых транзакций.
Но можно ли считать ZK-роллапы оптимальным стеком для игр? Для этого нам нужно немного больше подумать о концепции «быстрой завершенности» в ZK-роллапах. Представьте ситуацию, когда один пользователь наслаждается игрой Web3, запущенной на стеке на основе ZK-роллапа. Пользователь обменивает внутриигровой предмет на внутриигровую валюту и пытается вывести этот актив из игры.
Чтобы вывести актив, внутриигровая транзакция должна быть завершена; это означает, что транзакция должна быть включена в новое обязательство по состоянию свертки, соответствующий ZKP должен быть отправлен L1, и нужно подождать, пока доказательство будет завершено в L1 Ethereum, чтобы гарантировать, что транзакция не может быть отменена. Если бы все эти процессы происходили мгновенно, то да, мы могли бы добиться «мгновенного подтверждения транзакции», за которое часто рекламируются ZK-роллапы, позволяя пользователю сразу же вывести актив.
Однако реальность далека от этого. Согласно статистике, предоставленной L2beat о времени завершения для различных ZK-роллапов, zkSync Era занимает около 2 часов, Linea — 3 часа, а Starknet — в среднем около 8 часов. Это связано с тем, что требуется время для создания ZKP от доказывающего, и требуется дополнительное время, чтобы включить больше транзакций в один пакет (т. е. одно доказательство), чтобы снизить стоимость транзакционных сборов. Другими словами, скорость генерации и отправки доказательств является потенциальным узким местом для достижения быстрой финализации в ZK-роллапах, что может снизить пользовательский опыт в играх Web3.
Рисунок 5: Генерация ZKP может быть потенциальным узким местом для быстрой финализации в ZK-роллапах
(Источник: imgflip)
С другой стороны, оптимизированные для игр цепочки, такие как Ronin (на основе таких игр Web3, как Pixels и Axie Infinity), обеспечивают сверхбыструю завершенность, жертвуя при этом децентрализацией и безопасностью. Ronin — это не ZK или блокчейн на основе роллапа: это блокчейн EVM, который работает под алгоритмом консенсуса PoA (Proof of Authority) + DPoS (Delegated Proof of Stake). Он выбирает 22 валидатора на основе суммы делегированного стейка, затем эти валидаторы просто генерируют и проверяют блоки в стиле PoA (т.е. процесс голосования только среди 22 валидаторов). Следовательно, транзакции в Ronin завершаются быстро, так как он почти не имеет задержек для включения транзакций в блок и занимает мало времени для проверки. После хардфорка Shillin на завершение каждой транзакции уходит в среднем всего 6 секунд . Всего этого Ронин добивается и без ЗКП.
И да, конечно, у Ronin есть и недостатки. Управление централизованными валидаторами делает его относительно более уязвимым для атаки 51%. Более того, поскольку он не использует Ethereum в качестве расчетного уровня, он не может унаследовать безопасность Ethereum. Риски безопасности, связанные с использованием кроссчейн-моста, также существуют. Но подумайте с точки зрения пользователей: будет ли их это волновать? Текущие объединения ZK без децентрализованной последовательности также страдают от проблемы единой точки отказа (SPOF). Ethereum предлагает им уверенность, поскольку снижает вероятность отмены транзакций, но если централизованный секвенсор или прувер выходит из строя, ZK-роллапы также зависают. Еще раз обратите внимание, что "ZK" в ZK-роллапах используется только для проверки правильности выполнения. Если есть другой проект, предлагающий ту же функциональность, что и ZK-роллапы, но быстрее и дешевле, ZK-роллапы больше не могут считаться главным приоритетом для пользователей и разработчиков игр Web3.
Еще одним моментом является практичность реализации протоколов для ZK-роллапов. Среди них мы сосредоточимся на публикации различий состояний, которая является одним из способов обеспечения доступности данных (см. Unlocking Dencun Upgrade: Unseen Truth of Scaling DA Layers, Jaehyun Ha, 12Apr24) в ZK-роллапах.
Простой способ понять доступность данных в сводках — это представить себе альпиниста-любителя, сертифицирующего и записывающего свое восхождение на Эверест. Самый простой способ — записывать на видео каждый шаг восхождения от базового лагеря до вершины. Несмотря на то, что видеофайл может быть большим, любой желающий может проверить восхождение альпиниста на Эверест и, возможно, воспроизвести отснятый материал. Эту аналогию можно сравнить с методом публикации необработанных данных о транзакциях для обеспечения доступности данных. Оптимистичные свертки следуют этому подходу, чтобы заставить отдельные претенденты воспроизводить и проверять правильность выполнения, так как нет ничего, чему можно было бы доверять в приверженности состояния секвенсора. Среди ZK-накопителей Polygon zkEVM и Scroll используют этот подход, сохраняя необработанные данные транзакций L2 в сжатом виде на L1, чтобы любой мог воспроизвести транзакции L2 для восстановления состояния накопителя при необходимости.
Возвращаясь к примеру альпиниста-любителя, альтернативным методом проверки может быть восхождение выдающегося альпиниста на Эверест вместе с альпинистом-любителем, чтобы убедиться в том, что восхождение действительно завершено. Поскольку восхождение было сертифицировано доверенным лицом, альпинисту больше не нужно записывать каждый шаг для документирования. Достаточно было просто сделать фотографию в начальной точке и еще одну на вершине, а другие просто считали бы, что альпинист достиг вершины. Эта аналогия отражает метод сравнения состояний, используемый для обеспечения доступности данных. В ZK-роллапах zkSync Era и StarkNet используют этот подход, сохраняя только разницу состояний до и после выполнения транзакций L2 на L1, чтобы любой мог вычислить различия состояний из генезиса для восстановления состояния накопителя, когда это необходимо.
Рисунок 6: Публикация необработанных транзакций в сравнении с публикацией различий состояний
(Источник: Presto Research)
Этот подход с разницей состояний, несомненно, выгоден с точки зрения затрат по сравнению с подходом к публикации необработанных данных транзакций, поскольку он позволяет пропустить хранение промежуточных транзакций, снижая стоимость хранения в L1. Однако, несмотря на то, что это не является проблемой, здесь есть основной недостаток: этот подход не позволяет восстановить полную историю транзакций L2, что может быть проблемой для некоторых DApps.
Давайте возьмем в качестве примера Compound, протокол кредитования DeFi, и предположим, что он построен на основе подхода ZK rollup stack на основе подхода с различиями состояний. Эти протоколы требуют полную историю транзакций, чтобы каждую секунду рассчитывать предложение и процентные ставки по займам. Но что произойдёт, если каким-то образом секвенсор ZK rollup выйдет из строя, а другие узлы свертывания попытаются восстановить последнее состояние? Он может восстановить состояние, но процентная ставка будет восстановлена неточно, поскольку он может отслеживать только снимки между пакетами, а не все промежуточные транзакции.
В этой статье в основном утверждается, что в большинстве современных ZK-роллапов нет «ZK», и в DApps есть много областей, в которых использование ZKP и ZK-роллапов может быть не самым оптимальным выбором. Технология ZK может казаться невинной из-за того, что ее обвиняют; потому что в нем нет ничего плохого по своей сути — просто в процессе использования своих технических достижений он может привести к потенциальному снижению производительности в DApps. Однако это не значит, что технологии ЗК бесполезны для этой отрасли. Когда ZKP и ZK-роллапы в конечном итоге достигнут технической зрелости, они, безусловно, могут предоставить еще лучшие решения для решения трилеммы блокчейна. На самом деле, существуют проекты на основе ZK, которые поддерживают конфиденциальность ZK, а также множество типов DApps, которые эффективно используют преимущества ZKP и ZK-роллапов. Мы рассмотрим это подробнее в следующей статье - следите за обновлениями!
Переслать оригинальное название '[ZK series - 1] ZK Rollups: Elephant In the Room'
Рисунок 1: ZK — хорошее модное словечко
(Источник: imgflip)
Нынешнее состояние блокчейн-индустрии можно сравнить с эпохой Zero-Knowledge (ZK). Куда ни глянь, везде ЗК на виду... Становится все более редким найти блокчейн-проекты нового поколения, которые не включают ZK в свои названия. С технической точки зрения нельзя отрицать, что ZK является многообещающей технологией, способной внести свой вклад в более масштабируемую и частную экосистему блокчейна. Тем не менее, из-за сложного технического бэкграунда ZK, многие инвесторы, как розничные, так и институциональные, часто вкладывают средства в проекты ZK, основываясь на «вере» в то, что они выглядят круто, новы и могут решить трилемму блокчейна, не понимая в полной мере, какую пользу приносит технология ZK.
В этой серии статей мы рассмотрим как неудобные истины (недостатки и недостатки), так и полезные приложения ZK-роллапов. Во-первых, мы раскроем два основных свойства ZK-доказательств (ZKP) для блокчейнов: «нулевое разглашение» и «лаконичность»; Затем мы обсудим, почему большое количество ZK-роллапов, находящихся в настоящее время в сервисе, на самом деле не используют аспект «нулевого разглашения». Далее мы рассмотрим области, в которых применение ZK-роллапа скорее вредно, чем полезно, избегая общеизвестных проблем, таких как сложность реализации. Наконец, мы выделим образцовые проекты, которые эффективно воплощают принципы ZK и на самом деле демонстрируют ощутимую выгоду от использования технологии ZK.
Роллапы — это решение для масштабирования, которое устраняет ограничения пропускной способности L1 путем выполнения пакетов транзакций вне сети, а затем хранения сводных данных о последнем состоянии L2 на L1. Среди них ZK-роллапы выделяются своей способностью быстро выводить средства, предоставляя доказательства действительности для внесетевых вычислений в сети. Прежде чем мы углубимся в проблемы с ZK-роллапами, давайте кратко подведем итоги их жизненного цикла транзакций.
Рисунок 2: Жизненный цикл транзакций в ZK-роллапах
(Источник: Presto Reserach)
(Обратите внимание, что это объяснение является упрощенной версией полного процесса свертки ZK, и каждая из реализаций может варьироваться в зависимости от протокола. Сущностей в L2 может быть больше, если мы разделим роли; таких как агрегаторы, исполнители и инициаторы. Уровни блоков данных также могут различаться, такие как блоки, блоки и пакеты, в зависимости от их использования. Приведенное выше объяснение предполагает ситуацию, когда централизованный секвенсор имеет строгие полномочия, которые выполняют транзакции, а также создают унифицированный формат фрагментов данных в виде пакетов.
В отличие от оптимистичных роллапов, благодаря ZKP (например, ZK-SNARK или ZK-STARK), ZK-роллапы могут проверять правильность выполнения тысяч транзакций, просто проверяя простое доказательство, не воспроизводя их все. Итак, что же это за ЗКП, и какими характеристиками он обладает?
Как следует из названия, ZKP в основном является доказательством. Доказательством может быть все, что может в достаточной степени подтвердить утверждение доказывателя. Допустим, Боб (доказатель) хочет убедить Алису (верификатор) в авторитетности своего портативного компьютера. Самый простой способ доказать это — Боб просто сообщает Алисе пароль, а Алиса вводит пароль на ноутбуке и проверяет, есть ли у Боба полномочия. Однако этот процесс проверки неудовлетворителен как для Алисы, так и для Боба. Если Боб установил очень длинный и запутанный пароль, Алисе будет очень сложно правильно его ввести (предположим, что Алиса не может копировать и вставлять). Более реалистично, Боб может не захотеть раскрывать свой пароль Алисе, чтобы доказать свою власть.
Что делать, если существует процесс проверки, в котором Алиса может быстро проверить полномочия компьютера, не раскрывая Бобу свой пароль? Например, Боб может просто коснуться пальцем, чтобы разблокировать ноутбук с сенсорным идентификатором перед Алисой, как показано на рисунке 3 (обратите внимание, что это не идеальный пример для ZKP). Именно здесь и Алиса, и Боб могут извлечь выгоду из обоих ключевых свойств ZKP: свойства нулевого разглашения и свойства краткости.
Рисунок 3: Высокоуровневая интуиция нулевого разглашения и лаконичности
(Источник: imgflip)
Свойство «нулевое разглашение» относится к случаю, когда доказательство, сгенерированное доказывающим, ничего не раскрывает о секретном свидетеле (т.е. о личных данных), в результате чего проверяющий ничего не знает о данных, кроме достоверности доказательства. В блокчейне это свойство может быть использовано для сохранения конфиденциальности отдельных пользователей. Если ZKP применяются для каждой транзакции, пользователи могут доказать законность своих действий (т.е. доказать, что у пользователя достаточно средств для совершения транзакции), не раскрывая детали своих транзакций (например, переводы, обновления баланса счета, развертывание смарт-контрактов и выполнение смарт-контрактов) общественности.
Другое свойство, «краткость», относится к способности ZK генерировать короткие и быстро проверяемые доказательства из утверждения большого размера. Другими словами, это консолидация чего-то большого во что-то компактное. В блокчейне это особенно используется в роллапах. С помощью ZKP проверяющие в L2 могут претендовать на правильное выполнение транзакций, отправив краткое доказательство верификатору в L1 (действительность терабайт транзакций может быть представлена 10~100 КБ доказательства). Затем верификаторы могут легко подтвердить действительность исполнений за короткое время (т.е. 10 мс ~ 1 с), проверив краткое доказательство вместо того, чтобы воспроизводить все транзакции.
Вышеупомянутые характеристики ZKP хорошо используются в ZK-роллапах. Несмотря на то, что верификаторы не могут вывести исходные данные транзакции из ZKP, полученных от доказывающего, проверка краткого доказательства позволяет им эффективно проверить утверждение проверяющего (т. е. новое состояние L2). Тем не менее, утверждение о том, что свертки ZK в их текущей итерации полностью соответствуют свойствам нулевого разглашения и краткости, вводит в заблуждение. Это может быть верно, если сосредоточено исключительно на взаимодействии между проверяющим и верификатором, но в ZK-роллапах также существуют и другие компоненты, такие как узлы секвенсора, прувера и свертки. Гарантирован ли принцип «нулевого разглашения» и для них?
Проблема достижения полной конфиденциальности с помощью ZKP в любых ZK-роллапах возникает из-за потенциальной компрометации, если другие части остаются общедоступными, в то время как некоторые становятся частными ZK. Подумайте о жизненном цикле транзакций в ZK-роллапах — сохраняется ли конфиденциальность, когда транзакция отправляется от пользователя в секвенсоры? А как насчет пруверов? Или конфиденциальность информации об отдельной учетной записи сохраняется при отправке пакета L2 на уровень DA? Ни один из сценариев в настоящее время не верен.
Рисунок 4: Утечка конфиденциальности в ZK-роллапах
(Источник: Presto Research)
В большинстве основных ZK-роллапов секвенсор или прувер (или некоторые другие централизованные организации с сильными полномочиями) имеет четкое представление о деталях транзакции, включая суммы переводов, обновления баланса счета, развертывание и исполнение контрактов. В качестве простого примера, вы можете легко увидеть все упомянутые детали, посетив любой из обозревателей блоков ZK rollup. Кроме того, рассмотрим ситуацию, когда централизованный секвенсор каким-то образом не работает, а другой узел объединения пытается восстановить состояние свертки. Он соберет публично опубликованные данные L2 с уровня DA (которым в большинстве случаев является L1 Ethereum) и реконструирует состояние L2. В этом процессе любой узел, способный воспроизводить транзакции L2, хранящиеся на уровне DA, может восстановить информацию о состоянии учетной записи каждого пользователя.
Таким образом, термин «нулевое разглашение» реализован в фрагментарном виде в текущих ZK-роллапах. Хотя это нельзя считать неверным, очевидно, что это отличается от общепринятого представления о том, что «ZK означает нулевое разглашение и приравнивается к полной конфиденциальности». Новизна текущих ZK-роллапов заключается в использовании свойства «краткости», а не «нулевого разглашения», которое заключается в выполнении транзакций вне блокчейна, и создании кратких доказательств для верификаторов, чтобы проверить действительность выполнения быстрым и масштабируемым способом без их повторного выполнения.
По этой причине некоторые ZK-роллапы, такие как Starknet, называют себя «Валидными роллапами», чтобы избежать путаницы, в то время как другие, обеспечивающие истинную конфиденциальность ZK, такие как Aztec, помечают себя как ZK-ZK роллапы.
Как упоминалось выше, конфиденциальность ZK не полностью реализована в большинстве ZK-роллапов. Итак, какой должна быть наша следующая цель? Достижение полной конфиденциальности транзакций за счет полного развертывания ZK в каждой части накопительного пакета? На самом деле это непростая проблема. Помимо необходимости значительного технологического прогресса для дальнейшего совершенствования технологии, для ZK остаются спорные вопросы с точки зрения идеологии (например, незаконное использование частных транзакций) и практичности (например, полезно ли это на самом деле?). Учитывая, что обсуждение моральности полной конфиденциальности транзакций выходит за рамки этой статьи, давайте сосредоточим наше внимание на двух практических моментах ZK-роллапов, с которыми сталкиваются блокчейн-проекты.
Давайте сначала поговорим о практичности самих ZK-роллапов. Наиболее привлекательным преимуществом роллапов ZK является короткая задержка вывода активов из-за «быстрого завершения» транзакций благодаря ZKP. Бонусом являются улучшенные TPS и низкие комиссии за транзакции. Сектором, который наиболее эффективно использует характеристики ZK-роллапов, является гейминг, поскольку ввод и вывод внутриигровой валюты происходит очень часто, и каждую секунду генерируется большой объем внутриигровых транзакций.
Но можно ли считать ZK-роллапы оптимальным стеком для игр? Для этого нам нужно немного больше подумать о концепции «быстрой завершенности» в ZK-роллапах. Представьте ситуацию, когда один пользователь наслаждается игрой Web3, запущенной на стеке на основе ZK-роллапа. Пользователь обменивает внутриигровой предмет на внутриигровую валюту и пытается вывести этот актив из игры.
Чтобы вывести актив, внутриигровая транзакция должна быть завершена; это означает, что транзакция должна быть включена в новое обязательство по состоянию свертки, соответствующий ZKP должен быть отправлен L1, и нужно подождать, пока доказательство будет завершено в L1 Ethereum, чтобы гарантировать, что транзакция не может быть отменена. Если бы все эти процессы происходили мгновенно, то да, мы могли бы добиться «мгновенного подтверждения транзакции», за которое часто рекламируются ZK-роллапы, позволяя пользователю сразу же вывести актив.
Однако реальность далека от этого. Согласно статистике, предоставленной L2beat о времени завершения для различных ZK-роллапов, zkSync Era занимает около 2 часов, Linea — 3 часа, а Starknet — в среднем около 8 часов. Это связано с тем, что требуется время для создания ZKP от доказывающего, и требуется дополнительное время, чтобы включить больше транзакций в один пакет (т. е. одно доказательство), чтобы снизить стоимость транзакционных сборов. Другими словами, скорость генерации и отправки доказательств является потенциальным узким местом для достижения быстрой финализации в ZK-роллапах, что может снизить пользовательский опыт в играх Web3.
Рисунок 5: Генерация ZKP может быть потенциальным узким местом для быстрой финализации в ZK-роллапах
(Источник: imgflip)
С другой стороны, оптимизированные для игр цепочки, такие как Ronin (на основе таких игр Web3, как Pixels и Axie Infinity), обеспечивают сверхбыструю завершенность, жертвуя при этом децентрализацией и безопасностью. Ronin — это не ZK или блокчейн на основе роллапа: это блокчейн EVM, который работает под алгоритмом консенсуса PoA (Proof of Authority) + DPoS (Delegated Proof of Stake). Он выбирает 22 валидатора на основе суммы делегированного стейка, затем эти валидаторы просто генерируют и проверяют блоки в стиле PoA (т.е. процесс голосования только среди 22 валидаторов). Следовательно, транзакции в Ronin завершаются быстро, так как он почти не имеет задержек для включения транзакций в блок и занимает мало времени для проверки. После хардфорка Shillin на завершение каждой транзакции уходит в среднем всего 6 секунд . Всего этого Ронин добивается и без ЗКП.
И да, конечно, у Ronin есть и недостатки. Управление централизованными валидаторами делает его относительно более уязвимым для атаки 51%. Более того, поскольку он не использует Ethereum в качестве расчетного уровня, он не может унаследовать безопасность Ethereum. Риски безопасности, связанные с использованием кроссчейн-моста, также существуют. Но подумайте с точки зрения пользователей: будет ли их это волновать? Текущие объединения ZK без децентрализованной последовательности также страдают от проблемы единой точки отказа (SPOF). Ethereum предлагает им уверенность, поскольку снижает вероятность отмены транзакций, но если централизованный секвенсор или прувер выходит из строя, ZK-роллапы также зависают. Еще раз обратите внимание, что "ZK" в ZK-роллапах используется только для проверки правильности выполнения. Если есть другой проект, предлагающий ту же функциональность, что и ZK-роллапы, но быстрее и дешевле, ZK-роллапы больше не могут считаться главным приоритетом для пользователей и разработчиков игр Web3.
Еще одним моментом является практичность реализации протоколов для ZK-роллапов. Среди них мы сосредоточимся на публикации различий состояний, которая является одним из способов обеспечения доступности данных (см. Unlocking Dencun Upgrade: Unseen Truth of Scaling DA Layers, Jaehyun Ha, 12Apr24) в ZK-роллапах.
Простой способ понять доступность данных в сводках — это представить себе альпиниста-любителя, сертифицирующего и записывающего свое восхождение на Эверест. Самый простой способ — записывать на видео каждый шаг восхождения от базового лагеря до вершины. Несмотря на то, что видеофайл может быть большим, любой желающий может проверить восхождение альпиниста на Эверест и, возможно, воспроизвести отснятый материал. Эту аналогию можно сравнить с методом публикации необработанных данных о транзакциях для обеспечения доступности данных. Оптимистичные свертки следуют этому подходу, чтобы заставить отдельные претенденты воспроизводить и проверять правильность выполнения, так как нет ничего, чему можно было бы доверять в приверженности состояния секвенсора. Среди ZK-накопителей Polygon zkEVM и Scroll используют этот подход, сохраняя необработанные данные транзакций L2 в сжатом виде на L1, чтобы любой мог воспроизвести транзакции L2 для восстановления состояния накопителя при необходимости.
Возвращаясь к примеру альпиниста-любителя, альтернативным методом проверки может быть восхождение выдающегося альпиниста на Эверест вместе с альпинистом-любителем, чтобы убедиться в том, что восхождение действительно завершено. Поскольку восхождение было сертифицировано доверенным лицом, альпинисту больше не нужно записывать каждый шаг для документирования. Достаточно было просто сделать фотографию в начальной точке и еще одну на вершине, а другие просто считали бы, что альпинист достиг вершины. Эта аналогия отражает метод сравнения состояний, используемый для обеспечения доступности данных. В ZK-роллапах zkSync Era и StarkNet используют этот подход, сохраняя только разницу состояний до и после выполнения транзакций L2 на L1, чтобы любой мог вычислить различия состояний из генезиса для восстановления состояния накопителя, когда это необходимо.
Рисунок 6: Публикация необработанных транзакций в сравнении с публикацией различий состояний
(Источник: Presto Research)
Этот подход с разницей состояний, несомненно, выгоден с точки зрения затрат по сравнению с подходом к публикации необработанных данных транзакций, поскольку он позволяет пропустить хранение промежуточных транзакций, снижая стоимость хранения в L1. Однако, несмотря на то, что это не является проблемой, здесь есть основной недостаток: этот подход не позволяет восстановить полную историю транзакций L2, что может быть проблемой для некоторых DApps.
Давайте возьмем в качестве примера Compound, протокол кредитования DeFi, и предположим, что он построен на основе подхода ZK rollup stack на основе подхода с различиями состояний. Эти протоколы требуют полную историю транзакций, чтобы каждую секунду рассчитывать предложение и процентные ставки по займам. Но что произойдёт, если каким-то образом секвенсор ZK rollup выйдет из строя, а другие узлы свертывания попытаются восстановить последнее состояние? Он может восстановить состояние, но процентная ставка будет восстановлена неточно, поскольку он может отслеживать только снимки между пакетами, а не все промежуточные транзакции.
В этой статье в основном утверждается, что в большинстве современных ZK-роллапов нет «ZK», и в DApps есть много областей, в которых использование ZKP и ZK-роллапов может быть не самым оптимальным выбором. Технология ZK может казаться невинной из-за того, что ее обвиняют; потому что в нем нет ничего плохого по своей сути — просто в процессе использования своих технических достижений он может привести к потенциальному снижению производительности в DApps. Однако это не значит, что технологии ЗК бесполезны для этой отрасли. Когда ZKP и ZK-роллапы в конечном итоге достигнут технической зрелости, они, безусловно, могут предоставить еще лучшие решения для решения трилеммы блокчейна. На самом деле, существуют проекты на основе ZK, которые поддерживают конфиденциальность ZK, а также множество типов DApps, которые эффективно используют преимущества ZKP и ZK-роллапов. Мы рассмотрим это подробнее в следующей статье - следите за обновлениями!