لقد أعدتُ تشغيل عملية التشارك بالرهان (共质押) الخاصة بـ Babylon من جديد؛ أكثر ما أزعجني هو أن الكثير من الشروط المهمة لا يكتشفها المستخدم إلا عندما لا يحصل على مكافآت.
لقد لخصت الجهة الرسمية العملية في خطوتين: تُفوَّض BTC إلى مزوّد Finality Provider، ثم تُفوَّض BABY مرة أخرى إلى المُتحقق (validator). لكن عند التطبيق فعليًا، يجب أن تنتقل BTC من حالة PENDING إلى VERIFIED، ثم في النهاية إلى ACTIVE. ولا تُحتسب المكافأة إلا عندما تكون حالة BTC هي ACTIVE؛ كما يجب أن تستخدم BTC وBABY عنوان BABY واحدًا. إذا كانت العناوين غير متطابقة، فسيتم تصفير مكافأة التشارك مباشرةً. ولتحقيق أقصى كفاءة في الحصول على المكافآت، يجب أيضًا أن تتذكر أن 1 BTC تقابل 20,000 BABY.
المشكلة هي أن المستخدم العادي عندما يرى “تم الإرسال” أو “تم التحقق”، قد يظن بسهولة أن كل شيء قد اكتمل. أما أين توقفت الأمور بالضبط، ولماذا لا توجد مكافآت، وهل الـ Finality Provider المختار ما يزال نشطًا، وهل العنوانان متطابقان فعلاً—فالمفترض أن توضح الصفحة ذلك مباشرة، وألا تترك للمستخدم مهمة قراءة الوثائق ومحاولة التخمين.
الآن تعرض لوحة Babylon حوالي 51,342 BTC مُرهَنة، ومن بين 132 مزوّد Finality Provider هناك 36 فقط في حالة نشطة، والمدى السنوي لعائد BTC يتراوح من 0.04% إلى 0.70%. تم بناء الحجم بالفعل، لكن ما يزال جانب المستخدم يعتمد على استكشاف الأخطاء بأنفسهم.
كذلك، لا تكون مرحلة الخروج سهلة كما يبدو على السطح. فقد وثّقت الجهة الرسمية لمستند تفكيك/فك الرهان (解质押) الخاص بـ BTC حد انتظار أدنى يبلغ 301 بلوك من بلوكات بيتكوين؛ كما أن تعقب الأعطال في CLI قد يتضمن التعامل مع معاملات gas، وتهيئة RPC وGRPC. وإذا لم يُحل ذلك، فاذهب لطلب المساعدة في Discord.
لقد كانت شكوكي بشأن @BabylonLabs_io مباشرة جدًا: يمكن فهم تعقيد البروتوكول، لكن لا يجوز للمنتج أن ينقل التعقيد كما هو إلى المستخدم.
ما كان ينبغي استكماله فعلًا هو تفسير الحالات وتحديد الأخطاء ومسار معالجة واضح. وإلا فإن ما يُسمى “التخزين الذاتي” قد يتحول بسهولة إلى—أن كل الأسئلة التي لا يمكن فهمها يصبح عبؤها على المستخدم وحده.
#baby $BABY @BabylonLabs_io
لقد لخصت الجهة الرسمية العملية في خطوتين: تُفوَّض BTC إلى مزوّد Finality Provider، ثم تُفوَّض BABY مرة أخرى إلى المُتحقق (validator). لكن عند التطبيق فعليًا، يجب أن تنتقل BTC من حالة PENDING إلى VERIFIED، ثم في النهاية إلى ACTIVE. ولا تُحتسب المكافأة إلا عندما تكون حالة BTC هي ACTIVE؛ كما يجب أن تستخدم BTC وBABY عنوان BABY واحدًا. إذا كانت العناوين غير متطابقة، فسيتم تصفير مكافأة التشارك مباشرةً. ولتحقيق أقصى كفاءة في الحصول على المكافآت، يجب أيضًا أن تتذكر أن 1 BTC تقابل 20,000 BABY.
المشكلة هي أن المستخدم العادي عندما يرى “تم الإرسال” أو “تم التحقق”، قد يظن بسهولة أن كل شيء قد اكتمل. أما أين توقفت الأمور بالضبط، ولماذا لا توجد مكافآت، وهل الـ Finality Provider المختار ما يزال نشطًا، وهل العنوانان متطابقان فعلاً—فالمفترض أن توضح الصفحة ذلك مباشرة، وألا تترك للمستخدم مهمة قراءة الوثائق ومحاولة التخمين.
الآن تعرض لوحة Babylon حوالي 51,342 BTC مُرهَنة، ومن بين 132 مزوّد Finality Provider هناك 36 فقط في حالة نشطة، والمدى السنوي لعائد BTC يتراوح من 0.04% إلى 0.70%. تم بناء الحجم بالفعل، لكن ما يزال جانب المستخدم يعتمد على استكشاف الأخطاء بأنفسهم.
كذلك، لا تكون مرحلة الخروج سهلة كما يبدو على السطح. فقد وثّقت الجهة الرسمية لمستند تفكيك/فك الرهان (解质押) الخاص بـ BTC حد انتظار أدنى يبلغ 301 بلوك من بلوكات بيتكوين؛ كما أن تعقب الأعطال في CLI قد يتضمن التعامل مع معاملات gas، وتهيئة RPC وGRPC. وإذا لم يُحل ذلك، فاذهب لطلب المساعدة في Discord.
لقد كانت شكوكي بشأن @BabylonLabs_io مباشرة جدًا: يمكن فهم تعقيد البروتوكول، لكن لا يجوز للمنتج أن ينقل التعقيد كما هو إلى المستخدم.
ما كان ينبغي استكماله فعلًا هو تفسير الحالات وتحديد الأخطاء ومسار معالجة واضح. وإلا فإن ما يُسمى “التخزين الذاتي” قد يتحول بسهولة إلى—أن كل الأسئلة التي لا يمكن فهمها يصبح عبؤها على المستخدم وحده.
#baby $BABY @BabylonLabs_io