Чому PerpDex "загас"? Повний огляд 4-годинного збої Lighter

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

Як компанія з безпеки Web3, що провела аудит багатьох Perp Dex, таких як Surf Protocol та Tifo.trade, Beosin у цій статті поділиться накопиченим за багато років досвідом у сфері технологій та аналізу даних на блокчейні, щоб допомогти всім глибше зрозуміти причини цього інциденту з 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 шляхом аналізу даних на основі блокчейну основного періоду події (за пекинським часом з 00:17 до 05:08 11 жовтня 2025 року) виявив, що Lighter з Batch#55661 почав втрачати 3 Batch, а о 00:17 почав відновлювати виробництво Batch (о 00:23 Lighter опублікував оголошення, що замовлення користувачів не можуть бути оброблені або виконані).

Платформа Lighter обробляла близько 4005 угод/хвилину перед збоєм, починаючи з 00:17 обсяг угод різко зріс, Batch#55665 містить 560 блоків, оброблена кількість угод становить 196913, в середньому потрібно обробляти близько 65638 угод на хвилину, що приблизно у 16 разів більше, ніж у звичайний період.

Нижче наведено статистичну діаграму кількості оброблених угод за часовими проміжками з 00:17 до 05:08 11 жовтня для кожної партії:

!

Складено Beosin

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

Вищезазначене є угодами, успішно обробленими платформою Lighter, а багато користувачів не змогли відрегулювати позиції (вимкнення) через невдачу у поданні угоди, тому дані не були зафіксовані в мережі. З технічної точки зору, ця вимкненість і заподіяна шкода LLP мають дві основні причини:

1. Окрім проблем з доступом до фронтенд-сторінок та поданням замовлень, ZK Rollup від Lighter залежить від єдиного сортувальника для впорядкування та упаковки транзакцій. Хоча отримано підтвердження результатів через ZK Proof, централізація сортувальника призводить до ризику одноточкової відмови. В період різкого падіння, сортувальник і база даних не можуть впоратися з раптовим навантаженням, можуть виникнути пошкодження індексу та блокування транзакцій, що безпосередньо призводить до розриву з'єднання між механізмом зведення та кінцевим користувачем. 2. Процес генерації та подання підтверджень ZK-SNARK під час різкого збільшення обсягу транзакцій стає вузьким місцем у співпраці між вузлами генерації підтверджень та базою даних. В екстремальних умовах, синхронно зростаючі запити на зведення та клірингові операції одночасно надсилаються до вузлів генерації підтверджень ZK. Платформа, можливо, не встановила механізм резервування ресурсів для таких операцій з високим пріоритетом, через що запити на генерацію підтверджень звичайних транзакцій та клірингу вступають у конкуренцію за ресурси, що додатково посилює затримки у відповіді системи, ускладнюючи своєчасне виконання процесу клірингу та збільшуючи втрати користувачів. З точки зору операційної діяльності, за словами CEO Lighter Володимира Новацького, “Lighter спочатку планував оновлення бази даних на вихідних, коли відбулося це падіння, щоб відповідати постійно зростаючому попиту на транзакції”. З цієї події видно, що “помилка у виборі вікна оновлення” була наслідком недостатньої готовності команди до ринкових ризиків, в процесі швидкого розширення платформи не вдалося вчасно завершити оновлення інфраструктури, що в кінцевому підсумку призвело до системних збоїв платформи в умовах екстремальних ринків. Ця подія виявила одну з основних проблем, з якими стикається PerpDex: як підтримувати нормальну роботу платформи в екстремальних умовах. Щодо безпеки смарт-контрактів, команди проектів у сегменті Perp Dex повинні провести всебічний, професійний аудит безпеки контрактів. Beosin раніше надавала послуги з безпеки для Surf Protocol, Tifo.trade та інших Perp Dex, охоплюючи безпеку коду смарт-контрактів, правильність бізнес-логіки (кредитне плечо, кліринг, управління ліквідними пулами тощо), оптимізацію газу коду контрактів, виявлення та виправлення потенційних вразливостей, успішно допомагаючи командам проектів усувати кілька середньо- та високоризикових вразливостей.

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