ثلاثة شبكات بلوكشين توقف عملياتها وسط حوادث أمنية

كتابة: Liam 'Akiba' Wright

ترجمة: Saoirse، Foresight News

في غضون أربعة أيام، توقفت ثلاث شبكات سلسلة كتل على التوالي عن إنتاج الكتل. وقد استُخدمت صلاحيات طارئة مختلفة تمامًا في كل تعطيل للشبكة، حيث لم تُعدّل سوى كرونوس جزءًا من تاريخ السلسلة الرسمي.

أفاد كرونوس أن عقدات التحقق أوقفت الشبكة عبر آلية الإجماع بعد تعرض بروتوكول تيكتونيك لهجوم ثغرة، وأعادت السلسلة إلى حالتها قبل الهجوم، ثم أعادت بدء إنشاء الكتل من ارتفاع الكتلة 90,896,189. لم يُوقف هذا الإجراء إنشاء الكتل فحسب، بل قام أيضًا بكتابة حالة السلسلة مباشرةً. جميع المعاملات وتغييرات الحالة التي تم إنشاؤها بعد نقطة الاستعادة لم تعد جزءًا من السلسلة الرئيسية الرسمية بعد إعادة التشغيل.

استخدمت Ontology و ICON مجموعة أخرى من إجراءات الطوارئ. فقد أوقفت Ontology إنتاج الكتل قبل التأكد من سلوك الهجوم الخبيث، وأفادت ملاحظات التحديث الخاصة بها في 1 سبتمبر أن هذا النشاط الخبيث لم يتسبب في خسارة أصول المستخدمين. أما ICON، فأوقفت أولاً العقد المهاجم، ثم أوقفت الشبكة بالكامل؛ وقالت المؤسسة إن الشبكة كانت في مرحلة الهجرة وكانت تحت سيطرتها، وفي ذلك الوقت تم نقل معظم ICX المسروقة إلى حسابات التخزين في البورصات.

تعطيل البلوكشين هو مجرد وسيلة تحكم من الطبقة الأولى. المشكلة الأعمق هي: من يملك الصلاحية لطلب إيقاف الشبكة؟ هل يمكنهم إعادة كتابة حالة السلسلة المؤكدة؟ عندما تنتقل الأموال عبر السلاسل أو تدخل إلى جهات وساطة مركزية، ما هي الخسائر التي لا يمكن تعويضها؟

تم استعادة صلاحيات الإفصاح عن إجراءات الطوارئ لحدث التحفيز الشبكي؛ تم التحقق من توافق المُحققين على استعادة الحالة السلسلية إلى ما قبل الهجوم على ثغرة CronosTectonic؛ جميع الأنشطة السلسلية بعد نقطة التحقق الخاصة ببيانات العد والعتبة التصويتية التي لم تُكشف عنها تم إلغاؤها؛ الأموال المحولة إلى إيثريوم خارجة عن نطاق تحكم Cronos؛ لم يكتمل بعد تجميع الإحصائيات النهائية للخسائر الناتجة عن بروتوكول Tectonic؛ خلال الفحص اليومي لـ Ontology، تم اكتشاف مخاطر محتملة، وتم تأكيد وجود أنشطة خبيثة لاحقًا، مما أدى إلى إيقاف إنتاج الكتل احترازيًا دون تنفيذ عملية التراجع؛ شارك فريق التطوير الأساسي وفريق التقنية وعقد المُحققين؛ لم تُكشف عن عتبات التحفيز للتعامل الطارئ؛ خلال إصلاحات وترقيات الشبكة، كانت المعاملات غير قابلة للتنفيذ؛ لم يتم اكتشاف أي ضرر على أصول المستخدمين؛ عقد نقل ICON يحتوي على ثغرة إعادة التشغيل، لذا تم إيقاف العقد أولًا، ثم إيقاف الشبكة بالكامل للانتقال، حيث تولت المؤسسة السيطرة على الشبكة خلال مرحلة الانتقال، وتم تقليل عدد عقد المُحققين الأساسية، وتحمل المؤسسة الخسائر؛能否 استرداد ICX المخزنة في البورصات يعتمد على الجهة المُودِعة، والإجراءات القانونية، وسلطات إنفاذ القانون

مقارنة طرق التصرف الطارئ لسلاسل Cronos و Ontology و ICON

وصف كرونيس الحدث بأنه "إجراء طارئ للإجماع من قبل المُحققين". أظهر إعلان إعادة التشغيل في 31 أغسطس أن الشبكة استؤنفت لإنتاج الكتل في 30 أغسطس، الساعة 23:49:01 بتوقيت عالمي منسق، مع عودة حالة السلسلة إلى ما قبل هجوم ثغرة تيكتونيك عند ارتفاع الكتلة 90,896,189.

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

لا يزال حجم الأصول التي حمتها هذه التدخلات فعليًا غير مؤكد. تقدر TRM Labs أن حوالي 75 مليون دولار من الأصول تم إقراضها بعد تلاعب في سعر رمز TONIC؛ حيث ذهب حوالي 6 ملايين دولار إلى إيثريوم، وتم تنفيذ إعادة التوجيه داخل سلسلة Cronos بقيمة حوالي 68.7 مليون دولار. بينما تقدم إحصائيات Bitquery حجمًا أعلى لإجمالي التدفقات الخارجة، حيث ذهب حوالي 8.3 مليون دولار من الأصول إلى إيثريوم، وتم التخلي عن ما مجموعه 10961 كتلة.

الإحصائيتان تقيسان كيانات مختلفة، ولا تزال بيانات الخسارة النهائية من Tectonic قيد الإعلان. لكن نقطة واحدة أصبحت واضحة جدًا: لا يمكن لعملية التراجع في Cronos استعادة الحالة إلا إذا ظلت داخل السلسلة نفسها، بينما الأصول على سلسلة إيثريوم غير خاضعة لأي تحكم منها.

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

تختلف خطوات استعادة البنية التحتية المختلفة عن إعادة تشغيل توافق السلسلة. يذكّر Cronos أن البروتوكولات المختلفة، وجسور العبور بين السلاسل، ومتصفحات الكتل، وخدمات RPC تحتاج إلى وقت أطول للتعافي. كما سجّلت صفحة حالة Alchemy بشكل منفصل هذه فترة التوقف ثم عملية الاستعادة اللاحقة. يمكن الإعلان عن إعادة تشغيل شبكة السلسلة رسميًا، لكن الخدمات المعتمدة عليها قد لا تكون جاهزة بعد.

حدث إجراء التخلص من Ontology قبل تأكيد النشاط الضار. أفادت الشبكة أن فريق التطوير الأساسي اكتشف ثغرات أمنية محتملة أثناء الفحوصات اليومية، فوقف فورًا إنتاج الكتل وسلّم الأمر لفريق التقنية وعقدات التحقق لإجراء مراجعة للنظام.

أُعلن في تحديث بتاريخ 1 سبتمبر أن المراجعة أكدت وجود هجوم خبيث، وسيظل الشبكة الرئيسية متوقفة لإجراء إصلاحات الثغرات وترقية الشبكة؛ ولم يتأثر أصول المستخدمين بهذا الهجوم. يهدف Ontology إلى استعادة التشغيل الطبيعي خلال 24 ساعة، بشرط إكمال فحوصات الأمان وإصلاح الثغرات والترقية والاختبار بنجاح.

يحتفظ توقف تشغيل Ontology بجميع الحالات على السلسلة التي تم تأكيدها، ويتوقف فقط عن تأكيد وتسوية المعاملات الجديدة. لم يحدد الإعلان نقطة الاستعادة، ولم يُعلن عن مجموعة المعاملات التي تحتاج إلى إلغائها.

معلومات الصلاحيات المُعلنة علنيًا غير كاملة. ذكر الإعلان مشاركة فريق التطوير الأساسي وفريق التقنية وعقد التحقق في الشبكة في المعالجة، لكنه لم يحدد من هو صاحب القرار النهائي الملزم، ولم يُقدّم عتبة طوارئ رقمية. وصف وثيقة VBFT الخاصة بـ Ontology آلية التوافق العادية، بما في ذلك توليد العقد للكتل المؤكدة وإدارة مجموعة عقد التوافق لتحديث العقود، لكن الوثيقة تغطي فقط سيناريوهات التشغيل العادية، ولم تُنشر قواعد الإيقاف الطارئ المستخدمة في 31 أغسطس علنًا.

حتى لو لم يُسبب التوقف خسارة في الأصول، فإنه لا يزال يترتب عليه تكاليف فعلية. أبلغت Ontology المستخدمين أن المعاملات على السلسلة لن تُعالج، ونصحت بعدم تنفيذ العمليات الحساسة للوقت؛ ثم أوضحت لاحقًا أن إعادة تشغيل الشبكة تعتمد على إصلاح الثغرة والترقية والاختبار. لا يمكن للمستخدمين تعديل مراكزهم أو إجراء تحويلات أو تسويات على السلسلة، ويجب على جميع الخدمات الخارجية المتصلة بهذه السلسلة الانتظار حتى استعادة إشارة الشبكة.

معايير إعادة التشغيل مبنية على السلامة، لكن التفاصيل المحددة محدودة. أفادت Ontology أنه ستسعى لإعادة الخدمة خلال 24 ساعة بمجرد إتمام الإصلاح والترقية والاختبار والتحقق، لكنها لم تكشف عن من يحدد إتمام الشروط أو ما هي عتبات التشغيل.

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

حدث 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 إلى أن جميع الأصول المتأثرة تعود إلى المؤسسة، ولم تُلمس إيداعات أو أرصدة أو مراكز المستخدمين العاديين. أظهر التقرير استرداد 531,600 وحدة من bnUSD و1.366 مليون وحدة من SODA بالكامل؛ من بين 113,634 وحدة من USDC التي تم إقراضها، تم استرداد 82,430 وحدة. تبلغ الخسارة الصافية المؤكدة حوالي 150.2 وحدة من ETH، بالإضافة إلى 31,204 وحدة من USDC. معظم ICX المعنية لم تُسترد فعليًا، بل تم تجميدها أو تتبعها فقط في البورصة.

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

كل تعطيل للسلسلة البلوكية هو في جوهره نقل للمخاطر إلى مكان آخر.

• تعديل كرونوس للتاريخ الرسمي للسلسلة: يمكنه حماية الأصول التي لا تزال تحت نطاق السلسلة، لكنه يلغي أيضًا الأنشطة الطبيعية على السلسلة خارج الثغرة، ولا يستطيع فعل شيء تجاه الأصول على إيثريوم.
• تحويل Ontology للمخاطر إلى تكلفة زمنية وفقدان في توفر الخدمة، حيث لم يتم تسويات المعاملات أثناء التحقيق، ولم يتم التأكيد على خسارة أصول محاسبية.
• أكمل ICON فصل العقد عن الشبكة بعد نقل الأصول خارج نطاق التخزين المُدار على السلسلة؛ تأكيد أن الخسارة تتحملها المؤسسة، ويعتمد استرداد ICX المُجمدة على تعاون البورصات والسلطات القضائية.

إن التقييم اللامركزي البسيط سيُخفي هذه النتائج المتناقضة تمامًا. المعيار الأكثر واقعية هو: هل قواعد التدخل الطارئ معلنة؟ ما هي عتبات تفعيل التدخل؟ هل يتم فقط وقف كتل جديدة، أم إعادة كتابة حالة السلسلة المُؤكدة؟ من يتحكم في الأصول التي تخرج عن نطاق اختصاص السلسلة عند حدوث التدخل؟ من يتعهد بتحمل الخسائر المتبقية؟

لا تزال تقارير المراجعة الكاملة لـ Cronos و Tectonic قيد الإصدار. يتعين على Ontology الكشف عن تفاصيل الهجوم وقواعد التفويض الطارئ، كما يجب التحقق لاحقًا مما إذا كانت شروط التقييم للترقية وإعادة التشغيل قد تحققت. ما يستحق المقارنة حقًا هو حدود المخاطر التي حددتها كل شبكة — أي السجلات والتوقيتات والأموال التي تم تعريضها للمخاطر.