#baby $BABY كيف تقوم بفرض "القطع/السلخ" (slashing) على مُتحقق في بيتكوين عندما لا توجد لدى بيتكوين منطق slashing مدمج؟
استغرقني وقتًا أطول مما توقعت لفهم هذه المسألة فعليًا، لأن الإجابة ليست عقدًا ذكيًا بل مخطط تواقيع يقوم بشيء ذكي باستخدام الرياضيات بدلًا من الكود.
@BabylonLabs_io يستخدم ما يُسمّى بـ Extractable One-Time Signature (EOTS)، مبنيًا على تواقيع Schnorr الأصلية في بيتكوين. إليك الحيلة الأساسية: يقوم مزوّد/مُوفّر الإنهاء (finality provider) بتوليد زوج مفاتيح فريد لكل ارتفاع بلوك (block height) يقوم بالتصويت عليه. طالما أنهم يوقّعون بلوكًا واحدًا فقط لكل ارتفاع، تبقى التوقيعات آمنة تمامًا ولا يتسرّب أي شيء. لكن إذا وقّعوا بلوكين متعارضين في نفس الارتفاع، تنهار الرياضيات.
إعادة استخدام مفتاح ذلك الارتفاع لتوقيع رسالتين مختلفتين تكشف مفتاحهم الخاص مباشرةً، بسبب كيفية عمل رياضيات توقيع Schnorr عندما يُعاد استخدام nonce (قيمة عشوائية لمرة واحدة).
تتطلب جولة الإنهاء نفسها توقيعات من أكثر من ثلثي وزن BTC المُرهَن حتى يتمكن البلوك من الترسيم النهائي (finalize) فعليًا؛ وبالتالي فإن أي انتهاك للسلامة، بحكم التعريف، يتطلب أن يكون لدى أكثر من ثلث الرهن توقيعان مزدوجان. هذا ما يجعل ضمان "قابل للقطع بالكامل" (fully slashable) مفروضًا رياضيًا لا كتعهد سياساتي: بمجرد تسريب المفتاح، يمكن لأي شخص—ليس فقط Babylon ولا فقط المُتحقق—بناء معاملة slashing وإرسالها للبث. لا حاجة لتصويت لجنة في تلك المرحلة، ولا توجد إجراءات استئناف؛ فقط رياضيات مكشوفة.
ما لم أره جوابًا واضحًا بشأنه: هل توليد المفاتيح لكل ارتفاع بلوك يخلق عبئًا تشغيليًا مهمًا على مزوّدي الإنهاء الذين يعملون على عدة BSNs في وقتٍ واحد، وهل قد يصبح هذا العبء بدوره سطح هجوم، مثلًا إذا أعاد مزوّد تحت الضغط استخدام العشوائية عن طريق الخطأ بدلًا من سوء النية؟
هل أمان EOTS ضمان رياضي بحت، أم أنه يعتمد أيضًا—وبصمت—على امتلاك مزوّدي الإنهاء بنية تحتية قوية لإدارة المفاتيح؟
$BABY
استغرقني وقتًا أطول مما توقعت لفهم هذه المسألة فعليًا، لأن الإجابة ليست عقدًا ذكيًا بل مخطط تواقيع يقوم بشيء ذكي باستخدام الرياضيات بدلًا من الكود.
@BabylonLabs_io يستخدم ما يُسمّى بـ Extractable One-Time Signature (EOTS)، مبنيًا على تواقيع Schnorr الأصلية في بيتكوين. إليك الحيلة الأساسية: يقوم مزوّد/مُوفّر الإنهاء (finality provider) بتوليد زوج مفاتيح فريد لكل ارتفاع بلوك (block height) يقوم بالتصويت عليه. طالما أنهم يوقّعون بلوكًا واحدًا فقط لكل ارتفاع، تبقى التوقيعات آمنة تمامًا ولا يتسرّب أي شيء. لكن إذا وقّعوا بلوكين متعارضين في نفس الارتفاع، تنهار الرياضيات.
إعادة استخدام مفتاح ذلك الارتفاع لتوقيع رسالتين مختلفتين تكشف مفتاحهم الخاص مباشرةً، بسبب كيفية عمل رياضيات توقيع Schnorr عندما يُعاد استخدام nonce (قيمة عشوائية لمرة واحدة).
تتطلب جولة الإنهاء نفسها توقيعات من أكثر من ثلثي وزن BTC المُرهَن حتى يتمكن البلوك من الترسيم النهائي (finalize) فعليًا؛ وبالتالي فإن أي انتهاك للسلامة، بحكم التعريف، يتطلب أن يكون لدى أكثر من ثلث الرهن توقيعان مزدوجان. هذا ما يجعل ضمان "قابل للقطع بالكامل" (fully slashable) مفروضًا رياضيًا لا كتعهد سياساتي: بمجرد تسريب المفتاح، يمكن لأي شخص—ليس فقط Babylon ولا فقط المُتحقق—بناء معاملة slashing وإرسالها للبث. لا حاجة لتصويت لجنة في تلك المرحلة، ولا توجد إجراءات استئناف؛ فقط رياضيات مكشوفة.
ما لم أره جوابًا واضحًا بشأنه: هل توليد المفاتيح لكل ارتفاع بلوك يخلق عبئًا تشغيليًا مهمًا على مزوّدي الإنهاء الذين يعملون على عدة BSNs في وقتٍ واحد، وهل قد يصبح هذا العبء بدوره سطح هجوم، مثلًا إذا أعاد مزوّد تحت الضغط استخدام العشوائية عن طريق الخطأ بدلًا من سوء النية؟
هل أمان EOTS ضمان رياضي بحت، أم أنه يعتمد أيضًا—وبصمت—على امتلاك مزوّدي الإنهاء بنية تحتية قوية لإدارة المفاتيح؟
$BABY