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