#dusk $DUSK @Dusk يُخفِّض كثير من الناس الذين ينظرون إلى Dusk لأول مرة نموذجَي Phoenix وMoonlight إلى مجرد تبديل بسيط—الوضع الخاص والوضع العام. ظللت أفكر بأن هذا التصنيف يتجاهل ما هو مثير فعلًا بخصوص كيفية تموضع هذين النموذجين داخل البروتوكول نفسه.
Phoenix ليس مجرد "خاص". إنه بنية معاملات مختلفة بالكامل. لا تعيش الأموال ضمن أرصدة—بل تعيش كـملاحظات (Notes) مشفَّرة. عند الإنفاق، تستهلك الملاحظات الموجودة وتُنشئ ملاحظات جديدة، مع إثباتات عبر إثباتات معرفة-صفرية (Zero-Knowledge Proofs) أنه لم يحدث إنفاق مزدوج وأن المبالغ تتطابق، دون كشف من أرسل ماذا إلى من أو مقدار ما تم تحويله. المُستلم يرى الملاحظة. لا يراها أحد غيره، ما لم تشارك مفتاح مشاهدة.
أما Moonlight فيعمل بالعكس—نموذج قائم على الحسابات، شفاف بالكامل؛ حيث تكون تفاصيل المُرسِل والمُستلم والمبلغ كلها ظاهرة على السلسلة (On-chain). هذا هو النوع من النماذج الذي يفهمه معظم الناس غالبًا بالفعل من Ethereum.
ما شدَّ انتباهي هو أن كلا النموذجين يتم التسوية عبر نفس عقد التحويل (Transfer Contract) على DuskDS. ليست هناك سلاسل منفصلة أو دفاتر أستاذ منفصلة. يمكن لمعاملة Phoenix ومعاملة Moonlight أن تكون موجودتين داخل الكتلة نفسها، وتتم تسويتهما بواسطة جولة الإجماع نفسها، دون أن يحتاج أي من النموذجين إلى معرفة منطق النموذج الآخر الداخلي.
الجزء الذي يستحق التوقف عنده هو ما الذي يعنيه ذلك للأصول الخاضعة للتنظيم. قد تتطلب معاملة الأوراق المالية شفافية كاملة للجهة التنظيمية وخصوصية كاملة من الطرف المقابل. مفاتيح مشاهدة Phoenix تجعل الإفصاح الانتقائي ممكنًا—تُظهر بالضبط ما يجب، وبالضبط لمن يلزمه ذلك، دون أي شيء إضافي. يتعامل Moonlight مع التدفقات التي تكون الشفافية فيها هي المتطلب افتراضيًا.
ما أجد صعبًا في الإجابة عليه هو ما إذا كان سيسمح المنظمون باعتبار إفصاح يعتمد على مفاتيح المشاهدة مكافئًا لمسارات التدقيق التقليدية. التشفير يعمل. أما ما إذا كانت الأطر القانونية ستلحق بالركب—فهذه مسألة مختلفة تمامًا.
Phoenix ليس مجرد "خاص". إنه بنية معاملات مختلفة بالكامل. لا تعيش الأموال ضمن أرصدة—بل تعيش كـملاحظات (Notes) مشفَّرة. عند الإنفاق، تستهلك الملاحظات الموجودة وتُنشئ ملاحظات جديدة، مع إثباتات عبر إثباتات معرفة-صفرية (Zero-Knowledge Proofs) أنه لم يحدث إنفاق مزدوج وأن المبالغ تتطابق، دون كشف من أرسل ماذا إلى من أو مقدار ما تم تحويله. المُستلم يرى الملاحظة. لا يراها أحد غيره، ما لم تشارك مفتاح مشاهدة.
أما Moonlight فيعمل بالعكس—نموذج قائم على الحسابات، شفاف بالكامل؛ حيث تكون تفاصيل المُرسِل والمُستلم والمبلغ كلها ظاهرة على السلسلة (On-chain). هذا هو النوع من النماذج الذي يفهمه معظم الناس غالبًا بالفعل من Ethereum.
ما شدَّ انتباهي هو أن كلا النموذجين يتم التسوية عبر نفس عقد التحويل (Transfer Contract) على DuskDS. ليست هناك سلاسل منفصلة أو دفاتر أستاذ منفصلة. يمكن لمعاملة Phoenix ومعاملة Moonlight أن تكون موجودتين داخل الكتلة نفسها، وتتم تسويتهما بواسطة جولة الإجماع نفسها، دون أن يحتاج أي من النموذجين إلى معرفة منطق النموذج الآخر الداخلي.
الجزء الذي يستحق التوقف عنده هو ما الذي يعنيه ذلك للأصول الخاضعة للتنظيم. قد تتطلب معاملة الأوراق المالية شفافية كاملة للجهة التنظيمية وخصوصية كاملة من الطرف المقابل. مفاتيح مشاهدة Phoenix تجعل الإفصاح الانتقائي ممكنًا—تُظهر بالضبط ما يجب، وبالضبط لمن يلزمه ذلك، دون أي شيء إضافي. يتعامل Moonlight مع التدفقات التي تكون الشفافية فيها هي المتطلب افتراضيًا.
ما أجد صعبًا في الإجابة عليه هو ما إذا كان سيسمح المنظمون باعتبار إفصاح يعتمد على مفاتيح المشاهدة مكافئًا لمسارات التدقيق التقليدية. التشفير يعمل. أما ما إذا كانت الأطر القانونية ستلحق بالركب—فهذه مسألة مختلفة تمامًا.