#baby $BABY @BabylonLabs_io لقد سهرّتُ الليلة الماضية طوال الليل في مراجعة الصفحات داخل وثائق BabylonLabs حول منطق التقسيم الخاص بـ delegation و slashing.
يعتقد أغلب الناس أن المصادرة/الغرامة تتم وفق قاعدة "التحقق أولاً ثم المفوِّض"، لكن اتضح أن الأمر ليس كذلك.
عند تفعيل slashing في البروتوكول، يتم خفض الـ self-bond الخاص بالمدقِّق ورصيد المفوِّض بنفس النسبة. وإذا كانت نسبة الاكتتاب الذاتي للمدقِّق منخفضة جدًا، ففي مصادرة واحدة يمكن أن يخسر هو ألفي دولار، بينما قد تخسر أنت مئتي ألف. فجوة التعرض للمخاطر غير متكافئة تمامًا. #baby
والتفاصيل الأعمق: في الوثائق لا توجد برمجة ثابتة (hard encoding) لحد أدنى محدد للاكتتاب الذاتي الخاص بالمدقِّق. هذه المعلمة تُترك لكل سلسلة POS لتعيينها بنفسها؛ وبعض إعدادات الشبكات التجريبية تكون قريبة من الصفر. من جهة المفوِّض لا توجد واجهة موحّدة تمكّنه من المقارنة بشكل بصري وفوري لـ "كم يملك المدقِّق الذي أفوّضه من أمواله الخاصة". لم أجد تعريفًا واضحًا ومباشرًا لهذه النقطة. @BabylonLabs_io
للتشبيه: تخيّل أنك تبرم عقد شراكة لافتتاح مطعم بمبلغ مليون، يشارك الشركاء بمبلغ عشرة آلاف. ونص العقد يقول: "يتحمل الخسارة الجميع". في النهاية يتقاسم كل طرف 20%—فيخسر الشريك ألفين، بينما تخسر أنت مئتي ألف.
بالنسبة لي، عند النظر إلى هذا الميكانيزم، في التطبيق سأُرجّح أولاً تفويض المدقِّقين بنسبة self-bond أعلى وبمبالغ مطلقة أكبر، ولا أنظر فقط إلى APR. إذا كانت عتبة القبول على سلسلة ما منخفضة جدًا، فسأقوم مباشرة بتخفيض وزن/أهمية التفويض. القيود هنا أن الشبكة الرئيسية لم تعمل بعد، وبيانات self-bond الحقيقية لم تُسجل على السلسلة بعد، ولم أختبر تسلسُل تنفيذ slashing الحقيقي في بيئة تشغيل فعلية.
وبالنسبة لمسار BABY لاحقًا، فمن الصعب على المدى القصير تسعير هذا النوع من "مخاطر الوكيل/المفوِّض" بشكل مباشر؛ بل يشبه تقرير فحص طبي يُقدَّم للمؤسسات—كلما كانت آليات حماية المفوِّض قادرة على الصمود أمام التدقيق في التفاصيل حرفًا بحرف، كلما كانت عتبات دخول الأموال الكبيرة أقل. لن أُعدّل ترتيب الحيازات/توزيع الأصول لمجرد أنني فهمت هذه النقطة؛ سأنتظر بيانات الشبكة الرئيسية والحالات الفعلية ثم أُعيد التقييم.
عندما تختارون المدققين: هل ستتحققون من نسبة self-bond لديه، أم تكتفون بترتيب العائدات؟ لنحكِ في قسم التعليقات في Binance Square.
يعتقد أغلب الناس أن المصادرة/الغرامة تتم وفق قاعدة "التحقق أولاً ثم المفوِّض"، لكن اتضح أن الأمر ليس كذلك.
عند تفعيل slashing في البروتوكول، يتم خفض الـ self-bond الخاص بالمدقِّق ورصيد المفوِّض بنفس النسبة. وإذا كانت نسبة الاكتتاب الذاتي للمدقِّق منخفضة جدًا، ففي مصادرة واحدة يمكن أن يخسر هو ألفي دولار، بينما قد تخسر أنت مئتي ألف. فجوة التعرض للمخاطر غير متكافئة تمامًا. #baby
والتفاصيل الأعمق: في الوثائق لا توجد برمجة ثابتة (hard encoding) لحد أدنى محدد للاكتتاب الذاتي الخاص بالمدقِّق. هذه المعلمة تُترك لكل سلسلة POS لتعيينها بنفسها؛ وبعض إعدادات الشبكات التجريبية تكون قريبة من الصفر. من جهة المفوِّض لا توجد واجهة موحّدة تمكّنه من المقارنة بشكل بصري وفوري لـ "كم يملك المدقِّق الذي أفوّضه من أمواله الخاصة". لم أجد تعريفًا واضحًا ومباشرًا لهذه النقطة. @BabylonLabs_io
للتشبيه: تخيّل أنك تبرم عقد شراكة لافتتاح مطعم بمبلغ مليون، يشارك الشركاء بمبلغ عشرة آلاف. ونص العقد يقول: "يتحمل الخسارة الجميع". في النهاية يتقاسم كل طرف 20%—فيخسر الشريك ألفين، بينما تخسر أنت مئتي ألف.
بالنسبة لي، عند النظر إلى هذا الميكانيزم، في التطبيق سأُرجّح أولاً تفويض المدقِّقين بنسبة self-bond أعلى وبمبالغ مطلقة أكبر، ولا أنظر فقط إلى APR. إذا كانت عتبة القبول على سلسلة ما منخفضة جدًا، فسأقوم مباشرة بتخفيض وزن/أهمية التفويض. القيود هنا أن الشبكة الرئيسية لم تعمل بعد، وبيانات self-bond الحقيقية لم تُسجل على السلسلة بعد، ولم أختبر تسلسُل تنفيذ slashing الحقيقي في بيئة تشغيل فعلية.
وبالنسبة لمسار BABY لاحقًا، فمن الصعب على المدى القصير تسعير هذا النوع من "مخاطر الوكيل/المفوِّض" بشكل مباشر؛ بل يشبه تقرير فحص طبي يُقدَّم للمؤسسات—كلما كانت آليات حماية المفوِّض قادرة على الصمود أمام التدقيق في التفاصيل حرفًا بحرف، كلما كانت عتبات دخول الأموال الكبيرة أقل. لن أُعدّل ترتيب الحيازات/توزيع الأصول لمجرد أنني فهمت هذه النقطة؛ سأنتظر بيانات الشبكة الرئيسية والحالات الفعلية ثم أُعيد التقييم.
عندما تختارون المدققين: هل ستتحققون من نسبة self-bond لديه، أم تكتفون بترتيب العائدات؟ لنحكِ في قسم التعليقات في Binance Square.