شيء واحد تعلمته أثناء التعمق في دورة حياة معاملة Dusk غيّر بالكامل الطريقة التي أنظر بها إلى عبارة “الاستقرار الفوري”.

إرسال معاملة ليست هو نفسه تسوية معاملة.

على @Dusk توجد عدة خطوات بين الأمرين:

الإنشاء + التوقيع
الإرسال
القبول
مساحة الذاكرة (mempool)
الانتشار
إدراج الكتلة
التنفيذ
التحقق/الإقفال النهائي.

يبدو هذا التمييز تقنيًا حتى تضع أصلًا ماليًا خلف المعاملة.

تخيل أن مستثمرًا يشتري ورقة مالية مُرمّزة (tokenized security).

يقول المحفظة إن المعاملة تم إرسالها.

هل يعني ذلك أن الملكية قد تغيّرت؟

ليس بالضرورة.

ما تزال المعاملة بحاجة إلى أن يتم قبولها/إدراجها/تنفيذها & في النهاية إتمامها.

& يجعل Dusk هذا التمييز واضحًا بشكل صريح.

حتى استجابة ناجحة للإرسال لا تعني أن المعاملة موجودة بالفعل في كتلة.

هذا مهم لأن التطبيقات المالية يجب ألا تخلط بين:

هل استلمت الشبكة معاملتي

و: هل قامت الشبكة بإتمام الحالة المالية بشكل نهائي.

بالنسبة لتحويلات العملات الرقمية العادية قد لا يفكر الناس كثيرًا في هذا الفرق.

لكن بالنسبة للأوراق المالية المنظمة يصبح الفرق أكثر أهمية بكثير.

قد يمثل التحويل تغييرًا في الملكية.

قد تمثل الدفعة خطوة التسوية.

يمكن لإجراء مُدار بالامتثال أن يحدد ما إذا كان التحويل مُسموحًا به أصلًا.

لذلك تحتاج هذه التطبيقات إلى معرفة متى تصبح الحالة الأساسية نهائية بدقة.

لهذا السبب أجد تصميم Dusk القائم على “الحسم الحتمي” (deterministic-finality) أمرًا مثيرًا للاهتمام.

المقياس المهم ليس فقط:

ما مدى سرعة ظهور المعاملة؟

بل هو: ما مدى السرعة التي يمكن للتطبيق أن يصل بها إلى حالة يمكنه عندها التعامل مع المعاملة على أنها نهائية بثقة؟

هذا تعريف أكثر معنى لسرعة التسوية بالنسبة لي.

& بصراحة هذه هي تفاصيل البنية التحتية التي أريد أن أرى المزيد منها من مشاريع RWA.

ليس فقط: الأصول تُضاف إلى البلوكشين.

بل: ماذا يحدث لتلك الأصول في كل خطوة بين التفويض والتسوية النهائية؟

هنا يبدأ سرد قصة البنية التحتية الحقيقية.

هل يهتم المستخدمون الأفراد بالحتمية الحقيقية، أم أنها حاجة مؤسسية فحسب؟

#dusk $DUSK