الكاتب: Liam 'Akiba' Wright، cryptoslate
مُحرر: Saoirse، Foresight News
في غضون أربعة أيام، توقفت ثلاث شبكات سلسلة كتل على التوالي عن إنتاج الكتل. واستُخدمت صلاحيات طوارئ مختلفة تمامًا في كل تعطيل للشبكة، حيث لم تُعدّل سوى كرونوس جزءًا من تاريخ السلسلة الرسمي.
أفاد Cronos أن عقدات التحقق أوقفت الشبكة عبر آلية الإجماع بعد تعرض بروتوكول Tectonic لهجوم ثغرة، وأعادت السلسلة إلى حالتها قبل الهجوم، ثم أعادت بدء إنشاء الكتل من ارتفاع الكتلة 90,896,189. لم يُوقف هذا الإجراء إنشاء الكتل فحسب، بل قام أيضًا بكتابة حالة السلسلة مباشرة. جميع المعاملات وتغييرات الحالة التي تم إنشاؤها بعد نقطة الاستعادة لم تعد جزءًا من السلسلة الرئيسية الرسمية بعد إعادة التشغيل.
استخدمت Ontology و ICON مجموعة أخرى من إجراءات الطوارئ. فقد أوقفت Ontology إنتاج الكتل قبل التأكد من سلوك الهجوم الضار، وأفادت ملاحظات التحديث الخاصة بها في 1 سبتمبر أن هذا النشاط الضار لم يتسبب في خسارة أصول المستخدمين. أما ICON، فأوقفت أولاً العقد المهاجم، ثم أوقفت الشبكة بالكامل؛ وذكرت المؤسسة أن الشبكة كانت في مرحلة النقل وكانت تحت سيطرتها، وفي ذلك الوقت تم تحويل معظم ICX المسروقة إلى حسابات التخزين في البورصات.
إن توقف البلوكشين هو مجرد وسيلة تحكم من الطبقة الأولى. المشكلة الأعمق هي: من لديه السلطة لطلب إيقاف الشبكة؟ هل يمكنهم إعادة كتابة حالة السلسلة المؤكدة؟ عندما تنتقل الأموال عبر السلاسل أو تدخل إلى جهات وساطة مركزية، ما هي الخسائر التي لا يمكن تعويضها؟
تم استعادة معلومات الصلاحيات المتعلقة بالإجراءات الطارئة لحدث التحفيز الشبكي؛ تم اكتشاف خطر الاسترداد بسبب هجوم ثغرة CronosTectonic، مما أدى إلى إيقاف الشبكة واستعادة حالة السلسلة إلى ما قبل حدوث الثغرة من خلال توافق المُحققين؛ تم إلغاء جميع الأنشطة على السلسلة بعد نقطة التحقق من بيانات العد وعتبة التصويت التي لم تُكشف عنها؛ الأموال المحولة إلى إيثريوم لا تخضع لسيطرة Cronos؛ لم تُكتمل بعد إحصائيات الخسائر النهائية لبروتوكول Tectonic؛ أثناء الفحص اليومي لـ Ontology، تم اكتشاف مخاطر محتملة، وتم التأكد لاحقًا من وجود أنشطة خبيثة، مما أدى إلى إيقاف إنتاج الكتل احترازيًا دون تنفيذ عملية تراجع؛ شارك فريق التطوير الأساسي وفريق التقنية وعقد المُحققين؛ لم تُكشف عن عتبات التحفيز للتعامل الطارئ؛ خلال فترة الإصلاح والترقية الشبكية، لم تكن المعاملات قابلة للتنفيذ؛ لم يتم اكتشاف أي ضرر على أصول المستخدمين؛ يوجد ثغرة إعادة التشغيل في عقد الهجرة لـ ICON، لذا تم إيقاف العقد مؤقتًا، ثم إيقاف الشبكة بالكامل؛ خلال مرحلة الهجرة، كانت الشبكة تحت سيطرة المؤسسة، وتم تقليل عدد عقد المُحققين الأساسية، وتحمل المؤسسة الخسائر؛能否 استرداد ICX المخزنة في البورصات يعتمد على جهة التخزين والإجراءات القانونية وسلطات إنفاذ القانون

مقارنة طرق التصدي الطارئة لسلاسل Cronos و Ontology و ICON
Cronos: من التوقف إلى إعادة كتابة حالة السلسلة
وصف كرونيس الحدث بأنه "عملية طارئة للإجماع من قبل المُحققين". أظهر إعلان إعادة التشغيل في 31 أغسطس أن الشبكة استؤنفت لإنتاج الكتل في 30 أغسطس، 23:49:01 بالتوقيت العالمي المنسق، مع عودة حالة السلسلة إلى ما قبل هجوم ثغرة Tectonic.
عملية إيقاف تشغيل Cronos تعني اتخاذ قرار بتوزيع المكاسب على نقاط الاستعادة. بعد نقطة التحقق، يتم حذف الحالة على السلسلة المرتبطة بالثغرة، إلى جانب جميع المعاملات غير ذات الصلة خلال تلك الفترة، من السلسلة الرسمية. لم يرفق إشعار إعادة التشغيل بقائمة بالمعاملات، أو إحصائيات عقد التحقق، أو عتبة وزن التصويت، أو قائمة بالعقد المشاركة. وتعهد Cronos بنشر تقرير مراجعة ما بعد الحادث لشرح عملية التصرف ونطاق التأثير التقني بشكل كامل.
لا يزال حجم الأصول التي حمتها هذه التدخلات فعليًا غير مؤكد. تقدر TRM Labs أن حوالي 75 مليون دولار من الأصول تم إقراضها بعد تلاعب في سعر رمز TONIC؛ حيث تدفق حوالي 6 ملايين دولار إلى إيثريوم، وتم تنفيذ إعادة التوجيه داخل سلسلة Cronos بقيمة حوالي 68.7 مليون دولار. بينما تقدم إحصائيات Bitquery حجمًا إجماليًا أعلى للخروج، حيث تدفق حوالي 8.3 مليون دولار من الأصول إلى إيثريوم، وتم التخلي عن ما مجموعه 10961 كتلة.
المنهجيتان الإحصائيتان تقيسان كيانات مختلفة، ولا تزال بيانات الخسارة النهائية من قبل Tectonic رسمياً بانتظار الإعلان. لكن هناك نقطة واحدة أصبحت واضحة جداً: لا يمكن لعملية التراجع الخاصة بـ Cronos استعادة الحالة التي لا تزال موجودة على السلسلة الخاصة بها فقط، بينما الأصول على سلسلة إيثريوم غير خاضعة لأي تحكم منها.
لا تزال هناك مشكلات محاسبية للمستخدمين معلقة في خطة التخلص من الأصول الخاصة بـ Tectonic. أفاد البروتوكول أنه سيتم تمكين وظيفتي السحب وسداد قروض القروض أولاً، مع تعليق الإيداعات والاقتراض الجديد. توفر هذه الخطة للمستخدمين مسارًا للخروج وتخفيض الرافعة المالية، لكن لم يتم التأكد بعد من قدرة مزودي السيولة على استرداد أموالهم بالكامل. لا تزال تقرير ما بعد الحدث الذي سيُصدره Tectonic بحاجة إلى توضيح طبيعة الثغرة، وإجمالي تدفق الأموال الخارجة، وحجم الديون السيئة، والأصول المستردة، والديون المتبقية الأخرى.
تختلف جداول استعادة البنية التحتية المختلفة وإعادة تشغيل توافق السلسلة. ويشير كرونوس إلى أن البروتوكولات المختلفة، وجسور العبور بين السلاسل، ومتصفحات الكتل، وخدمات RPC تحتاج إلى مزيد من الوقت للتعافي. كما سجّلت صفحة حالة Alchemy بشكل منفصل هذه فترة التوقف ثم عملية الاستعادة اللاحقة. يمكن الإعلان عن إعادة تشغيل شبكة السلسلة رسميًا، لكن الخدمات المعتمدة عليها قد لا تكون جاهزة بعد.
Ontology: التوقف عن العمل يهدف فقط إلى كسب وقت للتعامل مع الموقف، ولا يلغي المعاملات
حدثت إجراءات التصرف الخاصة بـ Ontology قبل تأكيد النشاط الضار. وذكرت الشبكة أن فريق التطوير الأساسي اكتشف ثغرات أمنية محتملة أثناء الفحوصات اليومية، فوقف فورًا إنتاج الكتل، وسلّم الأمر إلى فريق التقنية وعقدات التحقق لإجراء مراجعة للنظام.
أُعلن في تحديث بتاريخ 1 سبتمبر أن المراجعة أكدت وجود هجوم خبيث، وسيستمر تعطيل الشبكة الرئيسية لإجراء إصلاحات الثغرات وترقية الشبكة؛ ولم يتأثر أصول المستخدمين بهذا الهجوم. يهدف Ontology إلى استئناف التشغيل الطبيعي خلال 24 ساعة، بشرط إكمال فحوصات الأمان وإصلاح الثغرات والترقية والاختبار بنجاح.
يحتفظ Ontology بجميع الحالات على السلسلة التي تم تأكيدها أثناء التوقف، ويتوقف فقط عن تأكيد وتسوية المعاملات الجديدة. لم يحدد الإعلان نقطة الاستعادة، ولم يُعلن عن مجموعة المعاملات التي تحتاج إلى إلغائها.
معلومات الصلاحيات المعلنة ليست كاملة. ذكر الإعلان مشاركة فريق التطوير الأساسي وفريق التقنية وعقد التحقق في الشبكة في التصرف، لكنه لم يحدد من هو صاحب القرار النهائي الملزم، ولم يُقدّم عتبة طوارئ رقمية. وصف وثيقة VBFT الخاصة بـ Ontology آلية التوافق العادية، بما في ذلك توليد العقد للكتل المؤكدة وإدارة مجموعة عقد التوافق لتحديث العقود، لكن الوثيقة تغطي فقط سيناريوهات التشغيل العادية، ولم تُنشر قواعد الإيقاف الطارئ المستخدمة في 31 أغسطس.
حتى لو لم يُسبب التوقف خسارة في الأصول، فإنه لا يزال يترتب عليه تكاليف فعلية. أبلغت Ontology المستخدمين أن المعاملات على السلسلة لن تُعالج، ونصحت بعدم تنفيذ العمليات الحساسة للوقت؛ ثم أوضحت لاحقًا أن إعادة تشغيل الشبكة تعتمد على إصلاح الثغرة والترقية والاختبار. لا يمكن للمستخدمين تعديل مراكزهم أو إجراء تحويلات أو تسويات على السلسلة، وجميع الخدمات الخارجية المتصلة بهذه السلسلة يجب أن تنتظر إشارة الشبكة.
معايير تحديد استئناف التشغيل مبنية على السلامة، لكن التفاصيل المحددة محدودة. أفاد Ontology أنه يسعى لاستعادة الخدمة خلال 24 ساعة بمجرد اكتمال الإصلاح والترقية والاختبار والتحقق، لكنه لم يكشف عن من يحدد تحقيق الشروط أو ما هي عتبات التفعيل.
هذا يخلق عدم يقينًا على مستوى الحوكمة: يُذكر الإعلان الأطراف المشاركة في المراجعة، لكن الجهة التي تمتلك الصلاحية النهائية لاتخاذ قرار إعادة التشغيل لم تُحدد بوضوح. بالنسبة للمستخدمين، فإن المخاطر الحالية ناتجة عن انقطاع الخدمة، وليس عن خسارة مؤكدّة للأصول أو عكس السلسلة.
ICON: لماذا أصبح توقف البلوكشين متأخرًا جدًا
حدث ICON أظهر بالكامل عملية التنبيه والتعامل وتحرير الأصول من التحكم على السلسلة.
وفقًا لتقرير مراجعة ما بعد الحادث الذي أصدرته المؤسسة، قام المهاجم بإعادة تشغيل 1492 رسالة سحب موقعة صالحة سابقًا بين الساعة 02:01:02 و02:21:12 بتوقيت عالمي منسق في 27 أغسطس. وأدى عيب في الدقة إلى نجاح 1490 من هذه الاستدعاءات، ونقلت 119.866 مليون من ICX و531,600 من bnUSD من صندوق أصول المؤسسة.
02:08 أطلق نظام المراقبة إنذارًا، ثم قام الفنيون لاحقًا بالتحقيق؛ تم إيقاف العقد المتأثر في 03:53. بدأت البورصات الكبرى في إيقاف إيداع وسحب ICX تدريجيًا في 05:54، ودخل إيقاف التشغيل الشامل حيز التنفيذ رسميًا في 06:18:54. أُعيد تشغيل ICON حوالي 07:51 في 28 أغسطس، بعد فترة استمرت حوالي 25 ساعة، مع إصلاح الثغرات الأساسية.
تُشير تقرير المراجعة إلى أن جذر المشكلة يكمن في إجراءات الاستجابة للحوادث، وليس في نقص القدرة على الكشف. تم تفعيل التنبيهات خلال 7 دقائق، لكن هذه التنبيهات كانت غالبًا ما تُخلط مع استثناءات RPC غير ذات صلة، ولم يتم إخطار الفريق المكلف بالحراسة. ولم يبدأ التحقيق الفني حتى حوالي الساعة 03:40، وبعد فترة قصيرة تم إيقاف العقد.
عندما يتم إيقاف السلسلة رسميًا، كانت معظم ICX المتأثرة قد تم بالفعل دمجها في أنظمة التخزين الخاصة بالبورصات. لا يمكن للوسائل التي تمتلكها سلسلة ICON منع البورصات من نقل أو تحويل الأصول التي تمتلكها. لا يمكن لصندوق التمويل سوى الاعتماد على تجميد الأصول من قبل البورصات، وإشعارات الحفظ، والمحامين، ومؤسسات إنفاذ القانون للتعامل مع الأمر.
يحدد الحدود المُدارة مباشرة ملكية الخسائر. يشير ICON إلى أن جميع الأصول المتأثرة تعود إلى المؤسسة، ولم تُلمس إيداعات أو أرصدة أو مراكز المستخدمين العاديين. أظهر التقرير استرداد 531600 من bnUSD و1.366 مليون من SODA بالكامل؛ من بين 113634 من USDC المُقرضة، تم استرداد 82430. تم تحديد الخسارة الصافية بحوالي 150.2 من ETH، بالإضافة إلى 31204 من USDC. معظم ICX المعنية لم تُسترد فعليًا، بل تم تجميدها أو تتبعها فقط في البورصة.
تختلف هيكلية إدارة ICON عن الحالتين الأخريين. أشار تقرير المراجعة إلى أن الشبكة كانت تحت سيطرة المؤسسة أثناء نقل الرموز؛ وأشار مستند الإرشادات إلى أن توافق الآراء كان يعمل في وضع الصيانة، مع 7 عقد أساسية فقط. وبالتالي، فإن هذا التوقف اعتمد على هيكل تشغيلي خاص مُحدَّد تمامًا تحت سيطرة المؤسسة.
الصلاحيات الطارئة هي أيضًا صلاحيات على مستوى الميزانية العمومية
كل توقف في البلوكشين هو في جوهره نقل للمخاطر إلى مكان آخر.
- تعديل كرونوس للتاريخ الرسمي للسلسلة: يمكنه حماية الأصول التي لا تزال تحت نطاق سلسلة التحكم، لكنه يلغي الأنشطة الطبيعية على السلسلة خارج الثغرة، ولا يستطيع فعل شيء تجاه الأصول على إيثريوم.
- يُحوّل Ontology المخاطر إلى تكلفة زمنية وفقدان في توفر الخدمة، ولم يتم تسويق المعاملات أثناء فترة التحقيق، ولم يتم تأكيد خسارة أصول محاسبية.
- أكمل ICON فصل العقد عن الشبكة بعد نقل الأصول خارج نطاق التخزين المُدار على السلسلة؛ تأكيد أن الخسارة تتحملها المؤسسة، ويعتمد استرداد ICX المُجمدة على تبادل العملات الرقمية والسلطات القضائية.
سيؤدي التقييم اللامركزي البسيط إلى إخفاء هذه النتائج المتناقضة. المعيار الأكثر واقعية هو: هل يتم نشر قواعد التدخل الطارئ؟ ما هي عتبات تفعيل التدخل؟ هل يتم إيقاف كتل جديدة فقط، أم إعادة كتابة حالة السلسلة المؤكدة؟ من يتحكم في الأصول التي تخرج عن نطاق اختصاص السلسلة عند حدوث التدخل؟ من يتعهد بتحمل الخسائر المتبقية؟
لا يزال يتعين نشر تقرير مراجعة كامل لـ Cronos و Tectonic. يتطلب Ontology الكشف عن تفاصيل الهجوم وقواعد التفويض الطارئ، كما يجب التحقق لاحقًا مما إذا كانت شروط الترقية وإعادة التشغيل قد تحققت. ما يستحق المقارنة حقًا هو حدود المخاطر التي حددتها كل شبكة — أي السجلات والتوقيتات والأموال التي ستُعرض للمخاطرة.



