كنت أنظر إلى كيفية تعامل Phoenix مع الملاحظات المُنْفَقة، وكنت أتوقع أن يقوم المُبطِّلات (nullifiers) فقط بإبطال المخرجات القديمة لـ UTXOs بهدوء ثم المضي قدمًا. هذا هو نموذج التفكير الذي تمنحك إياه الشفافية في السلاسل: تحدث عملية إنفاق، يتم تحديث السجل، ويصبح البيانات القديمة بلا أهمية.

لكن الأمر ليس كذلك تمامًا هنا. الملاحظة القديمة لا تختفي. يبقى تجزئها (hash) موجودًا بشكل دائم في شجرة ميركل للملاحظات — سواء كانت مُنْفَقة أم لا، لا تزال الورقة (leaf) موجودة، لأن الشجرة تُضاف فقط (append-only) ولا يمكن للشبكة أن تقوم بقطع/حذف ملاحظة بشكل انتقائي دون أن تكشف أيها كانت إنفاقًا حقيقيًا مقابل كونها مُغَيِّرات/قرائن (decoys). المُبطِّل هو ما يُبطل الملاحظة فيما بعد، وقد تم تصميمه عمدًا بحيث لا يستطيع أي مراقب ربط مُبطِّل مرة أخرى بالملاحظة التي جاء منها.

وهذا ما جعلني أتوقف: الخصوصية هنا لا تتحقق بحذف المعلومات، بل بتحصيل معلومات لا يمكن ربطها ببعضها. الشجرة لا تكبر إلا. كل محفظة تقوم بالمزامنة من البداية عليها أن تمر عبر مجموعة ملاحظات أكبر من الرصيد غير المنفق الفعلي الذي تهتم به — فالملاحظات المُنْفَقة تصبح عبئًا لا قيمة له بالنسبة للرصيد، لكنها لا تزال بحاجة إلى معالجتها لإثبات الانتماء (membership) بشكل صحيح.

هذا ليس بالضرورة عيبًا. إنه ثمن جعل عملية الربط عديمة المعنى حسابيًا بدلًا من أن تكون محظورة قانونيًا. لكن هذا يعني أن سرية Phoenix تتدرج مع نمو الحالة (state growth)، لا ضدها — شيء يستحق المتابعة مع ازدياد الاستخدام. #dusk $DUSK @Dusk