zkEVM Rollup: разрыв между технологическим видением и проектом

Чтобы решить проблему расширения сети Blockchain Layer 1, появилось решение Rollup. В сочетании с технологией ZK, ZK Rollup стал новым любимцем дорожки Layer 2. Однако для большинства людей связанные понятия, такие как ZK, Rollup и EVM, могут иметь определенный порог понимания. Таким образом, цель этого исследовательского отчета состоит в том, чтобы систематически разобраться в ряде концепций zkEVM Rollup для вас кратким и простым для понимания языком, глубоко проанализировать эволюцию и состояние развития технологии zkEVM Rollup, а также интерпретировать основные экологические аспекты. проекты в деталях.Он разработан, чтобы помочь вам полностью понять и оценить тенденцию развития трека zkEVM Rollup.

ЧАСТЬ 1 Понимание ZK

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

Конечно, в дополнение к преимуществам защиты конфиденциальности, которые может принести технология ZK, в ZK Rollup технология ZK более важна для решения проблемы «сложной проверки». Процесс «верификации» очень важен для блокчейна.Большая часть процесса вычислений в Ethereum заключается в выполнении требований верификации, и ZK Rollup может значительно сократить время, затрачиваемое на верификацию всей сетью узлов. Например, если блок долго проверяет, что он удовлетворяет правилам всей сети, когда блок был сгенерирован, может быть один доказывающий, который сначала проверяет его и генерирует «доказательство» результата вычисления этого блока, и все остальное Цель проверки блока может быть достигнута за счет быстрой проверки этого «доказательства» вместо исходного блока с огромным объемом вычислений.

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

01 Генерация, доказательство и проверка ключа

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

Рисунок 1 Пример принципиальной схемы, можно заметить, что все операции в схеме разбиты на простейшие базовые операции | Исходник

Используя эту схему и некоторые случайные числа в качестве входных данных, мы можем сгенерировать ключ проверки (pk, ключ проверки) и ключ проверки (vk, ключ проверки) для последующего процесса проверки, схематическая диаграмма показана на рисунке 2.

Рисунок 2 Генерация «общедоступных параметров»

Наша система проверки также требует два типа входных данных — частный и общедоступный, а также ключ подтверждения для создания доказательства. Среди них частный ввод (свидетель) — это секрет, который мы хотим скрыть, а публичный ввод — это информация, которую можно сделать общедоступной. Например, в уравнении X+Y*Z=OUT X и OUT являются общедоступными входными данными, а Y и Z имеют значения, которые мы не хотим публиковать для валидатора. Хотя значение Y*Z можно вывести на основе общедоступных данных, конкретные значения Y и Z все еще не определены.

Рис. 3. Процесс доказательства и процесс проверки ZK-SNARK.

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

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

02 Попробуйте немного SNARK

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

1. Убедитесь, что отправитель и получатель транзакции находятся на листовых узлах дерева.

2. Проверьте подпись отправителя.

3. Обновить балансы отправителя и получателя.

4. Обновите корневой узел дерева Меркла (т.е. корень Меркла) и используйте его в качестве конечного результата.

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

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

Само дерево Меркла действует как свидетель (свидетель) и не нуждается в чтении или обработке верификатором.

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

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

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

03 От ZK-SNARK к ZK-STARK

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

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

В то же время ZK-STARKs, как модернизированная версия ZK-SNARKs, может не только повысить эффективность проверки (теоретическая эффективность в 10 раз), но и не полагаться на эллиптические кривые или доверенные настройки, а также не требует процесса генерации начальных общедоступных параметров (буква «Т» означает прозрачность), что устраняет необходимость в централизованной доверенной настройке. Некоторые разработчики считают, что хеш-функция в ZK-STARK может помочь противостоять квантовым атакам.

Однако ZK-STARKs был введен поздно, текущая технология недостаточно зрелая, и она опирается на хеш-функции, что ограничивает ее универсальность.ZK-SNARKs по-прежнему является алгоритмом общего доказательства. Некоторые примеры алгоритмов на основе STARK включают Fractal, SuperSonic и т. д., а связанные проекты включают StarkWare, Polygon Miden и т. д.

ЧАСТЬ 2 Общие сведения о накопительном пакете

В дополнение к ZK нам нужно понять еще одну концепцию — Rollup, Значение Rollup заключается в решении проблемы перегрузки сети уровня 1.

Возьмите Ethereum в качестве примера, в настоящее время у него есть проблема перегрузки транзакций. Есть два способа решить эту проблему: один — увеличить транзакционную способность самого блокчейна, например, увеличить пропускную способность блокчейна с помощью таких технологий, как шардирование. Другой подход заключается в том, чтобы изменить способ использования блокчейна, то есть выполнять большинство действий на втором уровне (уровень 2, далее именуемый L2), а не непосредственно в цепочке. В этом случае в цепочке часто развертывается смарт-контракт, который отвечает только за обработку депозитов и выводов средств и использует различные методы для считывания данных вне сети, чтобы убедиться, что все, что происходит вне сети, соответствует правилам. Это равносильно возведению шоссе рядом с небольшой дорогой, то есть за счет расширения L2 для решения проблемы заторов.

В настоящее время существует три основных типа или решений для расширения L2: каналы состояний, Plasma и Rollup. Это три разные парадигмы, каждая со своими преимуществами и недостатками. Все расширения L2 можно условно разделить на эти три категории (хотя есть некоторые споры по поводу наименования, например валидности), среди которых у Rollup есть свои преимущества.

Сведение и доступность данных

По сравнению с другими решениями для расширения, Rollup имеет определенные преимущества.Одно из наиболее интуитивно понятных преимуществ заключается в том, что он решает проблему доступности данных Plasma (упомянутую в главе «Доступность данных» статьи г-на Даррена), и здесь я также сделаю некоторые добавка.

Тот факт, что данные находятся в сети, очень важен (примечание: размещение данных «в IPFS» не сработает, потому что IPFS не обеспечивает проверки на уровне консенсуса, что нет гарантии, что данные данные доступны, т. е. данные должны быть хранится в блоках). В двух схемах расширения Plasma и предыдущем Channel данные и вычисления полностью размещаются в сети второго уровня.Когда сеть второго уровня взаимодействует с Ethereum, все данные транзакций в цепочке второго уровня не включаются. state С точки зрения машины каждое изменение состояния цепи Plasma не учитывается. Это приведет к тому, что если Ethereum будет отделен от сети второго уровня, такой как Plasma, он не сможет восстановить прежние изменения состояния, поэтому доступность данных Ethereum очень зависит от защиты данных Plasma.

Механизм объединения

Чтобы обеспечить доступность данных, рынок выбирает Rollup, так как же работает Rollup?

Рисунок 4 State Root в контракте L1 | Источник

В дизайне Rollup есть контракт Rollup в основной цепочке, в котором хранится корень состояния. Этот корень состояния можно рассматривать как обновленную версию корня Merkle дерева Merkle, в котором хранится баланс счета (то есть своего рода состояние), код контракта и другая информация.На рисунке 4 показан корень состояния, хранящийся в контракте Rollup. .

У узла L2 есть три основные функции: во-первых, определить, какие транзакции должны быть упакованы в первую очередь (обычно этот тип узла или клиента называется Sequencer Sequencer), во-вторых, он должен предоставить подтверждение для каждого упакованного данных и, наконец, отправить его в Контракт L1 The Rollup проверяется этим контрактом. На рисунке 5 показана роль секвенсора в L2.

Рисунок 5. Последовательность, проверка и отправка пакета — основные функции этапа L2 | Источник

В частности, L2 может передавать пакет данных (пакет) на L1.Эти данные могут быть сильно сжатыми коллекциями транзакций или изменениями состояния после выполнения контракта, а также включать в себя корень состояния, хранящийся в контракте L1, и новый корень после состояния ( post-state root), полученный после того, как L2 обработает данные. Контракт проверяет правильность корня после состояния на основе этих данных. Как только проверка будет пройдена, пакет данных будет подтвержден на уровне L1, завершив процесс цепочки от L2 до L1.

Корень после состояния (post-state root) вычисляется из исходных данных.Чтобы убедиться, что новый корень post-state в представленных данных верен, самый простой способ — позволить L1 пересчитать один раз. Однако это, несомненно, окажет сильное давление на L1. Для решения этой критической проблемы существуют две совершенно разные схемы оптимизации: Optimistic Rollup и ZK Rollup.

Объединение ZK и Оптимистическое объединение

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

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

На рисунке 6 показано сравнение преимуществ и недостатков Optimistic Rollup и ZK Rollup. Здесь важно отметить, что ZK Rollup превосходен в TPS и имеет значительное преимущество в циклах возврата. Однако его недостатками являются совместимость с EVM и потребление вычислительных ресурсов на уровне L2:

1. Проекты Optimistic Rollup, такие как Optimism и Arbitrum, используют OVM и AVM соответственно, и их виртуальные среды в основном такие же, как EVM, поэтому они могут напрямую переносить контракты L1 на L2 для развертывания. Однако в ZK Rollup довольно сложно использовать ZK-SNARK для доказательства общего выполнения EVM, потому что EVM не разработан в соответствии с математическими требованиями расчета доказательства ZK, поэтому необходимо преобразовать определенный тип клиента EVM для использования. Технология ZK для проверки транзакций и контрактных операций.

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

3. ZK Rollup обеспечивает лучшее сжатие данных, чем Optimistic Rollup, поэтому он может отправлять меньшие данные на уровне L1.

4. Поскольку процесс проверки доказательств в ZK выполняется быстрее и имеет более высокую плотность пакетов, ZK Rollup требует меньше вычислений для уровня L1. Можно понять, что оплата узла на L2 значительно снижает требования к узлам L1, тем самым значительно улучшая масштабируемость уровня L1.

Рисунок 6. Сравнение двух методов свертки | Источник:

** Накопительный пакет ZK или накопительный пакет zkEVM? **

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

Как понять настроенный ZK Rollup? Разработчики создают схемы для конкретных приложений («ASIC») для различных DApps, таких как Loopring, StarkEx rollup и zkSync 1.0, которые поддерживают определенные типы платежей, обмен токенами или кастинг NFT.Однако дизайн их схем требует высокой степени технические знания, что приводит к плохому опыту разработчиков. Взяв в качестве примера определенный тип платежных данных, узел отправляет данные транзакции секвенсору, а секвенсор упаковывает их в пакет и отправляет узлу, который отправляет доказательство в качестве общедоступных входных данных, процесса подтверждения и контракта. процесс выполнения на виртуальной машине Это не имеет никакого отношения, ZK отвечает только за доказательство сверты вычисления и процесса сжатия конкретного результата выполнения.

А zkEVM Rollup представляет собой возможность суммировать текущие результаты виртуальной машины. При запуске смарт-контракта общего назначения на уровне L2 необходимо доказать правильность перехода состояния до и после запуска контракта, а также требуется виртуальная среда для поддержки работы алгоритма ZK. Следовательно, смысл zkEVM заключается в запуске контракта, выводе конечного состояния, подтверждении правильности процесса выполнения контракта и отправке записей транзакций, учетных записей и данных записи изменения состояния вместе в сводке. Уровень L1 должен только быстро проверить доказательство, накладные расходы небольшие, и нет необходимости снова запускать контракт Рисунок 7 наглядно иллюстрирует роль zkVM. Следует отметить, что zkEVM на самом деле является EVM-подобной виртуальной машиной, работающей на уровне L2, поэтому более точным термином является виртуальная машина с нулевым разглашением, zkVM, но все подчеркивают, что она совместима с Ethereum и называет ее zkEVM.

Рисунок 7. Диаграмма, иллюстрирующая zkVM | Source

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

ЧАСТЬ 4 Обзор проекта объединения zkEVM

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

1. Текущий ход проекта: включая текущую стадию проекта и ожидаемое время запуска тестовой сети и основной сети, а также соответствует ли он дорожной карте разработки.

2. Фактическое взаимодействие проекта: благодаря взаимодействию с тестовой (основной) сетью и т. д., субъективно почувствовать сетевой TPS, время подтверждения одной транзакции и т. д., а также интуитивно почувствовать производительность сети.

3. Совместимость с zkEVM: это самый основной технический момент и о нем труднее всего судить.Даже если некоторые проекты имеют открытый исходный код, технология на уровне VM является самой сложной и включает в себя больше протоколов ZK. Конкретно необходимо обратить внимание на протокол ZK, безопасность ВМ, совместимость и т.д.

4. Архитектура zkEVM Rollup: по сравнению с zkEVM общие проекты раскрывают свою архитектуру Rollup в технических документах и других технических документах, и общая разница меньше, но следует обратить внимание на общую степень децентрализации.

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

6. Инвестиционная и финансовая ситуация.

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

Прокрутка

Команда Scroll, основанная в 2021 году, занимается разработкой EVM-эквивалента ZK Rollup для масштабирования Ethereum.В течение почти двух лет Scroll работает с командой Privacy and Scaling Explorations и другими участниками с открытым исходным кодом, чтобы публично создать накопительный пакет, совместимый с байт-кодом. .зкЭВМ. В конце февраля Scroll объявила, что ее тестовая альфа-сеть теперь работает на Goerli. Любой пользователь может участвовать в техническом тестировании без разрешения. Среднее время блока тестовой сети составляет 3 секунды. Уже более 20 миллионов транзакций и более 1,5 млн блоков и более 4 млн интерактивных адресов. В то же время Scroll также открыл интерфейс экосистемы веб-сайта 11 апреля.

Судя по недавнему раскрытию информации, Scroll постоянно движется вперед по пути эквивалентности EVM Type 2. Недавно Scroll завершил совместимую разработку всех кодов операций EVM и находится в процессе аудита.В то же время следующей целью является совместимость с транзакциями EIP2718.

С точки зрения технической архитектуры архитектура Scroll относительно традиционна, поэтому здесь она будет подробно представлена. Как показано на рисунке 8, он в основном разделен на две части: основная часть — это zkEVM, которая используется для подтверждения правильности выполнения EVM в L2; но чтобы превратить zkEVM в полный ZK Rollup на Ethereum, полный L2 должен быть построен на основе архитектуры zkEVM. В частности, существующая тестовая сеть Scroll Alpha состоит из Scroll Node, Bridge Contract и Rollup Contract:

Рисунок 8 Общая архитектура свертывания прокрутки | Источник

1. Узел прокрутки: состоит из секвенсора, ретранслятора и координатора.

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

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

c) Relayer отслеживает Bridge Contract и Rollup Contract в цепочках Ethereum и Scroll. Контракт объединения гарантирует доступность данных L2 на уровне L1 и гарантирует, что блок L2 может быть восстановлен на уровне L1. достигнет окончательности на уровне L2.Неизменяемое состояние . Мостовой контракт отвечает за обмен данными между двухцепочечными контрактами при пересечении цепочек, отправку произвольных сообщений в обоих направлениях или выполнение операций залога и снятия активов при пересечении цепочек.

Рисунок 9 2. Роликовая сеть |Источник

1. Сеть Roller: Roller имеет встроенный zkEVM, который выступает в качестве средства проверки в сети и отвечает за создание доказательств достоверности для свертки ZK, как показано на рисунке 9.

а) Roller сначала преобразует трассировку действия, полученную от координатора (то есть, какие конкретные операции выполнил контракт и какие адреса задействованы) в свидетели цепи.

б) Он генерирует доказательства для каждой схемы zkEVM и, наконец, объединяет эти доказательства из нескольких цепей ZK.

Старкваре

StarkWare предоставляет решение для масштабирования на основе STARK, обеспечивающее безопасность L2, скорость и удобство работы пользователей. Они поддерживают несколько режимов доступности данных. StarkNet — это их сеть L2, а StarkEx — это служба проверки Rollup для корпоративных пользователей, а DApps могут быть построены на службах StarkEx. Однако в настоящее время для конкретных DApp можно писать только индивидуальные схемы, а не для общего zkEVM Rollup. StarkEx поддерживает ряд услуг plug-and-play, включая разработку и торговлю NFT, торговлю деривативами и т. д. С точки зрения экологии, децентрализованная платформа для торговли фьючерсными контрактами DYDX является постоянным пользователем StarkWare.

Строго говоря, StarkNet — это zkVM.Вместо того, чтобы создавать схемы ZK для кодов операций Ethereum, он создал набор более дружественного к ZK языка ассемблера, AIR (Algebraic Intermediate Representation) и языка высокого уровня Cairo. Хотя сам StarkNet не совместим с EVM, он все же может быть совместим с Ethereum с помощью других методов, включая Kakarot (Kakarot — это zkEVM, написанный в Каире, то есть zkEVM, чей байт-код эквивалентен EVM). Насколько я понимаю, StarkNet является относительно централизованным проектом, одним из которых является то, что он не может быть синхронизирован с обновлением безопасности Ethereum, поэтому необходимо сконцентрировать R&D-персонал, чтобы восполнить недостатки в безопасности и следить за развитием и адаптация нового соглашения ETH.

StarkNet использует STARK в качестве системы доказательств, по сравнению со SNARK, STARK имеет больше инноваций. Ему не нужно полагаться на «надежные настройки», такие как SNARK. Более того, он также имеет более простые криптографические предположения, избегает необходимости в предположениях об эллиптической кривой, спаривании и экспоненциальном знании и полагается исключительно на хэширование и теорию информации, поэтому он более устойчив к квантовым атакам. В целом STARK более безопасны, чем SNARK. Что касается возможностей расширения, STARK имеет значительный предельный эффект, и чем больше доказательство, тем ниже общая стоимость.

Однако с точки зрения архитектуры на данный момент в системе есть только один Sequencer (секвенсор), которым управляет StarkWare, и всего один Prover (то есть прувер, генерирующий ZK Proof), который не только генерирует пруфы для StarkNet, но также работает самостоятельно. Доказательство генерации для всех других приложений в накопительном пакете StarkEx.

Варианты ZK Rollup: Validiums and Volitions

Validium также является решением масштабирования L2, которое использует доказательство вычислений, такое как ZK Rollup, для обеспечения целостности процесса транзакции. В отличие от ZK Rollup, Validium не хранит данные транзакций в сети Ethereum. Жертвовать доступностью данных в сети — это компромисс, который может привести к огромным улучшениям в масштабируемости, самым непосредственным моментом является то, что Validiums может обрабатывать около 9000 транзакций в секунду.

Но в глазах автора Validium нельзя рассматривать как строгий ZK Rollup. Это решение похоже на Plasma, и оно не обеспечивает доступность данных на уровне L1, поэтому его нельзя считать накопительным пакетом. Разница с Plasma заключается в том, что Plasma настроила «механизм выхода за семь дней», аналогичный OP Rollup на уровне L2, в то время как Validium использует средства ZK для сокращения времени проверки данных на уровне L2 и не синхронизирует данные в L1.

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

зксинк

Подобно StarkNet, zkSync всегда настаивал на выборе zkVM, который эквивалентен языку высокого уровня и привлекал большое внимание благодаря очень высокой популярности и объему блокировок. zkSync 1.0 (zkSync Lite) был запущен в основной сети Ethereum 15 июня 2020 года, достигнув пропускной способности транзакций около 300 TPS, но он не совместим с EVM. А zkSync 2.0 (zkSync Era) будет запущен 24 марта 2023 года.

Цель zkSync Era — быстрее генерировать доказательства, используя свою собственную виртуальную машину для оптимизации, а не гоняться за эквивалентностью EVM. Он поддерживает Solidity, Vyper, Yul и Zinc (внутренний язык программирования накопительного пакета) через мощный компилятор LLVM для реализации большинства функций смарт-контракта. Благодаря самостоятельно разработанной виртуальной машине zkSync Era поддерживает абстракцию собственной учетной записи, поэтому любая учетная запись может использовать любой токен для оплаты.

Кроме того, благодаря применению протокола zkPorter в сочетании с ZK Rollups и технологией фрагментации пропускная способность сети увеличилась в геометрической прогрессии, достигнув более 20 000 TPS (аналогично переключению доступности данных в Volitions).

В целом, zkSync — это экологически чистый L2-проект, привлекший внимание разработчиков и инвесторов. Хотя в последнее время было несколько случаев полного провала проектов на zkSync, все еще остается вопрос, смогут ли разработчики получить хороший опыт разработки и миграции на языке высокого уровня, эквивалентном zkVM. В настоящее время не хватает точных отчетов об использовании на уровне разработчиков.Если разработчики имеют хороший опыт, какой смысл в других типах zkVM, которые стремятся быть ближе к EVM? Нам все еще нужно больше времени, чтобы наблюдать.

Полигон zkEVM

27 марта компания Polygon запустила бета-версию основной сети zkEVM Rollup, которая также является эквивалентом виртуальной машины Ethereum и имеет открытый исходный код всего кода zkEVM. По сравнению с zkSync заблокированный объем полигона zkEVM намного меньше, но в экологии тоже много интересных и динамичных проектов.

Что касается дизайна Rollup, Polygon отличается от Scroll тем, что использует модель Proof of Efficiency (PoE), чтобы мотивировать Sequencer и Aggregator решать некоторые проблемы децентрализации и валидаторов без разрешения. В безразрешительной двухэтапной модели сортировщика-агрегатора любой сортировщик может подать заявку на упаковку партий, чтобы получить плату за упаковку, но ему необходимо оплатить плату за газ уровня L1 и внести определенное количество токенов. ; в то же время токены агрегации должны ставить собственные цели, чтобы максимизировать гарантированную прибыль для каждого поколения доказательства. Кроме того, режимы Polygon и Volition (ZK Rollup и Validium) также имеют полностью совместимые модели доступности данных для предоставления пользователям различных уровней услуг.

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

1. Более совместимый: Polygon всегда настаивал на использовании zkVM, который эквивалентен EVM, чтобы снизить затраты разработчиков на миграцию dApps. В то же время, хотя Polygon Miden принимает протокол ZK-STARK, он по-прежнему поддерживает выполнение контрактов Solidity.

2. Простая проверка. Причина, по которой ZK Rollup часто критикуют, заключается в том, что для создания доказательств достоверности требуется дорогостоящее специализированное оборудование, которое поставщики используют и перекладывают стоимость на пользователей. Polygon ZK Rollup (как и Polygon Zero) направлен на упрощение схем проверки, чтобы устройства более низкого уровня могли участвовать, например, в тестах генерации проверки Plonky2 на ПК потребительского уровня.

3. Более быстрое создание доказательства и процесс проверки: Polygon Zero может создать доказательство размером 45 КБ за 170 миллисекунд.

ЧАСТЬ 5 Разрыв между теоретическими технологиями и практическими проектами

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

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

Целью технологии Rollup является дальнейшее раскрытие ценности блокчейна, но часто из-за острой необходимости стать «инновационной концепцией» на рынке возникает явление «отката» и возврата к централизации. Это проблема нынешнего рынка.

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

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