Обзор Rollup

Rollup - это категория масштабируемых решений уровня 2 блокчейна. В схемах Rollup операторы проекта запускают относительно независимую платформу уровня 2 под расширенной основной цепью (т.е. уровень 1). Пользователи могут выполнять контракты или передавать токены на платформе уровня 2.

Безопасность платформы Layer 2 гарантируется базовым блокчейном Layer 1, на котором она основана. Когда в Layer 2 создается новый блок, информация о транзакции из блока Layer 2, а также корневое состояние после транзакции Layer 2, упаковываются как транзакция Rollup и публикуются на цепочке Layer 1. Фактическое выполнение транзакции и изменение состояния обрабатываются на платформе Layer 2 под главной цепочкой, и Layer 1 должен только проверить правильность переходов состояния Layer 2. Поскольку стоимость проверки правильности перехода состояния намного ниже, чем выполнение этих транзакций на Layer 1, Layer 2 может достичь расширения платформы Layer 1. Платформа Layer 2 может обеспечить более высокую пропускную способность транзакций и более низкие издержки на транзакции по сравнению с Layer 1, сохраняя при этом эквивалентный уровень безопасности.

По сравнению с другими схемами транзакций вне цепи, Rollups имеют две характеристики:

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

Основываясь на методах проверки обновлений состояния уровня 2 основной цепочкой, в настоящее время существует два основных типа технологических решений Rollup. Один из них — Optimistic Rollup. В этом типе схемы контракт основной цепи не проверяет напрямую новое состояние, представленное уровнем 2. Вместо этого для каждого нового поданного штата готовится период оспаривания. Поскольку Rollup отправляет всю информацию о транзакциях в основную цепочку и делает ее публичной, любой может проверить обновление состояния (особенно если обновление касается его собственного кошелька). Если новое состояние неверно, верификатор может создать доказательство мошенничества против этого ошибочного состояния и отправить его в течение периода оспаривания, тем самым аннулировав неверное обновление состояния.

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

По сравнению с схемой Оптимистичного Rollup, zk Rollup не требует длительного периода оспаривания для окончательного подтверждения транзакций уровня 2 и может быть подтвержден более быстро. Кроме того, zk Rollup не полагается на предположение, что в сети всегда будут честные верификаторы, которые своевременно представят доказательства мошенничества при возникновении мошенничества. Однако в то же время zk Rollup также сталкивается с проблемами, такими как высокая вычислительная стоимость технологии нулевого доказательства, сложность и трудность разработки, которые затрудняют практическую реализацию технологии zk Rollup в Rollups. С дальнейшим развитием технологии нулевого доказательства в последние два года эти препятствия постепенно преодолеваются. Технология zk Rollup начинает занимать все бОльшую долю рынка уровня 2.

Как показано на рисунке ниже, в области масштабирования уровня 2 Rollup zkRollup уже занимает более половины территории и быстро развивается.

Источник изображения

Данные получены: 18 января 2024 г.

От специализированного zkRollup к общему zkRollup

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

Разница между этими двумя типами технологий zkRollup в основном заключается в том, выполняет ли платформа уровня 2 ограниченную специализированную логику, написанную провайдером платформы, или произвольную логику смарт-контрактов, написанную пользователями в транзакциях.

В проектах zkRollup, отличных от общих (например, zkSync Lite, занимающем 8-е место на рисунке выше), пользователи могут выполнять только несколько типов операций с транзакциями, таких как передачи FT (функциональных токенов), платежи, обмен и передачи NFT (нефункциональных токенов). Логика транзакций для этих операций может быть определена и реализована только владельцами проекта.

Через такие проекты zkRollup мы можем переводить с гораздо меньшими сборами по сравнению с основной сетью Ethereum и получать более высокую пропускную способность транзакций. Однако, если мы хотим попробовать какой-то интересный контракт на цепи, мы не сможем этого сделать.

Почему специализированные zkRollups не позволяют пользователям развертывать и использовать свои собственные смарт-контракты? Это возвращает нас к архитектуре доказательства самого zkRollup.

Для того чтобы обеспечить правильность и надежность переходов состояний L2, в zkRollup всю логику перехода состояний L2 необходимо записать в виде цепей доказательств с нулевым разглашением и проверить контрактами L1. Только состояния, прошедшие проверку, могут быть приняты L1 и в конечном итоге завершить Rollup. Для этого необходимо проверить всю логику выполнения транзакций платформы zkRollup в цепи доказательств с нулевым разглашением. Однако поддержка выполнения произвольной логики контрактов в цепях доказательств с нулевым разглашением является вызовом (причины этой сложности будут объяснены позже в тексте). В результате ранние проекты zkRollup часто поддерживали только ограниченное количество относительно простых транзакций.

Возможность выполнения только фиксированного количества простых транзакций, очевидно, не соответствует нашим ожиданиям от zkRollup. К счастью, технология zkVM (Zero-Knowledge Virtual Machine) решает сложность доказательства выполнения любого произвольного кода, полностью совместимого с машиной Тьюринга, в рамках доказательств нулевого знания, что делает общую платформу zkRollup возможной. Далее в этой статье будут представлены принципы реализации zkVM, позволяющие читателям понять, как работает этот наиболее важный компонент общей технологии zkRollup.

Принципы реализации zkVM

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

Введение в доказательства нулевого разглашения

Доказательства нулевого знания в zkRollup служат для доказательства того, что транзакции Уровня 2 были выполнены правильно и что состояние Уровня 2 было обновлено правильно.

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

Почему нужны доказательства нулевого знания

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

Доказательства с нулевым разглашением имеют три основных свойства:

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

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

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

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

Процесс нулевых доказательств

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

c=a²+b+5

Во имя объяснения аспекта нулевого знания в доказательствах нулевого знания мы установим переменные a и c в качестве общедоступных значений этого доказательства нулевого знания, а b в качестве секретного ввода, известного только доказывающему. Поскольку наш расчет очень прост, верификатор легко может вывести значение секретного ввода из общедоступных значений. Это не влияет на свойство нулевого знания самого метода доказательства нулевого знания, поскольку это только гарантирует, что верификатор не может получить информацию о секретном вводе в процессе доказательства.

При доказательстве доказатель сначала выбирает значение для a и b соответственно в качестве входных данных и вычисляет значение c. Здесь мы устанавливаем a = 3, b = 2, тогда c = 16. После завершения всех вычислений доказатель может сгенерировать доказательство в нулевом знании для этих значений и операций.

После завершения доказательства доказатель передаст верификатору открытые входные данные доказательства (т. е. значения a и c), а также доказательство нулевого разглашения.

Получив доказательство, верификатор может, проверив доказательство с нулевым разглашением, убедиться, что доказывающий использовал секретный вход b, что делает указанную выше формулу истинной при a = 3 и c = 16 (т.е. общедоступные входные значения), и не имеет возможности получить какую-либо информацию за пределами общедоступных входов (a = 3, c = 16).

Следующая часть статьи познакомит с конкретным процессом доказательства. Когда нам нужно доказать вычисление с использованием метода доказательства в нуле, сначала нам нужно представить вычисление в виде арифметической цепи, которую алгоритм доказательства в нуле может принять. Арифметические цепи - это универсальное представление вычисления. Как следует из названия, арифметическая цепь - это вычислительная цепь, состоящая из ворот, выполняющих арифметические операции. В нашем примере результат преобразования показан на рисунке. Вы можете заметить, что помимо общедоступных входов a и c и секретного входа b, о которых мы упомянули, есть два дополнительных значения, d и e. Это промежуточные переменные, используемые в процессе вычисления.

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

Мы можем рассматривать арифметическую схему как две части: одна часть - все числовые значения, которые появляются в схеме, а другая часть - отношения (ограничения) между этими значениями. Мы обычно называем общедоступные входы в схеме утверждением (в нашем примере, a и c), а все остальные значения, включая секретные входы (b) и промежуточные переменные (d и e), - свидетель.

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

Следовательно, схема ворот арифметической схемы также может быть представлена в следующей форме:

заявление:

а,с

свидетель:

b,d,e

ограничение:

d = a * a

e = b + 5

c = d + e

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

В фактических приложениях пользователи доказательств нулевого знания должны написать логику, которая им необходима, в исходный код цепи zk и сгенерировать соответствующий VK через аудит. Этот VK передается верификатору. Публичные входы, доказанные доказателем, вместе с сгенерированным доказательством, представляются, и верификатор может проверить, соответствуют ли эти общедоступные входы ограничениям. В этом примере доказатель может сгенерировать доказательство с значениями a, b и c. Верификатор может проверить, равно ли a² + b с без выполнения этой операции.

Ограничения цепочек доказательств с нулевым разглашением

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

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

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

Возьмем следующую операцию в качестве примера:

if (flag) {

c = x + x

} else {

c = x * x

}

Когда эта операция преобразуется в арифметическую схему, она будет преобразована в указанные ниже ограничения. Очевидно, что к схеме будут добавлены два новых свидетеля, temp1 и temp2. Кроме того, будут вычислены как значение x+x, так и значение x*x.

То есть в zk-схеме все ветви и логика будут вычисляться, независимо от того, выполняются они или нет.

temp1 = x + x

temp2 = x * x

c = флагtemp1 + (1-flag)temp2

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

Доказательство выполнения любой программы — доказательство универсальной вычислительной машины в схеме

Источник изображения

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

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

Состояние регистров перед выполнением инструкции

На рисунке ниже показан базовый рабочий процесс доказательства цепи виртуальной машины ZK:

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

• Таблица байткода: Хранит программу, выполненную в состоянии машины.
• I/O Table: Хранит все входы и выходы, сгенерированные во время выполнения виртуальной машины.

На рисунке процесс выполнения n-ой инструкции абстрагируется и отображается слева. Состояние конечного автомата, State n, переходит к State n+1 после выполнения n-ой инструкции. Та же схема после m итераций достигает выполнения m инструкций в vm.

Здесь две проблемы.

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

Второе - как доказать, что количество инструкций к выполнению не равно m?

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

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

Для решения этой проблемы в набор инструкций можно добавить команду noop, которая не будет изменять состояние. Таким образом, для каждой фиксированной схемы существует верхний предел количества инструкций, которые она может выполнить. Схему zkVM можно рассматривать как контейнер с фиксированным количеством слотов для инструкций. Если требуется больше инструкций, необходима более крупная схема. В реальном доказательстве можно выбрать схему подходящего размера по мере необходимости.

Доказательство базовой инструкции

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

Источник изображения

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

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

Из этой фигуры видно, что для создания ограничений для изменений состояния схема вводит несколько вспомогательных управляющих состояний:

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

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

Получение инструкций реализуется специализированной схемой поиска, которая может доказать извлечение сегмента данных из фиксированной таблицы через индекс. Следовательно, цепь zkVM может доказать выполнение перехода состояния, выполненного виртуальной машиной, указанной в регистре PC.

Доказательство условных суждений и переходов управления

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

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

Сначала мы представляем доказательство суждения о состоянии:

Возьмем в качестве примера оценку того, равен ли операнд в i-ой инструкции нулю. Мы добавляем вспомогательное состояние isZero для результата оценки. Если оценочное значение равно 0, тогда значение вспомогательного состояния isZero равно 1; если оценочное значение отлично от 0, то isZero равно 0.

Этот процесс ограничивается двумя формулами на диаграмме.

Действительность этого ограничения связана с математическими свойствами эллиптических кривых, используемых в доказательствах с нулевым разглашением. Каждое значение в цепи доказательства с нулевым разглашением является элементом в пределе на эллиптической кривой. Если значение не равно 0, должен существовать обратный элемент, который, умноженный на самого себя, дает 1. Используя это свойство, с двумя ограничениями на диаграмме, можно проверить, является ли значение нулевым, и преобразовать его во вспомогательное состояние.

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

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

I/O и Сложные Операции

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

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

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

Источник изображения: 1 2

Диаграмма слева - это схема архитектуры проекта Scroll, а диаграмма в правом нижнем углу - схема архитектуры Polygon. Они оба используют аналогичный подход, как показано на диаграмме в верхнем углу.

Общий автомат состояний отвечает за доказательство управления логикой выполнения программы. В большинстве контрактов фактическое время выполнения этой части логики очень мало, поэтому доказательство этого с неэффективным общим автоматом состояний все еще приемлемо с точки зрения эффективности.

Более фиксированные сложные вычисления, такие как хэш, операции дерева MPT, внешние входные данные и т. д., доказываются специализированными схемами.

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

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

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

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

Заключение

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

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

Отказ от ответственности:

1. Эта статья перепечатана из [ZAN], Все авторские права принадлежат оригинальному автору [ZAN и AntChain Open Labs]. Если есть возражения по поводу этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не составляют инвестиционных рекомендаций.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.