#dusk $DUSK لقد أعدتُ مؤخرًا مشاهدة مسار Dusk مرةً أخرى، وأعتقد أن أكثر ما يستحق الملاحظة فيه ليس أنه يضيف كمًّا من المفاهيم أكثر، بل هل يمكن إدخال الخصوصية والامتثال وتجربة المطورين فعلًا ضمن نفس المنظومة. تركز كثير من السلاسل العامة على الرسوم المنخفضة والأداء العالي أو التوافق مع EVM، لكن المشاكل التي تواجه إدخال الأصول المالية على السلسلة تتجاوز بكثير نشر العقود فقط. فالمؤسسات تحتاج إلى أن لا تُفحص بيانات المعاملات بشكل عشوائي، وفي الوقت نفسه يجب استيفاء متطلبات التدقيق والرقابة والتسوية النهائية. وهذا يفرض على الشبكة الأساسية متطلبات أكثر تعقيدًا.$SNDKB
فكرة تصميم Dusk هي فصل القدرات المختلفة ومعالجتها بشكل مستقل. يتولى DuskDS الإجماع وتوافر البيانات والتسوية النهائية، بينما يوجه DuskVM الأصلي قدرات Rust وWASM وما يتصل بالمعرفة الصفرية، أما DuskEVM فيجعل مطوري Solidity قادرين على الاستمرار باستخدام الأدوات المألوفة لديهم. إن هذا النوع من المعمارية يمكنه فعلًا تقليل عتبة الهجرة، ويترك للمطورين مساحة أكبر للاختيار. وبالنسبة للفرق التي تمتلك خبرة تطوير على إيثيريوم، فقد يكون البدء بطريقة EVM ثم التعرف تدريجيًا على قدرات الخصوصية الأصلية في Dusk أكثر واقعية من تعلم بيئة جديدة بالكامل من الصفر.
لكن التوافق مع EVM لا يعني أن الخصوصية تكتمل تلقائيًا. فطريقة استدعاء Hedger في التطبيق، وكيف تُجرى تسوية الأصول عبر الطبقات، ومن يتحمل تكلفة إثباتات الخصوصية—كل ذلك سيؤثر على تجربة الاستخدام النهائية. وبالخصوص بالنسبة للأصول الخاضعة للرقابة، فإن وجود خيارات بين الإفصاح الانتقائي والإخفاء الكامل يتطلب تصميمًا أدق للأذونات.$SPCXB
لذلك أرى أن المفتاح في المرحلة التالية من Dusk ليس الاستمرار في تكديس المصطلحات التقنية، بل إثبات أن هذه البنية متعددة الطبقات يمكن استدعاؤها بشكل مستقر في تطبيقات واقعية. لا يمكن لقيمة الشبكة أن تُبنى على أساس متين إلا إذا تحققت في آنٍ واحد عتبة التطوير ونتائج الخصوصية وتجربة التعامل عبر الطبقات وعمليات الامتثال. فهل تهتم أكثر بالحد التقني لـ Dusk، أم بقدرتها على إنجاز أول تطبيق مالي قابل للاستمرار في التشغيل؟
#dusk @Dusk