#baby لقد شاهدت مؤخرًا TBV الخاص بـ @BabylonLabs_io 。

بدأت ألا أراقب الإيداع في الصفحة بعد الآن。

بدلًا من ذلك، ركزت تحديدًا على ما الذي قد يحدث بعد اختفاء الـ Provider。

الإجابة مخبأة داخل WOTS keypair وملفات claimer artifacts。

عند إنشاء الـ Vault。

سيحصل المستخدم على مفتاح توقيع لمرة واحدة。

بالإضافة إلى مجموعة كاملة من المعاملات المُعدة مسبقًا وبيانات التحديات。

عادةً ما تبدو هذه الأشياء وكأنها مرفقات تقنية。

لكن عند وقوع مشكلة فعلًا، قد تكون هي المخرج الوحيد。

Vault Provider متصل بالإنترنت。

يمكنه مساعدة المستخدم في تنفيذ Claim وAssert وPayout。

لكن الـ Provider لا يستجيب。

من الناحية النظرية، يستطيع المستخدم ما زال تشغيل أدوات سطر الأوامر، واتباع مسار المعاملات المُحدد مسبقًا لإرجاع $BTC إلى العنوان الأصلي。

يبدو هذا عديم الثقة。

لكنني فكرت فورًا في سيناريو أكثر واقعية。

انقطع اتصال Provider。

وتعطّل أيضًا كمبيوتر المستخدم القديم。

ملف WOTS موجود فقط على الجهاز الأصلي。

لا توجد نسخ احتياطية خارجية على وضع عدم الاتصال。

في هذه اللحظة، لا يتم حجز الأصول وفق البروتوكول。

والسكربت أيضًا لا يمنع الخروج。

ومع ذلك، قد يظل المستخدم واقفًا أمام باب المخرج، لكنه لن يجد مفتاح فتح الباب。

لذلك فإن عبارة “لا يحتاج إلى موافقة المشغل” هي مجرد الخطوة الأولى。

الخطوة التالية هي جعل المستخدم العادي يمتلك فعلًا القدرة على الاستعادة بشكل مستقل。

والبيانات التي أريد رؤيتها بسيطة أيضًا。

كم عدد المستخدمين الذين احتفظوا بالمواد.

ما نسبة نجاح Self-Claim.

كم يستغرق الأمر لإجراء استعادة كاملة.

أين تتعثر الأمور غالبًا في حالة الفشل.

يمكن أن تكون قصة البنية التحتية لـ $BABY كبيرة.

لكن ما إذا كان TBV ناضجًا لا يمكن أن يُقاس فقط بعدد عمليات الإيداع الناجحة التي أدت إلى إرجاع $BTC .

الاختبار الحقيقي هو: عندما تكون جميع الأدوار المساعدة غير متصلة، هل يستطيع المستخدم وحده—بفضل الملفات التي حفظها—أن يأخذ الأصول كاملة معه.

#baby