عند ذكر شبكة Dusk، يتبادر إلى أذهان الكثيرين تلقائيًا وسم "سلسلة الخصوصية". لكن إذا فكرنا بهذه الطريقة، فإننا نكون قد فاتنا أهم شيء.

ما تقوم به Dusk حقًا، ليس جعل التفاعلات على السلسلة تبدو مبهرجة، بل هو الإجابة على سؤال أعمق: عندما تكون الأصول المالية الحقيقية (مع قيود التنظيم والمسؤولية القانونية) على السلسلة، هل يمكن للنظام أن يتحمل ذلك حقًا؟

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

**مبدأ إنشاء الأصول: القواعد يجب أن تكون أولاً**

كيف تتعامل معظم الشبكات العامة؟ أولاً، يتم إصدار الأصول، ثم يتم استخدام الواجهة الأمامية، أو قوائم المسموح لهم، أو العمليات خارج السلسلة لإضافة القواعد. العكس هو الصحيح.

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

اختيار Dusk هو أن يكون قريبًا تمامًا من المنطق الواقعي.

في هذا النظام، عند إنشاء الأصل، يتم كتابة شروط الامتثال مباشرة في طبقة البروتوكول. مؤهلات الحيازة، قيود النقل، متطلبات التحقق — يجب على النظام التحقق من هذه قبل كل تغيير في الحالة.

وهذا يخلق فرقًا رئيسيًا: القواعد ليست ملصقات تُلصق على الأصل، بل هي الهيكل العظمي للأصل نفسه.

**التحقق المسبق والتصحيح اللاحق، أيهما أكثر موثوقية**

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

ما تطلبه Dusk هو أن يكون من المستحيل حدوث ذلك. ليس المعالجة بعد الحدوث، بل أن النظام ببساطة لن يسمح بتلك الخطوة أن تتم. هل يكلف ذلك أكثر؟ نعم. لكن بالمقارنة مع منطق تشغيل الأنظمة المالية الواقعية، فإن هذا الاختيار منطقي وله مبرراته.