ذهبت للبحث عن وثائق معمارية TermMax V2 متوقعًا العثور على مواصفات تحسين استهلاك الغاز موضحة بشكل واضح. لكن ما وجدته كان أرقّ مما كنت أتمنى.
يعمل البروتوكول على تسوية دخل ثابت عبر السلسلة من خلال بنية هجينة تجمع بين دفتر أوامر وAMM. تأتي كفاءة الغاز من الطريقة التي يتم بها تجميع التسوية عند الاستحقاق بدلًا من معالجتها بشكل مستمر. هذا الاختيار التصميمي منطقي. أما التسوية المستمرة فتحرق الغاز باستمرار.
التسوية المجمّعة في تاريخ محدد أرخص وأكثر قابلية للتنبؤ. ترددي تحديدًا حول تسمية V2. غالبًا ما تعني أرقام الإصدارات في التمويل اللامركزي أقل مما توحي به.
أسئلة مثل: ماذا تغيّر من V1؟ ما الذي تم إصلاحه؟ وما مدى تغطية التدقيق للمعمارية الجديدة؟ لا تجيب عنها الوثائق بشكل واضح. تبدو منطقية التسوية سليمة. لكن الشفافية في الترقيم تحتاج إلى عمل. #termmax @TermMax
لقد شاهدت دي فاى يحاول بناء هياكل آجال (term structures) لسنوات. أغلب المحاولات تنهار لأنها لا تستطيع حل مشكلة السيولة.
دفاتر الأوامر تحتاج إلى عمق على الجانبين. تتطلب نماذج الـ AMM رأس مالًا يكون متواجدًا بشكل خامد داخل المجمعات. ولا يعمل أي منهما وحده بشكل نظيف للإقراض بسعر ثابت. يجمع TermMax بين الاثنين.
يتولى دفتر الأوامر اكتشاف السعر بينما يتفاوض المقرضون والمقترضون على المعدلات مباشرة. توفر طبقة الـ AMM ضمانًا سيوليًا عندما يصبح أحد جانبي دفتر الأوامر رقيقًا.
اعتقدت أن هذا الدمج سيخلق تعقيدًا ينكسر تحت الضغط. لكن عند النظر إلى كيفية تفاعل الآليات، يبدو الأمر أكثر أناقة مما توقعت.
السؤال الحقيقي هو ما إذا كانت معلمات الـ AMM تُضبط بشكل صحيح عندما تتغير ظروف السوق. وهذا قرار حَوْكمي.
وقرارات الحوكمة في دي فاى لا تحدث دائمًا بسرعة كافية عندما تكون هناك حاجة لذلك. #termmax @TermMax
لم أفهم تمامًا معنى تاريخ الاستحقاق في إقراض التمويل اللامركزي (DeFi) حتى اضطررت للتفكير في ما يحدث عند انتهاءه. في التمويل التقليدي الأمر واضح؛ إذ يستحق السند ويستعيد المرء رأس ماله.
يعمل TermMax بشكل مشابه على الورق. تقرض بمعدل ثابت، وتستحق الصفقة في تاريخ محدد، وتتلقى القيمة الاسمية. السؤال الذي ظللت أطرحه هو: ماذا يحدث إذا انخفض الضمان الخاص بالمقترض بشكل حاد قبل الاستحقاق مباشرة؟
تتعامل معظم بروتوكولات الإقراض مع ذلك عبر التصفية (liquidation). يطبق TermMax المنطق نفسه على المراكز غير المغطاة بشكل كافٍ؛ إذ يتم تصفيتها قبل أن يحين الموعد.
ما لم أرَ اختبارًا علنيًا هو كيف يتصرف البروتوكول عندما تقترب عدة مراكز كبيرة من الاستحقاق في الوقت نفسه في سوق هابط. هذا السيناريو تحديدًا هو ما يحدد ما إذا كانت آليات المعدل الثابت ستصمد أم تنكسر. #termmax @TermMax
قضيت وقتًا أطول مما توقعت في محاولة فهم ما الذي تفعله FT وXT وGT فعليًا في TermMax. ثلاثة توكنات داخل بروتوكول إقراض واحد تبدو تعقيدًا زائدًا إلى أن تتضح المنطق.
FT هو التوكن الثابت Fixed Token، ويمثل رأس مالك بالإضافة إلى العائد المقيّد، ويمكن استبداله عند الاستحقاق بقيمة اسمية.
XT هو توكن العائد الزائد Excess Yield Token، يلتقط أي عائد يزيد عن السعر الثابت، وهو ما يذهب إلى مزودي السيولة الذين يتحملون مخاطر تغيّر السعر.
GT هو توكن الحوكمة قرارات البروتوكول، ومعلمات الرسوم، والاتجاه. التقسيم منطقي على الورق. يحصل المقترضون ذوو الفائدة الثابتة على اليقين.
يحصل مزودو السيولة على الجانب الإيجابي إذا تحركت الأسعار لصالحهم. ما أريد فهمه بشكل أفضل هو ماذا يحدث لحاملي XT عندما تبقى الأسعار ثابتة لفترات طويلة. هذه الحالة لا يتم الحديث عنها بما يكفي. #termmax @TermMax
لقد أمضيت وقتًا كافيًا في مجال التمويل اللامركزي (DeFi) لأعرف أن "سعر الفائدة الثابت" هو واحد من تلك الوعود التي تبدو بسيطة حتى تحاول العثور على بروتوكول يقدّمها فعليًا بشكل نظيف وواضح.
غالبًا ما يكون الإقراض في DeFi بسعر متغير. تتأرجح الفوائد مع نسبة الاستخدام (utilization)، إما أن تراقبها باستمرار أو تنصدم عندما تتغير. يتبع TermMax نهجًا مختلفًا. اقتراض وإقراض بسعر فائدة ثابت على السلسلة (on-chain)، مع تداول الخيارات مدمج داخل نفس البروتوكول.
هذا الجمع غير مألوف. لم أرَ الكثير من المشاريع تحاول الأمرين معًا دون أن يشعر أحدهما وكأنه فكرة لاحقة. ما إذا كان TermMax ينجح في ذلك يعتمد على مدى صمود الآليات تحت ضغط الأسواق الحقيقي. الفكرة بحد ذاتها قوية.
تتجلى أهمية الأسعار الثابتة أكثر عندما تتحرك الأسواق بسرعة. وهذا بالضبط الوقت الذي تُظهر فيه معظم البروتوكولات نقاط ضعفها. #termmax @TermMax
إن دعم IBC على سلسلة تركز على الأمان هو واحدٌ من تلك الإضافات التي تتطلب التفكير بعناية في ما الذي تكسبه مقابل ما الذي تفتحه على مصراعيه.
إن التواصل بين السلاسل (Inter-Blockchain Communication) هو بنية تحتية ناضجة. لقد كانت منظومة كوزموس (Cosmos) تعمل بتقنية IBC في الإنتاج لفترة طويلة بما يكفي لتكوين سجلّ حافل وذي معنى. إن إضافة IBC أصليًا إلى سلسلة جنيسيس الخاصة ببابلون يعني أن BSNs المبنية ضمن منظومة كوزموس يمكنها الاتصال بطبقة أمان بابلون دون حلول جسور مخصّصة.
إن ذلك يمثل تحسنًا حقيقيًا في قابلية التشغيل البيني يوسّع السوق القابل للاستهداف لغايات الإنهاء النهائي لتأمين البيتكوين.
ما يفعله IBC أيضًا هو إضافة نقاط اتصال. كل قناة هي سطحٌ محتمل للفشل. تصبح افتراضات أمن كل سلسلة متصلة ذات صلة جزئيًا بأمن بابلون.
يتجه التشغيل البيني وعزل الأمان في اتجاهين متعاكسين. بابلون تختار قابلية التشغيل البيني. ربما يكون ذلك هو الخيار الصحيح لتبني التقنية. ومن الجدير معرفة ما الذي يأتي مع ذلك. #baby $BABY @BabylonLabs_io
فترات فكّ الارتباط موجودة لسبب. إنها الآلية التي تمنع المشاركين (المُراهنين) من الخروج قبل اكتشاف حدث الحظر/الـslashing ومعالجته. إن إزالة التأخير تعني إزالة المسؤولية.
جذبني ادّعاء بايبلون بشأن فكّ الارتباط السريع لسببٍ محدد تمامًا. إذا كان بإمكان مُراهنِي البيتكوين الخروج بسرعة، فيجب أن تكون آلية الـslashing التي تجعل نموذج الأمان بأكمله يعمل سريعة بما يكفي لالتقاط سوء السلوك قبل أن يُغلق نافذة الخروج.
هذه قيود هندسية لها تبعات حقيقية. إمّا أن اكتشاف الـslashing سريع بما يكفي حقًا ليجعل فكّ الارتباط السريع آمنًا، أو أن فكّ الارتباط السريع يوفّر مسار هروب يمكن للجهات الفاعلة المتقدمة استغلاله خلال تلك اللحظات بالذات التي تكون فيها المساءلة أهم ما تكون.
تُعد كفاءة رأس المال فائدةً حقيقية تستحق التحسين. كما أنها تُشكّل سطح هجومًا حقيقيًا يستحق الفحص.
أود الاطلاع على أرقام زمن التأخر في الكشف قبل أن أشعر بالاطمئنان تجاه سرعة فكّ الارتباط. #baby $BABY @BabylonLabs_io
تُعد عبارة «Bitcoin Secured Networks» جملة تؤدي الكثير من العمل في تسويق بابل، وأردت تفكيكها قبل قبولها.
تأتي أمان بيتكوين من إثبات العمل المتراكم، وهو أغلى سطح هجوم في مجال العملات المشفّرة. ما يقدّمه بابيل إلى BSNs ليس ذلك. بل هو ضمان الحتمية الذي ينشأ عن توثيق نقاط تفتيش PoS بالطوابع الزمنية على سلسلة بيتكوين، مدعومًا بضمانات (collateral) من مُوقعي بيتكوين يمكن توقيفها/اقتطاعها عند حدوث سلوكٍ خاطئ.
هذا أمان ذو معنى. إنه ليس الشيء نفسه كأمان إثبات العمل الخاص ببيتكوين، والتمييز مهم عندما تقيم ما الذي يرثه BSN فعلًا مقابل ما يستعيره بالاسم فقط.
سلسلة Genesis تنسّق ذلك. إنها الطبقة التي تجعل الأمان قابلًا للنقل.
ما إذا كان الأمان القابل للنقل مكافئًا للأمان الأصلي هو السؤال الذي ينبغي على متبنّي BSN الإجابة عنه قبل البناء على هذا الافتراض. #baby $BABY @BabylonLabs_io
محاذاة الحوافز هي إحدى تلك العبارات التي تبدو مكتملة حتى تسأل: محاذاة نحو ماذا بالضبط، وتحت أي شروط.
يربط توكن BABY جهات الإسناد والـمُراهنين بالنتيجة الاقتصادية نفسها. تكسب الجهات BABY مقابل السلوك الصادق. يُفوّض المُراهنون BABY إلى الجهات التي يثقون بها. ويعاقب الـSlashing على سوء السلوك عبر قطع كلٍّ من الجهة المزوّدة والمُراهنين المُفوِّضين.
إن وجود هذا العجز المشترك هو آلية المحاذاة. عندما تكون العقوبة متبادلة، يصبح الدافع لمراقبة جهة الإسناد دافعًا ماليًا لا مجرد فكرة فلسفية.
تتبع منطق التصميم هذا في الظروف العادية. ما أدرسه هو ظروف الضغط. عند حدوث حدث كبير للـSlashing يهدد بخسائر كبيرة، هل يندفع المُراهنون إلى إلغاء التفويض قبل أن تقع عملية الـslash.
إذا تمكنوا من ذلك، فإن المحاذاة تنكسر بالضبط عندما يكون الأمر في أمس الحاجة.
لقد استخدمت wBTC. كما قرأت اتفاقيات الحفظ لدى BitGo بعناية كافية لأعرف بالضبط مقدار الثقة التي تمنحها عند امتلاك أصلٍ مُعبّأ يدّعي أنه يمثّل البيتكوين.
إن الغلاف لا يكون جيدًا إلا بقدر ما يكون عليه الحارس الذي يحتفظ بالأصل الأساسي. عندما يواجه الحارس مشكلات، يعاني الغلاف من مشكلات أيضًا. هذا ليس مجرد افتراض. لقد حدث.
لا تتطلب بنية Babylon التغليف لأن البيتكوين لا يتحرك أبدًا. توجد آليات الإيداع/الاستيكينغ داخل سكريبت البيتكوين على سلسلة البيتكوين نفسها. لا جسر. لا حارس. لا تمثيل للبيتكوين على نحو يتحكم فيه طرف آخر.
هذا يقدّم ملف مخاطر مختلفًا جوهريًا عن أي شيء تقدمه wBTC.
ما كنت أودّ أن يتم اختباره تحت ضغط هو تعقيد السكريبت. سكريبت بيتكوين محدود عمدًا. إن بناء شروط إلغاء/حجز (slashing) معقدة ضمن تلك القيود يمثل تحديًا هندسيًا تكون فيه حالات الحافة (edge cases) ذات أهمية كبيرة للغاية.
الفكرة تُزيل مخاطر الحارس. أما التنفيذ فيُدخل مخاطر السكريبت. #baby $BABY @BabylonLabs_io
تواجه سلاسل البلوكشين الناشئة مشكلة في تمهيد الأمان (security bootstrapping) لا يُتحدث عنها بما يكفي.
يحتاج شريط PoS جديد إلى مُحققين (validators). يحتاج المُحققون إلى حوافز. تتطلب الحوافز وجود توكن ذي قيمة. تتطلب قيمة التوكن ثقة المستخدمين. تتطلب ثقة المستخدمين الأمان. يتطلب الأمان وجود مُحققين. الدائرة لا تفك نفسها.
يقدم نموذج أمان بيبيليون (Babylon) القائم على الاقتصاديات طريقة للدخول إلى هذا الأمر. إذ يمنح مُسَجِّلو بيتكوين (Bitcoin stakers) الذين يقدمون ضمانات نهائية (finality guarantees) لسلسلة ناشئة مصداقية لا يمكن للسلسلة أن تخلقها بشكل مستقل. ترث السلسلة سمعة أمان بيتكوين دون أن تمسك بيتكوين مباشرة.
وهذا يُعد بداية ذات معنى لسلاسل كانت ستقضي سنوات في ترسيخ ثقة المُحققين بشكل عضوي بخلاف ذلك.
ما أريد فهمه هو هيكل التكلفة. لا يعمل مقدمو النهائيّة (finality providers) في بيبيليون مجانًا. إن العائد الذي يتطلبونه لتأمين سلسلة ناشئة يضيف عبئًا اقتصاديًا مستمرًا يحتاج أن تُحسن السلاسل الصغيرة نمذجته بعناية قبل الالتزام.
يبدو أن إلغاء أمناء الحفظ من طرف ثالث بمثابة مكسب صِرف، حتى تسأل عمّا يستبدلهم.
توجد أمناء الحفظ لأن شخصًا ما يحتاج إلى الاحتفاظ بالأصل، وفرض القواعد، وتحمل المسؤولية عند حدوث خطأ ما. نموذج بابيلون يستبدل أمين الحفظ بشروط تقطيع تشفيري (cryptographic slashing) مُشفّرة داخل برنامج بيتكوين (Bitcoin script). يبقى بيتكوين الخاص بك في محفظتك. أما سوء السلوك فيتم معاقبته عبر آليات البروتوكول بدلًا من فريق امتثال تابع لشركة.
هذا تحول حقيقي في نموذج الثقة. لستُ أقلّل من قيمته.
ما أبحث عنه هو المساءلة عندما تفشل الآلية التشفيرية نفسها أو عندما تُنتج نتيجة غير مقصودة. مع أمين الحفظ لديك سبل انتصاف قانونية. مع العقد الذكي لديك الكود.
الكود أكثر قابلية للتنبؤ. كما أنه أقل تساهلًا.
إن معرفة أيّهما تريده فعليًا تتطلب فهمًا دقيقًا لما يمكن أن يحدث خطأ #baby $BABY @BabylonLabs_io
عمليات الإطلاق على ثلاث مراحل تمنح البروتوكولات الطموحة وقتًا كي تفكّ الأجزاء الصعبة.
لا أقول ذلك على سبيل التقليل. غالبًا ما تكون الإطلاقات المراحلية هي النهج الصحيح فعلًا للبنية التحتية التي تحتاج إلى إثبات الأمن في كل مرحلة قبل توسيع النطاق. تنتقل مراحل بابيلون من شبكة التشغيل الرئيسية للـ Bitcoin staking، إلى تكاملات سلسلة PoS، إلى اللامركزية الكاملة لمزوّد التمهيد النهائي. التسلسل منطقي تقنيًا.
ما أبحث عنه في أي خريطة طريق مراحلية هو شروط الانتقال. ما المعايير المحددة التي تُفعّل الانتقال من المرحلة الأولى إلى المرحلة الثانية؟ هل هو تاريخ، أم مقياس، أم تصويت حوكمي، أم قرار تقديري من الفريق.
القرارات التقديرية التي تُرتدى ثوب خرائط الطريق شائعة في عالم العملات المشفّرة. المحفزات القابلة للقياس أقل شيوعًا وأكثر موثوقية.
أنا أبحث عن المحفزات. لم أجدها محددة بشكل دقيق بما يكفي بعد. #baby $BABY @BabylonLabs_io
بدأت بسؤال بسيط عندما صادفت نموذج الستيكينغ المزدوج في Babylon. لماذا توكنان بينما توكن واحد عادةً يكفي ليُسبب مشاكل.
كانت الإجابة أكثر تدقيقًا مما توقعت. BABY يتولى الحوكمة وأمن الشبكة لسلسلة Babylon نفسها. BTC يتولى ضمانات الإنهاء الممنوحة لسلاسل PoS الخارجية.
إنهما يؤديان وظائف مختلفة في طبقات مختلفة من النظام. دمجهما في توكن واحد يعني إما إجبار حاملي بيتكوين على القيام بالحوكمة أو جعل حاملي توكن الحوكمة مسؤولين عن ضمانات أمان بمستوى بيتكوين. ولا يجدي أي من الخيارين.
منطق التصميم سليم. ما أراقبه بعناية مع الأنظمة ذات التوكنين هو ما إذا كانت العلاقة الاقتصادية بين التوكنين تظل مستقرة تحت الضغط.
عندما يتحرك أحد التوكنين بشكل حاد، ماذا يحدث للحوافز في التوكن الآخر. هذا التفاعل هو المكان الذي تكشف فيه أنظمة التوكنين المزدوجة غالبًا عن هشاشتها. #baby $BABY @BabylonLabs_io
لقد تخليت عن حيازة الأصول لبروتوكولات الاستيك قبل ذلك، وتعلمت في كل مرة شيئًا جديدًا حول الفجوة بين ما تعد به الوثائق وبين ما يتحكم به فعليًا العقد الذكي.
إن نموذج الاستيك بالاحتفاظ الذاتي لدى بايبليون هو الادعاء الذي فحصته بعناية أكبر. لا يغادر البيتكوين محفظتك أبدًا. ليست أنت من يقوم بتغليفها أو ربطها أو إيداعها في عقد بروتوكولي. تستخدم آليات الاستيك قدرات سكربت البيتكوين الأصلية لإنشاء شروط للـ slashing تفرض سلوكًا صادقًا دون الحاجة إلى تحويل الحيازة.
هذا نموذج مختلف فعلاً عن أغلب أنظمة الاستيك التي رأيتها. تأتي ضمانة الأمان من العقاب التشفيري وليس من ضمانات يُحتجز جزء منها لدى طرف ثالث.
ما أريد فهمه هو آلية الـ slashing تحديدًا. من الذي يقوم بتشغيلها. وفي أي ظروف. وما إذا كان قد تم اختبارها من قبل ضد حدث سوء سلوك حقيقي. #baby $BABY @BabylonLabs_io
لقد رأيت ما يكفي من المشاريع التي تدّعي أنها ستُحدِث ثورة في أمن البلوكشين لدرجة أنني سأتعامل مع الكلمة كإشارة لقراءةٍ أكثر دقة بدلًا من اعتبارها سببًا للحماس.
طرح بايبيليون هو أن أمان إثبات العمل في بيتكوين يمكن تمديده إلى سلاسل إثبات الحصة دون أن تكون تلك السلاسل تمسك أي بيتكوين بشكل مباشر. إن توقيت نقاط التحقق في PoS على سلسلة توقيت بيتكوين يُنشئ ضمانًا نهائيًا يمنع مجموعة المدققين الخاصة بسلسلة PoS نفسها من عكس المعاملة من طرفٍ واحد.
هذه خاصية أمنية حقيقية. إن هجمات المدى الطويل على سلاسل PoS هي ثغرة فعلية، ووسم بيتكوين بالوقت يعالجها بطريقة لا تتطلب الثقة بجسر أو متعددة التواقيع.
سؤالي هو مسألة التبني. لا يؤمّن أي شيءٌ طبقة أمان لا يدمجها أحد.
الهيكلية سليمة. لكن التأثيرات الشبكية لا تزال بحاجة إلى كسبها. #baby $BABY @BabylonLabs_io