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