Постер запуска Polygon zkEVM вызвал большую дискуссию среди основателей публичной сети о масштабируемости

26 февраля рекламный плакат, объявляющий о запуске основной сети Polygon zkEVM, вызвал дискуссию об использовании эквивалентности термина «Ethereum», а Е Чжан, основатель Scroll, торжественно указал, что Polygon zkEVM не имеет этой функции. Оглядываясь назад, Райан Уайетт, глава Polygon Labs, ответил, что это было скорее результатом плохой коммуникации между маркетологами и техническими специалистами внутри команды.

Это нетривиальный вопрос, и степень эффективности даже будет напрямую связана с производительностью и масштабируемостью L1/L2, всего два дня назад соавтор Solana Toly опубликовал статью о том, что ZK L2s не будет лучшим решением для решения проблемы масштабируемости.

27 февраля техническая команда Polygon, главный герой этого мероприятия, также активно отреагировала на принцип работы zkRollup, объяснив, на что указывает масштабируемость zkRollup.

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

В этой статье мы объединим твиты нескольких основателей L1/L2, чтобы раскрыть все тонкости большой дискуссии о производительности публичных сетей.

Истоки: Дебаты об эквивалентности EVM

zkEVM от Polygon, строго говоря, это механизм zk VM, который согласуется с основной сетью Ethereum на уровне L2 через сопоставление, и внедрение технологии zk является причиной, по которой он называется zk VM, и в нестрогом смысле, пока он может поддерживать синхронизацию, то безвредно называть его zk EVM.

Однако, по словам Е Чжана, основателя Scroll, эквивалентность EVM — это не совсем то же самое, что эквивалентность Ethereum, потому что последняя должна быть, по крайней мере, совместима с основной сетью Ethereum с точки зрения хранения данных.

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

Чтобы интуитивно понять разницу между ними, можно привести простой пример, Optimism занимается разницей между ними в планировании продукта, по его мнению:

Эквивалентность EVM: В основном с точки зрения разработчиков dApp, их опыт работы с OVM ничем не отличается от опыта разработки децентрализованных приложений в основной сети Ethereum, поэтому OVM имеет эквивалентность EVM;

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

В дополнение к дебатам об эквивалентности EVM, следует также отметить, что споры о масштабируемости в настоящее время находятся в центре внимания битвы между L2 на основе Ethereum и высокопроизводительным L1.

Предыстория: сомнения Solana в масштабируемости ZK

24 февраля, за два дня до запуска трейлера Polygon zkEVM, один из создателей Solana Toly опубликовал пост в Twitter, в котором поставил под сомнение способность ZK L2s решить проблему масштабирования публичной сети, чтобы развеять сомнения общественности в механизме работы Solana.

Его основные тезисы заключаются в следующем:

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

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

К сожалению, 25 февраля в Solana произошел серьезный сбой, и сообщество, инженеры и валидаторы восстановили основную сеть после двух перезагрузок, а утечка из дома совпала с ночным дождем, и «благотворители» воспользовались возможностью, чтобы поставить под сомнение механизм Solana, а пользователь Twitter DBCryptoX утверждал, что «90-95% транзакций на Solana содержат сообщения валидаторов и голосование в сети».

Solana использует механизм консенсуса PoS, который называет себя механизмом «Proof of History». PoH позволяет сети работать быстрее, поскольку узлам не нужно взаимодействовать для проверки блока, а PoH позволяет валидаторам точно определять события в определенный момент времени.

С одной стороны, этот механизм обеспечивает высокую степень единообразия, выводя TPS далеко за пределы основной сети Ethereum, но с другой стороны, он занимает много места в блоке сети, и как только что-то идет не так, трудно достичь консенсуса для восстановления сети. По крайней мере, одно событие сбоя основной сети происходило в год в течение как минимум 2021–2023 годов.

Сбой стал негативным уроком для масштабируемости Solana. Один из создателей Solana Толи считает, что прувер на ZK L2 не может быть выполнен в режиме реального времени, поэтому окончательное ончейн-исполнение ZK L2s не будет происходить в установленном порядке, поэтому пользователи могут либо запускать полные узлы, чтобы увеличить нагрузку на сеть, либо полагаться на несколько честных узлов для повышения эффективности и перехода на централизованность.

Однако оказывается, что высокопроизводительная L1 Solana, похоже, не решает проблему исполнения в реальном времени, ведь рухнувшая сеть со временем потеряет установленный порядок, а принудительно восстановленные данные станут искусственным «консенсусом», а не спонтанным состоянием самой сети.

Последствия: масштабируемость Polygon имеет решающее значение

Polygon zkEVM сначала был допрошен Solana, а затем объявил, что произошел инцидент с улуном, который заподозрили в непрофессионализме и вводе в заблуждение. Поэтому разработчик Жорди Байлина (Jordi Baylina) бросил вызов профессионализму, сосредоточившись на объяснении того, что прувер не является ограничивающим фактором для ZK L2, а реальным препятствием является DA (доступность данных).

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

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

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

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

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

Таким образом, Прувер, в который верит Solana, не может помешать работе ZK-доказательств, а реальным препятствием является доступность данных, которую нужно решать с помощью ETH 2.0, DankSharding, EIP4844 и других решений.

Заключение: Куда движется масштабируемость

Дебаты вокруг Polygon zkEVM будут продолжаться, и ключ будет заключаться в том, насколько хорошо zk EVM может решить текущую проблему масштабируемости, которая станет следующим испытанием для L1/L2, с которым придется столкнуться с крупномасштабными децентрализованными приложениями и пользователями.