مراجعة سلسلة "نشأة بابل" من شركة زليك، المنشورة في 26 مارس 2025، توثّق 32 ملاحظة عبر خمسة مستشارين خلال عشرة أسابيع. وبلغت سبع ملاحظات مستوى حرجًا. وقد تم إصلاح جميعها أو الاعتراف بها من قِبل شركة Babylon Labs.

توجد ملاحظتان من هذه الملاحظات بجوار بعضهما في التقرير وتصفان فجوة واحدة كامنة من زوايا مختلفة.

من المفترض أن يفقد مزوّد الإنهاء (finality provider) قوته التصويتية فورًا عند تعرضه للـ slashing. لكن الكود تحقّق من حالة الـ slash في مسار تنفيذ واحد وتجاهلها في مسار آخر. إذا تم slashing لمزوّد بينما كانت هناك تفويضات BTC لا تزال معلّقة له، فقد تتم لاحقًا معالجة ذلك التفويض دون إعادة التحقق من الـ slash — ما يعيد المزوّد إلى مجموعة التصويت النشطة.

هذه ليست فرضية تخيّلها شخص ما بعد وقوع الحادث. بل هي مسار كود موثّق، مع ذكر الوظائف المحددة بالاسم في التقرير، وإصلاح قامت Babylon Labs بالفعل بشحنه عبر عمليتي تنفيذ (commit) اثنتين.

يجدر بنا التوقف عند سبب حدوث ذلك أصلًا. يعتمد التصميم الأساسي لبابل على تشغيل دورتين منفصلتين للحياة بالتوازي — حالة الـ slash الخاصة بالمزوّد من جهة، ومسار اعتماد التفويض من جهة أخرى. وفي معظم الأوقات تبقى هاتان الحالتان متزامنتين. وهذه الملاحظة توضّح ما يحدث في النافذة الضيقة التي لا تتزامن فيها.

تشبيه معقول: يتم تعطيل بطاقة موظف بسبب انتهاك أمني، لكن طلبًا منفصلًا لمنحه صلاحية الدخول إلى المباني — تم تقديمه قبل التعطيل — يكتمل بعد ذلك ويعيد تفعيل البطاقة، لأن النظامين لا يتحققان من بعضهما البعض في الزمن الفعلي.

ما أعود للتفكير فيه هو أن نظامًا مبنيًا على حالتين تم التحقق منهما بشكل مستقل — الـ slashing من جهة بيتكوين وقوة التصويت من جهة السلسلة — لا يكون قويًا إلا بقدر قوة الكود الذي يحافظ على الاتساق بينهما ضمن توقيتات الحالات الحدّية. لا يزول هذا تحدي التنسيق بالكامل لمجرد أن هذه الحالة المحددة تم تصحيحها.#baby $BABY
@BabylonLabs_io #crypto #Binance