Starknet又宕机了：الطبقة التنفيذية وطبقة الإثبات تتصارعان، وتم التراجع عن النشاط الذي استمر لمدة 18 دقيقة

以Ethereum L2 الشبكة Starknet تعرضت لعطل رئيسي في الشبكة يوم الاثنين الماضي، ووفقًا لتقرير التحليل اللاحق الصادر في 11 يناير، فإن الحادث نجم عن عدم تطابق الحالة بين طبقة التنفيذ(blockifier) وطبقة الإثبات. في سيناريوهات معينة تتضمن استدعاءات عبر الوظائف وعمليات التراجع، قام طبقة التنفيذ بتسجيل حالة تم التراجع عنها بشكل خاطئ، مما أدى إلى حدوث استثناء في تنفيذ المعاملة. على الرغم من أن المعاملات المعنية لم تحصل على تأكيد نهائي من L1، إلا أن الحدث أدى إلى إعادة تنظيم الكتلة، حيث تم التراجع عن حوالي 18 دقيقة من النشاط على السلسلة. والأهم من ذلك، أن هذا هو ثاني حادث انقطاع كبير يحدث لـ Starknet منذ عام 2025.

التفاصيل التقنية: عدم التزامن بين طبقة التنفيذ وطبقة الإثبات

السبب الجذري للحادث

السبب التقني وراء هذا الانقطاع معقد نسبياً. بنية Starknet تتضمن مستويين رئيسيين: طبقة التنفيذ التي تتولى معالجة منطق المعاملات، وطبقة الإثبات التي تنتج إثباتات المعرفة الصفرية وتقدمها إلى شبكة Ethereum الرئيسية. في هذا الحادث، عند ظهور مجموعة معينة من استدعاءات الوظائف وعمليات التراجع، سجلت طبقة التنفيذ(blockifier) حالة كان من المفترض أن يتم التراجع عنها بشكل خاطئ، مما أدى إلى تعارض في الحالة بين المستويين.

الخبر السار هو أن طبقة الإثبات تمكنت من التعرف على الخطأ بشكل صحيح ورفضت المعاملة المشكوك فيها، ولم تدرجها في السجل. هذه الآلية “الذاتية التصحيح” ساعدت على منع ترسيخ الحالة الخاطئة على شبكة Ethereum الرئيسية.

لماذا يتطلب الأمر إعادة تنظيم

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

المقارنة التاريخية: تكرار المشكلات بشكل متزايد

على الرغم من أن مدة التراجع هذه المرة كانت أقصر (18 دقيقة مقابل ساعة)، إلا أن تكرار الحوادث بدأ يظهر بوضوح. من سبتمبر إلى يناير، شهدت Starknet حادثتين كبيرتين خلال أقل من ستة أشهر، مع اختلاف نوع العطل، مما يعكس وجود مخاطر محتملة على المستويين.

استجابة الفريق والتزامه

اتخاذ إجراءات فورية

أصدر فريق Starknet تقرير التحليل بعد الحادث، وقدم عدة وعود منها:

• تعزيز عمليات اختبار الكود، خاصة للظروف الحدية والسيناريوهات المعقدة
• تقوية آليات تدقيق الكود لمنع تكرار مشكلات عدم تطابق الحالة
• وفقًا للمعلومات، تخطط Starknet لإطلاق الإصدار v0.14.1 الذي يتضمن ترقية دوال التجزئة وتحسينات في سرعة إصدار الكتل

هذه التدابير تظهر أن الفريق ملتزم بتحسين استقرار النظام بشكل نشط، لكن مدى فاعليتها في منع حوادث مستقبلية لا يزال يتطلب وقتًا للتقييم.

تقييم التأثير على النظام البيئي

على مستوى المستخدمين

تأثير هذا الحادث كان محدودًا نسبيًا، لأن:

• مدة التراجع قصيرة (18 دقيقة)، وعدد المعاملات المتأثرة قليل
• المعاملات لم تحصل على تأكيد نهائي من L1، لذلك لم تُفقد أموال بشكل حقيقي
• المستخدمون بحاجة فقط لإعادة تقديم معاملاتهم، وليس فقدان أصولهم

على مستوى النظام البيئي

لكن من منظور أوسع، فإن تكرار الانقطاعات يهدد تطور نظام Starknet البيئي، حيث يؤدي إلى:

• تقليل ثقة المستخدمين في استقرار الشبكة
• قد يؤثر على رغبة تطبيقات DeFi في النشر على Starknet
• وضعها في موقف أضعف مقارنة بمشاريع L2 أخرى مثل Arbitrum وOptimism

ومن الجدير بالذكر أن Starknet تعمل حاليًا على توسيع تطبيقاتها، مثل التعاون مع Noon لإطلاق Bitcoin Vault، ومع مشاريع مثل AlchemyPay. مدى قدرة هذه المبادرات على تعويض التأثير السلبي لمشاكل الاستقرار هو ما سيتم مراقبته في المستقبل.

الخلاصة

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

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