لماذا توقف بيربديكس؟ إعادة عرض كاملة لتوقف لايتر لمدة أربع ساعات.

في الحادي عشر من أكتوبر، شهد سوق العملات المشفرة أكبر طلب هامش ربح في تاريخه، بإجمالي تصفية بلغت حوالي 19 مليار دولار. وفي خضم هذا الاختبار السوقي القاسي، تعرضت العديد من منصات تداول المبادلات الدائمة اللامركزية (PerpDex) لانقطاعات، وكانت Lighter الأكثر تضررًا. وقد أثارت الخسائر الناتجة في مجموعة مزودي السيولة (LLP) نقاشًا واسع النطاق في السوق حول منصة PerpDex. وبصفتها شركة أمن Web3، والتي قامت بتدقيق العديد من منصات PerpDex، بما في ذلك Surf Protocol و Tifo.trade، ستستفيد Beosin من سنوات خبرتها في التحليل الفني وتحليل البيانات على السلسلة لتوفير فهم أعمق لأسباب انقطاع Lighter. الإطار الفني لـ Lighter: تتميز Lighter وسط رواج PerpDex برسوم معاملاتها الصفرية، مما يجذب العديد من المستخدمين للتداول على منصتها. تم بناء Lighter على zkLight، وهو نظام ZK Rollup L2 متخصص، لتحسين أداء التداول وكفاءة مطابقة سجل الطلبات. آلية التشغيل الأساسية موضحة في الشكل أدناه:

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

محرك المطابقة: يستقبل الدفعات من المفرز ويلتزم بدقة بمنطق المطابقة "السعر أولاً، الوقت أولاً".

كل مطابقة ناجحة تُجهز البيانات لتوليد دليل عدم المعرفة، مما يضمن أن يتمكن أي شخص من التحقق من عدالة عملية مطابقة لاحقة ومنع احتمالية التلاعب. المُثبِّت: يُولِّد عمليات محرك المطابقة في دليل ZK-SNARK مُوجَّه، ويُستخدم لاحقًا للتحقق من صحة تنفيذ المطابقة وانتقالات الحالة. عقد الشبكة الرئيسية: مسؤول عن التحقق من دليل المعرفة الصفرية الذي يُقدِّمه المُثبِّت. بمجرد التحقق، يُحدَّث جذر الحالة، وتُؤكَّد نتيجة المعاملة وتُنتهى على إيثريوم. بالإضافة إلى التصميم المذكور أعلاه، يُوفِّر Lighter للمستخدمين وظيفة خزنة، تُمكِّنهم من إيداع الأموال في مُجمَّع سيولة Lighter (LLP)، الذي يُؤدِّي الوظائف الثلاث: توفير السيولة، وتوليد عروض الأسعار، وتحمل المخاطر. يُشارك المشاركون في مُجمَّع سيولة Lighter في أرباح المنصة وخسائر الأطراف المُقابلة، مع تحمُّل بعض المخاطر في حالة طلب المستخدم هامشًا. هذا، إلى جانب نظام التصفية في Lighter، يُنشئ آليةً لتخفيف المخاطر. مراجعة فترة توقف Lighter: في 11 أكتوبر 2025، شهد سوق العملات الرقمية عمليات تصفية قياسية للعقود. خلال هذا السوق المتطرف، واجهت Lighter انقطاعًا في الخدمة لعدة ساعات، مما منع المستخدمين من تشغيل مراكزهم وأدى إلى خسارة 5.35٪ من LLP.

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

قبل الانقطاع، كانت منصة Lighter تعالج عادةً حوالي 4005 معاملة في الدقيقة. ارتفع حجم المعاملات من 00:17. احتوت الدفعة رقم ٥٥٦٦٥ على ٥٦٠ كتلة، وعالجت ١٩٦,٩١٣ معاملة. في المتوسط، تمت معالجة حوالي ٦٥,٦٣٨ معاملة في الدقيقة، أي ما يعادل حوالي ١٦ ضعف الفترة الزمنية الاعتيادية.

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

تم إنتاجه إحصائيًا بواسطة Beosin

في الساعة 04:56 يوم 11 أكتوبر، وصل عدد المعاملات التي تمت معالجتها بواسطة الدفعة رقم 55743 إلى أقصى حد له، حيث أكملت 639,370 معاملة في دقيقتين، وهو ما يعادل 79.8 ضعف عدد المعاملات التي تتم معالجتها في الدقيقة خلال الأوقات العادية. من خلال تحليل البيانات من حادثة Lighter، وجدنا أن دفعة Lighter يمكنها استيعاب ما يصل إلى 1600 كتلة، يمكن لكل منها استيعاب ما يصل إلى 500 معاملة. العدد النظري للمعاملات التي يمكنها معالجتها هو 800000 لكل دفعة، بينما أعلى رقم تم قياسه هو 639370. المعاملات المذكورة أعلاه هي معاملات تمت معالجتها بنجاح بواسطة منصة Lighter. يوجد أيضًا العديد من المستخدمين الذين لم يتم تسجيل بياناتهم على السلسلة بسبب فشل إرسال المعاملات وعدم القدرة على تعديل مواقعهم (وقت التوقف). من منظور البنية التقنية، فإن هذا التوقف والخسائر الناتجة عن LLP ترجع في المقام الأول إلى سببين: 1. بالإضافة إلى مشكلات الوصول إلى صفحة الواجهة الأمامية وإرسال الطلبات، تعتمد ZK Rollup من Lighter على فرز واحد لفرز المعاملات وتعبئتها. وعلى الرغم من استخدام ZK Proof للتحقق من النتائج، فإن مركزية الفرز تخلق نقطة واحدة لخطر الفشل. خلال فترات الانخفاض الحاد في الأسعار، يعجز جهاز التسلسل وقاعدة البيانات عن التعامل مع الحمل المفاجئ، مما قد يؤدي إلى تلف الفهرس وعرقلة المعاملات في قاعدة البيانات، مما يُعطل الاتصال بين محرك المطابقة والمستخدم مباشرةً. 2. خلال فترات الارتفاع المفاجئ في حجم التداول، تُصبح عملية توليد وإرسال إثباتات ZK-SNARK عائقًا بسبب قدرات المعالجة المنسقة لعقد توليد الإثباتات وقاعدة البيانات. في ظل ظروف السوق القاسية، تُؤدي الزيادة المتزامنة في عمليات مطابقة التداول والمقاصة إلى بدء الطلبات إلى عقدة توليد إثباتات ZK في نفس الوقت. ربما لم تُطبّق المنصة آليات حجز الموارد للعمليات ذات الأولوية العالية مثل المقاصة، مما يؤدي إلى تنافس على الموارد بين طلبات توليد إثباتات التداول والمقاصة العادية، مما يُفاقم تأخير استجابة النظام، ويمنع تنفيذ عملية المقاصة بسرعة، ويُفاقم خسائر المستخدمين. على المستوى التشغيلي، ردّ فلاديمير نوفاكوفسكي، الرئيس التنفيذي لشركة Lighter، قائلاً: "كانت Lighter قد خططت في الأصل لتحديث قاعدة بياناتها خلال عطلة نهاية الأسبوع التي شهدت انخفاض الأسعار لاستيعاب الزيادة المستمرة في الطلب على التداول". يكشف هذا الحادث أن "اختيار فترة الترقية الخاطئة" كان نتيجةً لعدم استعداد الفريق الكافي لمخاطر السوق. فخلال التوسع السريع للمنصة، فشلوا في إكمال ترقيات البنية التحتية في الوقت المناسب، مما أدى في النهاية إلى أعطال نظامية في ظل ظروف السوق القاسية. يكشف هذا الحادث عن تحدٍّ أساسي يواجه PerpDex: كيفية الحفاظ على سير عمل المنصة بشكل طبيعي خلال ظروف السوق القاسية. فيما يتعلق بأمن العقود الذكية، ينبغي على فرق مشروع PerpDex إجراء عمليات تدقيق شاملة واحترافية لأمن العقود. سبق لشركة Beosin تقديم خدمات تدقيق أمني لمشاريع PerpDex مثل Surf Protocol و Tifo.trade، حيث غطت جوانب مثل أمن شيفرة العقود الذكية، ودقة منطق تنفيذ الأعمال (التداول بالهامش، والمقاصة، وإدارة تجمع السيولة، إلخ)، وتحسين غاز شيفرة العقود، واكتشاف الثغرات المحتملة ومعالجتها، ومساعدة فرق المشروع بنجاح في حل العديد من الثغرات متوسطة وعالية الخطورة. علاوةً على ذلك، يجب على فريق مشروع PerpDex مراعاة التكرار الهيكلي وآليات الاستجابة للطوارئ. في المستقبل، مع تطبيق التقنيات مثل التسلسلات المتعددة وجدولة الموارد الديناميكية، من المتوقع أن يحل Perp Dex مشكلة الاختناق الحالية، ويخدم المزيد من المستخدمين ويصبح البنية التحتية الأساسية للتمويل المشفر.