ديفيد شوارتز يحدد سيناريوهين قد يوقفان دفتر الحسابات بعد التباطؤ

التباطؤ مر دون أي توقف للشبكة

لم يتوقف دفتر حسابات XRP Ledger رغم ما مرت به خلال الساعات الأخيرة. فقد تباطأت المعاملات على الشبكة على مدى 24 ساعة، بيد أن الدفتر ظل يغلق كتلته ويعتمدها طوال تلك المدة، وإن كان بإيقاع أبطأ بكثير من المعتاد. سجل فريق عمليات XRP Ledger الحالة أولا، حين لوحظ أن إغلاق الدفتر يستغرق وقتا أطول من المعتاد بشكل واضح، وهو ما دفع المهندسين إلى البحث عن مصدر التأخير. أثارت الحادثة داخل المجتمع تساؤلات حول مدى صمود البنية اللامركزية للشبكة تحت الضغط. وقد أجاب عن تلك التساؤلات ديفيد شوارتز، المدير التقني السابق في Ripple وأحد مطوري النظام نفسه، في تقييم علني نشره بعد الحادثة. وقال شوارتز إن برنامج XRPL محمي ببنية أمنية متعددة الطبقات، وحدد سيناريوهين وحدهما القادرين على إيقاف الشبكة بأكملها: الأول هو تعطل كبير في آن واحد لمئات خوادم المصادقين (validators) المنتشرة حول العالم، وهو احتمال وصفه بأنه لا يتجسد إلا في كارثة طبيعية ضخمة على نطاق عالمي. والثاني هو نشوء خلل داخل خوارزمية الإجماع، أو تلف على مستوى الشيفرة في إحدى الوظائف الجوهرية للبروتوكول. ولم يقع أي من السيناريوهين في هذه الحادثة. فما وقع، في قراءته، هو تضييق في هامش الأمان التقني للنظام: فالتباطؤات المسجلة في جولات الإجماع خلال الحدث قد تشير، بحسبه، إلى هجوم موجه أو إلى خطأ خفي داخل الشيفرة. ورفض شوارتز أيضا الادعاءات التي تقول إن الشبكة تعتمد على عقدة أو مركز واحد، مؤكدا أن XRPL تعمل ببنية لامركزية كاملة، وأن تعطل أو إثقال أي مركز رئيسي، بما في ذلك عقدته هو، لن يؤثر مباشرة في قابلية الشبكة للعمل بصورة عامة. ولا تتبع عملية الإجماع في الشبكة نموذج إثبات الحصة المفوض الذي تستخدمه شبكات أخرى، لكنها تظل قائمة على اتفاق واسع بين المصادقين. وتسوّي شبكة XRP المدفوعات وأنشطة التمويل اللامركزي على شبكة رئيسية مفتوحة المصدر ومستقلة عن Ripple، الشركة التي تبني حلولا للبنية التحتية للمدفوعات وحلولا مالية قائمة على البلوكتشين، وهو عمل يقع في القطاع الذي يُعرف اليوم باسم payfi.

أنظمة التشخيص تعطلت في أسوأ لحظة

لم يكن الدفتر نفسه مصدر الضرر الأكثر ملموسية خلال الحادثة، بل أنظمة التشخيص. فحين تباطأت جولات الإجماع، انتقل المصادقون فورا إلى الحمل الأقصى. وتعطلت عقدة شوارتز الخاصة تحت ضغط طلبات الاتصال، وبقيت اتصالات RPC المحلية لديه، وهي القناة التي يستخدمها أي برنامج لطلب بيانات أو تنفيذ أوامر على نظام بعيد، عالقة في حالة CLOSE_WAIT، وهي حالة تكون فيها الاتصالة قد استقبلت إشارة الإغلاق من الطرف الآخر بينما لم تُنهِ العملية المحلية إجراءاتها بعد. والاتصالة في هذه الحالة تُبقي مأخذ اتصال مفتوحا على الجانب المحلي، وحيثما تجمعت عدوى منها في ذروة حركة البيانات يمكن أن تستنزف ما تحتاجه العقدة من موارد للإجابة عن الطلبات الجديدة. ونتيجة لهذا العطل، عجز نظام المراقبة الداخلي لديه عن تسجيل بيانات التشخيص أو إرسالها في اللحظة الأكثر حرجا. فتوجب على المهندس إعادة تشغيل الخادم دون تحديد السبب الدقيق للخلل، وقد قال ذلك بصراحة في روايته للحدث. وقد برز تفصيل منفصل أثناء المراجعة: فمركز يتبع أحد مطوري الدفتر كان يرسل سجلاته إلى مضيف اختبار قديم تابع لمؤسسة XRP Ledger Foundation. جعل هذا التوجيه مهمة جمع البيانات الكاملة عن الحدث أكثر تعقيدا، إذ انتهت سجلات نافذة الحادثة خارج مسار الإنتاج. ويعمل فريق الهندسة ومشغلون من المجتمع الآن على تفتيش السجلات الباقية يدويا لعزل الخطأ. وخلاصة شوارتز لوضع الحال: الهامش الأمني ضاق مؤقتا، والفريق أبقى الوضع تحت السيطرة، وبنية الشبكة تحمل احتياطيا تقنيا كافيا لمواصلة التشغيل. أما ما لم يحدث فهو جوهر القصة اليوم: لم يُذكر أي خلل مؤكد في الشيفرة، ولم يقع أي توقف، ولا يظهر أي تباطؤ متكرر في السجل. الغيابات هي شكل الحدث الحالي: تباطؤ انتهى، وتشخيص فشل، وسبب ما يزال عزلوه يدويا جاريا.

المراقبة فشلت قبل الإجماع

صمد الإجماع، بينما لم تصمد قدرة الشبكة على مراقبة نفسها. هذا الانقسام هو الاستنتاج الذي يستحق البقاء من رواية شوارتز، وهو راسخ في سجل من الدرجة الأولى: سجلات عقدته الخاصة وما عجزت عن التقاطه. تصرفت الشبكة كما تقصد بنيتها أن تفعل، فقد امتصت ذروة ضغط دفعت المصادقين إلى الحمل الأقصى دون توقف، بينما انهارت أولا الطبقة المبنية لمراقبتها. وما سيحوّل هذا من حادثة عابرة إلى حدث مؤسس هو أمر محدد: خلل مؤكد في شيفرة الإجماع، أو تباطؤ ثان تتوافر فيه بيانات تشخيص سليمة للمقارنة. لا شيء من الأمرين مسجل حتى الآن، وتقع ردة فعل السوق خارج نطاق الحدث، ويتابع التحليل الفني لـXRP تلك الجانب. وحتى تُحدد المراجعة اليدوية للسجلات سببا واضحا، يبقى الهامش الضيق مشاهدا لا مفسرا.