هناك سؤال سهل أن يُطرح: يمكن لـ$BTC تمريره عبر "Slashing"—لكن بيتكوين لا يوجد فيها مُصدِّقون بنظام PoS، والعمال (المعدّنون) لا يعرفون من الذي يجب معاقبته. فبابل (Babylon) على أي أساس تتحرك على BTC؟
كنت أظن أن Covenant Committee هو "القاضي"، لكن بعد تنظيم EOTS وBitcoin Staking Scripts، اتضح أنه أقرب إلى "الشاهد"—الجهة التي تضغط فعليًا زر العقوبة هي Finality Provider نفسه.
الجوهر يكمن في "الإفراج الشرطي عن صلاحية التوقيع". يستخدم Finality Provider EOTS لإنشاء التزام توقيع لمرة واحدة لكل ارتفاع. فإذا حدث توقيع مزدوج، فإن إعادة استخدام nonce (العدد العشوائي) ستكشف مفتاحه الخاص الكامل. هذا المفتاح الخاص هو بالضبط المفتاح الأخير المطلوب لفتح/فك معاملة Slashing المسبقة التوقيع. لقد تم تضمين كل المسارات في Taproot script خلال مرحلة التقييد (الـstaking)، وما ينقص هو هذا المفتاح—ويُحتفَظ به عادةً بواسطة Finality Provider، بينما لا تعترف بيتكوين بسلطة خارجية تستطيع إجبار الاستخدام. لا تظهر هذه "المفاتيح" على السلسلة بطريقة قابلة للتحقق إلا عندما تتكسر EOTS بسبب التوقيع المزدوج.$BABY
لذلك لم تُحاول Babylon جعل بيتكوين تفهم مخالفة PoS، بل حوّلت العواقب الرياضية للمخالفة إلى توقيع صالح تستطيع بيتكوين التعرف عليه. هذه هي نوع من "التخزين المُشروط للمفاتيح" للتوقيع.#baby
لكن المخاطر واقعية جدًا: أخطاء في العميل (client bug) أو تأخر الشبكة قد يسبب توقيعات مكررة، وقد يؤدي ذلك إلى كشف المفتاح الخاص حتى دون نية سيئة. كما أن معاملة Slashing مسبقة التوقيع تعتمد على UTXO محدد وحالة على السلسلة؛ فإن إعادة التنظيم العميقة أو تغيّر الرسوم بشكل كبير قد يؤدي إلى تعطل المعاملة.
@BabylonLabs_io الأكثر جدارة بالمتابعة ليس عدد العقد الخبيثة التي تم معاقبتها، بل ما إذا كان هذا التحويل من "أدلة تشفير" إلى "عقوبة على BTC" يمكن أن يعمل بثبات وموثوقية في التشغيل الفعلي.
ما رأيك؟
كنت أظن أن Covenant Committee هو "القاضي"، لكن بعد تنظيم EOTS وBitcoin Staking Scripts، اتضح أنه أقرب إلى "الشاهد"—الجهة التي تضغط فعليًا زر العقوبة هي Finality Provider نفسه.
الجوهر يكمن في "الإفراج الشرطي عن صلاحية التوقيع". يستخدم Finality Provider EOTS لإنشاء التزام توقيع لمرة واحدة لكل ارتفاع. فإذا حدث توقيع مزدوج، فإن إعادة استخدام nonce (العدد العشوائي) ستكشف مفتاحه الخاص الكامل. هذا المفتاح الخاص هو بالضبط المفتاح الأخير المطلوب لفتح/فك معاملة Slashing المسبقة التوقيع. لقد تم تضمين كل المسارات في Taproot script خلال مرحلة التقييد (الـstaking)، وما ينقص هو هذا المفتاح—ويُحتفَظ به عادةً بواسطة Finality Provider، بينما لا تعترف بيتكوين بسلطة خارجية تستطيع إجبار الاستخدام. لا تظهر هذه "المفاتيح" على السلسلة بطريقة قابلة للتحقق إلا عندما تتكسر EOTS بسبب التوقيع المزدوج.$BABY
لذلك لم تُحاول Babylon جعل بيتكوين تفهم مخالفة PoS، بل حوّلت العواقب الرياضية للمخالفة إلى توقيع صالح تستطيع بيتكوين التعرف عليه. هذه هي نوع من "التخزين المُشروط للمفاتيح" للتوقيع.#baby
لكن المخاطر واقعية جدًا: أخطاء في العميل (client bug) أو تأخر الشبكة قد يسبب توقيعات مكررة، وقد يؤدي ذلك إلى كشف المفتاح الخاص حتى دون نية سيئة. كما أن معاملة Slashing مسبقة التوقيع تعتمد على UTXO محدد وحالة على السلسلة؛ فإن إعادة التنظيم العميقة أو تغيّر الرسوم بشكل كبير قد يؤدي إلى تعطل المعاملة.
@BabylonLabs_io الأكثر جدارة بالمتابعة ليس عدد العقد الخبيثة التي تم معاقبتها، بل ما إذا كان هذا التحويل من "أدلة تشفير" إلى "عقوبة على BTC" يمكن أن يعمل بثبات وموثوقية في التشغيل الفعلي.
ما رأيك؟