لماذا توقفت PerpDex؟ تحليل كامل لتوقف Lighter لمدة 4 ساعات

في 11 أكتوبر، شهد سوق الأصول الرقمية أكبر حدث تصفية في التاريخ، حيث بلغ إجمالي مبلغ التصفية حوالي 19 مليار دولار. خلال هذه التجربة السوقية المتطرفة، تعرضت عدة منصات تداول العقود الآجلة الدائمة اللامركزية (Perp Dex) للاختراق، حيث كانت Lighter الأكثر تضرراً من الحادث، مما أدى إلى خسائر في حوض الأموال لمزود السيولة (LLP) وأثار مناقشات واسعة في السوق حول منصة PerpDex.

بصفته شركة أمان Web3 قامت بتدقيق عدة بروتوكولات مثل Surf Protocol وTifo.trade، ستساعد Beosin في هذه المقالة من خلال سنوات من الخبرة في التحليل الفني وبيانات السلسلة، الجميع على فهم الأسباب وراء حدث تعطل Lighter.

إطار عمل Lighter

تتألق Lighter من خلال ميزة عدم وجود رسوم تداول في ذروة PerpDex، مما يجذب العديد من المستخدمين للتداول على منصتها. تم بناء Lighter على zkLight، وهو نوع محدد من ZK Rollup L2، لتحسين أداء التداول وكفاءة مطابقة دفتر الطلبات. آلية التشغيل الأساسية لها موضحة في الشكل أدناه:

!

المُرتب: بوصفه محطة التفاعل الأولى للمستخدم، فهو مسؤول عن استقبال أوامر التداول، وترتيب المعاملات وتجميعها في دفعة (حزمة بيانات المعاملات).

محرك المطابقة: يستقبل دفعات من النظام المرتب، ويتبع بدقة منطق المطابقة “الأولوية السعرية، الأولوية الزمنية”. كل عملية مطابقة ناجحة ستعد البيانات اللازمة لإنشاء إثباتات المعرفة الصفرية، مما يضمن أن أي شخص يمكنه التحقق من عدالة عملية المطابقة بعد ذلك، وتجنب إمكانية التلاعب.

المُثبت (Prover): تحويل عمليات محرك المطابقة إلى إثبات ZK-SNARK مختصر، لاستخدامه في التحقق من صحة تنفيذ المطابقة وتحويل الحالة لاحقًا.

الشبكة الرئيسية للعقود: مسؤولة عن التحقق من الإثباتات التي يقدمها المدّعون. بمجرد التحقق من صحة ذلك، سيتم تحديث جذر الحالة، وبذلك تحصل نتيجة المعاملة على تأكيد نهائي على الإيثيريوم.

بجانب التصميم المذكور أعلاه، يوفر Lighter للمستخدمين وظيفة الخزينة، حيث يمكن للمستخدمين إيداع الأموال في Lighter Liquidity Pool (LLP)، والذي يتحمل ثلاث وظائف: توفير السيولة، توليد الأسعار وتحمل المخاطر. يمكن لمشاركي LLP مشاركة أرباح المنصة والأرباح الناتجة عن خسائر الطرف الآخر، وفي نفس الوقت تحمل جزء من المخاطر في حالة تصفية المستخدم، بالتعاون مع نظام التسوية الخاص بـ Lighter، لتشكيل آلية لتخفيف المخاطر.

مراجعة انقطاع Lighter

في 11 أكتوبر 2025، سجلت أحجام تصفية العقود في سوق الأصول الرقمية رقماً قياسياً تاريخياً. خلال هذا السوق المتطرف، تسبب Lighter في انقطاع الخدمة لعدة ساعات مما أدى إلى عدم قدرة المستخدمين على إدارة مراكزهم، وخسرت LLP حوالي 5.35٪.

اكتشفت Beosin من خلال تحليل بيانات السلسلة الزمنية الرئيسية لهذا الحدث (بتوقيت بكين 2025/10/11 00:17-05:08) أن Lighter فقدت 3 دفعات منذ Batch#55661، وبدأت استعادة إنتاج الدفعات عند 00:17 (في 00:23 أصدرت Lighter إعلانًا تفيد بأن أوامر المستخدمين لا يمكن معالجتها أو تنفيذها).

كان حجم المعاملات التي تمت معالجتها بشكل طبيعي على منصة Lighter حوالي 4005 معاملات في الدقيقة قبل تعطل النظام، ومنذ الساعة 00:17، شهد حجم المعاملات زيادة كبيرة، حيث يحتوي Batch#55665 على 560 كتلة، وعدد المعاملات المعالجة هو 196913، مما يتطلب معالجة حوالي 65638 معاملة في الدقيقة، وهو ما يعادل حوالي 16 مرة من الفترة العادية.

فيما يلي مخطط إحصائي لعدد المعاملات المعالجة في كل Batch من 00:17 إلى 05:08 بتاريخ 11 أكتوبر:

!

تم إحصاؤها بواسطة Beosin

في 11 أكتوبر الساعة 04:56، وصلت عدد المعاملات المعالجة في Batch#55743 إلى الحد الأقصى، وتم إكمال 639370 معاملة خلال دقيقتين، وهو ما يعادل 79.8 ضعف عدد المعاملات المعالجة في الدقيقة خلال الفترة العادية. من خلال إحصاء بيانات Lighter في هذه الحادثة، نجد أن Batch من Lighter يمكن أن يستوعب ما يصل إلى 1600 كتلة، حيث يمكن أن تحتوي كل كتلة على 500 معاملة كحد أقصى، وعدد المعاملات النظري القابل للمعالجة هو 800000/Batch، بينما كانت النتيجة القصوى المختبرة 639370.

أعلاه هو التداول الذي تمت معالجته بنجاح على منصة Lighter، وهناك العديد من المستخدمين الذين لم يتمكنوا من تعديل مراكزهم بسبب فشل تقديم التداول (تعطل النظام) ولم يتم تسجيل البيانات على السلسلة. من حيث البنية التقنية، هناك سببان رئيسيان لتعطل النظام ولخسارة LLP:

1. بخلاف مشكلات الوصول إلى واجهة المستخدم الأمامية وتقديم الطلبات، يعتمد ZK Rollup من Lighter على مُرتب واحد لتصنيف المعاملات وتعبئتها، وعلى الرغم من أنه يتم تحقيق التحقق من النتائج من خلال ZK Proof، فإن مركزية المُرتب تؤدي إلى مخاطر فشل النقطة الواحدة. خلال فترات الانهيار، لا يمكن للمُرتب وقاعدة البيانات تحمل الحمل المفاجئ، وقد يحدث تلف في الفهرس وعرقلة للمعاملات في قاعدة البيانات، مما يؤدي مباشرةً إلى انقطاع الاتصال بين محرك المطابقة وواجهة المستخدم. 2. تصبح القدرة التعاونية بين عقد توليد إثبات ZK-SNARK وقاعدة البيانات نقطة اختناق عندما يرتفع حجم التداول بشكل حاد. في ظروف السوق المتطرفة، تتقدم عمليات مطابقة المعاملات والتسوية التي تزداد بشكل متزامن بطلبات إلى عقد توليد إثبات ZK. قد لا يكون لدى المنصة آلية احتياطي للموارد لمثل هذه العمليات ذات الأولوية العالية، مما يؤدي إلى تنافس على موارد طلبات توليد إثبات المعاملات العادية والتسوية، مما يزيد من تأخير استجابة النظام، مما يجعل عملية التسوية غير قادرة على التنفيذ في الوقت المناسب، مما يفاقم خسائر المستخدمين. من الناحية التشغيلية، وفقًا لما ذكره الرئيس التنفيذي لشركة Lighter، فلاديمير نوفاكوفسكي، “كانت Lighter تخطط في الأصل لترقية قاعدة البيانات خلال عطلة نهاية الأسبوع التي حدثت فيها هذه الانهيارات لتناسب الطلب المتزايد المستمر على التداول”. من خلال هذا الحدث، يتضح أن “اختيار نافذة الترقية الخاطئة” كان بسبب عدم استعداد فريقهم لمخاطر السوق، حيث لم يتمكنوا من إكمال ترقية البنية التحتية في الوقت المناسب خلال عملية التوسع السريع للمنصة، مما أدى في النهاية إلى فشل النظام الأساسي في ظل ظروف السوق المتطرفة. يكشف هذا الحدث عن مشكلة جوهرية تواجه PerpDex: كيفية الحفاظ على تشغيل المنصة بشكل طبيعي في ظل ظروف السوق المتطرفة. في جانب أمان العقود الذكية، يجب على فرق مشاريع Perp Dex إجراء تدقيق أمان شامل ومهني للعقود. قد قدمت Beosin سابقًا خدمات تدقيق الأمان لـ Surf Protocol وTifo.trade وغيرها من مشاريع Perp Dex، والتي تغطي أمان كود العقود، وصحة منطق تنفيذ الأعمال (التداول بالهامش، التسوية، إدارة pools السيولة، إلخ)، وتحسين الغاز لكود العقود، واكتشاف الثغرات المحتملة وإصلاحها في عدة جوانب، مما ساعد بنجاح فرق المشاريع في إصلاح العديد من الثغرات متوسطة إلى عالية المخاطر.

بالإضافة إلى ذلك، يحتاج فريق مشروع Perp Dex إلى أخذ الهيكل الزائد وآليات الطوارئ في الاعتبار. في المستقبل، مع تطبيق تقنيات مثل تعدد المعالجات، وجدولة الموارد الديناميكية، من المتوقع أن يتمكن Perp Dex من حل هذه العقبة الحالية، لخدمة المزيد من المستخدمين وأن يصبح بنية تحتية أساسية في المالية المشفرة.