#dusk $DUSK @Dusk
راجعتُ هذا الأسبوع بنية ملاحظات Phoenix لأنني أردت أن أفهم ماذا يعني "spent" فعليًا في نموذج خصوصية UTXO — وكانت الإجابة أكثر لفتًا للانتباه مما توقعت.
في نموذج UTXO شفاف مثل Bitcoin، عندما تنفق عملةً يعرف الشبكة بالضبط أي مخرجات غير مُنفقة (unspent) تم استهلاكها. يزيلها من مجموعة UTXO. يمكن للسلسلة تتبّع إلى أين انتقلت الأمور.
يفعل Phoenix شيئًا مختلفًا. عند إنفاق مذكرة (note)، لا يقوم الشبكة بإزالتها من شجرة ميركل (Merkle tree) الخاصة بالملاحظات. النصّ التعريفي (الورقة البيضاء) واضح: "لا تُزال الملاحظات من شجرة ميركل. بدلًا من ذلك، تستمر الشجرة بالنمو بينما تُضاف معاملات جديدة إلى الشبكة."
ما الذي يحدث بدلًا من ذلك: تتم إضافة مُبطِل (nullifier) إلى قائمة مُنفصلة للأبطال. المُبطِل قيمة حتمية ناتجة من المفتاح السري للمذكرة. يتحقق الشبكة أن المُبطِل لم يُرَ من قبل — وهذا هو ما يمنع الإنفاق المزدوج. لكن الشبكة لا تملك طريقة لربط مُبطِل معيّن بمذكرة محددة داخل الشجرة. إنها تعرف أن شيئًا قد تم إنفاقه. لكنها لا تعرف أي مذكرة.
هذا الجزء متين. تأتي قابلية عدم الربط (unlinkability) تحديدًا من عدم تعلّم الشبكة لما لا تتعلمه. تبدو المذكرة في شجرة ميركل متطابقة سواء كانت قد تم إنفاقها أم لا. لا يستطيع المراقب الذي يراقب السلسلة التمييز بين مذكرة غير مُنفقة جديدة وبين مذكرة يكون مُبطّلها موجودًا بالفعل في القائمة.
. مع مرور الوقت، ومع زيادة استخدام Phoenix، تصبح الحالة الكاملة لشجرة ميركل عبئًا تخزينيًا ذا معنى على العقد — إذ تبقى كل تلك الملاحظات المُنفقَة هناك، وغير قابلة للتمييز عن الملاحظات الحية.
أعتقد بالفعل أنها مفاضلة تصميم مقصودة وليست سهوًا — إذ إن إزالة الملاحظات المُنفقَة كانت ستسرّب أي الملاحظات تم إنفاقها، مما يُبطل عدم الربط. لكن هذا يعني أن ضمان الخصوصية لديه تكلفة بنية تحتية حقيقية مرتبطة به، وتتزايد مع الاستخدام.
ما لم أُحدده بعد هو ما إذا كانت هناك آلية تقليم (pruning) للملاحظات القديمة جدًا التي اتفقت الشبكة على أنها مُنفقَة بشكل دائم — أم أن الشجرة مصممة للنمو بشكل غير محدود دون أي استراتيجية ضغط.
راجعتُ هذا الأسبوع بنية ملاحظات Phoenix لأنني أردت أن أفهم ماذا يعني "spent" فعليًا في نموذج خصوصية UTXO — وكانت الإجابة أكثر لفتًا للانتباه مما توقعت.
في نموذج UTXO شفاف مثل Bitcoin، عندما تنفق عملةً يعرف الشبكة بالضبط أي مخرجات غير مُنفقة (unspent) تم استهلاكها. يزيلها من مجموعة UTXO. يمكن للسلسلة تتبّع إلى أين انتقلت الأمور.
يفعل Phoenix شيئًا مختلفًا. عند إنفاق مذكرة (note)، لا يقوم الشبكة بإزالتها من شجرة ميركل (Merkle tree) الخاصة بالملاحظات. النصّ التعريفي (الورقة البيضاء) واضح: "لا تُزال الملاحظات من شجرة ميركل. بدلًا من ذلك، تستمر الشجرة بالنمو بينما تُضاف معاملات جديدة إلى الشبكة."
ما الذي يحدث بدلًا من ذلك: تتم إضافة مُبطِل (nullifier) إلى قائمة مُنفصلة للأبطال. المُبطِل قيمة حتمية ناتجة من المفتاح السري للمذكرة. يتحقق الشبكة أن المُبطِل لم يُرَ من قبل — وهذا هو ما يمنع الإنفاق المزدوج. لكن الشبكة لا تملك طريقة لربط مُبطِل معيّن بمذكرة محددة داخل الشجرة. إنها تعرف أن شيئًا قد تم إنفاقه. لكنها لا تعرف أي مذكرة.
هذا الجزء متين. تأتي قابلية عدم الربط (unlinkability) تحديدًا من عدم تعلّم الشبكة لما لا تتعلمه. تبدو المذكرة في شجرة ميركل متطابقة سواء كانت قد تم إنفاقها أم لا. لا يستطيع المراقب الذي يراقب السلسلة التمييز بين مذكرة غير مُنفقة جديدة وبين مذكرة يكون مُبطّلها موجودًا بالفعل في القائمة.
. مع مرور الوقت، ومع زيادة استخدام Phoenix، تصبح الحالة الكاملة لشجرة ميركل عبئًا تخزينيًا ذا معنى على العقد — إذ تبقى كل تلك الملاحظات المُنفقَة هناك، وغير قابلة للتمييز عن الملاحظات الحية.
أعتقد بالفعل أنها مفاضلة تصميم مقصودة وليست سهوًا — إذ إن إزالة الملاحظات المُنفقَة كانت ستسرّب أي الملاحظات تم إنفاقها، مما يُبطل عدم الربط. لكن هذا يعني أن ضمان الخصوصية لديه تكلفة بنية تحتية حقيقية مرتبطة به، وتتزايد مع الاستخدام.
ما لم أُحدده بعد هو ما إذا كانت هناك آلية تقليم (pruning) للملاحظات القديمة جدًا التي اتفقت الشبكة على أنها مُنفقَة بشكل دائم — أم أن الشجرة مصممة للنمو بشكل غير محدود دون أي استراتيجية ضغط.