DUSK في طبقة DuskDS صمم حلاً مثيرًا للاهتمام — وهو دعم نوعين مختلفين تمامًا من منطق المعاملات على نفس السلسلة. أحدهما هو Phoenix، المستند إلى نموذج الخصوصية القائم على UTXO؛ والآخر هو Moonlight، المستند إلى نموذج الحسابات الشفاف. يمكن لنظامين أن يتنقلا بسلاسة على نفس السلسلة.

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

لنبدأ بـ Phoenix. يستخدم منطق UTXO، وهو مشابه لبيتكوين، لكنه يضيف حماية الخصوصية باستخدام ZK-SNARK. كل معاملة تولد ملاحظة (note)، تحتوي على المبلغ والمفتاح العام للمستلم، لكن هذه البيانات مشفرة بالكامل. على السلسلة، يمكن رؤية شيئين فقط: commitment (التزام) و nullifier (إلغاء).

عندما تريد إنفاق هذه الملاحظة، تحتاج إلى تقديم إثبات عدم معرفة (Zero-Knowledge Proof). يجب أن تثبت شيئين: أولاً، أنك تعرف المفتاح الخاص بالملاحظة، وثانيًا، أن nullifier لم يُستخدم من قبل. لكن هذا الإثبات لا يكشف عن محتوى الملاحظة نفسه — وهو أمر ذكي جدًا.

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

أما Moonlight فهي العكس تمامًا. تعتمد على نموذج الحسابات، والمعاملات شفافة تمامًا. من أرسل كم وإلى من، واضح على السلسلة. هذا النموذج أكثر كفاءة، ومناسب للمعاملات عالية التردد وسيناريوهات التسوية.

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