الروبوتات الخاصة بالتصفية لا تمتلك مقصًا؛ بل تنقل الصناديق كاملة فقط. عندما رأيت @BabylonLabs_io في الشبكة الاختبارية الحالية تقوم بتصميم كل Vault كـ UTXO مستقل، فهمت أخيرًا: إن الـ Double Vault ليس خيار إيداعًا جميلًا، بل هو طريقة لتقطيع خسائر التصفية إلى حبيبات.
في DeFi العادية، يمكن قص الضمانات بنِسب، لكن معاملات Bitcoin لا تسمح إلا بصرف مخرج كامل. لنفترض أن لديك 0.4 BTC في المركز؛ التصفية تحتاج فقط إلى معالجة حوالي 0.25 BTC منها. أما إذا كانت كل 0.4 BTC محشورة داخل Vault واحد، فلن يستطيع البروتوكول قص 0.25 BTC من بين محتوياته؛ بل سيتعين عليه إدخال الـ Vault كامل ضمن التصفية. لا تختفي القيمة الزائدة فجأة: ستقوم آلية الإنصاف أولًا بتقليل إجمالي الديون المتبقية عن المستخدم، وإذا بقي رصيد فسيتم ردّه بـ WBTC. لكن «الحصول على تعويض مكافئ» و«بقاء الـ BTC الأصلي داخل الـ Vault الخاص بك» ليسا الشيء نفسه.
وهذا بالضبط هو المكان الذي تصبح فيه قيمة الـ Double Vault حقيقية. وفقًا لإعدادات الشبكة الاختبارية العامة الحالية، عامل الضمان 78%، وعامل الصحة المستهدف 1.24. تقدّر الوثائق أنه عندما يَشتعل التصفية للتو، فإن الكمية المستهدفة التي يتم أخذها تمثل نحو 62% من قيمة BTC. وبحسب المعلمات الفعلية، سيقوم Portal بوضع الـ Vault الذي يتطلب تضحية أكبر في المقدمة، بينما يتم وضع بقية BTC في الـ Vault الخاص بالحماية. يقوم إجراء التصفية بفحص القائمة من بدايتها، ويُوقف بعد أن تكون أولى الـ Vault كافية، بينما تبقى الثانية ضمن المركز.
لذلك فهي ليست «أداة تمنع التصفية» بقدر ما هي «بوابة مانعة لتسرب المياه داخل حجرة السفينة»: ستظل هناك خسارة عند وقوع المشكلة، لكننا نحاول ألا تبتلع الخسارة السفينة بأكملها. إذا انخفض السوق بسرعة كبيرة، أو كان حجم الـ Vault المُضحّى به غير كافٍ، أو تم ترتيب الترتيب بشكل خاطئ، فقد يستمر النظام في أخذ الـ Vault التالي. كما أن 62/38 ليست معادلة دائمة؛ بعد تغيّر المعلمات يجب إعادة النظر في التقسيم الذي يقدمه Portal.
أنا أفضل تسمية هذا التصميم «إدارة دقة الخسارة». الشيء الذي يجب على المقترض مراقبته حقًا ليس عامل الصحة فقط، بل أيضًا حجم vault الخاص به وترتيبها. هل ستقبل بإدارة أكثر تعقيدًا للمركز من أجل الحفاظ على vault الـ BTC الأصلي في الموضع الثاني؟
#baby $BABY
في DeFi العادية، يمكن قص الضمانات بنِسب، لكن معاملات Bitcoin لا تسمح إلا بصرف مخرج كامل. لنفترض أن لديك 0.4 BTC في المركز؛ التصفية تحتاج فقط إلى معالجة حوالي 0.25 BTC منها. أما إذا كانت كل 0.4 BTC محشورة داخل Vault واحد، فلن يستطيع البروتوكول قص 0.25 BTC من بين محتوياته؛ بل سيتعين عليه إدخال الـ Vault كامل ضمن التصفية. لا تختفي القيمة الزائدة فجأة: ستقوم آلية الإنصاف أولًا بتقليل إجمالي الديون المتبقية عن المستخدم، وإذا بقي رصيد فسيتم ردّه بـ WBTC. لكن «الحصول على تعويض مكافئ» و«بقاء الـ BTC الأصلي داخل الـ Vault الخاص بك» ليسا الشيء نفسه.
وهذا بالضبط هو المكان الذي تصبح فيه قيمة الـ Double Vault حقيقية. وفقًا لإعدادات الشبكة الاختبارية العامة الحالية، عامل الضمان 78%، وعامل الصحة المستهدف 1.24. تقدّر الوثائق أنه عندما يَشتعل التصفية للتو، فإن الكمية المستهدفة التي يتم أخذها تمثل نحو 62% من قيمة BTC. وبحسب المعلمات الفعلية، سيقوم Portal بوضع الـ Vault الذي يتطلب تضحية أكبر في المقدمة، بينما يتم وضع بقية BTC في الـ Vault الخاص بالحماية. يقوم إجراء التصفية بفحص القائمة من بدايتها، ويُوقف بعد أن تكون أولى الـ Vault كافية، بينما تبقى الثانية ضمن المركز.
لذلك فهي ليست «أداة تمنع التصفية» بقدر ما هي «بوابة مانعة لتسرب المياه داخل حجرة السفينة»: ستظل هناك خسارة عند وقوع المشكلة، لكننا نحاول ألا تبتلع الخسارة السفينة بأكملها. إذا انخفض السوق بسرعة كبيرة، أو كان حجم الـ Vault المُضحّى به غير كافٍ، أو تم ترتيب الترتيب بشكل خاطئ، فقد يستمر النظام في أخذ الـ Vault التالي. كما أن 62/38 ليست معادلة دائمة؛ بعد تغيّر المعلمات يجب إعادة النظر في التقسيم الذي يقدمه Portal.
أنا أفضل تسمية هذا التصميم «إدارة دقة الخسارة». الشيء الذي يجب على المقترض مراقبته حقًا ليس عامل الصحة فقط، بل أيضًا حجم vault الخاص به وترتيبها. هل ستقبل بإدارة أكثر تعقيدًا للمركز من أجل الحفاظ على vault الـ BTC الأصلي في الموضع الثاني؟
#baby $BABY
