قراءة المواصفة التقنية لـ @BabylonLabs_io ، تستخدم سكربت الإيداع في بيتكوين الأمر OP_CHECKMULTISIGVERIFY لفرض شرط توافر النصاب المطلوب من المُصدّقين. لكن إليك الدقّة: السكربت نفسه لا يشفّر حالات الإيقاف/الخصم (slashing)—فهو يتحقق فقط من أن العدد المطلوب من المُصدّقين قد قام بالتوقيع.
وهذا يعني أن قفل بيتكوين من الناحية البنيوية بسيط: إما أن يقوم المستخدم بالسحب بعد فك الارتباط، hmm.. أو أن يقوم مجموعة المُصدّقين بالتوقيع لإجراء عملية الخصم. منطق الخصم الفعلي—ما الذي يُعدّ سلوكًا مخالفًا، كم سيتم خصمه، أي المُصدّقين يوقّعون—كل ذلك موجود بالكامل خارج السلسلة (على مستوى off-chain)، ويتم فرضه بواسطة سلسلة Babylon Genesis، وليس بواسطة سكربت بيتكوين.
إذًا طبقة بيتكوين توفر حسمًا نهائيًا تشفيريًا للقفل، لكن شروط ذلك القفل يحددها حالة سلسلة Babylon. إذا قالت سلسلة Babylon: "المُصدّق X أساء السلوك، فليتم خصم مفوّضيهم/مُفوّضي التفويض (delegators)"، يقوم نصاب المُصدّقين بتوقيع معاملة الخصم، وتنفيذها يتم بواسطة بيتكوين. لكن بيتكوين لا يملك أي طريقة للتحقق بشكل مستقل من أن الخصم كان مبررًا.
وهذا يقلب نموذج الثقة: يضمن بيتكوين أنه لا يمكن إنفاق UTXO دون توقيع النصاب، hmm.. لكنه لا يضمن أن النصاب يستخدم ذلك التوقيع بأمانة. انتقلت الموثوقية من إثبات العمل في بيتكوين إلى إجماع مُصدّقي Babylon. الجزء "الأصلي" حقيقي، لكن الجزء "غير قائم على الثقة" يعتمد على نفس الافتراضات التي لدى أي سلسلة PoS: أن مجموعة المُصدّقين صادقة ومتوافقة اقتصاديًا.
وبالمقارنة مع جسر يعتمد على Ethereum فقط، تقلل Babylon مساحة السطح للهجمات—لا توجد توكينات مُغلّفة، ولا يوجد خطر الإنشاء (minting)—لكنها لا تلغي الاعتماد على المُصدّقين. سكربت القفل مجرد أداة؛ سلسلة Babylon هي القاضي.
إذا أصبحت مجموعة المُصدّقين مُخترَقة، فهل يقدم سكربت بيتكوين أي دفاع بخلاف قفل لا يملكه المهاجمون سوى التحكم بالمفتاح بالفعل؟
#baby $BABY
وهذا يعني أن قفل بيتكوين من الناحية البنيوية بسيط: إما أن يقوم المستخدم بالسحب بعد فك الارتباط، hmm.. أو أن يقوم مجموعة المُصدّقين بالتوقيع لإجراء عملية الخصم. منطق الخصم الفعلي—ما الذي يُعدّ سلوكًا مخالفًا، كم سيتم خصمه، أي المُصدّقين يوقّعون—كل ذلك موجود بالكامل خارج السلسلة (على مستوى off-chain)، ويتم فرضه بواسطة سلسلة Babylon Genesis، وليس بواسطة سكربت بيتكوين.
إذًا طبقة بيتكوين توفر حسمًا نهائيًا تشفيريًا للقفل، لكن شروط ذلك القفل يحددها حالة سلسلة Babylon. إذا قالت سلسلة Babylon: "المُصدّق X أساء السلوك، فليتم خصم مفوّضيهم/مُفوّضي التفويض (delegators)"، يقوم نصاب المُصدّقين بتوقيع معاملة الخصم، وتنفيذها يتم بواسطة بيتكوين. لكن بيتكوين لا يملك أي طريقة للتحقق بشكل مستقل من أن الخصم كان مبررًا.
وهذا يقلب نموذج الثقة: يضمن بيتكوين أنه لا يمكن إنفاق UTXO دون توقيع النصاب، hmm.. لكنه لا يضمن أن النصاب يستخدم ذلك التوقيع بأمانة. انتقلت الموثوقية من إثبات العمل في بيتكوين إلى إجماع مُصدّقي Babylon. الجزء "الأصلي" حقيقي، لكن الجزء "غير قائم على الثقة" يعتمد على نفس الافتراضات التي لدى أي سلسلة PoS: أن مجموعة المُصدّقين صادقة ومتوافقة اقتصاديًا.
وبالمقارنة مع جسر يعتمد على Ethereum فقط، تقلل Babylon مساحة السطح للهجمات—لا توجد توكينات مُغلّفة، ولا يوجد خطر الإنشاء (minting)—لكنها لا تلغي الاعتماد على المُصدّقين. سكربت القفل مجرد أداة؛ سلسلة Babylon هي القاضي.
إذا أصبحت مجموعة المُصدّقين مُخترَقة، فهل يقدم سكربت بيتكوين أي دفاع بخلاف قفل لا يملكه المهاجمون سوى التحكم بالمفتاح بالفعل؟
#baby $BABY
