paint-brush
Технический анализ на ZKBase: высокопроизводительный пакет ZK для масштабируемых и безопасных транзакций ETHк@zkbase
2,864 чтения
2,864 чтения

Технический анализ на ZKBase: высокопроизводительный пакет ZK для масштабируемых и безопасных транзакций ETH

к ZKBase6m2024/08/07
Read on Terminal Reader

Слишком долго; Читать

ZKBase — это высокопроизводительный пакет ZK-Rollup на основе ZK Stack и средства проверки с несколькими графическими процессорами. Это решение расширяет возможности обработки транзакций и обеспечивает экономичную работу сети. Его ключевое преимущество заключается в использовании технологии доказательства с нулевым разглашением (ZKP), позволяющей быстро проверять транзакции вне сети.
featured image - Технический анализ на ZKBase: высокопроизводительный пакет ZK для масштабируемых и безопасных транзакций ETH
ZKBase HackerNoon profile picture


ZKBase — это высокопроизводительный ZK-Rollup, основанный на ZK Stack и многопроцессорном средстве проверки. Это решение расширяет возможности обработки транзакций и обеспечивает экономичную работу сети. Его ключевое преимущество заключается в использовании технологии доказательства с нулевым разглашением (ZKP), позволяющей быстро проверять и подтверждать транзакции вне сети, сохраняя при этом конфиденциальность транзакций и целостность данных. Поскольку все доказательства действительности проверяются на Ethereum, пользователи могут пользоваться теми же гарантиями безопасности, что и в L1. ZKBase работает аналогично Ethereum, но с более высокой пропускной способностью и более низкими комиссиями. Смарт-контракты написаны на Solidity/Vyper и могут вызываться с использованием тех же клиентов, что и другие EVM-совместимые цепочки. В этой статье будут представлены основные инженерно-технические реализации ZKBase.

1. Ключевые компоненты ZKBase

Tree и TreeBackup : эти компоненты используют RocksDB для поддержки локальных копий дерева хранилища L2. База данных остается синхронизированной с последним хэшем корня состояния, постоянно отражая текущее состояние системы.


StateKeeper/VM : выполняет транзакции и безопасно хранит вложенные блоки в локальной базе данных RocksDB, обеспечивая целостность данных и постоянное обновление состояния.


Смарт-контракт : эти смарт-контракты, развернутые в сети Ethereum, проверяют доказательства с нулевым разглашением (ZKP), отправленные из оффчейна. После успешной проверки эти контракты обновляют состояние учетной записи в сети Ethereum.


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


Мост : ZKBase обеспечивает механизм моста для безопасной передачи активов между ZKBase и основной сетью Ethereum, обеспечивая совместимость и ликвидность активов между двумя платформами.

2. Рабочий процесс ZKBase

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


Структура хранения мемпула представляет собой btreeset (набор, реализованный btree). Структура индексации следующая:



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

Транзакции в мемпуле управляются компонентом выборки мемпула внутри State Keeper. За исключением транзакций с истекшим сроком действия, стандартные транзакции извлекаются из мемпула в порядке, определенном обходом btree, и записываются в базу данных. Затем они обрабатываются State Keeper/VM, выполняются и используются для обновления дерева состояний.


Схема расположения блоков показывает организацию транзакций внутри блока и расположение блоков L2 в пакете L1.



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



Корневой хеш дерева Меркла служит основным корневым хешем в этом процессе, гарантируя достоверность пакета и подлинность транзакций. В то же время State Keeper имеет право решать, когда завершать конкретный блок L2 или пакет L1, тем самым определяя его состояние. Это решение определяется набором предопределенных критериев, управляемых модулем Conditional_sealer. Эти критерии включают такие параметры, как количество транзакций, ограничения размера и пороговые значения использования газа. После обработки транзакции State Keeper проверяет, какое условие опечатывания выполнено.


Conditional_sealer поддерживает реестр SealCriteria, который включает в себя:


  • Лимиты количества транзакций,

  • Пределы газа L2,

  • Верхние ограничения на объем публикуемых данных, среди других правил.


Существует четыре сценария принятия решений: NoSeal, IncludeAndSeal, ExcludeAndSeal и Unexecutable. В первых двух случаях процесс один и тот же: состояние после выполнения обновляется в State Keeper. ExcludeAndSeal обрабатывает транзакции, которые превышают предопределенные ограничения пакетов, откатывая выполнение транзакции и помещая ее обратно в очередь для включения в следующий блок L2. В случае возникновения ситуации «Неисполнимость» транзакция не может быть выполнена и будет отклонена.


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


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


Основная сеть Ethereum проверяет правильность доказательства и после успешной проверки соответствующим образом обновляет состояние.


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

3. Архитектура проверки с несколькими графическими процессорами


Архитектура использует базу данных Postgres для обмена данными, обеспечивая параллельные вычисления на нескольких графических процессорах для повышения эффективности генерации доказательств. Ключевые компоненты включают в себя:


Оператор : сервер, предоставляющий услуги уровня 2.


Шлюз проверяющего устройства : модуль связи, который соединяет оператора с подсистемой проверки.


Генератор свидетелей : генерирует задачи вычисления доказательств и сохраняет промежуточные артефакты.


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


Доказывающее: выполняет фактические вычисления и проверку доказательств.


Компрессор: сжимает окончательное доказательство в форму SNARK.

Рабочий процесс создания доказательства

Генерация пакета : Оператор собирает транзакции и генерирует новый пакет.


Прием пакета : шлюз Prover получает новую партию от оператора и начинает подготовку к генерации доказательства с нулевым разглашением.


Вставка в базу данных : шлюз Prover Gateway вставляет информацию о пакете в базу данных Postgres. Последующая обработка данных напрямую взаимодействует с базой данных, извлекая данные из соответствующих входных таблиц и помещая обработанные данные в соответствующие выходные таблицы.


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


  • Базовые схемыWitnessGenerator

  • LeafAggregationWitnessGenerator

  • Агрегация узлов

  • Планировщик


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


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


Сжатие : модуль Compressor сжимает доказательства, чтобы уменьшить размер данных, преобразуя их в форму SNARK.

4. Вывод

ZKBase, построенный на базе ZK Stack и Multi-GPU Prover, обеспечивает высокопроизводительную масштабируемость уровня 2. Однако решение для масштабирования Ethereum ZK-Rollup по-прежнему сталкивается с многочисленными техническими проблемами. В будущем ZKBase продолжит исследования и изучение реализации децентрализованного секвенирования и децентрализованной вычислительной сети ZK.