أصعب سؤال في بابل: لقد تم تكليف FP بالفعل بعمل تفويض لـ BTC، لكن تصرفاته لا يمكن مراقبتها في الوقت الفعلي.
كنت أعتقد سابقًا أن جميع توقيعات FP موجودة على السلسلة، وأنه يمكن التحقق فورًا مما إذا كانت التصويتات صحيحة. لكن عندما تعمقت فعليًا في سلسلة المراقبة الخاصة بـ FP، اكتشفت أنه توجد في الواقع آليتان مختلفتان تمامًا.
تُسجَّل سجلات التوقيعات التي يرسلها FP على Babylon Genesis Chain — من وقّع، وعلى أي ارتفاع تم التوقيع، وأي كتلة من BSN تم توقيعها؛ هذه البيانات تكون مرئية على السلسلة. لكن ما إذا كان "FP يصوّت بشكل صحيح" يتطلب مقارنته بسلوك BSN المتوقع — هل قام FP بالتوقيع أم لا، وهل كان ينبغي أن يوقّت في الوقت المناسب لكنه قام بالتأخير. ولا تُفرض هذه المقارنة على مستوى البروتوكول.
بعبارة أخرى، تسجل بابل ما الذي فعله FP، لكنها لا تسجل ما الذي كان ينبغي على FP أن يفعله. الجزء الأخير يجب أن يتتبعه BSN بنفسه، أو الاعتماد على أدوات مراقبة طرف ثالث.
تعني هذه الفجوة الزمنية: عندما يكتشف المستخدم أن سلوك FP غير طبيعي، يكون FP ربما يعمل بشكل غير طبيعي لعدة epochs بالفعل. وإذا كان المستخدم قد فوّض كمية كبيرة من BTC، فقد تكون نافذة كون سلوك FP غير طبيعي أطول بكثير مما يتوقعه المستخدم — من اكتشاف الشذوذ إلى بدء طلب السحب، وصولًا إلى انتهاء فترة unbonding.
وهذا أيضًا يفسّر لماذا تكون السيرة التشغيلية وسمعة FP أكثر أهمية من APY. يمكن تعديل APY، لكن لا يمكن تغيير سجلات السلوك.
إذا قام المستخدم بتفويض عدة FP في الوقت نفسه، فإن تأخر مراقبة كل FP سيكون مختلفًا، وقد تتراكم المخاطر.
لذلك عند تقييم اختيار FP، لن أنظر فقط إلى APY. سأراجع ثلاثة مؤشرات: هل توجد سجلات علنية لنسبة المشاركة في التصويت لـ FP، ومدة التأخر في إشعار السلوك غير الطبيعي، وكذلك إجمالي تكلفة التشغيل من قرار تغيير FP إلى أن يسري FP الجديد.
التحدي الحقيقي ليس في مدى موثوقية FP ظاهريًا وقت التفويض، بل في الوقت الذي تحتاجه عند حدوث شذوذ في سلوك FP لتكتشف الأمر وتغادر.
@BabylonLabs_io $BABY #baby
كنت أعتقد سابقًا أن جميع توقيعات FP موجودة على السلسلة، وأنه يمكن التحقق فورًا مما إذا كانت التصويتات صحيحة. لكن عندما تعمقت فعليًا في سلسلة المراقبة الخاصة بـ FP، اكتشفت أنه توجد في الواقع آليتان مختلفتان تمامًا.
تُسجَّل سجلات التوقيعات التي يرسلها FP على Babylon Genesis Chain — من وقّع، وعلى أي ارتفاع تم التوقيع، وأي كتلة من BSN تم توقيعها؛ هذه البيانات تكون مرئية على السلسلة. لكن ما إذا كان "FP يصوّت بشكل صحيح" يتطلب مقارنته بسلوك BSN المتوقع — هل قام FP بالتوقيع أم لا، وهل كان ينبغي أن يوقّت في الوقت المناسب لكنه قام بالتأخير. ولا تُفرض هذه المقارنة على مستوى البروتوكول.
بعبارة أخرى، تسجل بابل ما الذي فعله FP، لكنها لا تسجل ما الذي كان ينبغي على FP أن يفعله. الجزء الأخير يجب أن يتتبعه BSN بنفسه، أو الاعتماد على أدوات مراقبة طرف ثالث.
تعني هذه الفجوة الزمنية: عندما يكتشف المستخدم أن سلوك FP غير طبيعي، يكون FP ربما يعمل بشكل غير طبيعي لعدة epochs بالفعل. وإذا كان المستخدم قد فوّض كمية كبيرة من BTC، فقد تكون نافذة كون سلوك FP غير طبيعي أطول بكثير مما يتوقعه المستخدم — من اكتشاف الشذوذ إلى بدء طلب السحب، وصولًا إلى انتهاء فترة unbonding.
وهذا أيضًا يفسّر لماذا تكون السيرة التشغيلية وسمعة FP أكثر أهمية من APY. يمكن تعديل APY، لكن لا يمكن تغيير سجلات السلوك.
إذا قام المستخدم بتفويض عدة FP في الوقت نفسه، فإن تأخر مراقبة كل FP سيكون مختلفًا، وقد تتراكم المخاطر.
لذلك عند تقييم اختيار FP، لن أنظر فقط إلى APY. سأراجع ثلاثة مؤشرات: هل توجد سجلات علنية لنسبة المشاركة في التصويت لـ FP، ومدة التأخر في إشعار السلوك غير الطبيعي، وكذلك إجمالي تكلفة التشغيل من قرار تغيير FP إلى أن يسري FP الجديد.
التحدي الحقيقي ليس في مدى موثوقية FP ظاهريًا وقت التفويض، بل في الوقت الذي تحتاجه عند حدوث شذوذ في سلوك FP لتكتشف الأمر وتغادر.
@BabylonLabs_io $BABY #baby
