في أول مرة قرأت فيها Babylon Bitcoin Staking Scripts من البداية للنهاية، لم تكن المشكلة في كيفية الدخول إلى عملية الإيداع، بل في طبقة Covenant Committee. بروتوكول يروّج لـ BTC الأصلي مع إدارة ذاتية، لماذا إذن نحتاج إلى إحضار لجنة مكوّنة من مجموعة لتوقّع؟ كانت أول ردة فعلي حينها: هل سيضيف هذا طبقة إضافية من تكلفة الثقة؟$BABY
ثم كلما نظرت أكثر، اتضح لي أكثر أن الأمر ليس بهدف الاستحواذ على BTC الخاصة بالمستخدمين. بل يشبه جسراً أقامه Babylon أولاً عندما لا تكفي تعبيرات سكربتات Bitcoin الحالية. ما زالت الـ BTC محبوسة داخل قواعد UTXO في Bitcoin وقواعد Taproot، لكن التفاصيل الدقيقة—حالة الإيداع، شروط الخروج، ومسارات المصادرة—لم تكن Script الأصلية قادرة على كتابتها كاملةً بنفسها، لذلك احتاجت إلى M-of-N multisig لتقييد مسار المعاملات وضمان أن الأموال لا يمكن أن تتدفق إلا بالطريقة التي يحددها البروتوكول.#baby
أكثر ما وجدته مثيرًا للاهتمام هو فصل التعامل بين الخروج والعقوبة (Slashing). أثناء عملية Unbonding العادية، يكون التركيز على تمكين المستخدم من استرجاع BTC، لذلك الأهم هو ما إذا كانت عتبات التوقيع وقفل الوقت والإجراءات تسير بشكل سليم؛ أما في Slashing فالقيود تكون أقسى، وتصبح اللجنة أقرب إلى مساعده لتنفيذ قواعد البروتوكول، وليس لتخزين أصول المستخدمين بالنيابة. لديها صلاحية المشاركة في العملية، لكن هذه الصلاحية تأتي من البروتوكول نفسه، وليست تفويضًا مطلقًا بالتصرف الحر في BTC.@BabylonLabs_io
لذلك، ما الذي يعالجه Babylon حقًا؟ ليس «نقل BTC إلى مكان آخر»، بل تمكين BTC من المشاركة في أمان PoS دون التغليف أو الوصاية. لكن التكلفة واقعية أيضًا: ستصبح البنية أكثر تعقيدًا. بالنسبة لي، ما يستحق المتابعة لاحقًا ليس مدى أهمية اللجنة الآن، بل ما إذا كانت قدرات Bitcoin الأصلية، إذا استمرت في التحسن، ستجعل هذه الطبقة تترقق تدريجيًا.$BTC $ETH