Aave V4：من سوق منقسم إلى سيولة نمطية

كتابة: تييا، تيكهاب نيوز

في مجال الإقراض اللامركزي، لطالما كانت Aave علامة فارقة في الابتكار ومعيارًا صناعيًا. ومع تزايد حجم المستخدمين وتنوع الأصول، ظهرت تدريجيًا مشكلات في توزيع السيولة، وإدارة المخاطر، وآليات التسوية في الإصدار V3 من Aave. لمواجهة هذه التحديات، تم إجراء ترقية منهجية لـ V4: حيث تم إعادة تصميم تنظيم السيولة ليصبح بنية موحدة من مركز (Hub) ووحدات فرعية (Spoke) نمطية، مما يتيح مشاركة السيولة عبر أصول واستراتيجيات متعددة مع الحفاظ على عزل المخاطر؛ كما تم ترقية نظام الحسابات ليصبح بنموذج حصص من نوع ERC-4626، مما يجعل حالة السيولة الإجمالية واضحة وقابلة للتحكم؛ وأُعيد توجيه آلية التسوية من نمط نسبة ثابتة إلى منطق ديناميكي يعتمد على عامل الصحة (Health Factor) ووضعية التسوية الضرورية الدنيا. بشكل عام، فإن V4 ليست مجرد تحسينات على المعلمات، بل هي تطور منسق للهياكل والآليات، يرفع Aave من بروتوكول إقراض متعدد الأسواق يعاني من التشتت، إلى بنية تحتية نمطية أكثر توسعًا وفعالية رأس مال وقابلة للتحكم في المخاطر.

من «السوق» كمركز إلى قيود التوزيع السيولة في الواقع بـ V3

في V3 من Aave، اعتمد البروتوكول على طريقة نشر تعتمد على «السوق» كمحور مركزي. في شبكات مختلفة، أو حتى داخل الشبكة ذاتها، يتم تقسيم Aave إلى عدة أسواق مستقلة، مثل Core وPrime في شبكة إيثريوم الرئيسية. كل سوق يمتلك برك سيولة مستقلة تمامًا، مجموعة الأصول المدعومة، ومعاملات مخاطر خاصة، مما يشكل نمطًا مختلفًا من ملفات المخاطر.

عند إيداع الأصول في Aave V3، يكون الأمر بمثابة إيداع الأصول بشكل محدد في سوق معين، وليس في بركة مالية مشتركة عالمية. هذا يعني أن الأصول المودعة في سوق Ethereum Core يمكن استخدامها فقط من قبل المقترضين داخل هذا السوق، ولا يمكن استدعاؤها من قبل سوق Prime أو مستخدمين على شبكات أخرى.

تصميم كهذا يوفر ميزة واضحة في عزل المخاطر، حيث لا تنتقل المخاطر بين الأسواق، ولكن الثمن واضح أيضًا: تقسيم السيولة. حتى لو كانت الأصول ذاتها موجودة، فإنها تتوزع بين عدة أسواق، مما يصعب إدارة السيولة بشكل موحد، ويؤثر على كفاءة استخدام التمويل، وعمق السوق، وإمكانيات إضافة ميزات جديدة.

من مركز Hub ووحدة Spoke: إعادة تنظيم السيولة في V4

ردًا على ذلك، قام V4 بإعادة بناء البنية التحتية الأساسية بشكل جوهري، وأدخل بنية جديدة تسمى Hub وSpoke (عجلة الشعاع). كانت نقطة انطلاق هذا التصميم هي حل مشكلة تشتت السيولة وقيود التوسع الموجودة في V3.

في V4، لم يعد البروتوكول يربط السيولة بسوق واحد، بل يضع في كل شبكة Hub موحد يُعتبر مركزًا لجميع الأموال. الأصول المودعة لا تدخل في سوق معين، بل تُودع بشكل موحد في الـ Hub الخاص بالشبكة، والذي يتولى إدارة السيولة العامة ويخضع لقيود محاسبية أساسية، مثل ضمان عدم تجاوز إجمالي الأصول المقترضة حجم الأصول المودعة، وتسجيل استهلاك السيولة من قبل وحدات مختلفة.

لكن الـ Hub ليس هو واجهة التفاعل المباشر للمستخدم. جميع العمليات التي يمكن للمستخدمين إدراكها، تُوضع في وحدة عالية التخصيص تسمى Spoke، والتي تُعرف في V4.

Spoke: مدخل نمطي يعزل المخاطر

تُشكل Spoke الواجهة الأمامية التي يتفاعل معها المستخدمون مباشرة مع البروتوكول في V4. كل Spoke يتصل بالـ Hub نفسه، لكنه يمكن أن يحدد قواعد ومعاملات وفرضيات مخاطر مختلفة تمامًا. تُدار داخل Spoke مراكز المستخدم، وهيكل الضمانات، وواجهات البيانات (Oracle)، وآليات التسوية، بينما يوفر الـ Hub دعم السيولة ضمن حدود محددة خلف الكواليس.

الهدف من هذا التقسيم هو: عزل المخاطر بشكل صارم داخل الـ Spoke، وعدم انتقالها على مستوى النظام. أنماط الأصول المختلفة، واحتياجات الإقراض المتنوعة، لم تعد بحاجة لمشاركة نفس المعاملات والمخاطر، وإنما يمكن أن تحقق فصلًا في منطق المخاطر، مع مشاركة السيولة.

وبسبب ذلك، يمكن تنفيذ وظائف كانت موجودة بالفعل في V3، ولكنها كانت ثقيلة ومعقدة، بشكل أكثر طبيعية في V4. على سبيل المثال، وضع E-Mode لم يعد مجرد إعدادات لمعاملات، بل يمكن أن يُعتبر Spoke مستقل يخدم مجموعات أصول ذات صلة عالية؛ كما يمكن تحقيق وضع العزل عبر Spoke مخصص، وتحديد حد أعلى للسيولة المسموح به من قبل الـ Hub؛ وإذا كانت هناك أصول ذات مخاطر عالية أو هياكل ضمانات معقدة، فـ V4 يسمح بإضافة Spoke مخصصة، مع قواعد وصول ومخاطر صارمة، دون تعقيد البروتوكول بشكل كامل.

حساب السيولة الموحدة في V4، كيف يتم ذلك؟

لدعم السيولة الموحدة على مستوى الـ Hub، تخلى V4 عن نظام إعادة قياس الـ aToken، واتجه نحو نظام حصص من نوع ERC-4626.

في V4، يتخلى البروتوكول عن آلية إعادة التوازن في الـ aToken، ويعتمد بدلاً من ذلك على نظام الحصص (Shares) وفقًا لنموذج ERC-4626. هذا يعني أن المستخدمين لم يعودوا يمتلكون الـ aTokens التي تزداد تلقائيًا مع الفوائد، بل يمتلكون حصصًا ثابتة (Shares)، وتزداد قيمة الأصول الأساسية التي يمكن استبدال كل حصة بها مع مرور الوقت. بعبارة أخرى، لا تُعبر الفوائد عن زيادة كمية التوكن، بل عن زيادة قيمة الأصول التي يمكن استبدالها لكل حصة، مما يقربها من منطق الخزانة التقليدي (Vault).

هذا النموذج من الحصص مرتبط بشكل وثيق بالتصميم الموحد للسيولة في V4. في بنية V4، تجمع جميع الأصول المودعة في الـ Hub، وتستخدم نظام الحصص لتسجيل الحالة الكلية للأصول بدقة. الـ Hub لا يحتاج لمعرفة استراتيجيات الإقراض أو أنماط المخاطر لكل Spoke على حدة، وإنما يدير الحجم الإجمالي للأصول، وعدد الحصص الكلي، وتخصيصات الـ Spoke. يتيح هذا التصميم مشاركة نفس البركة من الأصول بين عدة Spoke، مع الحفاظ على وضوح ومراقبة في الحسابات، وتجنب التعقيدات والمخاطر الناتجة عن إعادة قياس الـ aToken في بيئة متعددة الوحدات.

إذا استمر اعتماد نظام إعادة قياس الـ aToken، فإن مشاركة الأصول بين Spoke مختلفة ستواجه صعوبة في التزامن، مع احتمالية تسرب الفوائد والمخاطر، وصعوبة التحكم الدقيق في حدود الوحدات الفرعية. نظام الحصص وفق ERC-4626 يحول هذه المشاكل إلى علاقات حسابية بسيطة، تمكن الـ Hub من دعم استراتيجيات إقراض متعددة وتكوينات مخاطر بشكل آمن وقابل للتحكم، مع الحفاظ على كفاءة رأس المال، وتوفير أساس لبنية V4 النمطية وقابليتها للتوسع في المستقبل.

تعديلات دقيقة في آلية التسوية: التخلص من التسوية بنسبة ثابتة

بعيدًا عن إعادة تنظيم السيولة، أجرت V4 تغييرات مهمة على آلية التسوية. وبعكس المنطق السابق الذي يعتمد على نسبة ثابتة، أدخلت V4 محرك تسوية يُركز على الهدف من المخاطر.

في V3 والإصدارات السابقة، عندما ينخفض عامل الصحة (Health Factor) لمركز معين إلى ما دون الحد الآمن، يسمح البروتوكول للمنفذين (Liquidators) بسداد نسبة محددة من الدين، وفقًا لـ close factor، واستيلاء على الضمانات. كانت هذه الطريقة فعالة في حماية أمان البروتوكول، لكنها قد تؤدي أحيانًا إلى تسوية مفرطة، حيث يتم تسوية حجم أكبر بكثير مما يلزم لاستعادة حالة آمنة للمركز.

أما محرك التسوية الجديد في V4، فهو يركز على «الهدف من الأمان» بدلاً من نسبة التسوية الثابتة. عندما يدخل المركز إلى حالة قابلة للتسوية، يُحسب مقدار الدين الذي يجب سداده، والضمانات التي يتعين التصرف فيها، لاستعادة عامل الصحة إلى مستوى آمن. التسوية لم تعد تهدف إلى تقليل المخاطر بأقصى حد، وإنما إلى الحد الأدنى الضروري من التسوية، مع ضمان عدم الإضرار بأمان البروتوكول، وتقليل الضرر على أصول المستخدمين.

هذا التغيير يعني أن close factor يتحول من معلمة ثابتة، إلى نتيجة تتحدد ديناميكيًا بناءً على حالة المخاطر للمركز. حجم التسوية يتغير وفقًا لتقلبات الأصول، وهياكل الضمانات، ومعاملات المخاطر، مما يجعل آلية التسوية تعكس بشكل أدق الفروقات في المخاطر بين المراكز، ويساعد على تقليل الصدمات الناتجة عن التسويات والتصفية غير الضرورية.

ويمكن ربط تحديث آلية التسوية في Aave بتصميم Fluid للتسويات، التي حسنت بشكل كبير من طريقة التسوية «الجراحية» الأصلية، وجعلتها أكثر دقة وملاءمة للمخاطر.

لكن، بالمقارنة مع دمج إقراض السيولة من الـ DEX مثل Fluid، فإن Aave لا تزال ضمن نموذج تصميم مختلف. فـ Fluid يدمج مراكز الإقراض مباشرة ضمن تدفقات التداول، مما يسمح بامتصاص بعض المخاطر داخل البركة، ويقلل الحاجة لوجود طرف خارجي يقوم بالتسوية، مما يوفر تكاليف وكفاءة عالية. أما Aave، التي تعتمد على طرف خارجي للقيام بالتسويات، فهي تواجه تحديات في مجال التكامل والكفاءة، حتى مع تحسينات في دقة آلياتها.

ملخص

بشكل عام، فإن Aave V4 لا يمثل انقلابًا على النموذج الموجود، بل هو مسار تطور متحفظ ومنظم، يعتمد على إعادة هيكلة السيولة عبر بنية Hub وSpoke، وعزل المخاطر بشكل موضعي، وتطوير آلية تسوية أكثر دقة. يهدف هذا إلى أن يتحول Aave من بروتوكول إقراض متعدد الأسواق يعاني من التشتت، إلى بنية مرنة قابلة لدعم هياكل مالية أكثر تعقيدًا، مع بنية أساسية نمطية ومرنة في التوسع.