أصبحتُ أشعر أكثر فأكثر بأن الصعوبة الحقيقية في RWA ليست في “رفع الأصول إلى السلسلة”، بل في ألا يتم نقل الأنظمة القديمة كما هي دون تغيير.
أعدتُ مؤخراً دراسة @Dusk ، ولاحظتُ تفصيلاً كان يُتجاهَل بسهولة من قبل: تركز كثير من مشاريع RWA على خطوة “تحويل الأصل إلى Token”، لكن المشكلة الحقيقية تحدث بعد مرحلة الـToken.
بعد إصدار صندوق استثماري أو سند، كيف يدخل المستثمرون؟ من يملك الأهلية؟ لمن يتم التحويل؟ متى يتم إتمام التسوية؟ وما المعلومات التي يجب الإفصاح عنها؟ هذه هي الأمور التي يجب أن تتعامل معها الأصول المالية فعلياً يومياً. إذا كانت هذه العمليات ما تزال تعتمد على جداول خارج السلسلة، ومراجعة يدوية، ومطابقة متكررة بين أنظمة مختلفة، فقد تكون “الـTokenنة” مجرد تبديل حزمة “بلوكشين” للنظام المالي القديم.
مما شدّني في منهج Dusk هو أنه يحاول وضع هذه العمليات ضمن بنية تحتية واحدة. في المعمارية الرسمية، يتولى DuskDS الإجماع والنهائية وإتاحة البيانات والتسوية؛ ويمكن لـ DuskVM تشغيل عقود Rust/WASM مباشرة؛ بينما يوفر DuskEVM بيئة تنفيذ متوافقة مع EVM. ليست الفكرة أن يكون هناك المزيد من الوحدات فحسب، بل تقليل الفجوات بين قواعد الأصول والتنفيذ والنهائية في التسوية.
وما يستحق النظر أيضاً هو مسار XSC وZedger. في التصميم المبكر لـ Dusk، كان Zedger مبنياً حول قدرات الحسابات للأصول من نوع الأوراق المالية، مع قيود التحويل والتصويت وتوزيع الأرباح وتسوية الامتثال. أي أن دورة حياة الأصل نفسه تصبح شيئاً يتعين على البروتوكول التعامل معه، وليس مجرد إصدار Token ثم نقل كل القواعد إلى خارج السلسلة.
هذا جعلني أُعيد فهم $DUSK : ما يستحق الملاحظة حقاً ليس فقط الخصوصية أو التوافق مع EVM، بل هل يمكن ربط الإصدار والأهلية والتحويل والخصوصية والتسوية في عملية متكاملة.
وبطبيعة الحال، ما إذا كانت البنية ستنجح في النهاية يعتمد على التحقق من الأصول الحقيقية والمؤسسات الحقيقية. وبالنسبة لي، فهذا هو المكان الأكثر جدارة بالاهتمام بعد Dusk: ليس ما إذا كان يمكن نقل الأصول المالية إلى السلسلة، بل بعد نقلها، هل يمكن فعلاً التخلص من تلك الخطوات المتكررة التي كانت تتطلب وجود وسطاء بشكل ضروري. #dusk
#dusk $DUSK @Dusk
أعدتُ مؤخراً دراسة @Dusk ، ولاحظتُ تفصيلاً كان يُتجاهَل بسهولة من قبل: تركز كثير من مشاريع RWA على خطوة “تحويل الأصل إلى Token”، لكن المشكلة الحقيقية تحدث بعد مرحلة الـToken.
بعد إصدار صندوق استثماري أو سند، كيف يدخل المستثمرون؟ من يملك الأهلية؟ لمن يتم التحويل؟ متى يتم إتمام التسوية؟ وما المعلومات التي يجب الإفصاح عنها؟ هذه هي الأمور التي يجب أن تتعامل معها الأصول المالية فعلياً يومياً. إذا كانت هذه العمليات ما تزال تعتمد على جداول خارج السلسلة، ومراجعة يدوية، ومطابقة متكررة بين أنظمة مختلفة، فقد تكون “الـTokenنة” مجرد تبديل حزمة “بلوكشين” للنظام المالي القديم.
مما شدّني في منهج Dusk هو أنه يحاول وضع هذه العمليات ضمن بنية تحتية واحدة. في المعمارية الرسمية، يتولى DuskDS الإجماع والنهائية وإتاحة البيانات والتسوية؛ ويمكن لـ DuskVM تشغيل عقود Rust/WASM مباشرة؛ بينما يوفر DuskEVM بيئة تنفيذ متوافقة مع EVM. ليست الفكرة أن يكون هناك المزيد من الوحدات فحسب، بل تقليل الفجوات بين قواعد الأصول والتنفيذ والنهائية في التسوية.
وما يستحق النظر أيضاً هو مسار XSC وZedger. في التصميم المبكر لـ Dusk، كان Zedger مبنياً حول قدرات الحسابات للأصول من نوع الأوراق المالية، مع قيود التحويل والتصويت وتوزيع الأرباح وتسوية الامتثال. أي أن دورة حياة الأصل نفسه تصبح شيئاً يتعين على البروتوكول التعامل معه، وليس مجرد إصدار Token ثم نقل كل القواعد إلى خارج السلسلة.
هذا جعلني أُعيد فهم $DUSK : ما يستحق الملاحظة حقاً ليس فقط الخصوصية أو التوافق مع EVM، بل هل يمكن ربط الإصدار والأهلية والتحويل والخصوصية والتسوية في عملية متكاملة.
وبطبيعة الحال، ما إذا كانت البنية ستنجح في النهاية يعتمد على التحقق من الأصول الحقيقية والمؤسسات الحقيقية. وبالنسبة لي، فهذا هو المكان الأكثر جدارة بالاهتمام بعد Dusk: ليس ما إذا كان يمكن نقل الأصول المالية إلى السلسلة، بل بعد نقلها، هل يمكن فعلاً التخلص من تلك الخطوات المتكررة التي كانت تتطلب وجود وسطاء بشكل ضروري. #dusk
#dusk $DUSK @Dusk
