ما وراء المعاملات الخاصة: فهم معمارية DUSK. دخلت وأنا أتوقع أن تكون طبقة الخصوصية هي المسار الافتراضي، فوجدت العكس. يشغّل Dusk ($DUSK , #dusk , @Dusk ) نموذجين للمعاملات جنبًا إلى جنب، Phoenix وMoonlight، وتصف الوثائق Moonlight، وهو نموذج حسابي شفاف، بأنه "فقط الطريقة الشفافة لنقل DUSK" على مستوى البروتوكول. أما Phoenix، وهو نموذج الحماية الفعلي بالمعرفة-الصفرية مع ملاحظات مُشفّرة وnullifiers، فهو من يقوم بالعمل التشفيري الأصعب، لكنه يُقدَّم كمسار مُتعمَّد ومُختار مسبقًا أكثر من كونه الحالة الافتراضية الراسخة. كلاهما يتسوى عبر نفس عقد Transfer، وكلاهما يدفع رسوم الغاز، وكلاهما يمكنه تشغيل استدعاء عقد، لذا فاختيار أحدهما ليس عائقًا وظيفيًا؛ بل هو قرار تصميمي حول أي سلوك يُعامل على أنه أمر عادي. سلسلة بُنيت خصيصًا لحل تنفيذ العقود الذكية الخاصة تنتهي بوصف حساباتها العادية كالتفسير الافتراضي، ومحرك الخصوصية كالميزة التي تتوجه إليها عند الحاجة. ربما هذا مجرد تسلسل UX جيد لعمليات الإعداد المؤسسي. أو ربما يشير إلى حالة الاستخدام التي تُفعَّل فعليًا أولًا عندما يبدأ الاستخدام الحقيقي بالتدفق. أيٌّ منهما تعمل Dusk فعلًا على تحسين اعتماده؟