#dusk $DUSK @Dusk يتم تنفيذ إعداد السرية الخاص بـ Dusk فعليًا على مسارين منفصلين. على DuskDS، يمثّل نموذج Phoenix القيمة على شكل ملاحظات يتم الالتزام بها داخل شجرة Merkle — إذ إن إنفاق الملاحظة لا يشير إلى أي ملاحظة يتم إنفاقها. بدلًا من ذلك، يقوم المرسل بنشر مُبطِل (nullifier) وإثبات صحة بالمعرفة الصفرية يبيّن أن الإنفاق صحيح وأن الملكية حقيقية وأنه لم يتم إنشاء قيمة من العدم، دون كشف الملاحظة الأساسية. إلى جانب ذلك، يعمل Moonlight كنموذج شفاف قائم على الحسابات على السلسلة نفسها.

على DuskEVM، ومع ذلك، تأتي الخصوصية من مجموعة أدوات مختلفة تمامًا — وحدة تُسمّى Hedger، تجمع بين تشفير متماثل مبني على ElGamal مع إثباتات معرفة صفرية، بالإضافة إلى بنية هجينة من نوع UTXO/حساب. هنا يتفاعل المستخدم مع العقود عبر عنوان EVM معياري، بينما يتولى عنوان Hedger منفصل التعامل مع الأرصدة المُشفّرة، مع فرض الامتثال عبر آلية السماح (allowlisting).

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

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

هل يؤدي الحفاظ على محركين منفصلين للسرية إلى مضاعفة عبء التدقيق بصورة نسبية، أم أن الاعتماد المشترك على إثباتات المعرفة الصفرية يعني أن تكلفة المحرك الثاني الإضافية أقل مما يبدو؟