أجد دائمًا أن البروتوكولات تصبح أكثر منطقية بمجرد أن أستخدمها فعليًا، لذلك قضيت بعض الوقت في استكشاف شبكة بابيلون العامة التجريبية (Public Testnet). العنوان يقول "اقتراض بتكوين أصلي وبدون ثقة"، لكن رؤية التدفق بنفسك تشرح تلك الفكرة بشكل أفضل بكثير من أي إعلان يمكن أن يفعله.
ما لفت انتباهي لم يكن فقط أن الاقتراض أصبح ممكنًا الآن. بل كان مدى قلة ما يطلبه هذا الاستخدام منك التفكير في تغيير بتكوينك قبل استخدامه كضمان. تبدو العملية مصممة للحفاظ على BTC على طبيعته الأصلية مع إتاحة لك استكشاف الاقتراض من خلال تكامل Aave v4، وهو نقطة انطلاق مختلفة عمّا اعتاد عليه كثير من حاملي البيتكوين.
لا تزال شبكة تجريبية عامة، وهذا بالضبط سبب اعتقادي أنها تستحق التجربة. عادةً ما تكشف المنتجات عن نقاط قوتها—والأسئلة التي ما زالت تحتاج إلى الإجابة عنها—عندما يبدأ أشخاص حقيقيون في التفاعل معها ومشاركة الملاحظات.
بعد تجربتك للشبكة العامة التجريبية، ما الذي بدا أكثر بروزًا لك: تجربة الاقتراض نفسها، أم فكرة استخدام BTC الأصلي دون تغيير ما هو عليه من الأساس؟
ما أريد رؤيته هو **التبنّي الحقيقي**. كم تم إيداعه فعليًا من البيتكوين؟ كم عدد المستخدمين النشطين؟ كم يجري الاقتراض؟ وكم السيولة التي تبقى داخل النظام البيئي؟
يقول غوماينينغ إنه قد يجلب **حتى 1,000 BTC**. وتخطط إيجيس لإطلاق الإقراض بسعر فائدة ثابت في الربع الرابع. وتقول كيستون إن الشراكة تتوسع. هذه إعلانات واعدة، لكن أين النتائج؟
لقد أبلغت بابل عن أكثر من **10 مليارات دولار** من بيتكوين محلي مُفعّل، بينما لا تزال أنشطة ديفاي على بابل جينيسيس أصغر بكثير. المقاييس مختلفة، لكنها تبرز سؤالًا مهمًا: **هل يتحول الأمان إلى استخدام حقيقي داخل النظام البيئي؟**
يسعدني أن أرى بابل تنشر لوحة معلومات للشراكات تُظهر:
لقد وجدت نفسي أقيس @BabylonCapital من خزائن البيتكوين غير القائمة على الثقة (Trustless) بتوقعات خاطئة في البداية. كنت أستمر في التساؤل عن مدى سرعة سير العملية، بينما قد يكون السؤال الأكثر إثارة للاهتمام هو: لماذا لا تحاول أن تتحرك بشكل أسرع.
عند قراءة المستندات، يبدو أن البروتوكول يقبل عن قصد الانتظار عندما تكون عملية التحقق مهمة. وهذا يعبّر عن عقلية مختلفة عن مطاردة أفضل تجربة سلسة ممكنة. التأخير لا يُعرض كشيء يُراد إخفاؤه عن المستخدمين. بل هو جزء من تقليل افتراضات الثقة المتعلقة بحركة القيمة.
أنا أحترم هذا القرار فعلًا، لأن الأسرع ليس تلقائيًا أكثر أمانًا. ومع ذلك، هذا يعني أيضًا أن الأشخاص الذين اعتادوا التفاعلات الفورية قد يرون احتكاكًا قبل أن يروا سبب ذلك.
أحيانًا يخبِرك بروتوكول ما الذي يقدّره عبر ما يرفض أن يُحسّن.
هل قبول تسوية أبطأ هو التنازل الصحيح مقابل ضمانات أمن أقوى، أم أن توقعات المستخدمين في النهاية ستدفع التصاميم نحو مزيد من الراحة بدلًا من ذلك؟ 🤔
واحدة من اختيارات التصميم في خزائن بيتكوين غير القابلة للثقة في بابل فاجأتني أكثر مما توقعت. لا يتم إنشاء الخزنة كضمان عالمي يمكنه التحرك فورًا بين تطبيقات مختلفة. بل إنها مرتبطة بالتطبيق الذي تم إنشاؤها لأجله، وكنت أتساءل باستمرار لماذا نقبل هذا القيد.
كلما فكرت أكثر في الأمر، بدا لي الأمر وكأنه استراتيجية عزل. إذا كان يتعين على كل خزنة أن تعمل في كل مكان افتراضيًا، فستصبح الروابط بين البروتوكولات بطبيعتها أكثر تعقيدًا. إن إبقاء كل خزنة ضمن نطاق تكامل محدد يشبه رسم حدود قبل أن تتاح للتعقيد فرصة الانتشار.
يعجبني أنها تُجبر على افتراضات أوضح حول مكان استخدام الضمان فعليًا. لكن هذا يثير أيضًا سؤالًا عمليًا لأن المستخدمين غالبًا ما يتوقعون أن تتحرك الأصول بحرية بمجرد إيداعها.
أحيانًا لا تكون المرونة هي أقوى ميزة. أحيانًا تكون الحدود المتوقعة هي الأهم.
هل يؤدي تقييد الخزنة بتطبيق واحد إلى احتكاك غير ضروري، أم أن تقليل المخاطر المترابطة يستحق التضحية بهذه القابلية للنقل؟
كنت أظن أن إنشاء خزنة بيتكوين سيجعل ذلك الـ BTC جاهزًا فورًا للإقراض مقابلها. لكن المستندات كانت تثبتني بشكلٍ خاطئ.
أطروحتي بسيطة: يجب ألا يتحول الحفظ (custody) والضمان (collateral) إلى الحالة نفسها.
يفصل @BabylonLabs_io بين إنشاء خزنة بيتكوين بدون ثقة (Trustless) وتفعيلها كضمان. في البداية بدا الأمر خطوة إضافية. ثم أدركت أن البروتوكول يطرح سؤالين مختلفين. أولًا: هل تم قفل $BTC بأمان وفقًا لقواعد الخزنة؟ عندها فقط يمكن أن تصبح مؤهلة للاقتراض. هذا حدٌّ صارم بشكلٍ مدهش، لكنه أيضًا يجعل إذن الاقتراض أسهل في الفهم.
أقل ملاءمة، بالتأكيد. لكن خلط حماية الأصول مع الموافقة على الإقراض سيُشوش على مكان انتهاء مسؤولية وبدء مسؤولية أخرى.
هل يكون اقتراض بيتكوين بشكلٍ أوضح مبنيًا على تقليل الخطوات، أم عبر فصل كل حالة حرجة قبل أن تصبح الأموال قابلة للاستخدام؟ 🤔
الجزء الذي قللتُ من تقديره لم يكن قفل بيتكوين. بل كان ما رفض البروتوكول افتراضه بعد ذلك.
في البداية، ظننتُ أنه بمجرد دخول $BTC إلى صندوق بيتكوين غير قابل للثقة، فإن الاقتراض كان ينتظر تقريبًا مجرد ضغطة زر لاحقة. لكن الوثائق تحكي قصة مختلفة.
إن قفل بيتكوين يثبت أن البروتوكول قد أمّن الأصل ضمن قواعد الحيازة الخاصة به. ولا يثبت تلقائيًا أن جهة الإقراض ينبغي لها أن تثق ببيتكوينٍ ما كضمان. هذان قراران منفصلان، وبابلون намеренно تحافظ على هذا الفصل.
كلما تابعتُ التدفق أكثر، ازداد هذا الحدّ منطقية. الحيازة تجيب عمّا إذا كانت عملة البيتكوين محمية. الضمان يجيب عمّا إذا كان بروتوكول الإقراض مستعدًا لتحمّل مخاطرة مالية مقابلها. لا يضمن أحدهما تلقائيًا الآخر، حتى وإن كان كلاهما يتضمن نفس البيتكوين.
قد تبدو هذه فروقًا دقيقة، لكنها تغيّر الطريقة التي أنظر بها إلى عملية الاقتراض بالكامل. البروتوكول لا يبطّئ الأمور لمجرد ذلك. بل يرفض طمس مسؤوليتين تحملان عواقب شديدة الاختلاف.
هل ينبغي لأي نظام اقتراض أن يعامل بيتكوينٍ مقفلاً كضمانٍ مُعتبرٍ تلقائيًا على أنه محل ثقة؟ أم أن فصل هذين القرارين بالضبط هو ما يجعل التصميم أقوى؟
كان هناك شيء يظل يزعجني أثناء قراءتي لتدفق "الخزنة البيتكوين من دون ثقة". افترضت أن اللحظة المهمة هي إنشاء الخزنة.
لكن الأمر ليس كذلك.
إن إنشاء خزنة يثبت أن بيتكوينك قد تم قفلها تحت قواعد الوصاية الخاصة بالبروتوكول. هذه خطوة مهمة، لكنها لا تجعل تلك العملات تلقائيًا قابلة للاستخدام داخل نظام الاقتراض.
لا يزال يتعين على البروتوكول أن يَتعرف على تلك الخزنة كضمان نشط قبل أن يمكن أن يحدث أي شيء فعليًا.
هذا الفصل يبدو متعمدًا.
إحدى الحالتين تجيب: "هل تم قفل البيتكوين بأمان؟" والأخرى تجيب: "هل يمكن لبروتوكول الإقراض الاعتماد عليها؟" تبدوان متشابهتين حتى تلاحظ أنهما تعالجان مشكلتين مختلفتين تمامًا.
أنا أقدر هذا الحد الفاصل. فهو يمنع التعامل مع الوصاية والضمان وكأنهما الشيء نفسه.
لكن هذا يعني أيضًا أن رؤية إنشاء خزنة بنجاح لا تخبرك بأن تدفق الاقتراض جاهز للبدء بالفعل. القفل هو جانب واحد فقط من عملية الانتقال. لا يزال يتعين على البروتوكول نقل بيتكوينك إلى حالة يمكنها المشاركة كضمان.
إنها فروق بسيطة، لكنها على الأرجح واحدة من أسهل الأشياء التي يمكن تفويتها عند النظر إلى التدفق لأول مرة.
لذا عندما يقول الناس إن بيتكوينهم بالفعل "داخل الخزنة"، هل يتحدثون عن بيتكوين مقفلة بالفعل... أم عن ضمان بدأ البروتوكول في استخدامه فعليًا؟
كنت أعود باستمرار إلى سؤال واحد بعد قراءة المزيد عن صناديق البيتكوين غير القابلة للثقة (TBV). لماذا قبلنا أن استخدام البيتكوين عادةً يعني التنازل عن جزء ما من نموذج ملكيته الأصلي؟
يبدو أن افتراض TBV يتحدى ذلك. الجزء المثير للاهتمام ليس فقط أن $BTC الأصلي يمكن أن يصبح ضمانًا. الأهم هو أن الملكية والمنفعة لم يعودا يشعران كاختيارين متعارضين. يمكن للبيتكوين أن يبقى أصليًا بينما يظل يؤدي غرضًا يتجاوز مجرد الجلوس في محفظة، وهذا يغيّر طريقة تفكيري بشأن الضمانات كليًا.
يُقاس معظم الناس الضمان بما يتيحه. وفي الآونة الأخيرة كنت أتساءل إن كان سؤالًا أفضل هو: ماذا يطلب منك أن تتخلى عنه أولًا. إذا كان استخدام أصل ما يعني تغيير شكله أو تسليم السيطرة إلى جهة أخرى، فذلك جزء من التكلفة بالفعل حتى قبل وجود أي قرض.
أعجبني هذا الاتجاه لأنه يحافظ على توجيه النقاش إلى البيتكوين نفسه بدلًا من ابتكار نسخة أخرى منه. ومع ذلك، فإن فصل الملكية عن المنفعة ربما يكون أصعب في الهندسة مما يبدو للوهلة الأولى، وهنا سأولي أكبر اهتمام مع تطور التصميم.
ربما لا تكون #bitcoin ضمانات المستقبل متعلقة بجعل $BTC يتحرك أكثر. ربما يتعلق الأمر بجعل انتقال الملكية أقل، بينما تتوسع أوجه المنفعة.
قضيت وقتًا في القراءة عن خزائن بيتكوين غير قابلة للثقة (TBV)، وكان هناك شيء يزعجني باستمرار. معظم المحادثات حول الاقتراض تبدأ بأسعار الفائدة، لكنني أعتقد أن السؤال الأكثر أهمية يأتي في وقت أبكر بكثير. ماذا يجب أن يحدث لبيتكوينك قبل أن يبدأ الاقتراض أصلًا؟
هنا تحديدًا تبدو TBV مختلفة. الفكرة ليست فقط أن $BTC الأصلي يمكنه أن يدعم قرضًا. بل إن الضمان لا يحتاج أولًا إلى أن يتحول إلى شيء آخر عبر الالتفاف (wrapping) أو عبر خطوة موثوقة أخرى. تظل البيتكوين أصلية بينما تبقى قابلة للاستخدام كضمان، وهذا يغيّر بهدوء ما الذي أقيمه. أتوقف عن السؤال: "ماذا يمكنني أن أقترض؟" وأبدأ بالسؤال: "ما الافتراضات التي كان عليّ قبولها قبل أن يبدأ الاقتراض؟"
أعجبني هذا التحول لأنه يضع نموذج الثقة في المقدمة قبل المنتج المالي. ومع ذلك، فهذا يعني أيضًا أن جودة عملية التحقق تصبح هي الشيء الأهم الذي يجب مراقبته. وربما هنا سيتم كسب الثقة في النهاية أو خسارتها، وليس في مسار الاقتراض نفسه.
ربما كنا نقيس الاقتراض المدعوم بالبيتكوين من نقطة انطلاق خاطئة طوال الوقت. هل الابتكار الحقيقي هو اقتراضٌ أفضل، أم أنه اقتراضٌ يتطلب افتراضات ثقة أقل قبل أن يبدأ الاقتراض أصلاً.