عندما كنت أراجع اقتصاديات مُدقِّقي (validator) Babylon، لاحظت تصميمًا مثيرًا للاهتمام لمحاذاة الحوافز.
في سلاسل PoS التقليدية، تأتي إيرادات المُدقِّقين بشكل أساسي من مكافآت الكتل ورسوم المعاملات. لكن في إطار Babylon، يوجد مصدر إيراد إضافي للمُدقِّقين: رسوم أمان عبر السلاسل (cross-chain security fees).
تنشأ هذه الرسوم من سلاسل PoS التي تتصل بـ Babylon، حيث يتعيّن عليها دفع رموز BABY لاستئجار أمان شبكة Bitcoin. ثم يتم توزيع هذه الرسوم على المُدقِّقين وفقًا لنسبة حصصهم (stake).
أعتقد أن نموذج الإيرادات متعدد القنوات (multi-stream revenue model) يمكن أن يحسّن بشكل كبير مرونة الاقتصاديات لدى المُدقِّقين. حتى إذا انخفضت نشاط إحدى السلاسل التابعة (downstream chain) ما يؤدي إلى تقليل رسوم المعاملات، يمكن للمُدقِّقين ما يزالون الحصول على تعويض من سلاسل أخرى.
لكن هذا التصميم يضيف أيضًا تعقيدًا جديدًا: كيف يمكن تسعير خدمات الأمان بشكل عادل؟ تختلف احتياجات الأمان لكل سلسلة PoS؛ فبعض السلاسل تتطلب تقديم نقاط تحقق (checkpoint) بشكل متكرر، بينما تحتاج سلاسل أخرى إلى ضمان نهائية (finality) لكن بمعدل أقل.
الحل الحالي في Babylon هو أن كل سلسلة تحصل على “مقاطع أمان” (security slots) عبر آلية مزايدة (auction)، بحيث يوفّر تسعيرًا يعتمد على السوق (market-driven pricing) تخصيصًا كفؤًا نظريًا.
ومع ذلك، ما يقلقني هو أنه في المراحل المبكرة، إذا كان عدد السلاسل المشاركة قليلًا جدًا، فقد تفتقر المزايدات إلى منافسة كافية، مما يؤدي إلى تشوّه في التسعير.
ومن النقاط الأخرى التي تستحق الانتباه تصميم منحنى ربط المُدقِّقين (validator bonding curve). يتطلب Babylon من المُدقِّقين أن يربطوا (bond) كلًّا من BABY وBTC في الوقت نفسه، وتحدد نسبة كلٍ منهما قوة التصويت لديهم (voting power). ترفع هذه آلية الربط ذات الأصلين متطلبات رأس المال لدى المُدقِّقين، لكنها في الوقت نفسه تزيد من تكلفة الهجوم.
ومن منظور الأمان (security perspective)، يبدو هذا التصميم منطقيًا: يحتاج المُهاجم إلى الاستحواذ على نوعي الأصول معًا كي يتمكن من شن هجوم، مما يزيد بشكل كبير من تعقيد الهجوم.
$BABY #baby @BabylonLabs_io
في سلاسل PoS التقليدية، تأتي إيرادات المُدقِّقين بشكل أساسي من مكافآت الكتل ورسوم المعاملات. لكن في إطار Babylon، يوجد مصدر إيراد إضافي للمُدقِّقين: رسوم أمان عبر السلاسل (cross-chain security fees).
تنشأ هذه الرسوم من سلاسل PoS التي تتصل بـ Babylon، حيث يتعيّن عليها دفع رموز BABY لاستئجار أمان شبكة Bitcoin. ثم يتم توزيع هذه الرسوم على المُدقِّقين وفقًا لنسبة حصصهم (stake).
أعتقد أن نموذج الإيرادات متعدد القنوات (multi-stream revenue model) يمكن أن يحسّن بشكل كبير مرونة الاقتصاديات لدى المُدقِّقين. حتى إذا انخفضت نشاط إحدى السلاسل التابعة (downstream chain) ما يؤدي إلى تقليل رسوم المعاملات، يمكن للمُدقِّقين ما يزالون الحصول على تعويض من سلاسل أخرى.
لكن هذا التصميم يضيف أيضًا تعقيدًا جديدًا: كيف يمكن تسعير خدمات الأمان بشكل عادل؟ تختلف احتياجات الأمان لكل سلسلة PoS؛ فبعض السلاسل تتطلب تقديم نقاط تحقق (checkpoint) بشكل متكرر، بينما تحتاج سلاسل أخرى إلى ضمان نهائية (finality) لكن بمعدل أقل.
الحل الحالي في Babylon هو أن كل سلسلة تحصل على “مقاطع أمان” (security slots) عبر آلية مزايدة (auction)، بحيث يوفّر تسعيرًا يعتمد على السوق (market-driven pricing) تخصيصًا كفؤًا نظريًا.
ومع ذلك، ما يقلقني هو أنه في المراحل المبكرة، إذا كان عدد السلاسل المشاركة قليلًا جدًا، فقد تفتقر المزايدات إلى منافسة كافية، مما يؤدي إلى تشوّه في التسعير.
ومن النقاط الأخرى التي تستحق الانتباه تصميم منحنى ربط المُدقِّقين (validator bonding curve). يتطلب Babylon من المُدقِّقين أن يربطوا (bond) كلًّا من BABY وBTC في الوقت نفسه، وتحدد نسبة كلٍ منهما قوة التصويت لديهم (voting power). ترفع هذه آلية الربط ذات الأصلين متطلبات رأس المال لدى المُدقِّقين، لكنها في الوقت نفسه تزيد من تكلفة الهجوم.
ومن منظور الأمان (security perspective)، يبدو هذا التصميم منطقيًا: يحتاج المُهاجم إلى الاستحواذ على نوعي الأصول معًا كي يتمكن من شن هجوم، مما يزيد بشكل كبير من تعقيد الهجوم.
$BABY #baby @BabylonLabs_io