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