مررت فعليًا بتدفق شبكة الاختبار لـ TBV بدلًا من مجرد قراءة عنه، وتوقفت عند خطوة لم أتوقعها: مباشرة بعد الإيداع، لا يفتح التطبيق مجرد مجلّد واحد. بل يقترح تقسيمه إلى مجلّدين: "مجلّد تضحية" بحجم يغطي ما يتوقعه البروتوكول للاستيلاء عليه أولًا، و"مجلّد محمي" يحتوي على الباقي. يتم تصفية مجلّد التضحية أولًا وبالترتيب قبل أن يتم المساس بالمجلد المحمي أبدًا.
هذا ليس شكلًا كنت أتوقع أن تتم به التصفية هنا. في سوق عادي على Aave، التصفية تلتهم جزءًا من مركز ضمان واحد لديك بشكلٍ تناسبي.
ذكّرني الأمر بالتحضير لرحلة مع حقيبة أنت مستعد تمامًا أن تخسرها. أنت لا تقسم مقتنياتك بالتساوي بين حقيبتين على أمل الأفضل. بل تضع ما يمكنك تحمّل خسارته في الحقيبة التي تذهب في الشحن، وتحتفظ بما يهمك فعلًا معك. TBV يجعلُك تفعل ذلك مع BTC قبل أن تكون قد اقترضت أي شيء — تقرر مسبقًا ما هو قابل للإعطاء، بحيث إذا حدث خطأ، تُؤخذ فقط "الحقيبة المسلمة".
وهذه هي الجزء الذي فوجئني به: عند إعدادات شبكة الاختبار الحالية، مجلّد التضحية هو في الواقع الأكبر من الاثنين، وليس الأصغر. البروتوكول لا يطلب منك تعريض مبلغ رمزي للخطر مسبقًا — بل يطلب منك وضع وزن حقيقي وراء الطُعم.
يصبح الأمر منطقيًا عندما تفكر في السبب. فكّ BTC على شبكة Bitcoin ليس فوريًا مثل استدعاء تصفية عبر EVM — لا توجد طريقة نظيفة لفك جزء فقط من مجلّد مشترك واحد في منتصف الأزمة. وجود مجلّدين منفصلين يعني أن البروتوكول ببساطة يأخذ المجلّد الأصغر دون مشكلة فكّ جزئي، ودون صراع مع أوقات التأكيد أثناء التصفية.
يبدو الأمر أقل كأنه إدارة مخاطر وأكثر كونه تسلسل مخاطر، يتم تحديده بواسطة المودع بدلًا من البروتوكول.
أتساءل كم عدد الأشخاص الذين سيحددون حجم مجلّد التضحية عمدًا بالفعل بدلًا من قبول التقسيم الافتراضي في التطبيق فقط، ثم معرفة ما الذي اشتركوا فيه خلال أول عملية تصفية — هل هذه فجوة في تجربة المستخدم، أم أن إجبارك على اتخاذ القرار مسبقًا هو أصلًا الهدف؟
@BabylonLabs_io $BABY #baby $KOMA $AKE
هذا ليس شكلًا كنت أتوقع أن تتم به التصفية هنا. في سوق عادي على Aave، التصفية تلتهم جزءًا من مركز ضمان واحد لديك بشكلٍ تناسبي.
ذكّرني الأمر بالتحضير لرحلة مع حقيبة أنت مستعد تمامًا أن تخسرها. أنت لا تقسم مقتنياتك بالتساوي بين حقيبتين على أمل الأفضل. بل تضع ما يمكنك تحمّل خسارته في الحقيبة التي تذهب في الشحن، وتحتفظ بما يهمك فعلًا معك. TBV يجعلُك تفعل ذلك مع BTC قبل أن تكون قد اقترضت أي شيء — تقرر مسبقًا ما هو قابل للإعطاء، بحيث إذا حدث خطأ، تُؤخذ فقط "الحقيبة المسلمة".
وهذه هي الجزء الذي فوجئني به: عند إعدادات شبكة الاختبار الحالية، مجلّد التضحية هو في الواقع الأكبر من الاثنين، وليس الأصغر. البروتوكول لا يطلب منك تعريض مبلغ رمزي للخطر مسبقًا — بل يطلب منك وضع وزن حقيقي وراء الطُعم.
يصبح الأمر منطقيًا عندما تفكر في السبب. فكّ BTC على شبكة Bitcoin ليس فوريًا مثل استدعاء تصفية عبر EVM — لا توجد طريقة نظيفة لفك جزء فقط من مجلّد مشترك واحد في منتصف الأزمة. وجود مجلّدين منفصلين يعني أن البروتوكول ببساطة يأخذ المجلّد الأصغر دون مشكلة فكّ جزئي، ودون صراع مع أوقات التأكيد أثناء التصفية.
يبدو الأمر أقل كأنه إدارة مخاطر وأكثر كونه تسلسل مخاطر، يتم تحديده بواسطة المودع بدلًا من البروتوكول.
أتساءل كم عدد الأشخاص الذين سيحددون حجم مجلّد التضحية عمدًا بالفعل بدلًا من قبول التقسيم الافتراضي في التطبيق فقط، ثم معرفة ما الذي اشتركوا فيه خلال أول عملية تصفية — هل هذه فجوة في تجربة المستخدم، أم أن إجبارك على اتخاذ القرار مسبقًا هو أصلًا الهدف؟
@BabylonLabs_io $BABY #baby $KOMA $AKE
