قضيت ساعة أقرأ وثائق DUSK بحثًا عن الشيء الذي تدّعي كل سلسلة خصوصية أنها تقدمه: المعاملات السرّية افتراضيًا. $DUSK , #dusk , @Dusk . لكن الذي وجدته بدلًا من ذلك هو تفرّع طريق لا يلاحظه معظم الناس إلا إذا كانوا في الواقع يبنون. طبقة الأساس للمعاملة تكون مُحمّاة، بالتأكيد، لكن لحظة أن تريد قابلية التركيب (composability) مع أي شيء يشبه العقود الذكية، يتم تحويلك إلى Piecrust ومسار تنفيذ لعقدٍ سرّي منفصل ليس هو الشيء الذي تطرحه المحافظ افتراضيًا. لذا فإن صياغة "السرّية افتراضيًا" صحيحة من الناحية التقنية للتحويلات، لكنها مشروطة بهدوء للاستخدام البرمجي. برزت نقطة تصميم واحدة: الشبكة تتعامل مع الخصوصية وقابلية التدقيق كخيار (toggle) على مستوى التطبيق، لا كضمان على مستوى الشبكة بالكامل — وهذا يعني أن الوضع الفعلي للخصوصية لأي شيء يُبنى على DUSK يعتمد كليًا على أي وحدة (module) اختار المطوّر توصيلها. هذه ليست عيبًا بالضبط، بل قرار معماري له تبعات لا يروّج لها أحد. يجعلني أتساءل كم عدد تطبيقات "تحافظ على الخصوصية" فوق سلاسل مثل هذه ليست سوى تطبيقات قادرة على الخصوصية، منتظرة من يقوم بتفعيل الميزة.