ظننت أنني أفهم نموذج خصوصية Dusk حتى بدأتُ بتتبّع ما الذي يجب فعلاً أن يُوثق له بمجرد أن يغادرَت المعاملةُ المحفظة. عندها تصبح البنية أكثر إثارة بكثير من التشفير نفسه.

كلما رسمتُ خريطة لتدفّق المعاملة، تحوّل التركيز أكثر فأكثر بعيدًا عن التشفير نحو التنسيق. إن نقلُ Phoenix ليس مجرد إنشاء برهان صحيح. فهو يعتمد على شهود بُنيت من جذور ميركل الحديثة، وعلى مُبطِّلات (nullifiers) تمنع الإنفاق المزدوج، وعلى أن تتوافق الشبكة على حالةٍ متّسقة قبل أن يتم اعتماد أي شيء. كل طبقة تحمي افتراضًا مختلفًا، وهذا ما يجعل نموذج الثقة يستحق فحصًا دقيقًا.

توضح الوثائق أنه يمكن تفويض إنشاء البرهان وفحص البلوك تشين دون كشف مفاتيح الإنفاق، وذلك بفضل مفاتيح العرض (view keys) وفصل التفويض. يقلل هذا التصميم من تعرّض المفاتيح، لكنه يثير أيضًا أسئلة عملية. كيف يتم التحقق من خدمات إنشاء البرهان المُفوَّضة؟ ماذا يحدث إذا أصبحت ماسحةٌ مُفوَّضة غير متاحة، أو تأخرت، أو حجبَت المعلومات بشكل انتقائي؟ وما الضمانات التي تأتي من التشفير نفسه، وأيّها ما تزال تعتمد على بنية تحتية صادقة تعمل من حوله؟

تنبع أهمية هذا التمييز لأن أقوى أنظمة الخصوصية لا تُحدَّد فقط بما تُخفيه. بل تُحدَّد أيضًا بمدى صمودها عندما تتصرف أجزاء من النظام البيئي المحيط بشكل غير متوقع. بالنسبة إلى Dusk، قد يكون فهم هذه الحدود في النهاية أكثر أهمية من فهم برهانات المعرفة الصفرية بحد ذاتها.

@Dusk $DUSK #dusk