فاتني نافذة مكافأة المشاركة في الاستحواذ المشترك (co-staking) الشهر الماضي بفارق ست ساعات. لم أكن حتى أعلم بوجودها حتى بعد أن كان الموعد النهائي قد انقضى—فقط لاحظت دفعة أصغر مما توقعت وبدأت بالبحث.

إليك ما وجدته: مزوّدو Finality Providers لدى Babylon لا يمكنهم تدوير مفاتيحهم. بمجرد أن يسجّل المزوّد مفتاح EOTS ومفتاح Genesis، تصبح الهوية ثابتة بشكل دائم—لا يمكن استبدال مفتاح تم اختراقه كما يحدث في معظم شبكات المُدقّقين. وهذا مرتبط مباشرةً بتصميم الإجراء الخاص بالـ slashing: إذا قام المزوّد بالتوقيع المزدوج (double-signs)، يمكن لآلية EOTS كشف بيانات المفتاح اللازمة لإسقاطه (slashing). إن ثبات الهوية هو ما يجعل هذا التهديد حقيقيًا.

كنت أظن أن تدوير المفاتيح مجرد ممارسة تشغيلية قياسية في كل مكان. لكن الأمر هنا عكس ذلك—فقد أزال البروتوكول هذا المرونة عمدًا حتى لا يمكن إعادة ضبط المساءلة بهدوء.

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

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

@BabylonLabs_io $BABY #baby $BULLA $ON
معظم المُدقّقين: يدوّرون المفاتيح عند اختراقها. Babylon FPs: عالقون بمفتاح واحد، إلى الأبد. أي نهج تثق به أكثر؟