Phoenix و Moonlight موجودان معًا، وسلسلة خصوصية تُبقي منفذًا غير خاص؛ أرى أن هذا التصرف وعيٌ جدًا.

الذين يعملون في مشاريع الخصوصية غالبًا ينحازون إلى التطرف: إمّا إخفاء كل شيء تمامًا والتسويق لكونه «خصوصية مطلقة»، وإمّا التوفير في الجهد والتخلي عن الخصوصية مقابل الكفاءة. خلال السنتين الماضيتين، رأيت عددًا من المشاريع التي ترفع شعار الخصوصية في النهاية تُسقطها هذه المسألة: إمّا أن التدقيق والرقابة لا يمكن التعامل معهما إطلاقًا، وإمّا أن وظيفة الخصوصية تصبح شكلية بلا معنى. عندما قرأت وثائق $DUSK ، وجدت أنها لا تنحاز إلى التطرف. Phoenix هي نموذج UTXO، تقوم بإخفاء التحويلات بحيث تُغطّى كل من الرصيد وعلاقة المعاملات. أما Moonlight فهي نموذج حسابات، تسير ضمن مسار علني؛ الرصيد والتحويلات تظهران على الملأ. وجود قناتين معًا يعني أنهما تتشاركان القدرة على تحويل DUSK، والدفع بالـ gas، والقيام بدور بوابة تنفيذ للعقود؛ ومن يستخدم أي قناة أمرٌ اختياريّ.

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

انطباعي عن تصاميم مثل @Dusk هو أنها تعترف بأنها لا يمكنها تلبية مطالب الجميع؛ وهذا أصدق من محاولة «تجميع حل شامل» بالقوة. في مجال التقنية، في النهاية، غالبًا لا تكون المنافسة حول من كان مثاليًا أكثر، بل حول من هو المستعد أولًا لأن ينهش عظام الواقع. #dusk