تفاصيل تحقيق ما بعد الوفاة في Starknet: خطأ في التنفيذ وراء انقطاع الشبكة الرئيسية المؤقت
- تسبب خلل في حالة Blockifier في حدوث عدم تطابق مع طبقة الإثبات، مما أدى إلى توقف واسترجاع النشاط الأخير على Starknet.
- توقفت أنظمة الأمان عن التنفيذ الخاطئ قبل انتهاء صلاحية Ethereum، على الرغم من أن المستخدمين لا زالوا يواجهون توقف الخدمة وإلغاء المعاملات.
- تمت استعادة حوالي 18 دقيقة من نشاط الشبكة، مما اضطر المستخدمين لإعادة تقديم المعاملات بعد استئناف الخدمة.
- تخطط Starknet لإجراء اختبارات أقوى وكشف أسرع مع استمرار مواجهة أنظمة الطبقة-2 المعقدة لمخاطر الاعتمادية.
أصدرت Starknet تقرير ما بعد الحادث يوضح سبب انقطاع الشبكة الرئيسي القصير يوم الاثنين. أدى الحادث إلى توقف مؤقت للشبكة واسترجاع الكتل الأخيرة.
ومع ذلك، لم يؤثر ذلك على التسوية النهائية على Ethereum. وفقًا للفريق، عملت أنظمة الأمان المدمجة كما هو مخطط لها، على الرغم من أن المستخدمين واجهوا توقف الخدمة وإلغاء المعاملات.
استُنتج توقف Starknet إلى خلل في معالجة حالة Blockifier
كما ورد في التقرير، نشأ الانقطاع من عدم تطابق في حالة الشبكة بين طبقة التنفيذ في Starknet، المعروفة باسم الـ blockifier، وطبقة الإثبات. الـ blockifier مسؤول عن تنفيذ المعاملات. في حين أن طبقة الإثبات تتحقق من صحة تلك العمليات قبل أن يتم تثبيتها على Ethereum.
تسبب خطأ برمجي داخل الـ blockifier في نتيجة معاملة غير صحيحة تحت ظروف محددة جدًا. شملت هذه الظروف استدعاءات عبر الوظائف، تغييرات الحالة، إرجاع المعاملات، والمنطق الذي يلتقط تلك الإرجاعات.
في تلك الحالة الحافة، أخطأ الـ blockifier في الاحتفاظ بتغيير الحالة الذي كان من المفترض أن يُلغى بعد أن يرجع وظيفة ما. ونتيجة لذلك، اختلفت نتيجة المعاملة عما كانت تتوقعه طبقة الإثبات.
نظرًا لعدم الاتساق، لم تصل التنفيذات الخاطئة إلى صلاحية Ethereum. بدلاً من ذلك، توقفت الشبكة واسترجعت النشاط الأخير لاستعادة حالة متسقة. قال فريق Starknet إن هذا السلوك يعكس مبدأ تصميم أساسي يركز على الحفاظ على الصحة حتى عندما يتصرف برنامج التنفيذ بشكل غير متوقع.
تبع الحادث إعادة تنظيم للكتل، قضت على حوالي 18 دقيقة من نشاط الشبكة. خلال ذلك الوقت، تم إرجاع المعاملات المؤكدة واضطر المستخدمون لإعادة تقديمها بمجرد عودة الشبكة إلى الوضع الطبيعي. وأكدت Starknet أن الوظائف الكاملة قد استُعيدت منذ ذلك الحين.
تكرار الانقطاعات يسلط الضوء على تعقيد شبكة الطبقة-2
في عام 2025، شهد مستخدمو Starknet انقطاعًا أكثر إزعاجًا من حادثة الاثنين. في سبتمبر، أدت ترقية رئيسية للبروتوكول تسمى Grinta إلى خلل في الـ sequencer تسبب في توقف الشبكة لأكثر من خمس ساعات.
مصدر الصورة: Starknet
خلال تلك الفترة، لم تكن المعاملات قابلة للمعالجة، مما اضطر المستخدمين إلى الانتظار أو إعادة تقديم النشاط. تطلب الأمر تنظيمين للكتل لاستعادة التشغيل الطبيعي، وتم استرجاع حوالي ساعة من نشاط الشبكة.
كما اضطر المستخدمون المتأثرون بذلك الحدث إلى إعادة تقديم المعاملات، مما خلق احتكاكًا للمشاركين النشطين في السوق. وتشير هذه الحوادث إلى التحديات المستمرة التي تواجهها شبكات الطبقة-2 المتقدمة.
تعمل Starknet على عدة أنظمة مترابطة، بما في ذلك محركات التنفيذ، وطبقات الإثبات بصفر معرفة، و الـ sequencers، والتسوية على Ethereum. كل طبقة تعزز الأمان أو القابلية للتوسع، لكنها تزيد أيضًا من التعقيد.
مع تفاعل المزيد من الطبقات، يمكن أن تظهر أخطاء برمجية نادرة بطرق غير متوقعة، حتى عندما تظل آليات الأمان الأساسية سليمة.
تسلط حادثة Starknet الضوء على تكاليف المستخدم الناتجة عن استرجاعات الطبقة-2
توضح آخر انقطاع كيف يمكن لأخطاء التنفيذ الصغيرة أن تتسبب في تعطيلات مرئية، حتى عندما تعمل أنظمة الأمان بشكل صحيح. كانت طبقة الإثبات في Starknet بمثابة حماية، حيث التقطت عدم الاتساق قبل التسوية النهائية. ومع ذلك، فإن تلك الحماية لا تلغي تكلفة توقف الخدمة وإعادة التنظيم التي يواجهها المستخدمون.
يمكن لأخطاء التنفيذ الصغيرة أن تتسبب في تعطيلات ملحوظة في الشبكة، حتى عندما تعمل أنظمة الأمان المدمجة كما هو مخطط لها. في حالة Starknet، اكتشفت طبقة الإثبات المعاملة الخاطئة قبل أن تصل إلى التسوية النهائية على Ethereum، مما يمنع الضرر الدائم للشبكة.
حتى مع حماية أموال المستخدمين، لا تزال توقف الخدمة وإعادة التنظيمات تعطل النشاط الطبيعي. وكان المتداولون والتطبيقات التي تعتمد على تنفيذ المعاملات بسرعة وتوقعها الأكثر تأثرًا، حيث أجبرهم استرجاع الكتل على إعادة إرسال المعاملات وإدارة التأخيرات غير المتوقعة.
تشدد Starknet على اختبار نظام الـ Blockifier ونظام الإثبات
تُجرى مراجعات هندسية مستمرة في Starknet بعد الانقطاع الأخير للشبكة، مع التركيز بشكل خاص على تقليل مخاطر حوادث مماثلة. يتم إدخال مجموعات اختبار fuzz-testing جديدة لمقارنة نتائج تنفيذ الـ blockifier مباشرة مع نظام الإثبات.
كما يتم إجراء تدقيق داخلي على منطق الإرجاع في الـ blockifier لتحديد سيناريوهات أخرى قد تؤدي إلى معالجة حالة غير صحيحة. بالإضافة إلى ذلك، يخطط الفريق لتقصير الوقت بين تنفيذ المعاملة وتنفيذها بشكل متوافق مع الـ prover.
سيسمح المقارنة الأسرع بالكشف عن عدم التطابقات في وقت أقرب، مما يحد من كمية النشاط الشبكي التي قد تحتاج إلى استرجاع.
وصفت Starknet الحادث بأنه دليل على أن نموذج الأمان الخاص بها يعمل كما هو مصمم، حيث لم تصل التنفيذات الخاطئة إلى صلاحية Ethereum. وفي الوقت نفسه، أقر الفريق بأن تحسين الاستقرار يظل أولوية مع استمرار تطور تقنية الطبقة-2.