كنت أقرأ بروتوكول «قلعة Dusk Network» أثناء تنفيذ المهمة. مستودع القلعة على GitHub التقط عمليات إرسال (commits) في 8 أغسطس — عملٌ نشط، لا مجرد مواصفة ثابتة — وانتهى بي الأمر عالقًا في نموذج الأطراف الثلاثة مدة أطول مما كنت أعتزم.
تُستخدم عبارة «الإفصاح الانتقائي» كثيرًا في المواد $DUSK @Dusk #dusk . وهي دقيقة. لكن توجد مسألة بنيوية تكشفها البنية المعمارية لا يبرزها العرض (الخطاب).
لدى القلعة ثلاث جهات: المستخدم (User)، مزود الترخيص (LP)، ومقدم الخدمة (SP). تحميك إثباتات ZK من جهة SP — فهي تتحقق من أنك تفي بحد الامتثال دون أن ترى بياناتك الفعلية. وهذا الجزء يعمل كما هو موصوف. لكن مزود الترخيص (LP) يجري فحص KYC كاملًا. فهم يحتفظون ببياناتك. وهم يصدرون رخصة على السلسلة (on-chain). ومن ثم لا يحصل أي مقدم خدمة لاحق إلا على إثبات، وهذا أنيق. الاحتكاك يكون في البداية، أثناء التسجيل/الانضمام (onboarding)، وليس عند كل بوابة لاحقة.
لذا فإن نموذج خصوصية Dusk ليس «مخفى عن السلطة». بل هو «مخفى عن الأطراف المقابلة، ومرئي للجهة التي تختارها». مزود الترخيص يعرف كل شيء. مقدمو الخدمة لا يعرفون شيئًا. وبالنسبة للتمويل المنظم فربما يكون هذا هو التصميم الصحيح — لا بد أن يكون هناك مسؤولٌ عن حفظ البيانات لدى المنظمين. لكن الأمر يبدو مختلفًا عما يفهمه معظم الناس عادةً من «خصوصية البلوك تشين»، والتي تميل إلى أن تعني الإخفاء عن الجميع افتراضيًا.
همم… السؤال المفتوح المثير للاهتمام هو: من الذي يؤدي دور مزود الترخيص (LP) فعليًا في الواقع؟ إذا كان جهة حافظة منظمة أو مزود KYC مرخّص، فهذا يكون تفويضًا/خدمةً لبنية الهوية مع تجربة مستخدم أفضل، وليس هوية لامركزية. لست متأكدًا أن هاتين الصورتين تُحلّان دائمًا تمامًا إلى شيء واحد.
تُستخدم عبارة «الإفصاح الانتقائي» كثيرًا في المواد $DUSK @Dusk #dusk . وهي دقيقة. لكن توجد مسألة بنيوية تكشفها البنية المعمارية لا يبرزها العرض (الخطاب).
لدى القلعة ثلاث جهات: المستخدم (User)، مزود الترخيص (LP)، ومقدم الخدمة (SP). تحميك إثباتات ZK من جهة SP — فهي تتحقق من أنك تفي بحد الامتثال دون أن ترى بياناتك الفعلية. وهذا الجزء يعمل كما هو موصوف. لكن مزود الترخيص (LP) يجري فحص KYC كاملًا. فهم يحتفظون ببياناتك. وهم يصدرون رخصة على السلسلة (on-chain). ومن ثم لا يحصل أي مقدم خدمة لاحق إلا على إثبات، وهذا أنيق. الاحتكاك يكون في البداية، أثناء التسجيل/الانضمام (onboarding)، وليس عند كل بوابة لاحقة.
لذا فإن نموذج خصوصية Dusk ليس «مخفى عن السلطة». بل هو «مخفى عن الأطراف المقابلة، ومرئي للجهة التي تختارها». مزود الترخيص يعرف كل شيء. مقدمو الخدمة لا يعرفون شيئًا. وبالنسبة للتمويل المنظم فربما يكون هذا هو التصميم الصحيح — لا بد أن يكون هناك مسؤولٌ عن حفظ البيانات لدى المنظمين. لكن الأمر يبدو مختلفًا عما يفهمه معظم الناس عادةً من «خصوصية البلوك تشين»، والتي تميل إلى أن تعني الإخفاء عن الجميع افتراضيًا.
همم… السؤال المفتوح المثير للاهتمام هو: من الذي يؤدي دور مزود الترخيص (LP) فعليًا في الواقع؟ إذا كان جهة حافظة منظمة أو مزود KYC مرخّص، فهذا يكون تفويضًا/خدمةً لبنية الهوية مع تجربة مستخدم أفضل، وليس هوية لامركزية. لست متأكدًا أن هاتين الصورتين تُحلّان دائمًا تمامًا إلى شيء واحد.
