#dusk $DUSK @Dusk شدّ وجذب بين الخصوصية والامتثال… كلما واصلت السير في طريق Dusk ازدادت الأمور إرهاقًا
أعدت تشغيل شبكة الاختبار الخاصة بـ Dusk، وأوضح إحساسي لم يكن أن التقنيات لم تعمل، بل أنها أجبرت الخصوصية والامتثال على الارتباط بنفس دفاتر الحسابات. كل خطوة تبدو كأنها بحث عن نقطة توازن. لا تبقى بيانات صريحة في السلسلة (on-chain) من جهة المزامنة/الرسائل، والإثباتات الصفرية للمعرفة تجعل المبالغ وطرفي التعامل مضغوطين بما يكفي لتكون نظيفة، لكن جهة التدقيق (audit) تصبح في موقف محرج. عندما يريد المنظمون إعادة بناء معاملة ما، فإما عبر تفويضات إضافية، أو عبر تسجيل تكميلي خارج السلسلة. وبذلك تتحمل الجهة المُصدِرة تكلفة الامتثال بنفسها. أما Polymesh فقد كتب هوية المستخدم وقواعد التحويل بشكل مباشر، فتضحي بالخصوصية مقابل الحصول على درجة اليقين التي تطلبها المؤسسات. Dusk ترك مرونة، لكن في المراحل المبكرة عندما كان يقتنص الحصة من المؤسسات التقليدية تحوّل ذلك إلى نقطة خصم.
من ناحية الرهن وgas، فالأمور يمكن تشغيلها بشكل طبيعي، والمنطق داخل الحلقة مغلق ولا توجد به مشكلة. المشكلة تقع خارج الحلقة. فالمحفظة والمتصفح ما تزالان في الأساس على هيئة أدوات للمطورين؛ ومن لم يجرّب شبكات مشابهة سيشعر بوضوح بصعوبة أكبر عند البدء. عندما قارنت مع Ondo كان الأمر مباشرًا جدًا: Ondo لا يمس طبقة البنية التحتية، بل يغلّف الأصول في شكل حصص صناديق؛ بذلك تكون الأخف والأسرع، وتتركز السيولة. أما Dusk فيصر على أن يحمل بنفسه سلسلة الكتل، طبقة الخصوصية، وطبقة الامتثال، مع إطالة دورة الزمن إلى أقصى حد. لكن لهذا الثقل وجهًا آخر: عندما يُطلب يومًا ما أن يمتثل الرمز المشتق من الأوراق المالية على السلسلة بشكل أصلي، ستكون التراكمات الأساسية لـ Dusk أصعب في الاستبدال من حلول “تكديس/ترقيع” جاهزة.
السردية التي يسوقها حجم القيمة السوقية حاليًا تتجاوز بكثير التراكم الحقيقي للأصول على السلسلة، ولم يُضق الفجوة بعد؛ لذا لا تتسرع في القول إنه يتفوق مع الوقت. الخصوصية بالنسبة إلى Dusk ليست كلمة تسويق، بل شرط مسبق لتسجيل الأصول على السلسلة؛ غير أن الشرط المسبق لا يولّد قيمة من تلقاء نفسه، بل يجب ترسيخه عبر السيولة وبقاء الجهة المُصدِرة. في النهاية، لا يعتمد الأمر على TPS لشبكة الاختبار، بل على مقدار متطلبات الإصدار التي تكون مؤمّنة على السلسلة ومصعب نقلها بعيدًا.
#termmax @TermMax تسارع الإنهاء/التصفية وصل إلى مستوى أعلى، لكن الديون المعدومة لا يزال لا أحد يشتريها
راقبتُ معاملات التصفية في TermMax مرتين، وكانت درجـة الخصم أكثر جرأة من Aave. عندما ينخفض معامل الصحة إلى 1.05 يتم تشغيل التصفية الجزئية، وحماية الانزلاق تُمنح على مستوى واحد فقط؛ ما يحصل عليه مُصفّي الأصل من القيمة المتبقية يكون رقيقًا جدًا. هذه التصاميم تُحاول خفض احتمالية الديون المعدومة عبر تصفيات عالية التواتر وبمبالغ صغيرة، لكن حوافز توكن TERM لم تواكب ذلك—فالتعويضات أشبه بالكلام منها بالمساعدة. والنتيجة الفعلية ما زالت أن اللاعب الكبير هو من يجمع/يشتري.
على شبكة الاختبار، شغّلتُ مستودعًا مرهونًا بـ LRT، وتنفيذ التصفية في TermMax كان سريعًا بالفعل. تحديث الـ Oracle إلى حين اكتمال التصفية استغرق تقريبًا كتلتين، أي أسرع من فرصة المراجحة (arbitrage) في Compound. لكن المشكلة واضحة أيضًا: عمق مجمع الضمان غير كافٍ؛ فعندما تكون صفقة التصفية أكبر قليلًا، يلتهم الانزلاق الأرباح. سماكة أوامر الـ LRT لدى المشاركين الرئيسيين لا يمكن مقارنتها بالأسواق المعزولة في Morpho. يقوم TermMax بتجميع متطلبات التصفية في مجمع موحّد، فتتوزع السيولة ويصبح دفتر الأوامر أثناء التصفية المركزية رقيقًا بحيث يمكن ترك فروق أسعار واضحة.
وهناك شيء غير مريح آخر: مكافآت التصفية لا تُسدَّد فورًا، بل تمر بتوزيع مؤجل. هذا غير مناسب لعمليات تصفية الأفراد (المصفّين الصغار)، لأن انشغال رأس المال يمتد، والاستقرار السنوي (annualized stability) يكون أقل بكثير من المكافآت الفورية في Aave. إذا لم تُعالج حوافز التوكن تكلفة الوقت، فستتراجع مشاركة المُصفّين في النهاية. لم أرَ أن TermMax يقدّم تبديلات أكثر مرونة في المعلمات؛ وقد يلزم لاحقًا تغييره ليتم تنفيذ التصفية بحسب عزل الأصول. وإلا ففي سوق هابطة (Bear market)، قد يتخلى مُصفّون عن هذه المنظومة مباشرة.
إجمالًا، يبدو أن منهج TermMax في التصفية دفاعي أكثر، ومناسب للتعامل مع صفقات سيئة بحجم صغير وتواتر مرتفع. ومع التقلبات القصوى ما يزال الأمر يتطلب الاعتماد على صانع/وسط سوق خارجي لتغطية الفجوات. والفارق بينها وبين البروتوكولات الرائدة ليس في السرعة، بل في سماكة/عمق منظومة التصفية. إذا استطاع توكن TERM أن يربط الحوافز الخاصة بالتصفية بالتنفيذ الفعلي بشكل أقوى، فربما يمكن سد هذا النقص.
#termmax @TermMax بعد أن فشل لدى TermMax ثلاث صفقات لأوامر محددة بالسعر، بدأتُ بإعادة حساب دفتر الأوامر وقيود AMM.
قمتُ بنشر صفقات إقراض/اقتراض بفائدة ثابتة بأجل مختلف على TermMax. عمق الأوامر يبدو بالفعل أرق مما كنت أتوقع. فرق سعر العرض والطلب لنفس تاريخ الاستحقاق يمكن توسيعه بنحو 3 إلى 4 نقاط أساس في الآجال الرئيسية، لكن في الآجال الذيلية لا توجد فعليًا مقابلات/أطراف تقابل. هذا ليس أمرًا غير متوقع؛ بروتوكولات دفتر الأوامر على السلسلة تكون كذلك تمامًا في مرحلة الإطلاق الأولية. لكن إذا كنت قادمًا من جهة Pendle، فستشعر بوضوح أن إيقاع التنفيذ/التداول مختلف. يضمن مسار AMM لدى Pendle على الأقل إمكانية التبديل الفوري، بينما يعتمد TermMax أكثر على استعداد صناع السوق لإدخال السيولة.
ما جعلني أجد ذلك مثيرًا للاهتمام حقًا هو منطق وضع الأوامر نفسه. لا يقوم دفتر أوامر TermMax بضغط أسعارك داخل منحنى كما يفعل AMM. الأوامر المحددة بالسعر تُترك هناك ببساطة، وهي حكمك المستقل على سعر الفائدة لأجل معيّن؛ واضح مباشرة ما إذا كانت الصفقة ستُنفّذ أم لا. مقارنةً بـ Notional في إقراض/اقتراض الفائدة الثابتة، فإن درجة “تسييل” المراكز لدى TermMax أعلى، ومسار إعادة التدوير والخروج لا يعتمد على قيام الطرف الآخر بالسداد المبكر. هذا أكثر ملاءمة في إدارة المحافظ. لكن المشكلة تكمن هنا أيضًا: عندما لا يكون العمق كافيًا، فإن محاولة إغلاق مركز بغير معيار قد يبتلع جزءًا كبيرًا من فارق الفائدة بسبب الانزلاق.
الحوافز لدى TMX لم تُحل هذا عدم التطابق بشكل كامل بعد. إن كان إطلاق الرموز يُستخدم لتعويض السيولة، لكن إذا تركّزت الإعانات على عدد قليل من الآجال السائدة، ستظل الآجال الذيلية باردة دون نشاط؛ وإذا اتسعت دائرة التوزيع كثيرًا، فلن يتشكل عمق كافٍ عند أي نقطة بعينها. أرى أن تصميم الحوكمة لدى TermMax يحاول نقل سلطة توزيع الحوافز إلى الآخرين، لكن ما إذا كانت قوة التصويت الفعلية وسلوك صناع السوق متوافقين، ما زال يحتاج إلى مراقبة عدة دورات من المقترحات.
بعبارة مختصرة: نموذج دفتر أوامر TermMax في اكتشاف السعر أنظف من AMM، لكنه ينقل أيضًا مشكلة السيولة كما هي إلى السلسلة. ليست كل الآجال مناسبة لاستخدام فكرة الإعانة نفسها لزراعتها/ضخها. من ناحية اتجاه المنتج، أؤيد قدرًا من كبح النفس لديه—لم يتعجل في الحيلة المتعلقة بتوكنات عوائد إضافية—لكن لكي تُحسب السيولة وتُسوّى فعليًا بشكل كامل، ربما يتطلب الأمر وقتًا أطول مما كنت أتوقع.
#termmax @TermMax بعد أن تم تحويل الفائدة إلى دفتر أوامر، لا يزال عمق TermMax ينقصه نفس أخير
عندما فتحت صفحة تسعير TermMax، كانت أول ردة فعلي أنه حوّل الفائدة الثابتة إلى دفتر أوامر. لا توجد حيل لتفكيك PT وYT مثل Pendle، ولا احتساب خسائر الانزلاق عند الدخول والخروج من مجمعات Aave. يشبه TermMax أكثر سوق مزادات إقراض على السلسلة: يقف المُقترضون والمُقرضون بإدراج أوامرهم، وتُوزَّع تاريخ الاستحقاق والفائدة ونسبة الضمان على السلسلة. $TERM داخل النظام هو مجرد خصم للرسوم وصلاحية حوكمة، وليس مصدر عائد؛ وهذا، في المقابل، جعلني أشعر بالاطمئنان.
قمت بتعليق أمرين فعليًا: مرةً أقرضت USDC، ومرةً رهنت ETH لأقترض عملة مستقرة. لم تتم الصفقة بسرعة؛ فالعمق يتمركز في نطاق أسبوع وثلاثين يومًا، أما الأوامر التي تتجاوز التسعين يومًا فغالبًا يتعين على المرء تفكيكها بنفسه. الانزلاق ليس المشكلة الأساسية، بل إن الفائدة التي تُطابقها عملية المزاد تأتي مع تأخير بسيط عن فائدة السوق. عندما تكون التقلبات حادة، تميل التسعيرات للفائدة الثابتة مؤقتًا بعيدًا عن منحنى رسوم التمويل، ثم تدخل السيولة للاستفادة من الفروقات وتقوم بمحو الأثر؛ في حين أن أوامر الإدراج اليدوية العادية غالبًا لا تحصل على هذه الفرصة. تسعير TermMax والمطابقة نظيفان، لكن عندما يكون العمق رقيقًا، فإن “النظافة” تعني ببساطة أن الأمور هادئة.
أما من ناحية آلية التصفية، فإن خطّ إنذار نسبة الضمان في TermMax أكثر تحفظًا. مقارنةً بتصفية Aave الخطية والتسوية عند الاستحقاق في Pendle، فهو أقرب إلى صفقة إعادة شراء تقليدية؛ يراقب السعر عن كثب. العيب أنه لا يمكنك رفع الرافعة كثيرًا، لكن الميزة أنني على الأقل أعرف عند أي سعر ستحدث التصفية. لم يتم فتح وحدة رهن $TERM بالكامل بعد، كما أن حساب تخفيض الرسوم ملتوي بعض الشيء، وتبدو الرموز الحوكمية في الوقت الحالي كرمز أكثر من كونها تدفقًا نقديًا. لا أتوقع أن يتغير هذا بسرعة على المدى القصير؛ فثبات التصفية على السلسلة أكثر قيمة من أرقام العائد.
ما يقلقني أكثر هو: أين تذهب الأموال المقترضة بفائدة ثابتة في النهاية. يقوم TermMax فقط بإقراض الأصول الأصلية (native assets)، وبالتالي السقف واضح. إذا أراد أن ينافس Pendle على تجزئة العوائد وأن ينافس Notional على التمويل المؤسسي، فعليه أن يصنع حلاً لمسار الخروج قبل الاستحقاق، لا أن يكدّس APR فقط. لا أنكر أن آلية المزاد هذه نظيفة، لكن بين “النظافة” و“الحيوية”، الفرق هو تشغيل السيولة. من منظور بارد، يبدو TermMax الآن كأنه بنية تحتية للفائدة ذات زوايا لم تُصقل بعد: يمكن استخدامها، لكنها ليست جيدة الاستخدام. وحين يرتبط $TERM فعلًا بإيرادات البروتوكول، ربما عندها فقط يكون الوقت مناسبًا لإعادة تسعيره.
#dusk $DUSK @Dusk عقدةٌ مميتة لسلسلةٍ بلوك تشينٍ خصوصية، المرة هذه يريد Dusk أن يفكّها من طبقة البروتوكول
لطالما علقت سلاسل البلوك تشين الخصوصية في عقدةٍ واحدة: كلما تعمّقت في تحقيق المجهولية إلى أقصى حد اصطدمت بالرقابة، ومصير Tornado Cash حاضرٌ أمام الجميع؛ وإما أن تتخلّى عن الخصوصية، وهذا يعني فعليًا نزع السلاح. يسلك Dusk الطريق الثالث: لا يتجاهل الرقابة، بل يكتب الامتثال داخل البروتوكول نفسه.
ومحطته محددة بدقة. طبقة DuskEVM المتوافقة مع EVM تستهدف المؤسسات والمطورين؛ ومن يعرف Solidity يمكنه البدء تقريبًا بلا عتبة دخول. لكن ما يقلقني أكثر هو مُكوّن الخصوصية Hedger: تشفير متماثل متداخل فوقه إثباتات معرفة صفرية، بحيث يتم إنجاز الحساب داخل النص المُشفّر، مع ترك منفذ لمراجعة التفويضات.
المكان الذي تُصبح فيه هذه التصميمات ثمينة فعلًا هو قابلية التدقيق. لم يجعل Dusk المجهولية نقطة النهاية؛ يمكن إجراء الحساب داخل النص المُشفّر، وبعد منح التفويض يمكن تتبّع ما يلزم، فالخصوصية والامتثال تتقاطعان في خط واحد، بدل أن تُجبر على خيارٍ ثنائي. ما تريده المؤسسات ليس اختفاءً مطلقًا، بل أن يكون ما يجب أن يكون عامًا عامًا، وما يجب أن يكون محفوظًا محفوظًا، مع إمكانية ترك أثرٍ دائمًا عند الحاجة. عادةً يهيمن المنافسون على جانبٍ واحد فقط: Aztec قوي في الحوسبة العامة، وSecret Network يعتمد على TEE لتحسين الأداء، وOasis (Sapphire) يسير أيضًا بمنطق EVM لكن الامتثال يبقى عند مستوى السلسلة خارجها/إرادتها الذاتية. إدخال Dusk لهذا في طبقة البروتوكول هو الاتجاه الأقرب لما أريد التحقق منه.
لكن العيوب موجودة كذلك: الوثائق مبعثرة، وسلسلة الأدوات بدائية، وتأخير معاملات الخصوصية ورسوم Gas يجب أن يتحدث عنهما توفر بيانات الشبكة الرئيسية. ومع ذلك، إن كان يُقال إنه عالق في هذه الفئة الفرعية من مسار RWA الخاضعة للرقابة، فأنا مستعد أن أصدّقه إلى حدٍّ معقول.
dusk يدير شبكة كاملة بهذا الشكل؛ وهل تتحقق رواية المؤسسات أم لا، يعتمد إيقاع إتاحة DuskEVM على الشبكة الرئيسية، وما إذا كان هناك فعلاً أشخاص يستخدمونه في البيئة. تمضي هذه الطريق ببطء—@Dusk —لكنها بطيئة وفق منطقها. #dusk
#termmax @TermMax السرد التاريخي لبروتوكولات إقراض DeFi غالبًا ما يُقيَّد دائمًا بإجمالي الكمية المُقيدة ومعدل العائد السنوي. لكن الذي يحدد فعليًا تجربة بقاء المستخدم هو أداء محرك التصفية في ظروف السوق المتطرفة. مؤخرًا، حللتُ معلمات التصفية في TermMax ووجدت أنه يتجنب، على مستوى التصميم، واحدة من أكثر المشكلات شيوعًا في الصناعة. تعتمد أغلب بروتوكولات الإقراض على عتبة تصفية ثابتة؛ فإذا اخترق السعر تلك العتبة، يقوم المُصفّي فورًا بسحب الأصول المرهونة بسعر خصم، تاركًا للمقترض وقتًا احتياطيًا شبه معدوم. تفكك TermMax عملية التصفية إلى خطوات (سلمية)؛ كل مستوى يفعِّل خصمًا مختلفًا ومنافذ زمنية مختلفة. هذا المنطق أقرب إلى مفهوم الإغلاق المرحلي في التمويل التقليدي، وليس إلى نمط “صفقة واحدة” في البيع والشراء الأصلي للتشفير.
من ناحية البيانات، منحنى سعر فائدة الاقتراض لدى TermMax أكثر سلاسة من Aave v3، ويكون صعود الفائدة أهدأ داخل نطاق استغلال السيولة من 75% إلى 90%. هذا التصميم يضحّي بجزء من أرباح جهة الإمداد، لكنه يَكسب بدلاً من ذلك استقرار جهة الاقتراض. وفي سيناريوهات مشابهة، تكون قفزات معدل الفائدة لدى Aave حادة جدًا؛ فعندما تتجاوز نسبة استغلال السيولة نقطة حرجة، يتسع فرق الفائدة بسرعة، وهو ما لا يكون ودودًا لصفقات الاقتراض طويلة الأجل. حاليًا، يستخدم TermMax رمز TERM للحوافز والحوكمة، وبعض أزواج التداول تكون سيولتها بالفعل أرفع نسبيًا، ونقص العمق قد يتضخم عند التصفية بمبالغ كبيرة—وهذه هي أبرز نقطة ضعف لديه في الوقت الراهن.
ولتقريب الصورة، قارن آلية Compound للتصفية المتأخرة: فهي تحدد للمُصفّي فترة مهلة، لكن الشروط فيها أكثر بساطة وأحادية نسبيًا، كما أن وتيرة الابتكار انخفضت بشكل واضح بعد V3. وبالنسبة لـ TermMax، لا يمكن القول إنه “حل” مشكلة ما بقدر ما أنه أعاد تجميع عدة أفكار قديمة للحماية من التصفية بشكل أدق. ليست قفزة نموذجيّة (paradigm shift)، لكن في التشغيل الفعلي، يمكن بالفعل الإحساس بأن محركه أكثر صلابة عند مواجهة “طعنة” لحظية في السعر. توجد فرق كثيرة تعمل في مجال الإقراض داخل الصناعة، والقليل فقط من يَخوض تفاصيل التصفية، وهذا بدوره يجعل TermMax يبدو مختلفًا قليلًا.
وبالمناسبة، لا تتعجل في حساب العائد السنوي. أولاً اقرأ القسم في وثائقه حول تغطية الهامش والفواصل/الدرجات الخاصة بالتصفية؛ فسيكون ذلك أكثر إثارة للاهتمام بكثير من النظر إلى رسوم العائد السنوي. حتى لو كانت حسابات العائد جميلة، إذا كان منطق المحرك غير واضح، فستنكشف الحقيقة في سوق الهابطة كذلك.
#dusk @Dusk تفكيك عقد Dusk والعقود، والقصور في سلسلة الامتثال للخصوصية لا يكمن في آلية الإجماع بل في سلسلة الأدوات
شغّلت عقد شبكة اختبار Dusk لمدة يومين، وبالمناسبة نشرت عقد تحويلات سرّية. كانت العملية غير سلسة؛ فبعض إصدارات عناوين RPC في الوثائق لا تتطابق، ولم يكن بالإمكان تجميع الإعدادات الصحيحة إلا بالرجوع إلى سجلّات Discord. من ناحية الإجماع وتوليد الكتل، لا يوجد ما يثير الاعتراض في Dusk؛ كما أن زمن إثباتات PLONK ضمن نطاق مقبول، لكن نضج سلسلة الأدوات هو الذي يتأخر بوضوح. باعتبار DUSK أصولًا للغاز ورهن العقدة، فهي حاليًا أكثر في التحقق من الانضباط ضمن الشبكة، والطلب الخارجي لا يزال غير قوي.
ما يشغلني فعلًا هو حدود الخصوصية والامتثال. سلوك Dusk لمسار العقود السرّية مع واجهة التدقيق، يجعله أقرب إلى طبقة الأصول من نهج Secret Network في الإخفاء الافتراضي الأكثر تحفظًا، وأقرب من Concordium الذي يربط الهوية بسلسلة خارجية. في الاختبار، كانت الحقول التي يمكن للأدوار الخاصة بالتدقيق رؤيتها قابلة للتحكم فعلًا، لكن نموذج التفويض ما يزال خشنًا، والتفاصيل في مستوى الصلاحيات غير كافية. الفرق التي تريد إصدار رموز على شكل أوراق مالية تحتاج بشدة إلى هذه القابلية للتكوين. تم تعيين $DUSK كعتبة دخول لبوابة الحوكمة والامتثال؛ منطقها صحيح، لكن التنفيذ لا يزال ينقصه بعض النار.
مقارنةً بـ Polymesh، لم يقيّد Dusk نفسه بحالة استخدام وحيدة تخص الأوراق المالية. نظام حسابات Polymesh وقواعد التسوية صارمة جدًا، ولا يمكن عمليًا اللعب بالحسابات العامة. يحتفظ Dusk بمساحة تعاقدية أوسع، لكن ذلك يعني أن على المطورين التعامل بأنفسهم مع الكثير من تفاصيل الامتثال. بالعكس، أرى أن هذا تمايز، بشرط أن يُستكمل الأمر عبر سد الثغرات في الـSDK والوثائق. يمكن لعوائد الرهن المرتبطة بـ$DUSK تغطية جزء من التضخم، لكن عندما تكون تطبيقات النظام البيئي قليلة، تصبح نسبة العائد مجرد رقم على الورق.
إذا تم لاحقًا إعادة تنظيم نشر العقد والأدوات الخاصة بالتدقيق ووثائق المطورين من جديد، فإن Dusk على خط الخصوصية وRWA لديه مكانة وحيّز. في الوقت الحالي هو في مرحلة يمكن فيها للبروتوكول أن يعمل لكن النظام البيئي لم يأتِ بعد؛ وDUSK أكثر ملاءمة للملاحظة لا للمقامرة العاجلة.
#dusk $DUSK @Dusk سلسلة الخصوصية يرفع الجميع شعار الامتثال، وDusk هو من القلائل الذين تُجسِّد هذه الجملة في بنية النظام فعليًا
عندما أنظر إلى Dusk خلال هذه الفترة، أكبر شعور لدي أنه لا يبدو كأنه يصنع شيئًا أيديولوجيًا بالكامل في مجال الخصوصية؛ بل إنه يضع قابلية التدقيق (قابلية المراجعة) في المقام الأول مقارنةً باللا-تتبُّع/السرية. هذا الانضباط نادر جدًا في مجال الخصوصية، وهو جزء غالبًا ما يتم التقليل من قيمته ضمن المنطق الطويل لـ $DUSK . مخطط PLONK الخاص بها لا يخفي كل المعاملات بالكامل، بل يترك منافذ للامتحان/التدقيق بما يخدم الامتثال؛ وفي سيناريوهات ترميز الأصول للأوراق المالية، تكون هذه المرونة أكثر واقعية من الاخفاء البحت.
عند إعادة قراءة وثائقها، مدخل المطورين يبدو ملتفًا قليلًا؛ إذ إن مزامنة عقد شبكة الاختبار إلى مستوى معيّن قد تتوقف، وتحتاج إلى تنظيف الحالة يدويًا وإعادة البدء. أظن أن أغلب الناس عند تشغيل العقد لأول مرة سيتعثرون هنا، كما أن مسار استكشاف الأخطاء في الوثائق غير مباشر بما يكفي. هذه التفاصيل تكلف فرقًا ترغب بجدية في دمج RWA احتكاكًا غير قليل. تقدم Secret Network خصوصية على مستوى السلسلة بالكامل، فتكون تجربة المعاملات أكثر سلاسة، لكن أدوات الامتثال أضعف بدرجة ما؛ بينما تميل Oasis إلى خصوصية البيانات، وعمق البروتوكولات في طبقة الأصول المالية لا يرقى إلى Dusk؛ أما Concordium فلديه هوية على السلسلة، لكن قدرات خصوصية العقود الذكية متوسطة عمومًا. مشكلة Dusk هي أن النظام البيئي بارد، وسلسلة الأدوات لا تزال لا تدعم مجتمعًا مطورين حيويًا.
لا أتفق كثيرًا مع وصف Dusk ببساطة كونه المنصة التالية لترميز الأوراق المالية. ما تفعله يقع في مستوى أعمق: إيجاد طريق قابل للتطبيق بين إثباتات الخصوصية وعُقد التنظيم/الرقابة. لكن بحسب ما يبدو حاليًا، لا يزال هذا الطريق يتوقف أكثر عند تصميم البروتوكول، بينما تظل أدوات الإصدار القابلة للاستخدام فعليًا والسيولة على السلسلة غير كافية. مقارنةً بذلك، تتعامل كثير من مشاريع الخصوصية مع التنظيم كعبارة تسويقية، بينما Dusk بالأحرى تركت مداخل الهوية وواجهات التدقيق جاهزة مسبقًا على مستوى البروتوكول. رواية سعر العملة قد تنجرف بسهولة وراء موجة RWA، بينما إيقاع التحقق التقني أبطأ؛ وهذا الفارق بينهما يحتاج وقتًا للهضم.
بالنسبة لمن يرغب في المراقبة على المدى الطويل، فالتركيز ليس على مراقبة الارتفاع والانخفاض قصير المدى، بل على ما إذا كانت ستستكمل تجربة العقد وواجهات الامتثال. فخَنازير الامتثال للخصوصية كثيرًا ما تتعثر فيها مشاريع تقول كثيرًا وتُنجز أقل؛ وعلى الأقل حتى الآن، Dusk تكتب بشكل أجمل مما تفعل، وما زال عليها أن تُقدّم تسليمات أكثر رسوخًا.
#dusk $DUSK @Dusk كتب الامتثال في طبقة الخصوصية، لكن لم يضع المنتج في واجهة CLI
في الأيام القليلة الماضية أعدتُ مراجعة شبكة الاختبار ووثائق Dusk بالكامل، ولم أفتّش في الوعود الفارغة في خريطة الطريق؛ جرّبت فقط من ثلاث نقاط دخول: العقدة، والتحويلات، ومستعرض الكتل. ما يريده Dusk في مضمار الخصوصية ليس جديدًا: جعل معالجة الخصوصية للأصول الخاضعة للرقابة قدرة افتراضية على السلسلة. لكن طريقة إدخال الهوية المطابقة مباشرةً في بناء المعاملة لا تشبه كثيرًا Secret وOasis. Secret يميل إلى عقود خصوصية عامة الاستخدام، وOasis يعتمد على TEE للعزل، أما Dusk فشبهه أنه يضع قابلية التدقيق للعيان أولًا، ثم يضغط حجم المعلومات باستخدام البراهين الصفرية المعرفة. الاتجاه ليس سيئًا، لكن على مستوى المنتج يبدو أنه تأخر بوضوح.
حِمل الموارد لتشغيل عقدة ليس مبالغًا فيه، وبالنسبة للمتحققين الصغار والمتوسطين فهو ودود. المشكلة الأساسية تقع في مسار التفاعل. بمجرد إرسال تحويل خصوصي، لا يُرى تقريبًا أي تغيّر قابل للقراءة على مستعرض الكتل؛ ولا يبقى سوى الرجوع إلى سجلات الأحداث عبر CLI. هذا «الشفاف نصف الشفاف» مقبول من ناحية هدف الخصوصية، لكنه مزعج جدًا لفِرق المراجعة الامتثالية. كذلك توجد فجوة في وثائق SDK الخاصة بـ Dusk: أمثلة الأساس تعمل، لكن عند الاصطدام بتقسيم الصلاحيات والإفصاح الانتقائي لا يوجد ما يلي ذلك. بالمقارنة مع Polymesh، فإن أدوات طبقة الهوية هناك أكثر تفصيلًا بكثير، ويمكن ضبط الأدوار وقواعد التوقيع فورًا.
بالنسبة للرموز، ما زالت شبكة Dusk من ناحية القيمة تَلتقط بشكل رئيسي عبر الحصص والرسوم؛ ولم أرَ تمايزًا كبيرًا في أوزان الحوكمة. قد تُقبل قصة الامتثال في السوق الثانوية بسهولة، لكن كي تُعلّق المؤسسات أصولها فعلًا، لا تزال هناك حاجة إلى وحدة لتبادل الهوية لا تعتمد على KYC يدوي. تعامل Oasis وConcordium مع حدود «الهوية الخصوصية» و«الامتثال على السلسلة» أكثر نضجًا. إذا ظل Dusk عند مستوى عروض شبكة الاختبار فقط، فسيستمر الفارق في الاتساع.
لا أشك في القيمة طويلة الأمد لمسار السلاسل العامة للخصوصية، بل وأظن أن زاوية Dusk—مقارنةً بسردية إخفاء الهوية الخالصة—قد تكون أكثر قدرة على مقاومة التنظيم. لكن في هذه المرحلة أشعر بأن طموح البروتوكول أكبر من اكتمال الإنجاز على مستوى التطبيق. بدلًا من مواصلة التأكيد على سهولة الامتثال، من الأفضل أولًا سحب المطورين من واجهة سطر الأوامر، واستكمال المتصفح وأدوات الهوية.
#dusk $DUSK @Dusk عندما تُروَّج لسلاسل الكتل، غالبًا ما يقتصر الحديث على وقت الكتلة وسعة المعالجة (throughput)، بينما تُكلف تكلفة النطاق الترددي حضورًا ضعيفًا. لكن بمجرد زيادة عدد العقد، يبدأ تمرير الرسالة نفسها مرارًا بين العقد؛ فقبل أن يصل اختناقٌ متعلق بالحوسبة (القوة الحسابية/القدرة على المعالجة) إلى حدوده، تكون أجهزة التوجيه والطوابير (queues) هي التي تبدأ بالازدحام. يضع Dusk Kadcast في الطبقة الأساسية، فلا يكفي أن تعمل الشبكة المالية بسرعة فقط، بل يجب أيضًا أن تستمر العقد ذات التكوينات المختلفة في استقبال المجموعة نفسها من الكتل والتصويتات
لم يكتفِ Kadcast بأن يلقي رسائل Dusk عشوائيًا إلى حلقة من الجيران. فهو يحافظ على “حُزم التوجيه/سلال التوجيه” (routing buckets) عبر مسافة التباين (xor distance) المُعرَّفة بالمفاتيح/بمعرّفات العقد، ثم يوزّع الرسالة على مراحل تدريجية، ليُنتج مسارات انتشار منظمة. لا يتعين على العقد البعيدة المرور بسلسلة طويلة من عمليات الإعادة (الترحيل)، وبالتالي تقل عمليات النقل المكررة. يشبه هذا تصميم المسار حين يُوزَّع البيانات على محطات تبديل ثابتة؛ فالمسار يصبح أكثر قابلية للتنبؤ. غير أن جداول التوجيه تحتاج إلى حداثة أعلى، وجودة التقسيم إلى سلال (buckets) تصبح أهم، وكذلك تصبح آلية اكتشاف العقد أكثر أهمية
عندما أضع عقد Dusk في بيئة تشغيلية، تكون أولوياتي واقعية ومباشرة: هل منافذ الاستقبال قابلة للوصول؟ هل تم إعداد تحويل عنوان الشبكة (NAT) بصورة صحيحة؟ كم عدد الأقران (peers) التي يمكن للعقد العثور عليها؟ وهل تم إنشاء اتصالات كافية قبل بدء المزامنة؟ وهل يستمر ارتفاع ارتفاع الكتل (block height) بالتقدم دون توقف؟ تبدو بروتوكولات من فئة Gossip بطيئة/بدائية، لكنها تعوّض ذلك بالهامش الزائد (redundancy) لتحسين التسامح مع الأخطاء؛ أما Kadcast فيتسم بقدر أكبر من التقيّد والانضباط، ويعتمد أكثر على أن تكون البنية صحيحة. وإذا فشلت بعض المسارات الأساسية، أو تم احتلال سلال التوجيه من قِبل عقد خبيثة، فقد تتحول وفورات النطاق الترددي إلى صعوبة أكبر في إزالة الأعطال وفك الاختناقات
في ورقة الـwhitepaper، يقدّم Dusk بيانات تفيد بأن Kadcast يُوفّر ما بين ربع إلى نصف عرض النطاق الترددي مقارنة بـ Gossip، كما يُخفض معدل الكتل “المهملة/غير الفعالة” (stale/废块率) بنسبة تتراوح بين الثلث إلى الثلث تقريبًا في سيناريوهات الشبكات عالية السرعة. هذه الأرقام مستمدة من سيناريوهات في بحث علمي، وليست نتائج يمكن إعادة إنتاجها في كل وقت على الشبكة الرئيسية (mainnet). لذلك ليس من الدقيق أخذها مباشرة كشعارات دعائية. والأكثر قيمة للتحقق هو مراقبة توزيع وصول الرسائل عندما تنطلق العقد وتغادرها بشكل متكرر، وعندما تكون هناك تأخيرات بين المناطق، وعندما تطرأ ازدحامات مفاجئة—وليس الاكتفاء بالنظر إلى المتوسطات فقط
كما يطلب Dusk من العقد التحقق من تواقيع الرسائل، والاحتفاظ بأقران بدلاء داخل نفس سلة التوجيه. الأولى تعمل على تصفية المحتوى المُزوَّر، والثانية تتعامل مع تعطل عقد مفردة خارج الاتصال. وبما أن مُساهمي/حاملي ضمان DUSK يتحملون مسؤولية إنتاج الكتل والتصويت، فإن كفاءة انتشار الشبكة في النهاية ستنعكس على نظام المكافآت والعقوبات وعلى عتبة المشاركة. كلما كان متطلب النطاق الترددي أكثر قابلية للتحكم، زادت احتمالية بقاء المشغّلين العاديين ضمن مجموعة التحقق (validation set). وكلما تعقّدت البنية، لم يعد بالإمكان التنازل عن قدر كافٍ من المراقبة والتدقيق (monitoring & auditing). إن TPS هي أرقام المسرح، أما جدول توجيه Kadcast فهو ذلك المصهر في الخلفية: لا يلمع، لكنه يحدد ما إذا كان Dusk قد يختفي فجأة من المشهد (blackout)
#dusk $DUSK عندما أنظر إلى @Dusk ، فإن أول سوء فهم يتم استبعاده هو اعتباره منصّة تداول لامركزية أخرى. ما يريده Dusk هو أن يكون بوابة جديدة للوساطة المالية الموجهة للأصول المالية المُرمّزة. في الصفحة تظهر صناديق أسواق المال والسندات والأسهم وETF، ومسار المستخدم ليس مجرد الاتصال بمحفظة ثم التداول عشوائياً؛ بل إنه يبدأ بإكمال التحقق من الهوية، ثم اختيار الأصول المؤهلة، مع تنسيق الدفع والحيازة والتسوية. هذا التوصيف ليس “مجنوناً” بما يكفي، لكنه أقرب إلى الواقع المالي. المشكلة هي أنه كلما اقترب المنتج من كونه وسيطاً، لم يعد يمكن الاكتفاء بعرض عوائد جميلة وقائمة أصول فحسب.
التجربة التي يريدها Dusk أن ينافسها ليست فقط منصات RWA مثل Ondo، بل أيضاً Robinhood وشركات الوساطة الشبكية الناضجة. تضع شركات الوساطة التقليدية فتح الحساب والإيداع وتقديم الأسعار وإجراء الأوامر وتقارير المراكز كلها في واجهة واحدة، ويتجاهل المستخدمون إلى حد كبير أنظمة التسوية التي تقف خلف الأصول. إذا اشترط Dusk على المستخدمين فهم شبكة المحفظة، والأرصدة على السلسلة، وحالة التداول وصلاحيات الخصوصية، فإن الميزة التقنية ستتحول إلى عبء تعلم. أنا أفضل أن يقوم Dusk بنقل السلسلة إلى الخلفية، بحيث يرى المستخدمون بوضوح المناطق القابلة للاستثمار، والحد الأدنى للمبلغ، والرسوم، وأوقات تنفيذ الصفقة، وقواعد الاسترداد—بدلاً من جعلهم يتكهنون بما يحدث في كل خطوة.
تكمن ميزة Dusk في أنه لا يكتفي بتغليف الأصول الموجودة بطبقة “رمزية”، بل يسعى إلى ربط التحقق من الأهلية والملكية والتداول والتسوية النهائية في سلسلة عمل واحدة. قد يتيح ذلك تقليل تكرار القيود المحاسبية بين عدة أنظمة، كما يمكن أن يساعد الأصول على الدخول في تطبيقات أكثر على السلسلة. تبدو “قابلية التركيب” جميلة، لكن في الواقع لها حدود. يجب على Dusk توضيح أي الأصول يمكن رهنها، وأيها يمكن حيازتها فقط؛ ومن يتحمل مسؤولية الامتثال عند استدعاء الأصول عبر تطبيقات مختلفة؛ وهل يمكن إيقاف الأصول إذا أخطأ العقد الذكي. من دون هذه الحواجز الواقية، قد يؤدي انفتاح البنية التحتية إلى تضخيم المخاطر.
حالياً ما يزال Dusk في مرحلة ما قبل الإطلاق، لذلك لا يمكن لواجهة السوق في الموقع الرسمي أن تثبت سيولة حقيقية؛ هي لا تعطي إلا توجهاً للمنتج. ما أريد رؤيته ليس طول قائمة الانتظار، بل ما إذا كان الدفعة الأولى من الأصول قادراً على تقديم عروض أسعار بشكل مستمر، وما إذا كان فرق السعر بين البيع والشراء معقولاً، وما إذا كان الاسترداد يتم وفق الوعود، وما إذا كانت الإجراءات المؤسسية ووثائق الضرائب واضحة، وما إذا كان دعم العملاء قادراً على التعامل مع حالات عدم التطابق بين السجلات على السلسلة والسجلات القانونية. إذا تمكن Dusk من معالجة هذه الأسئلة “الرتيبة” بثبات، فقد يخرج عندها من سردية RWA، ليصبح منتجاً مالياً قابلاً للاستخدام فعلاً.
يشعر المرء بأن العالم الرقمي في المستقبل سيشهد حتماً المزيد من أنماط الابتكار. #宇宙之心 اختيار الحضارة بين الكواكب كنقطة دخول، ودمج الخيال مع تقنية البلوك تشين. على الرغم من أن الطريق لن يكون سهلاً، لكن الاتجاه يتميز بطابع فريد. #宇宙之心 $SPCX
عندما يلتقي الرهن ببيتكوين مع سعر فائدة ثابت، يتم حذف المتغير الذي تخشاه المؤسسات للتو
أعتقد أن ما يجب متابعته في Babylon Trustless Bitcoin Vaults هو الخطوة التالية: تحويل تكلفة الاقتراض بالـ BTC الأصلية من أرقام عائمة إلى عقود يمكن إعداد ميزانيتها. تعمل Babylon وAegis على ربط TBV وAave v4 وائتمان بسعر فائدة ثابت، بهدف الوصول إلى الربع الرابع من 2026، لكن ذلك لا يزال يعتمد على التطوير والاختبار. وهذه نقطة لا يمكن تجاوزها؛ فالخطط لا تعني الإطلاق.
هذا الاتجاه من Babylon يصيب جوهر آلام BTCFi الحالية. مديرو التمويل لا يهتمون بنسبة الرهن فقط، بل بما سيتعين دفعه فعليًا من فائدة بعد ثلاثة أشهر أو ستة أشهر. يناسب نموذج Aave سعر الفائدة العائم للسيولة قصيرة الأجل، لكنه يتذبذب مع تغير معدل استخدام الأموال. أما السعر الثابت فيقفل التقلبات داخل بنية المنتج، ما يسمح لخزائن الأموال والصناديق وأموال صانعي السوق بحساب صافي العائد أولًا قبل اتخاذ قرار الاقتراض. يبدو الأمر غير مثير، لكنه أقرب لما توقعه المؤسسات على الورق.
عند المقارنة بين Babylon والاقتراض بالبيتكوين من خلال جهات مركزية، لا تكمن الميزة بالضرورة في أن الفائدة ستكون أقل دائمًا، بل في أن الـ BTC الأصلية لا تزال خاضعة لقيود TBV، وأن قواعد الاقتراض وحالة الرهن يمكن التحقق منها، دون الحاجة إلى تسليم العملة ووعود السداد لطرف إقراض واحد. لكن هذا أيضًا أصعب من بناء حوض عائد فائدة عائم على السلسلة العادية. فمن أين تأتي الأموال ذات الأجل؟ وكيف يتم تسعير السداد المبكر وعدم التطابق بين مدد الاستحقاق؟ وكيف تتصل سيولة Aave وأسعار Aegis ببعضها؟ لا يمكن تغطية كل ذلك برقم ثابت.
تقييمي لتجربة منتج Babylon سيتوقف على عدة تفاصيل. يجب أن تعرض الصفحة في الوقت نفسه معدل الفائدة الاسمي، والرسوم البروتوكولية، وتكلفة التنفيذ عبر السلاسل، ووقت الخروج في أسوأ الحالات. لا ينبغي أن يكون السعر الثابت مريحًا للمقترضين فقط، بل يجب أن يتيح لمقدمي الأموال فهم مدة القفل وتعويض المخاطر. وإذا انكشفت مشكلة نقص السيولة قرب موعد الاستحقاق فقط، فإن ما يُسمّى “اليقين” يكون مجرد نقل التقلب من خانة الفائدة إلى خانة السداد؛ وبهدوء أكثر، هذا في الواقع أصعب للتعامل.
تظهر قيمة Babylon أيضًا عندما يحوّل TBV إلى قاعدة رهن معيارية. هنا يتضح دور كل طرف: Aave يوفر مجمع التمويل، وAegis يصمم منتجات ذات آجال، وBabylon يضمن حدود رهن الـ BTC الأصلية. تحفظي هو أنه كلما زاد عدد طبقات الشراكة، زادت احتمالية أن يتم دفع الرسوم والحوكمة ومسؤوليات الأعطال إلى بعضها البعض. هل يمكن أن يسلّم الربع الرابع سلسلة كاملة شفافة وقابلة للقياس—هذا أهم من قائمة الشركاء. سأستمر في مراقبة تسليم @BabylonLabs_io ، وأضع $BABY فقط ضمن إطار ملاحظة للحوكمة والتوافق مع النظام البيئي. #baby
لا يمكن قطع UTXO إلى نصفين، امتحان TBV مخبأ في لحظة التصفية
اطلعت على Babylon Trustless Bitcoin Vaults TBV، والمثير للاهتمام ليس مجرد أنها تقرض عملات اختبارية، بل أنها تتصادم مع القيود البنيوية للبيتكوين. يمكن تصفية مراكز Aave العادية بنسبة، لكن خزان Babylon يقابل UTXO كاملًا، والتصفية لا تملك إلا أخذ الخزان كاملًا. خزان واحد قد يكون أكثر سهولة، لكن حتى تقلبًا بسيطًا قد يفعّل تصفية شاملة للمركز؛ هذا “تأثير المنحدر” جدير بالمراقبة أكثر من سعر الفائدة. صحة الشبكة في شبكة اختبار Babylon لا تتأثر فقط بسعر BTC؛ بل إن فوائد الديون ستستمر في رفع المخاطر أيضًا. التذبذب الجانبي لا يعني أن المركز آمن؛ فحتى خزان واحد قد ينزلق ببطء نحو خط التصفية.
قسّم Babylon المركز إلى خزانتين: التصفية لجزء منه تأتي أولًا، بينما يبقى BTC الآخر لاحقًا. عندما تنخفض الصحة تحت الحد، يأخذ البروتوكول على الترتيب خزائن كاملة بمبالغ كافية، دون أن يمسح كل المركز دفعة واحدة. هذا يتطلب تفكيرًا أكثر من إقراض WBTC كضمان؛ لأن الأصول المغلّفة يمكن تقسيمها، ولا يحتاج المستخدم إلى إدارة ترتيب التصفية. Babylon يحافظ على BTC الأصلي، لكنه يحوّل الترتيب إلى زرّ مخاطرة. إذا لم تعرض الصفحة نتائج الخسارة تحت أسعار مختلفة، فقد يكون اقتراح التقسيم غير مضبوط. يسمح Babylon بتعديل ترتيب الخزائن، لكن إدارة المخاطر لا تنتهي بعد إنشاء الإعداد. عند تغيّر المعلمات قد لا يعود الخزان الأمامي قادرًا كفاية على امتصاص التصفية؛ وإذا لم تعُد الصفحة حسابها تلقائيًا، فسيصعب على المستخدم معرفة كيفية ترتيب الأرصدة.
تكتمل التصفية على إيثريوم فورًا، لكن استرداد بيتكوين يتطلب انتظار نافذة الإثبات؛ يدفع LLP أولًا لمنفّذ التصفية WBTC، ثم يتولى المتعهدون/المراجِحون استلام الخزائن واسترداد BTC. مقارنةً بالمنصات المركزية التي تخفي العجز داخل دفتر الأستاذ، يكون Babylon أكثر شفافية، لكنه يظل معتمدًا على عوامل. عمق LLP، انحراف المزودين/الأوراكل، تأخر الإثبات، وسيولة WBTC—أي بند منها قد يترقّق في السوق المتطرفة، مما سيُخصم من التصفية الذرية. سيوظّف Babylon قيمة التصفية الزائدة لتقليل الديون أو لاسترداد WBTC. القواعد تحسبها بعدالة لا يعني ألا توجد فجوة في التجربة؛ وعند خصم WBTC أو ضيق السيولة، قد تظهر فجوات بين التعويض الاسمي والقيمة الفعلية.
حكمي على @BabylonLabs_io بسيط: ليست نتيجة TBV هي ما إذا كانت تستطيع الاقتراض في سوق صاعدة، بل هل تستطيع في الانهيار الحاد أن تحصل على أقل قدر، وأن تُصفّي بسرعة، وأن تُرجع القيمة المتبقية بشكل عادل. إذا كانت شبكة الاختبار تستطيع أن تعرض بشكل بديهي محاكاة للخزانتين، وتنبيهات التصفية، وإعادة التمويل، عندها فقط يمكن اعتبار ائتمان BTC الأصلي “قابلًا للاستخدام”. $BABY جدير أكثر بخدمة معلمات المخاطر والحوكمة والترقيات الأمنية، ولا ينبغي أن يتحمل سرد الأسعار. #baby