#dusk $DUSK ذهبت للبحث في سبب إزعاج Dusk (الـDusk) لتشغيل نموذجين منفصلين للمعاملات على طبقته الأصلية على الإطلاق، إذ إن Phoenix، وهي النسخة المشفّرة/المحمية، كانت تبدو بالفعل وكأنها تغطي الخصوصية. اتضح أن Phoenix كان يُفترض أن تكون القصة كاملة، وكان ذلك مشكلة.

كان Phoenix يعمل في الأصل كـبروتوكول إخفاء هوية كامل، ضمن الفئة نفسها الخاصة بـ Zcash — لا توجد طريقة لتتبّع دفعة إلى المرسل على الإطلاق. وتم التراجع عن ذلك عمدًا. تمت إضافة إمكانية تحديد هوية المرسل إلى المستلم لضمان امتثال الرمز؛ بعد إدراك أن الأصل غير قابل للتتبّع بالكامل هو بالضبط النوع الذي يؤدي إلى سحب إدراجه من قائمة إحدى البورصات. جاء Moonlight مباشرة بعد ذلك — نموذج عام بالكامل، معتمد على الحسابات، قائم إلى جانب Phoenix، مع تحويل بنقرة واحدة بين الاثنين.

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

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

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

ما زال لدي تردد حول ما إذا كان معظم المستخدمين ينتهون فعلًا باستخدام الاثنين عمدًا عندما يكون mainnet مباشرًا، أم أن Moonlight سيصبح افتراضيًا بهدوء لأنه أبسط، بينما لا يتم اللجوء إلى Phoenix إلا عندما يحتاج شخص ما إليه تحديدًا. @Dusk