اليوم أطلعتُ على نطاق مكافآت الثغرات الذي حدّثته Babylon في 27 يوليو، فزاد ذلك قلقي بدل أن يهدّئه.
أعلى مكافأة 500 ألف دولار، و16 أصلًا ضمن النطاق؛ يبدو للوهلة الأولى أن الاستثمار في الأمان ليس قليلًا. لكن عند التعمّق أكثر، تُستبعد بشكل واضح فئات المخاطر التي قد تكون فعلًا قادرة على سحب النظام إلى حادث كبير: المخاطر المركزية، وتعطّل المرحلات مؤقتًا بين Bitcoin وBabylon، وأكثر من ثلث مزوّدي Finality Provider الخبيثين، ووصول لجنة Covenant إلى أغلبية خبيثة أو عدم القدرة على جمع التواقيعات، وإعدادات منخفضة جدًا لمعلمات مثل عمق التحقق.
ومن اللافت أيضًا أن قواعد المكافآت تمنع اختبار الآوراكل (Preoracles) والعقود الذكية التابعة لجهات خارجية.
هذا يتعارض بوضوح مع الاتجاه الذي دفعه مؤخرًا @BabylonLabs_io . لقد أعلنت Babylon أنها ستقوم بربط Trustless Bitcoin Vaults بـ Aave V4 وAegis، مع خطط لإطلاق إقراض بسعر فائدة ثابت أصلي مدعوم بـ BTC في الربع الرابع.
سيتحوّل تسلسل المنتج إلى: Babylon يدير البنية التحتية لتخزين/تأمين BTC، وAave يدير سوق الإقراض، وAegis يدير منتج الفائدة الثابتة، وقد يتطلب الأمر من الخارج توصيل محفظة (Wallet)، وواجهة أمامية (Frontend)، وأوراكل، وآليات تسوية (Clearing).
ما يراه المستخدم هو: “BTC أصلي، إدارة ذاتية، دون الحاجة لجسر (Cross-Bridge)”. أما ما يراه المهاجم فهو: نقاط التقاء/تداخل مسؤوليات بين عدة أنظمة.
مشكلات الأمان التي أفصحت عنها OpenZeppelin هذا العام بشأن Babylon تتركّز تحديدًا في هذا النوع من الوصلات: بقاء حق التصويت مع الرهن المنتهي، وتجاوز مزوّدي Finality Provider للحبس، وشذوذ سجلات Co-Staking مما يؤدي إلى تجميد الأموال، بل وحتى التسبب في انهيار المدقق (Validator). قامت الجهة الرسمية فعلًا بالإصلاح بسرعة، لكن هذا يؤكد أكثر أن هذه ليست مجرد مخاطر نظرية.
أنا لا أشكك في كون Babylon قامت بمراجعات تدقيقية (Audit). بل أشك في: عندما تتراكم المسؤولية ويستمر العمل في إضافة مكونات طرف ثالث، من الذي يتحمل مسؤولية الحوادث التي تقع “بين المكونات”؟
لا يمكن للأمان أن يقتصر على النظر إلى ما إذا كان هناك ثغرات في مستودع واحد. في الواقع، عندما تقع كارثة، غالبًا يستطيع كل طرف أن يثبت أن كوده سليـم، وفي النهاية لا يستطيع أحد ضمان أن أموال المستخدمين ستكون آمنة.
#baby $BABY @BabylonLabs_io
أعلى مكافأة 500 ألف دولار، و16 أصلًا ضمن النطاق؛ يبدو للوهلة الأولى أن الاستثمار في الأمان ليس قليلًا. لكن عند التعمّق أكثر، تُستبعد بشكل واضح فئات المخاطر التي قد تكون فعلًا قادرة على سحب النظام إلى حادث كبير: المخاطر المركزية، وتعطّل المرحلات مؤقتًا بين Bitcoin وBabylon، وأكثر من ثلث مزوّدي Finality Provider الخبيثين، ووصول لجنة Covenant إلى أغلبية خبيثة أو عدم القدرة على جمع التواقيعات، وإعدادات منخفضة جدًا لمعلمات مثل عمق التحقق.
ومن اللافت أيضًا أن قواعد المكافآت تمنع اختبار الآوراكل (Preoracles) والعقود الذكية التابعة لجهات خارجية.
هذا يتعارض بوضوح مع الاتجاه الذي دفعه مؤخرًا @BabylonLabs_io . لقد أعلنت Babylon أنها ستقوم بربط Trustless Bitcoin Vaults بـ Aave V4 وAegis، مع خطط لإطلاق إقراض بسعر فائدة ثابت أصلي مدعوم بـ BTC في الربع الرابع.
سيتحوّل تسلسل المنتج إلى: Babylon يدير البنية التحتية لتخزين/تأمين BTC، وAave يدير سوق الإقراض، وAegis يدير منتج الفائدة الثابتة، وقد يتطلب الأمر من الخارج توصيل محفظة (Wallet)، وواجهة أمامية (Frontend)، وأوراكل، وآليات تسوية (Clearing).
ما يراه المستخدم هو: “BTC أصلي، إدارة ذاتية، دون الحاجة لجسر (Cross-Bridge)”. أما ما يراه المهاجم فهو: نقاط التقاء/تداخل مسؤوليات بين عدة أنظمة.
مشكلات الأمان التي أفصحت عنها OpenZeppelin هذا العام بشأن Babylon تتركّز تحديدًا في هذا النوع من الوصلات: بقاء حق التصويت مع الرهن المنتهي، وتجاوز مزوّدي Finality Provider للحبس، وشذوذ سجلات Co-Staking مما يؤدي إلى تجميد الأموال، بل وحتى التسبب في انهيار المدقق (Validator). قامت الجهة الرسمية فعلًا بالإصلاح بسرعة، لكن هذا يؤكد أكثر أن هذه ليست مجرد مخاطر نظرية.
أنا لا أشكك في كون Babylon قامت بمراجعات تدقيقية (Audit). بل أشك في: عندما تتراكم المسؤولية ويستمر العمل في إضافة مكونات طرف ثالث، من الذي يتحمل مسؤولية الحوادث التي تقع “بين المكونات”؟
لا يمكن للأمان أن يقتصر على النظر إلى ما إذا كان هناك ثغرات في مستودع واحد. في الواقع، عندما تقع كارثة، غالبًا يستطيع كل طرف أن يثبت أن كوده سليـم، وفي النهاية لا يستطيع أحد ضمان أن أموال المستخدمين ستكون آمنة.
#baby $BABY @BabylonLabs_io
