#dusk $DUSK يضع الكثيرون نموذج الخصوصية الخاص بـ Dusk Phoenix ضمن نفس الفئة مع Monero — "إخفاء مبالغ المعاملات والعناوين، بحيث لا يمكن رؤيتهما على السلسلة". قمت بإعادة تفكيك منطق التصميم الأهم في Phoenix من خلال نظام المفاتيح الثنائية في الورقة البيضاء، ووجدت أن هذا التصنيف يمحو جوهر الفكرة. #dusk$SPCXB
Phoenix لا يسعى إلى "العمى التام"، بل إلى "الإفصاح الانتقائي". في كل معاملة، يتم إخفاء المبلغ والأطراف افتراضيًا، لكن لدى المُرسِل مفتاح رؤية (view key). يمكنه منح تصريح نشط لجهة تدقيق أو جهة تنظيمية لعرض معاملة محددة. الخصوصية ليست كتلة واحدة صلبة، بل شيء يتحكم فيه المستخدم بنفسه: من يمكنه أن يرى، وماذا يرى، ولفترة كم.
وهذا يختلف عن مسار Monero. يلاحق Monero هدف "عدم القدرة على التتبع من قبل أي أحد"، بينما يهدف Phoenix إلى "أن يكون التتبع ممكنًا فقط لمن حصل على تفويض". بالنسبة إلى سلاسل تهدف إلى احتضان أصول خاضعة للرقابة، فإن هذه الفئة الثانية هي شرط الامتثال أولًا — يمكن التحقق من شرعية المعاملة، لكن لن تُصب البيانات الحساسة تجاريًا على دفتر الأستاذ العام.$SNDKB
لكن هنا يوجد شدّ وجذب: سلطة إدارة مفتاح الرؤية بيد المستخدم، فكيف يمكن فرض التنفيذ عندما يتعلق الأمر بـ "الجهات الرقابية"؟ الإجابة في الورقة البيضاء هي أن المُصدر يمكنه إعداد شروط تدقيق مسبقًا على مستوى عقد الأصل؛ وبدون استيفاء الشروط، لن تكون العناوين قادرة أصلًا على استلام هذا النوع من الأصول. لا تتم موازنة الخصوصية والامتثال عبر التفاوض في كل معاملة، بل تُكتب القواعد في أسس إصدار الأصل.
لذلك عندما أقيم سردية خصوصية DUSK، سأقسمها إلى سؤالين: هل يمكنها حماية السرية التجارية؟ وهل يمكنها، مع الحفاظ على الخصوصية، أن تمنح الجهات التنظيمية المعلومات التي يجب أن تحصل عليها؟ السؤال الثاني صعب، وحتى إن أُحسن تنفيذ الأول فلن تدخل سوق المؤسسات.@Dusk