كانت اللامركزية نقطة البداية لقطاع التمويل اللامركزي DeFi، لكنها لم تعد نموذج التشغيل الكامل لمعظم البروتوكولات اليوم، ويجب أن تتطور لغتنا مع تطور الصناعة.
هذا ليس نقاشاً ضد اللامركزية، بل هو حجة لدقة تحديد أين توجد اللامركزية فعلياً، وأين تبقى المسؤولية التشغيلية، وما هي افتراضات الثقة التي تتبع ذلك.
أقول هذا بوصفي شخصاً قضى سنوات في البناء نحو المثال المعاكس. فقد أُطلق بروتوكول Yearn Finance بدون تخصيص للفريق، وبدون مؤسسة، وبدون تعدين مسبق. كل شيء ذهب لمستخدمي البروتوكول. كان الطموح مشابهاً لطموح بيتكوين: تقليل الاعتماد على المؤسس والسماح للمجتمع بقيادة النظام للأمام. كان بروتوكول Yearn الأصلي يعمل بالكامل على السلسلة، دون أي خادم خارج السلسلة يدعم عمليته الأساسية. الشيء الوحيد الذي دفعته كان اسم النطاق.
هذا النموذج سيكون من الصعب الحفاظ عليه اليوم. المستخدمون الآن يتوقعون وجود فريق محدد يحافظ على المنتج، ويدعم العمليات، ويدير المخاطر، ويواصل خلق القيمة. كما أن الرموز تُقيَّم بشكل متزايد أولاً كتعرض اقتصادي، ثم كأداة استخدام. كانت القاعدة المبكرة من المستخدمين أصغر وأكثر غوصاً في الجانب التقني؛ أما اليوم فالقاعدة أوسع، وتطور المنتج معها.
ماذا يتطلب البروتوكول الحديث في الممارسة؟
يحتاج البروتوكول الحديث إلى واجهة أمامية موثوقة، وقنوات دعم، وبنية تحتية خارج السلسلة، وروبوتات حراسة وتصفية غالباً ما تشغّل الفرق نفسها بدلاً من وضعها بالكامل على السلسلة. كل واحدة من هذه الوظائف لها تكلفة تشغيلية حقيقية.
كما يحتاج إلى فريق يمكنه الحصول على الرواتب، والبقاء خلال فترة الاستحقاق، والبناء لأفق يتجاوز عامين. لا شيء من ذلك موجود داخل العقد الذكي. النتيجة أن العديد من البروتوكولات تشبه بشكل متزايد الشركات التشغيلية: فهي تفرض رسوماً، وتوظف فرقاً، وتحافظ على الأنظمة بمرور الوقت.
الجمود خيار تصميمي وليس عقيدة
عندما يسألني الفرق عما إذا كانت العقود يجب أن تكون جامدة أم قابلة للترقية، فإنني عادةً أوصي بقابلية الترقية للأنظمة المالية المعقدة، بشرط تصميم نموذج الحوكمة والأمان على أساس تلك الحقيقة.
يبقى الجمود قيماً للأنظمة البسيطة والمحدودة. لكن في نظام مالي يجب أن يستجيب للأسواق المتغيرة وعمليات التكامل والتهديدات، يمكن أن يصبح الجمود قيداً أيضاً.
هذا الاختيار يحمل مسؤولية كبيرة. قابلية الترقية تخلق واحدة من أكبر أسطح التهديدات في البروتوكول. مفتاح مطور واحد بصلاحية أحادية الجانب لترقية العقود يمكن أن يصبح نقطة فشل على مستوى النظام بأكمله. تدقيق العقود الذكية التقليدي لا يمكنه القضاء على هذا الخطر التشغيلي.
التدقيق ليس استراتيجية أمان
عمليات التدقيق مهمة وضرورية، لكنها مجرد طبقة واحدة فقط. الصناعة لا تزال توليها اهتماماً أكبر من أمان البنية التحتية، وإدارة المفاتيح، وقواطع الدائرة، ومراقبة التدفقات الخارجة في الوقت الفعلي.
هذه الضوابط تحتاج وقتاً لبنائها. كما أنها تقدم احتكاكاً، والفِرق مترددة بشكل مفهوم في إضافته. لكنها لا تزال ضرورية.
في Flying Tulip، نستخدم طبقات متعددة من قواطع الدائرة. عندما يطلب المستخدم سحباً، يدخل الطلب في قائمة انتظار ويصبح قابلًا للاستحقاق بعد ست ساعات.
لقد استخدمت النظام بنفسي، وفحصت Etherscan، ورأيت الأموال موجودة في عقد قاطع الدائرة بدلاً من محفظتي، وتساءلت للحظة عما حدث قبل أن أتذكر التأخير. أنا أفهم الاحتكاك من تجربة مباشرة. لكنه لا يزال يستحق العناء.
قواطع الدائرة هي ميزة وليست عيباً. الخسائر المتكررة بثمانية أرقام عبر الصناعة تواصل تعزيز هذه الحجة.
إنجاز هذا الأمر بشكل صحيح لا يتعلق فقط بوجود طبقات متعددة، بل يتعلق أيضاً بفصل السلطات.
أي شيء في نظامنا يمكنه تحريك الأموال يقع خلف قفل زمني ومحفظة متعددة التوقيعات. وأي شيء يمكنه إيقاف أو تأخير تدفق خارجي لا يمكن أن يقع خلف نفس القفل الزمني، لأن ضابط طوارئ يتطلب 72 ساعة ليس ضابط طوارئ.
هذا الفصل يجب أن يكون موجوداً على مستوى الكود الأساسي، ويجب أن يُصمم من البداية.
طرفك المقابل ليس دائماً عقداً ذكياً
لكن القضية الأكثر أهمية ليست تقنية.
الجزء الأكبر من التمويل على السلسلة لا يزال يُوصف باستخدام افتراضات الثقة الخاصة بالتمويل اللامركزي المبكر، حيث يمكن للمستخدمين التعامل مع العقد الذكي كطرفهم المقابل الرئيسي.
الخزائن المُدارة توضح هذا التمييز. غالباً ما تُفهم من خلال النموذج المفاهيمي لخزينة Yearn لعام 2020: تعرضك هو للعقد وللبروتوكولات التي يودع فيها.
في العديد من الهياكل الحديثة، التعرض أوسع. الطرف المقابل الفعلي قد يشمل مدير خزينة، أو تسهيلات ائتمانية خارج السلسلة، أو أصولاً واقعية على السلسلة غير قابلة للتصفية، أو سندات دين.
قد يكون ذلك منتجاً سليماً. النقطة المهمة هي أن يفهم المستخدمون ما يتعرضون له فعلياً.
في معظم الحالات، يعكس هذا صناعة في مرحلة انتقالية وليس نية سيئة. الفِرق التي تشكلت أصلاً حول البرمجيات تتعلم تشغيل أعمال مالية كاملة، بما يستلزمه ذلك من إفصاح وحوكمة وضوابط.
لكن المخاطر تظهر عندما لا يتطابق عرض المنتج بشكل كامل مع نموذج الثقة والطرف المقابل الفعلي.
نفس المبدأ ينطبق على الرموز. الأسواق العامة المنظمة تفرض عموماً توقعات واسعة حول الإفصاح والامتثال والحوكمة والتقارير المالية. الرموز المتداولة علناً غالباً ما تُقيَّم من قبل المشترين من خلال عدسة اقتصادية مماثلة.
إذا كنا نسعى إلى مصداقية وسيولة الأسواق العامة، فيجب أن نكون مستعدين لتلبية معيار مماثل من الشفافية.
تطبيق هذا المعيار على أنفسنا
حسابات الهامش في Flying Tulip مبنية على حقوق الملكية بدلاً من نسبة القرض إلى القيمة LTV. قد يبدو هذا تفصيلاً تقنياً، لكنه أساسي للتصميم.
نموذج LTV التقليدي لا يمكنه تحييد الدلتا بشكل كامل. إذا كان سهم staked$ETH لديه LTV بنسبة 90%، تبقى متطلبات ميزانية عمومية بنسبة 10% لا يمكن القضاء عليها بمجرد التحوط من التعرض السعري. تحتاج النظام إلى الاعتراف بـ 100 مقابل 100.
تكوينات المقاصة يمكنها تقريب هذه النتيجة، لكنها لا تستطيع القضاء تماماً على المتطلب المتبقي. حسابات حقوق الملكية يمكنها ذلك، لأنها تقيّم حقوق الملكية الفعلية للحساب، بما في ذلك الأرباح والخسائر والمراكز المعاوضة مثل staked$ETH مقابل $ETH.
هذا ما يجعل ftUSD يعمل.
نأخذ USDC و USDT المودعة كضمان، ونقترض $ETH مقابل ذلك الضمان، ونستبدل $ETH المقترض بـ staked$ETH، ونودع staked$ETH كضمان إضافي. أرجل staked$ETH و $ETH مصممة لتعويض بعضها البعض، بينما يستمر ضمان العملة المستقرة الأساسي في دعم المركز.
تحت معاييرنا النموذجية، يمكن للتصميم دعم حوالي ثمانية أضعاف كحد أقصى.
نحن نعمل حالياً عند حوالي 1.5 ضعف، عمداً أقل من القدرة النموذجية بينما النظام ما يزال جديداً والسيولة المتاحة ما تزال في طور التطور.
عند الاستخدام الأعلى، تعتمد الاقتصاديات على الفارق السعري. إذا كان staked$ETH يحقق 2.4% وتكلفة اقتراض $ETH حوالي 2.1%، يساهم كل ضعف بحوالي 0.3 نقطة مئوية من العائد قبل التكاليف الأخرى. جانب العملة المستقرة قد يضيف 3.2% إلى 4% إضافية.
لذلك يتغير العائد الناتج مع الرافعة المالية وتكاليف الاقتراض وعوائد التخزين والسيولة والتنفيذ. إنها قدرة تصميمية وليست عائداً ثابتاً أو وعداً.
أسواقنا الدائمة ليست نشطة بعد. بمجرد أن تصبح نشطة، يمكن لتجارة الكاري القياسية أن تصبح مصدراً ثانياً للعائد بدلاً من ترك النظام معتمداً على آلية واحدة.
أحد خيارات التصميم التي أفتخر بها بشكل خاص هو عملية التصفية القائمة على طلب عرض الأسعار RFQ.
بدلاً من السماح للمصفي بسداد الدين وأخذ حصة ثابتة من الضمان، يرسل النظام طلب عرض أسعار ويملأ أفضل عرض. خلال ضغوط السوق الأخيرة، عالجنا عدداً مهماً من التصفيات، وفي جميع الحالات تقريباً تم سداد الدين القابل للتصفية دولاراً مقابل دولار دون خصم على المستخدم.
قد يبدو الأمر تدريجياً، لكن هذه الخيارات التصميمية تتراكم.
لا شيء من هذا يناسب النسخة النقية من تعريف اللامركزية في عام 2020. إنه يعكس ما نحن عليه: شركة تشغل بنية تحتية مالية على السلسلة، مع الإفصاح والضوابط التي يتطلبها هذا النموذج.
رأس المال يقيّم النتائج
غالباً ما يُسألني عما إذا كانت المؤسسات ستأخذ التمويل على السلسلة بجدية، عادةً كما لو أن المشاعر أو المصطلحات ستقرر النتيجة.
في الممارسة العملية، الأسئلة الأساسية هي ما إذا كان النظام يقدم نتائج أفضل معدلة بالمخاطر، ويفعل أكثر من البديل، ويدير المخاطر بشفافية، ويكلف أقل.
هذه الأساسيات أهم من التسمية. الخطاب العام حول العملات المشفرة وفحص المستثمرين المؤسسيين غالباً ما يركزان على أشياء مختلفة جداً.
سموها تمويلاً على السلسلة. الانضباط ما يزال مالياً؛ البنية التحتية الآن على السلسلة.
الأسئلة الشائعة
س1: ما الفرق بين اللامركزية الكاملة والنموذج التشغيلي الحديث للبروتوكولات؟
ج1: اللامركزية الكاملة تعني أن البروتوكول يعمل دون فريق مركزي أو خوادم خارجية، مثل الإصدار الأول من Yearn. أما النموذج الحديث فيتضمن فريقاً معروفاً يدير المنتج ويدعم العمليات ويتحمل مسؤولية المخاطر، مع استخدام العقود الذكية القابلة للترقية وأنظمة أمان متعددة الطبقات مثل قواطع الدائرة والمحافظ متعددة التوقيعات.
س2: لماذا تعتبر قواطع الدائرة ضرورية في الأنظمة المالية على السلسلة؟
ج2: قواطع الدائرة هي آليات أمان تسمح بتأخير أو إيقاف التدفقات الخارجة مؤقتاً، مثل وضع طلبات السحب في قائمة انتظار لست ساعات قبل التنفيذ. هذا يمنح الفريق وقتاً للاستجابة للهجمات أو الأعطال، ويحمي أموال المستخدمين من الخسائر الكبيرة، خاصة في ظل تكرار الخسائر المالية الضخمة في الصناعة.
س3: هل يجب أن تكون عقود البروتوكولات جامدة أم قابلة للترقية؟
ج3: ذلك يعتمد على نوع النظام. للأنظمة البسيطة والمحدودة، الجمود مفيد. أما للأنظمة المالية المعقدة التي يجب أن تتكيف مع الأسواق المتغيرة، فقابلية الترقية أفضل بشرط تصميم نموذج حوكمة وأمان قوي، بما في ذلك فصل صلاحيات الطوارئ عن الصلاحيات العادية واستخدام محافظ متعددة التوقيعات وقوائم زمنية.
