#baby $BABY يحتاج مقدّمو الإنهاء النهائي في Babylon إلى صيانة حالتيْ BTC وPoS معًا—هذا هو المقابل/التنازل وراء هذا التصميم

عندما رأيت أول مرة متطلبات عقد عقدة مُقدّم الإنهاء النهائي في Babylon، قلت في نفسي: ما هذه العتبة المرتفعة جدًا! يجب عليك تشغيل عقدة بثّي البيتكوين الكاملة وعقدة سلسلة PoS في الوقت نفسه، ويجب أن تتم مزامنة دفترَي الأستاذين في الوقت الحقيقي. ألا يؤدي ذلك إلى إنهاك العقد فعليًا؟

لاحقًا، تحدثت مع صديق كان قد شغّل عقدة تحقق (validator)، وقال لي جملة واحدة كانت بمثابة توضيح صريح: «التعب هو الصحيح.»

المهمة التي تقوم بها Babylon هي ربط نهائية معاملات سلسلة PoS بالبتكوين. فإذا كانت العقدة لا تراقب إلا سلسلة PoS ولا تراقب سلسلة BTC، فكيف ستعرف ما إذا كان جانب البيتكوين قد أكد فعليًا؟ وكيف تحدد ما إذا كانت شروط الجزاء قد تم تفعيلها فعلًا؟ باختصار: لكي يكون هذا الحكم، يجب أن ترى بيانات سلسلتيْن بعينيك أنت، لا أن تعتمد على من ينقلها لك.

هذا تنازل من نوع «الزيادة في الأمان». فالعقدة التي تعمل على دفتر واحد بالطبع تكون أخف وزنًا، لكن عند التوقيع تكون عمليًا «تخمن» ما الذي يحدث على الجهة الأخرى. إن كانت التخمينات صحيحة فلا بأس، لكن إن كانت خاطئة فإن الالتزام النهائي كله ينهار. اختارت Babylon أن تُحمّل العقد عبء العمل؛ وبالجوهر فهي ترفض «وهم العقد الخفيفة»: إما أن تقوم بالتحقق الكامل، أو ألا تشارك على الإطلاق، ولا وجود لوضعٍ وسط.

الثمن واضح جدًا: تتضاعف تكلفة الأجهزة، وتتضاعف نفقات عرض النطاق (الـ bandwidth)، وتزداد تعقيدات تشغيل العقدة على نحو مباشر بمستوى أعلى. هذا لا شك أنه سيستبعد فئة من الأفراد الذين يريدون تشغيل عقدة بسهولة، وسيترك غالبًا فرق البنية التحتية المتخصصة.

لكن ما ستحصل عليه مقابل هذا الثمن ملموس: كل توقيع نهائية نهائي يحمل في خلفيته تأكيدًا حقيقيًا من العقد لحالة كلتا السلسلتين بالكامل. ليس تفويضًا، وليس وكالة، وليس سلسلة دومينو من نوع «أنا أثق به وهو يثق بك». هذا السماك/العمق الأمني الصلب والقائم على الدليل لا يمكن الحصول عليه بمجرد الكسل.

أعتقد أن هذا التصميم يبرز بشكل خاص ترتيب أولويات قيمة فريق Babylon: الأمان أولًا، ويمكن تأجيل سهولة الاستخدام قليلًا. @BabylonLabs_io

سؤال واحد: برأيك، هل ارتفاع عتبة الدخول للعقدة أمرٌ جيد أم أنه عيب/مخاطرة؟