#dusk $DUSK اليوم أعدت مشاهدة نموذج الخصوصية الخاص بـ@Dusk من Phoenix، وأقرب ما يمكن تجاهله ليس هو إثباتات المعرفة الصفرية نفسها، بل هو مسار “مفتاح العرض”. كثيرون يفهمون سلسلة الخصوصية على أنها: إما أن تُخفي كل شيء، أو أن تُعلِن كل شيء. لكن نهج Phoenix أقرب إلى: إخفاء المبلغ والمرسل والمستلم افتراضيًا، ولا يمكن للمشاهد المُصرّح له فقط استعادة تفاصيل معاملة بعينها.
هذا التصميم مهم جدًا في سيناريوهات التمويل. قد تتضمن معاملة مؤسسة واحدة أطرافًا مقابلة ومبلغًا ونوع أصل وتاريخ تسوية. في نموذج الحسابات العامة، بمجرد وضع هذه الحقول على السلسلة، تصبح إيقاعات التعامل وتغيرات المراكز مكشوفة لكل من يراقب. أما الخصوصية الكاملة فستجعل من المستحيل تقريبًا على الجهات الامتثالية التحقق من مصدر الأموال. مفتاح العرض ليس “بابًا خلفيًا” سحريًا، بل هو قصر نطاق الإفصاح على مستلمين محددين أو معاملات محددة أو أوقات محددة. المشكلة فقط تكمن في كيفية تعريف حدود التفويض.
لنضرب مثالًا: ليس الأمر كأننا نغلق دفتر الأستاذ كاملًا في خزنة ونمنح المدقق مفتاحًا رئيسيًا؛ بل إن كل إيصال يحمل صلاحية عرض مؤقتة قابلة للإلغاء. يستطيع المدقق التحقق مما إذا كانت أموالًا معينة تتوافق مع عقد ما، دون الحاجة إلى أخذ سجل العميل الكامل معه. إذا كان نطاق الإفصاح واسعًا جدًا ستفشل الخصوصية؛ وإذا كان ضيقًا جدًا فلن تكتمل أعمال الامتثال.
تذكر الوثائق الرسمية فعلًا “الإفصاح الانتقائي”، لكن ما زالت هناك أمثلة متسلسلة أقل في المواد المتاحة حول عمليات التدقيق الواقعية. الاختبار الحقيقي هو ما إذا كان مفتاح العرض يمكن دمجه في برامج التدقيق وحلول الحفظ وأيضًا خدمات الامتثال. إذا احتاجت المؤسسة إلى تصدير البيانات الأولية لإنجاز المطابقة، فستُعوّض كلفة التشغيل عن مزايا الخصوصية التقنية.
لذلك، عندما أرى #dusk ، لن أهتم فقط بما إذا كانت المعاملات مجهولة. بالنسبة لـ DUSK، الأهم هو ما إذا كانت أدوات الإفصاح الانتقائي تُعتمد من قِبل مزودي خدمات الامتثال، وهل يمكن أن تُثبت عملية التدقيق الاكتمال بحيث تجمع بين الخصوصية وقابلية التحقق في آنٍ واحد. امتلاك التكنولوجيا مجرد نقطة بداية؛ ولا يُعد ذلك مُطبّقًا فعليًا إلا عندما يدخل في دورة التدقيق اليومية. #dusk @Dusk $DUSK