التفصيلة عند الغسق التي جعلتني أنظر مرتين ليست مكدس ZK — بل ما يفعله المحفظة عندما لا يعرف ما إذا كانت المعاملة المُشفّرة قد نجحت.

في Dusk Wallet v0.1.0، حصلت معاملات Phoenix على تتبّع “pending-nullifier reservation”. ويذكر سجل التغييرات أن هذه الحجوزات لا تُطلق تلقائيًا بعد انتهاء مهلة المراقِب، أو حالة غير معروفة، أو حالة “تمت إزالته”، أو بعد عملية مسح واحدة مفقودة من mempool.

لماذا نُبقي الأموال متقيّدة عمدًا بعد حالة من عدم اليقين؟

لأن Phoenix ينفق notes. إذا أعادت المحفظة فورًا استخدام مجموعة notes القابلة للإنفاق نفسها بينما قد تكون المعاملة الأولى ما تزال تصل، فقد يؤدي ذلك إلى إنشاء عمليات إنفاق مُشفّرة متعارضة. كما أضاف Dusk قفل “spend mutex” لمنع إنشاء عمليات إرسال Phoenix المتزامنة ضد نفس الـ notes.

حقيقة: هذه منطق سلامة على مستوى المحفظة، وليست قاعدة توافق جديدة. تفسيرِي: Dusk تختار تجربة مستخدم محافظة بدلًا من إتاحة الرصيد بشكل متفائل عندما تكون حالة المعاملة غير واضحة.

هذه المفاضلة تهم. أنظمة الخصوصية تحتاج أكثر من تشفير قوي؛ يجب أن يظل التعامل مع حالة المحفظة آمنًا عندما تكون الرؤية الشبكية غير مكتملة.

بالنسبة لـ DUSK، أنا أراقب ما إذا كانت الإصدارات المستقبلية للمحفظة ستستطيع تقصير تلك الفترة “غير المؤكدة” دون إضعاف الحماية. إلى أي مدى ينبغي لمحفظة خصوصية أن تُفك قفل الأموال عندما تكون حالة السلسلة غير واضحة؟

@Dusk $DUSK #dusk