MrRUHUL

في الوقت الحالي، في عالم الكريبتو يتم الحديث عن الستيكينغ، لذلك غالبًا ما يبحث معظم الناس أولًا عن الـ APY أو العوائد. لكن عندما حاولت فهم البنية المعمارية لـ @BabylonLabs_io بتفاصيل أكثر، انتبهت أكثر ما انتبهت إلى نموذج الأمان الخاص بها. برأيي، عند تقييم أي مشروع بنية تحتية، يجب النظر إلى حماية رأس المال وإدارة المخاطر قبل النظر إلى العوائد.

أمر واحد وجدته عمليًا جدًا أثناء قراءة التوثيق الرسمي. وبقدر ما فهمت، في الستيكينغ الخاص بالبيتكوين يتم تفعيل الـ slashing عندما يقوم الـ Delegated Finality Provider بسلوك قابل للـ slash، مثل القيام بالتوقيع المزدوج. بمعنى أنه لا يتم معاقبة الستكرز تلقائيًا بسبب مشكلة غير ذات صلة في النظام. من ناحية أخرى، $BABY تستند إلى قواعد الـ slashing القياسية في Cosmos SDK، حيث يتم تغطية حالات مثل الخمول والتوقيع المزدوج.

كما أن هيكل المكافآت بدا لي متوازنًا. وفقًا لشاشة توزيع المكافآت المرجعية، كان التوزيع الحالي على النحو التالي: مكافأة الستيكينغ الأساسية 3.44%، حاملو Pioneer Pass NFT بنسبة 0.24%، ومطورو GitHub بنسبة 0.01%. بالنسبة لي، لا تعكس هذه الأرقام محاولات لإظهار عوائد غير واقعية، بل تعكس نهجًا محسوبًا ومستدامًا.

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

إذا كنت تريد أيضًا التحقق بنفسك من نموذج الستيكينغ وتصميم الأمان، فعليك بالتأكيد الاطلاع على الموقع الرسمي والوثائق. في الكريبتو، فإن إجراء بحثك الخاص هو أفضل نهج.
https://babylonlabs.io
#baby $BABY @BabylonLabs_io

كنت أعتقد دائمًا أن الأجهزة المتخصصة هي أكثر الطرق أمانًا لحماية أنظمة الربط عبر السلاسل
بينما كنت أقرأ الورقة البيضاء الخاصة بـ Babylon
لاحظت شيئًا فاجأني
بدلًا من افتراض أن الأجهزة الموثوقة هي الإجابة النهائية، يقضي Babylon وقتًا في مناقشة المفاضلات المتعلقة بالاعتماد عليها
جعلني ذلك أتوقف للحظة
يمكن للأجهزة الجيدة تقليل العديد من المخاطر، لكنها تطرح أيضًا سؤالًا آخر
ماذا يحدث إذا كان الشيء الذي يثق به الجميع هو الشيء الذي يفشل
لم أكن قد نظرت إلى الأمن بهذه الطريقة من قبل
الجزء المثير للاهتمام لم يكن ما إذا كانت الأجهزة جيدة أم سيئة
بل كان إدراك أن كل افتراض إضافي يصبح مخاطرة أخرى يتعين على النظام حملها
لهذا وجدت اتجاه Babylon مثيرًا للاهتمام؛ بدلًا من مجرد إضافة أجهزة أكثر قوة، تحاول التصميمات تقليل مقدار الثقة الواجب وضعها في أي مكوّن واحد
أعتقد أن هذه طريقة مختلفة للتفكير في الأمن
أحيانًا لا تكون أفضل ترقية أمنية هي إضافة طبقة موثوقة أخرى
بل تصميم نظام يحتاج إلى عدد أقل من الطبقات الموثوقة من الأساس
#baby $BABY @BabylonLabs_io