ZKBase — это высокопроизводительный ZK-Rollup, основанный на ZK Stack и многопроцессорном средстве проверки. Это решение расширяет возможности обработки транзакций и обеспечивает экономичную работу сети. Его ключевое преимущество заключается в использовании технологии доказательства с нулевым разглашением (ZKP), позволяющей быстро проверять и подтверждать транзакции вне сети, сохраняя при этом конфиденциальность транзакций и целостность данных. Поскольку все доказательства действительности проверяются на Ethereum, пользователи могут пользоваться теми же гарантиями безопасности, что и в L1. ZKBase работает аналогично Ethereum, но с более высокой пропускной способностью и более низкими комиссиями. Смарт-контракты написаны на Solidity/Vyper и могут вызываться с использованием тех же клиентов, что и другие EVM-совместимые цепочки. В этой статье будут представлены основные инженерно-технические реализации ZKBase.
Tree и TreeBackup : эти компоненты используют RocksDB для поддержки локальных копий дерева хранилища L2. База данных остается синхронизированной с последним хэшем корня состояния, постоянно отражая текущее состояние системы.
StateKeeper/VM : выполняет транзакции и безопасно хранит вложенные блоки в локальной базе данных RocksDB, обеспечивая целостность данных и постоянное обновление состояния.
Смарт-контракт : эти смарт-контракты, развернутые в сети Ethereum, проверяют доказательства с нулевым разглашением (ZKP), отправленные из оффчейна. После успешной проверки эти контракты обновляют состояние учетной записи в сети Ethereum.
GPU Prover : технология ZK-Rollup, обеспечивающая безопасную и эффективную проверку транзакций посредством доказательств с нулевым разглашением. Когда пакет транзакций происходит за пределами сети Ethereum, система агрегации ZK сжимает несколько транзакций в одно «доказательство достоверности», рассчитанное проверяющим устройством, демонстрирующее правильность пакета. Это доказательство затем передается в сеть Ethereum, что позволяет быстро и безопасно подтвердить большой объем транзакций, происходящих вне сети.
Мост : ZKBase обеспечивает механизм моста для безопасной передачи активов между ZKBase и основной сетью Ethereum, обеспечивая совместимость и ликвидность активов между двумя платформами.
Пользователи могут инициировать запросы 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.
Архитектура использует базу данных Postgres для обмена данными, обеспечивая параллельные вычисления на нескольких графических процессорах для повышения эффективности генерации доказательств. Ключевые компоненты включают в себя:
Оператор : сервер, предоставляющий услуги уровня 2.
Шлюз проверяющего устройства : модуль связи, который соединяет оператора с подсистемой проверки.
Генератор свидетелей : генерирует задачи вычисления доказательств и сохраняет промежуточные артефакты.
Векторный генератор : объединяет все вычислительные задачи в векторный формат, подходящий для вычислений на графическом процессоре, и отправляет их проверяющим.
Доказывающее: выполняет фактические вычисления и проверку доказательств.
Компрессор: сжимает окончательное доказательство в форму SNARK.
Генерация пакета : Оператор собирает транзакции и генерирует новый пакет.
Прием пакета : шлюз Prover получает новую партию от оператора и начинает подготовку к генерации доказательства с нулевым разглашением.
Вставка в базу данных : шлюз Prover Gateway вставляет информацию о пакете в базу данных Postgres. Последующая обработка данных напрямую взаимодействует с базой данных, извлекая данные из соответствующих входных таблиц и помещая обработанные данные в соответствующие выходные таблицы.
Генерация свидетеля : этот начальный этап происходит, когда пользователь инициирует транзакцию, генерируя свидетеля. Свидетель подтверждает действительность транзакции на основе правил сетевого консенсуса, не раскрывая никаких подробностей транзакции. Новые свидетели транзакций собираются и обрабатываются пакетами. Каждая партия проходит следующие процессы:
Базовые схемыWitnessGenerator
LeafAggregationWitnessGenerator
Агрегация узлов
Планировщик
Генерация векторов : векторный генератор объединяет схемы для создания векторов-свидетелей, оптимизируя использование вычислительной мощности графического процессора.
Вычисление доказательств : Доказывающие устройства используют графические процессоры для вычисления доказательств с нулевым разглашением, проверяя правильность вычислений доказательства.
Сжатие : модуль Compressor сжимает доказательства, чтобы уменьшить размер данных, преобразуя их в форму SNARK.
ZKBase, построенный на базе ZK Stack и Multi-GPU Prover, обеспечивает высокопроизводительную масштабируемость уровня 2. Однако решение для масштабирования Ethereum ZK-Rollup по-прежнему сталкивается с многочисленными техническими проблемами. В будущем ZKBase продолжит исследования и изучение реализации децентрализованного секвенирования и децентрализованной вычислительной сети ZK.