وهذا هو سبب توقفي عن اعتبار «الأمان المدعوم بالبيتكوين» فئةً مفيدةً بذاتها.
عندما نظرتُ إلى بابيلون عن كثب، لم يكن الفارق هو أن BTC تظهر في مكان ما ضمن البنية. كان الفارق هو عيبٌ محددٌ واحد: قيام موفّر نهائية (Finality Provider) بالتوقيع على كتلتين مختلفتين عند الارتفاع نفسه، وهو ما يفتح مسارًا تشفيريًا من سلوكٍ سيّئ إلى الرهان/الحصة الأصلية من البيتكوين الكامنة خلفه.
يجعل تصميم EOTS لدى بابيلون الموفّر يلتزم بتوليد عشوائية عامة لكل ارتفاع كتلة مستقبلي. ويؤدي التوقيع المزدوج إلى إجبار تلك العشوائية على أن يُعاد استخدامها، ما يكشف مفتاح EOTS الخاص بالموفّر، ويزيل قدرته على التصويت، ويجعل معاملات الـ slashing عبر حصته المفوَّضة قابلة للتوقيع.
بالنسبة للباحث، يخلق ذلك نقطة مقارنة أكثر صرامة من مجرد سؤال ما إذا كان البروتوكول «يستخدم البيتكوين» أو يدّعي أنه يرث أمانه. أريد أن أعرف أي إجراءٍ محدد يجعل الرهن قابلًا للـ slash، وما إذا كانت العقوبة يمكن أن تصل إلى UTXO الأصلي للبيتكوين. لاختبار هذا، يضيق المجال بسرعة. يمكن إضافة إشارة إلى البيتكوين إلى مخطط بنيوي، لكن يجب أن يصمد مسارٌ كاملٌ من العيب إلى العقوبة أمام التشفير وإدارة المفاتيح والتفويض والتنفيذ.
فتموضع بابيلون يصبح أكثر منطقية على هذا المستوى الأضيق. ليس BTC تُستخدم كوسم أمان، بل BTC يتم الالتزام بها كضمان/رهن مع عواقب محددة عندما يكسر المُوقّع حالة النهائية.
@BabylonLabs_io $BABY
#baby
$BTC