Почему PerpDex "потух"? Полный обзор 4-часового простоя Lighter

11 октября рынок криптоактивов пережил крупнейшую за всю историю ликвидацию, общая сумма расчета составила около 19 миллиардов долларов. В ходе этого экстремального испытания рынка несколько платформ для торговли бессрочными фьючерсами (Perp Dex) вышли из строя, причем Lighter пострадал больше всего из-за сбоя, что вызвало убытки в фонде поставщика ликвидности (LLP) и привлекло широкое обсуждение платформы PerpDex на рынке.

Как аудитор Web3-безопасной компании Beosin, проверившей множество Perp Dex, таких как Surf Protocol и Tifo.trade, в этой статье мы с помощью многолетнего накопленного опыта в области технологий и анализа данных на блокчейне поможем всем глубже понять причины инцидента с отключением Lighter.

Техническая структура Lighter

Lighter выделяется на фоне бумов PerpDex благодаря нулевой торговой комиссии, привлекая множество пользователей для торговли на своей платформе. Lighter построен на zkLight, специфическом ZK Rollup L2, для повышения производительности транзакций и эффективности матчинга ордеров. Его основная операционная механика показана на рисунке ниже:

!

Сортировщик: как первая точка взаимодействия с пользователем, отвечает за прием торговых команд и их сортировку и упаковку в Batch (пакетные данные торгового процесса).

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

Доказатель (Prover): генерирует сжатое ZK-SNARK доказательство, чтобы подтвердить правильность выполнения свопов и преобразования состояния.

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

Помимо вышеуказанного дизайна, Lighter предоставляет пользователям функцию хранилища, позволяя пользователям вносить средства в Lighter Liquidity Pool (LLP), который выполняет три функции: предоставление ликвидности, генерация котировок и принятие рисков. Участники LLP могут делиться доходами платформы и получать прибыль от убытков контрагентов, а также принимать на себя часть рисков в случае ликвидации пользователей, что в сочетании с ликвидационной системой Lighter создает механизм буфера риска.

Анализ сбоев Lighter

11 октября 2025 года объем ликвидации контрактов на рынке шифрования установил исторический рекорд. В этой экстремальной ситуации Lighter произошло несколько часов простоя, что привело к невозможности пользователей управлять позициями, потери LLP составили около 5,35%.

Beosin, проведя анализ данных блокчейна за основной период события (Пекинское время 11 октября 2025 года с 00:17 до 05:08), обнаружила, что Lighter потерял 3 Batch начиная с Batch#55661 и начал восстанавливать производство Batch в 00:17 (в 00:23 Lighter выпустил объявление о том, что заказы пользователей не могут быть обработаны или выполнены).

Объем транзакций, который платформа Lighter обрабатывала до сбоя, составлял около 4005 транзакций в минуту. С 00:17 объем транзакций резко увеличился. Batch#55665 содержит 560 блоков, объем обработанных транзакций составил 196913, среднее количество транзакций, которое необходимо обрабатывать в минуту, составляет около 65638, что примерно в 16 раз больше обычного.

Ниже приведен статистический график количества обработанных сделок по времени подачи каждой партии с 00:17 до 05:08 11 октября:

!

Составлено Beosin

11 октября в 04:56, Batch#55743 достиг максимального количества обработанных сделок, завершив 639370 сделок за 2 минуты, что в 79,8 раз больше обычного количества сделок в минуту. Анализируя данные Lighter по этому событию, мы обнаружили, что Batch Lighter может вместить до 1600 блоков, каждый из которых может содержать до 500 сделок, что теоретически позволяет обрабатывать 800000 сделок на Batch, в то время как фактически максимальное количество составило 639370.

Выше приведены сделки, успешно обработанные платформой Lighter, также многие пользователи не смогли скорректировать свои позиции (получить ликвидацию) из-за неудачной подачи сделок, и данные не были зафиксированы в цепочке. С точки зрения технической архитектуры, причиной данной неисправности и потерь LLP являются в основном 2 фактора:

1. Помимо проблем с доступом к фронтенд-странице и подачей заказов, ZK Rollup от Lighter полагается на единого сортировщика для сортировки и упаковки транзакций. Несмотря на то, что результаты проверяются с помощью ZK Proof, централизация сортировщика приводит к риску единой точки отказа. В период резкого падения сортировщик и база данных не могут справиться с внезапной нагрузкой, что может привести к повреждению индексов базы данных и блокировке транзакций, что напрямую вызывает разрыв соединения между системой сватовства и пользователем. 2. Процесс генерации и подачи доказательств ZK-SNARK становится узким местом при резком увеличении объема транзакций. В экстремальных условиях синхронно возрастающие операции сватовства и клиринга одновременно отправляют запросы к узлам генерации ZK-доказательств. Платформа может не установить механизм резервирования ресурсов для таких операций с высоким приоритетом, как клиринг, что приводит к конкуренции за ресурсы между запросами на генерацию доказательств обычных транзакций и клиринга, что дополнительно усугубляет задержки в ответах системы и делает невозможным своевременное выполнение клиринговых процессов, увеличивая потери пользователей. На операционном уровне, по словам генерального директора Lighter Владимира Новаковски, “Lighter изначально планировал обновление базы данных в выходные дни, когда произошло это резкое падение, чтобы адаптироваться к постоянно растущему спросу на транзакции”. С точки зрения данного инцидента, такая “ошибка выбора окна обновления” произошла из-за недостаточной подготовки команды к рыночным рискам, в процессе быстрого роста платформы не удалось осуществить своевременное обновление инфраструктуры, что в конечном итоге привело к системному сбою платформы в условиях экстремальных рыночных условий. Этот инцидент выявил одну из ключевых проблем, с которой сталкивается PerpDex: как поддерживать нормальную работу платформы в условиях экстремальных рыночных условий. В области безопасности смарт-контрактов команды проектов в сегменте Perp Dex должны пройти всесторонний и профессиональный аудит безопасности контрактов. Beosin ранее предоставлял услуги по безопасности для таких проектов, как Surf Protocol и Tifo.trade в сегменте Perp Dex, охватывающие безопасность кода смарт-контрактов, правильность бизнес-логики (торговля с использованием плеча, клиринг, управление ликвидностью и т.д.), оптимизацию газа кода контрактов, а также обнаружение и исправление потенциальных уязвимостей, успешно помогая командам проектов исправить несколько уязвимостей средней и высокой степени риска.

Кроме того, команде проекта Perp Dex необходимо учитывать архитектурные избыточности и механизмы экстренной помощи. В будущем, с использованием таких технологий, как многосортировщики и динамическое распределение ресурсов, Perp Dex, вероятно, сможет решить текущую проблему и обслуживать больше пользователей, став основной инфраструктурой криптофинансов.