#MultiversXPlansHardForkRecovery A تم دفع خلل الذرية على مستوى الـVM إلى شبكة MultiversX حتى توقّف كامل — الآن يتم اختبار عملية الـHard Fork باعتبارها مسار التعافي. • حددت MultiversX السبب الجذري بوصفه مشكلة ذرية على مستوى الـVM تتعلق بخطأ في ترتيب العمليات في حالة حافة محددة. • أوقفت جهات التحقق (Validators) تقدم الشبكة لاحتواء الحادث ومنع المزيد من التأثير. • أعدت المجموعة تغييرات على التعليمات البرمجية وتختبر إجراء التعافي. • يتمثل التعافي المخطط في Hard Fork منسق من نقطة تحقق (Checkpoint) معروفة سابقًا وموثوقة. • من المتوقع أن تُجري جهات التحقق تدريبًا مسبقًا على الإجراء عبر Testnet وDevnet قبل التعافي على mainnet. • أُبلغ المستخدمون بعدم إرسال أو إعادة بث المعاملات، والامتناع عن إيداعات/سحوبات EGLD/ESDT عبر منصات التداول والجسور (Bridges) حتى صدور الإذن الرسمي بانتهاء الأزمة. يبدو لي أن هذا هو المكان الذي تصبح فيه القصة أكثر إثارة للاهتمام. عملية الـHard Fork نفسها ليست الجزء الذي أراقبه عن كثب. الاختبار الحقيقي هو ما إذا كانت MultiversX قادرة على استعادة الشبكة بسلاسة مع الحفاظ على الحالة المشروعة وإزالة التغييرات غير الصالحة التي نتجت عن الاستغلال. هذا يبدو بسيطًا على الورق. لكنه ليس كذلك. التعافي من هذا النوع يجب أن يَنسق بين جهات التحقق والبورصات والجسور ومقدمي البنية التحتية والمستخدمين حول حالة السلسلة نفسها. يمكن أن يحوّل رابط ضعيف التعافي التقني إلى فوضى تشغيلية. لذلك لا يهمني كثيرًا عنوان «الـHard Fork قادم»، بقدر اهتمامي بما إذا كانت عملية التعافي تعمل فعليًا في ظل ظروف حقيقية ومنسقة. هذا يخبرني بالكثير أكثر عن مرونة الشبكة مقارنة بإعلان إعادة التشغيل نفسه. ما زلت أحاول معرفة ما الذي تغيّره هذه الأمور فعليًا.