Привет, Хабр! Меня зовут Леша Куценко, я разработчик смарт-контрактов в команде MetaLamp, мой основной стек – Solidity. В этой статье я подробнее расскажу про решение для масштабирования с нулевым разглашением (Zero-knowledge proof), а именно – о блокчейне второго уровня Polygon zkEVM. Как блокчейн решает проблему высокой стоимости газа в транзакциях и использует другие преимущества ZK-Rollups? Ответы на эти и другие вопросы в этой статье. 

Для более детального понимания Zero-Knowledge Proofs (ZKP), рекомендую обратиться к этой статье в нашей Blockchain-Wiki на Гитхабе.

Погнали!:)

Polygon zkEVM — это блокчейн второго уровня для Ethereum, решение для масштабирования с нулевым разглашением (ZK). Polygon zkEVM использует криптографический примитив, называемый доказательством ZK, для проверки переходов состояний. Он сочетает в себе доступность данных и проверку выполнения на уровне L1 блокчейна Ethereum для обеспечения безопасности и надежности перехода состояний L2.

zkEVM позволяет разработчикам разворачивать в сети L2 смарт-контракты Ethereum без какого-либо изменения кода, используя при этом преимущества ZK-Rollups, как например низкую стоимость газа и быструю финализацию транзакций.

Стратегия эффективности блокчейна

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

• Вторая стратегия — выполнять все вычисления вне блокчейна, сохраняя в блокчейне только необходимые данные и zk-доказательства.

• Способ реализации смарт-контракта моста, например расчет счетов методом UTXO

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

  • Запуск специального языка ассемблера с нулевым разглашением (zkASM) для интерпретации байт-кодов.

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

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

zkEVM Протокол

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

Управления состояниями

Следует объяснить, как протокол Polygon zkEVM управляет состояниями L2 Rollup, обеспечивая при этом проверяемость данных и безопасность перехода между состояниями.

Для начала, следует дать определения:

• Sequencer (секвенсор) — это узел (zkNode), отвечающий за выборку транзакций из базы данных пула, проверку достоверности транзакций и последующее помещение действительных в пакет;

• Aggregator (агрегатор) — это такой же узел (zkNode), но настроен так, чтобы он мог предоставлять доказательств, подтверждающих целостность предлагаемого изменения состояния секвенсором. Эти доказательства представляют собой доказательства с нулевым разглашением (или ZK-доказательства), и для этой цели агрегатор использует криптографический компонент, называемый Prover;

• Prover - это сложный криптографический инструмент, способный создавать сотни пакетов ZK-proofs и объединять их в одно ZK-доказательство, которое публикуется как доказательство достоверности;

• PolygonZkEVM.sol- это cмарт-контракт в L1 проверяет доказательства действительности, чтобы гарантировать правильность выполнения каждого перехода состояния. Это достигается за счет использования схем zk-SNARK. Он получает от секвенаторов сгруппированные пакеты транзакций, хранит их порядок, проверяет транзакции и размещает их в L1.

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

Как только доверенный секвенсор зафиксирует последовательности пакетов, полученных непосредственно с L1, узлы сети L2 будут выполнять их снова, и им больше не придется доверять ему.

Выполненные пакеты off-chain в итоге будут подвергнуты проверке в самом блокчейне с использованием Zero-Knowledge Proof, после чего корень состояния L2, полученный в результате, будет зафиксирован.

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

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

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

• Непосредственно из доверенного секвенсора до того, как пакеты будут переданы в L1, или

• Прямо из L1 после секвенирования партий или

• Только после того, как корректность исполнения будет доказана Агрегатором и проверена контрактом PolygonZkEVM.sol.

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

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

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

• Виртуальное состояние (Virtual State): на второй стадии обновление базируется на информации, полученной из сети L1 узлами L2. Это происходит после того, как пакеты были упорядочены (секвенированы) и данные стали доступны в L1.

• Консолидированное состояние (Consolidated State): на последней стадии информация, используемая для обновления состояния L2, включает проверенные доказательства с нулевым разглашением (zero-knowledge proofs) вычислительной целостности. То есть после того, как доказательство с нулевым разглашением успешно проверено в L1, узлы L2 синхронизируют свой локальный корень состояния L2 с тем, который зафиксирован в L1 доверенным Агрегатором.

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

Жизненный цикл транзакций

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

Отправление транзакции

Транзакции в сети Polygon zkEVM создаются в кошельках пользователей и подписываются их приватными ключами.

После создания и подписания транзакции отправляются на узел Trusted Sequencer через интерфейс JSON-RPC. Затем транзакции сохраняются в пуле ожидающих транзакций, где они ожидают выбора Sequencer для выполнения или отмены.

Пользователи и zkEVM общаются с помощью JSON-RPC, который полностью совместим с Ethereum RPC. Такой подход позволяет любому EVM-совместимому приложению, например программному обеспечению кошелька, функционировать и чувствовать себя как настоящие пользователи сети Ethereum.

Важно! Следует отметить, что в текущей конструкции zk evm, одна транзакция эквивалентна одному блоку.

Каким образом это может улучшить работу в блокчейне?

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

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

Быстрая окончательность: В традиционных блокчейнах подтверждение транзакции может занять некоторое время, поскольку она должна быть включена в блок, а затем этот блок должен быть подтвержден сетью. Если каждая транзакция является отдельным блоком, это может ускорить процесс подтверждения транзакций на втором уровне (L2).

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

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

Таким образом эта стратегия проектирования не только улучшает связь RPC и P2P между узлами, но также повышает совместимость с существующими инструментами и обеспечивает быструю завершенность на уровне L2.

Выполнение транзакции и доверенное состояние

Доверенный секвенсор считывает транзакции из пула и решает, отбросить их или упорядочить и выполнить. Выполненные транзакции добавляются в пакет транзакций (batches), а локальное состояние L2 секвенсора обновляется.

Как мы ранее говорили, как только транзакция добавляется в состояние L2, она передается всем остальным узлам zkEVM через службу широковещания. Стоит отметить, что, полагаясь на Trusted Sequencer, мы можем добиться быстрого завершения транзакции (быстрее, чем в L1). Однако полученное состояние L2 будет находиться в доверенном (Trusted) состоянии до тех пор, пока пакет не будет зафиксирован в консенсусном контракте.

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

Вы спросите, что это за редкие случаи?

Редкий случай

• Проверка транзакций на L1 займет 1 неделю только в том случае, если активировано Emergency State или агрегатор вообще не пакетирует никаких доказательств.

• Кроме того, аварийный режим активируется, если секвенированная партия не агрегируется (не обрабатывается агрегатором) в течение 7 дней. Более детально про Emergency State можете посмотреть тут

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

Пакетное секвенирование и виртуальное состояние

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

Упорядочивание пакетов

Trusted Sequencer добавляет пакет из транзакций к последовательности пакетов через функцию sequenceBatches контракта PolygonZkEVM.sol (L1).

На рисунке ниже показана логическая структура последовательности пакетов.

Таким образом происходит пакетное секвенирование (упорядочивание) и устанавливается новое виртуальное состояние, которое потом передается на L2 узлы.

Следует понимать, что существует максимальный и минимальный размер пакета транзакций:

• открытая константа контракта MAX TRANSACTIONS BYTE LENGTH определяет максимальное количество транзакций, которые могут быть включены в пакет (300 000).

• количество пакетов в последовательности (пакетов для одного секвенирования) ограничено общедоступной константой контракта MAX VERIFY BATCHES (1000). Массив пакетов должен содержать хотя бы один пакет, но не более значения константы MAX VERIFY BATCHES.

Проверка достоверности пакетов и целостности состояния

Следует рассказать, что означают эти действия:

• Достоверность пакетов (Batch Validity): Это обозначает процесс проверки и удостоверения того, что каждый пакет данных, который обрабатывается или передается в сети L2, является законным и соответствует установленным критериям и правилам. Это включает в себя проверку правильности транзакций в пакете, их порядка, а также подлинности и соответствия протоколу;

• Целостность состояния L2 (L2 State Integrity): Этот аспект касается поддержания и защиты точного и непрерывного состояния сети второго уровня. Целостность состояния гарантирует, что все записи и изменения в сети L2 отражают действительные транзакции и взаимодействия, обеспечивая надежность и точность данных в блокчейне.

Данная проверка происходит при вызове функции sequenceBatches контракта PolygonZkEVM.sol (L1). Функция перебирает каждый пакет в последовательности и проверяет его достоверность.

Достоверный пакет должен соответствовать следующим критериям:

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

• Длина массива байтов транзакций должна быть меньше значения константы MAX_TRANSACTIONS_BYTE_LENGTH;

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

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

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

Целостность состояния

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

Вот как это работает:

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

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

Накопленный хеш (Accumulated Hash): Хеш данного пакета представляет собой накопленный хеш всех предыдущих пакетов. Это достигается за счет включения хеша предыдущего пакета (oldAccInputHash) в вычисление текущего. Накопленный хеш для конкретного пакета вычисляется с помощью функции хеширования keccak256, которая принимает в качестве аргумента набор данных, упакованных с помощью abi.encodePacked.

Хеш конкретного пакета имеет следующую структуру:

• oldAccInputHash это хеш предыдущего пакета,

• keccack256(transactions) хеш массива байтов транзакций,

• globalExitRoot является корнем Bridge’s Global Exit Merkle Tree,

• timestamp это временная метка пакета,

• seqAddress это адрес пакетного секвенсора.

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

Как только пакеты будут успешно секвенированы в L1, все узлы zkEVM смогут синхронизировать свое локальное состояние L2, получая данные непосредственно из контракта L1 PolygonZkEVM.sol, без необходимости полагаться только на Trusted Sequencer. Так достигается виртуальное состояние L2.

Пакетная агрегация и консолидированное состояние

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

Можно представить работу агрегатора:

• Агрегатор берет секвенированные пакеты и отправляет в Prover модуль;

• Prover предоставляет доказательство zk-proofs, подтверждающее целостность предлагаемого изменения состояния секвенсором;

• Агрегатор с полученным zk-proofs идет в L1 контракт PolygonZkEVM.sol и консолидирует состояние пакета транзакций. На этом этапе транзакции считаются завершенные и включены в состояние L1.

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

Используя схему SNARK, мы можем обеспечить безопасность в on-chain для исчерпывающих вычислений off-chain экономичным способом. Для любопытных, вы можете посмотреть целый огромный раздел в документации, который поясняет как работает модуль Prover.

После того как пакеты были успешно агрегированы в L1, все узлы zkEVM могут проверить свое локальное состояние L2, извлекая и проверяя консолидированные корни непосредственно из консенсусного контракта L1 (PolygonZkEVM.sol). В результате было достигнуто консолидированное состояние L2.

Сопротивления сбою в работе

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

Секвенсор

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

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

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

Агрегатор

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

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

Состояние аварийности zkEVM

Аварийное состояние — это состояние консенсусного контракта (PolygonZkEVM.sol и PolygonZkEVMBridge.sol), которое при активации прекращает пакетное секвенирование и операции моста.

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

Следующие функции будут отключены в аварийном режиме:

• sequenceBatches

• verifyBatches

• `forceBatch

• sequenceForceBatches

• proveNonDeterministicPendingState

Разработка контрактов

Polygon ZK EVM представляет собой революционный подход к масштабированию Ethereum, позволяя использовать стандартный код смарт-контрактов Ethereum (EVM байт-код) в новой, более эффективной среде. Для этого они используют zkASM.

zkASM преобразует инструкции смарт-контрактов, написанные на Solidity для Ethereum, в низкоуровневый код, который оптимизирован для создания zk-SNARKs. Это включает в себя преобразование операций и логики смарт-контрактов в последовательности более простых инструкций.

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

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

Из-за того что zkEVM Polygon основан на EVM ethereum, разработка практически идентична разработке в EVM блокчейне. Также можно без проблем использовать популярные инструменты: remix, foundry, hardhat.

Существуют небольшие различия между EVM и ZkEVM:

Список включает в себя поддерживаемые EIPs, операции и дополнительные изменения, внесенные для создания zkEVM. Различия не влияют на опыт разработчика zkEVM по сравнению с EVM. Техники оптимизации газа, взаимодействие с библиотеками, такими как Web3.js и Ethers.js, и развертывание контрактов работают беспрепятственно на zkEVM без каких-либо издержек.

Opcodes

• SELFDESTRUCT → удален и заменен на SENDALL.

• EXTCODEHASH → возвращает хэш байт-кода контракта из дерева состояний zkEVM без проверки, содержит ли контракт код.

• DIFFICULTY → возвращает "0" вместо случайного числа, как в EVM.

• BLOCKHASH → возвращает все предыдущие хэши блоков, а не только последние 256 блоков.

• NUMBER → возвращает количество обрабатываемых транзакций.

Предварительно скомпилированные контракты

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

• ecRecover

• identity

Другие предварительно скомпилированные контракты не влияют на дерево состояний zkEVM и обрабатываются как “revert”, возвращая весь газ предыдущему контексту и устанавливая флаг успеха в "0".

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

Другие незначительные различия

• zkEVM не очищает хранилище, когда контракт развертывается по адресу из-за спецификации дерева состояний zkEVM. (Это означает, что в zkEVM при развертывании нового контракта по уже существующему адресу, данные, ранее хранившиеся по этому адресу, не удаляются автоматически. В традиционном EVM при развертывании контракта по адресу, где уже существовал контракт, старые данные удаляются. Однако в zkEVM, из-за спецификации его дерева состояний, это не происходит, и старые данные остаются в хранилище. )

• Опкод JUMPDEST разрешен внутри байтов push, чтобы избежать анализа байт-кода во время выполнения. (Это означает, что в zkEVM разрешено использование опкода JUMPDEST внутри данных, передаваемых командами PUSH. В стандартном EVM, JUMPDEST используется для обозначения места в коде, куда может происходить прыжок (JUMP). Обычно, для обеспечения безопасности, во время выполнения контракта проводится анализ байт-кода на наличие корректных JUMPDEST. В zkEVM, позволяя JUMPDEST находиться внутри данных PUSH, упрощается процесс выполнения кода, так как не требуется анализ байт-кода в реальном времени для поиска JUMPDEST. Это ускоряет выполнение контрактов и снижает их сложность.)

• zkEVM реализует EIP-3541 из хардфорка Лондон. (Это означает, что zkEVM включает в себя реализацию предложения по улучшению Ethereum EIP-3541, которое было введено в сеть Ethereum во время обновления, известного как хардфорк Лондон. EIP-3541 устанавливает новые правила для структуры смарт-контрактов, запрещая развертывание контрактов, начинающихся с определенного байтового префикса (0xEF), что предотвращает потенциальные конфликты и проблемы совместимости с будущими изменениями в Ethereum.)

• EIP-2718, который определяет тип транзакции с типизированным конвертом, не поддерживается. (EIP-2718 представляет нововведение в стандарты транзакций Ethereum, вводя концепт оболочки для различных типов транзакций. Это позволяет в сети Ethereum использовать множество новых типов транзакций, каждый из которых может иметь уникальные поля и логику обработки. Тем не менее, в zkEVM Polygon, по состоянию на последние данные, этот стандарт не поддерживается, что означает, что разработчики и пользователи не могут пользоваться расширенными возможностями, которые предлагают типизированные транзакции в рамках этой платформы. Это может влиять на совместимость с некоторыми новыми функциями или контрактами, разработанными для основной сети Ethereum.)

• EIP-2930, который определяет тип транзакции с необязательными списками доступа, не поддерживается​​. (EIP-2930 – это предложение по улучшению Ethereum, которое вводит новый тип транзакции, содержащей необязательные списки доступа. Эти списки предварительно указывают, к каким учетным записям и хранилищам контрактов будет обращаться транзакция, что позволяет валидаторам заранее знать, какие состояния будут затронуты. Это улучшает эффективность и помогает снизить затраты на газ за счет уменьшения необходимости повторных вычислений. Отсутствие поддержки EIP-2930 в zkEVM означает, что пользователи и разработчики не могут использовать эту функциональность для оптимизации своих транзакций в сети Polygon.)

Разница между Polygon Pos и zkEVM Polygon

Решение для масштабирования

Polygon PoS в основном использует платформу Plasma и механизм консенсуса Proof-of-Stake (PoS) для создания sidechain, которая работает параллельно с основной сетью Ethereum. Polygon zkEVM, с другой стороны, использует архитектуру ZK-Rollup, которая использует доказательства с нулевым разглашением для предоставления решения уровня 2 поверх Ethereum.

Механизм консенсуса

Polygon PoS опирается на набор валидаторов, которые участвуют в механизме консенсуса PoS для проверки и подтверждения транзакций в sidechain. Polygon zkEVM использует консенсусный контракт, который поддерживает беспрепятственное участие нескольких координаторов (секвенаторов и агрегаторов) для создания и проверки пакетов на уровне L2.

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

В сети Polygon PoS данные хранятся на сайдчейне, который предоставляет отдельную блокчейн-систему для обработки транзакций. Polygon zkEVM предлагает два варианта доступности данных в рамках гибридной схемы: Validium (данные хранятся вне цепочки) и Volition (данные и доказательства их правильности находятся в цепочке для некоторых транзакций, а для других - только доказательства).

Совместимость смарт-контрактов

Polygon PoS — это сайдчейн, который обеспечивает совместимость с EVM (Ethereum Virtual Machine). Это позволяет разработчикам развертывать и запускать смарт-контракты Ethereum на сайдчейне Polygon PoS. Однако совместимость с EVM подразумевает, что, несмотря на поддержку смарт-контрактов Ethereum, могут быть некоторые различия в среде исполнения. В результате в редких случаях при работе со сложными децентрализованными приложениями (dapps) и кодом низкого уровня разработчикам может потребоваться адаптация или использование специфических для сайдчейна функций при работе с Polygon PoS.

В отличие от этого, Polygon zkEVM представляет собой ZK-Rollup, который фокусируется на достижении эквивалентности EVM. Эквивалентность EVM подразумевает более высокий уровень совместимости с Ethereum, позволяя существующим смарт-контрактам Ethereum разворачиваться и работать на Polygon zkEVM без каких-либо изменений. Разработчикам не нужно менять языки или инструменты, и они могут испытать бесшовный переход при развертывании своих смарт-контрактов на эквивалентном EVM rollup. Эквивалентность EVM фактически воссоздает всю среду исполнения Ethereum.

Ключевое отличие заключается в том, что эквивалентность EVM, предлагаемая Polygon zkEVM, обеспечивает "меньше трения" по сравнению с совместимостью EVM, предлагаемой Polygon PoS. Polygon zkEVM разработан для обеспечения прозрачного развертывания и полной совместимости с Ethereum, позволяя разработчикам сохранять тот же рабочий процесс разработки, что и на Ethereum, без необходимости каких-либо изменений или повторной реализации кода. Вкратце, Polygon zkEVM фокусируется на создании почти идеальной копии среды исполнения Ethereum, в то время как Polygon PoS фокусируется на предложении совместимости со смарт-контрактами Ethereum в контексте сайдчейна.

Безопасность

Polygon PoS полагается на свои валидаторы PoS для защиты сайдчейна, которая работает независимо от Ethereum. Polygon zkEVM наследует безопасность основной сети Ethereum, публикуя доказательства достоверности в цепочке, гарантируя, что вычисления вне цепочки являются правильными и безопасными.

Завершенность транзакции

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

Polygon PoS, и Polygon zkEVM предоставляют решения масштабирования уровня 2 для Ethereum, они различаются по своей архитектуре, механизмам консенсуса, параметрам доступности данных и деталям реализации. Polygon zkEVM, в частности, использует технологию ZK-Rollup для достижения улучшенной масштабируемости, безопасности и эквивалентности EVM, обеспечивая при этом быструю завершенность транзакции.

Плюсы и минусы zkEvm Polygon

Плюсы:

• Высокий уровень безопасности (сопоставимый c L1);

• Смарт-контракты практически полностью совместимы, за исключением некоторых precompiled contracts;

• При разработке контрактов возможно использовать инструменты как remix, foundry, hardhat без каких либо проблем;

• Нет необходимости настройки стека для разработки под протокол;

• Стандартный Web3 API (также поддержка стандартных кошельков для Ethereum, например MetaMask);

• Абстракция учетной записи поддерживаются через ERC-4337;

• Скорость обработки транзакций - транзакции на L2 подтверждаются сразу и на L1 через небольшой промежуток времени (около 30 минут);

• Низкая комиссия за транзакции;

• Малый размер zkSNARK в L1 для оптимизации затрат пользователей.

Минусы:

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

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

• Как относительно новая технология, она может содержать нерешенные проблемы или неопределенности.

Вывод

Polygon zkEVM представляет собой значительный прогресс в блокчейн-технологиях, объединяя совместимость с Ethereum и преимущества zero-knowledge proofs. Это открывает новые горизонты для бизнеса в сфере блокчейна, предлагая высокую производительность, масштабируемость, безопасность и экономическую эффективность. Разрабатывать для данного блокчейна практически так же легко как и на обычном EVM блокчейне. Масштабирование которое уже сейчас может помочь уменьшить нагрузку на ethereum и сократить расходы пользователей на газ. В свою очередь, разработчики уже планируют применить обновление EIP-4844 (Dencun) в ближайшее время, что в будущем поможет еще сильнее снизить цену на газ в основной сети Polygon zkEVM.

Ссылки

• Docs: zkEvm Polygon docs

• Video tutorials: The ULTIMATE Developers Guide To Polygon zkEVM

• Dashboard: Ecosystem

• Article: what is polygon zkEVM

• Proof of Efficiency

• The different types of ZK-EVMs

Спасибо, что прочитали! Буду рад, если поделитесь, была ли статья для вас полезной.