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