#dusk $DUSK @Dusk هذه الأسبوع قَرأتُ ورقة عمل حول نموذج تداول Phoenix الخاصة بـ Dusk (الورقة التي لدى Citadel وبها قسم يتحدث تحديدًا عن Phoenix) حتى النهاية. كنت أظن سابقًا أن الأمر لا يختلف جوهريًا عن مخططات الخصوصية الأخرى في UTXO، لكن بعد الانتهاء أدركت أن التصميم التفصيلي أكثر إحكامًا مما كنت أتخيله.
في Phoenix، لا تُسمّى كل "الأصول" في كل عملية UTXO؛ بل تُسمّى note. لا يقوم الشبكة بتخزين الـ note نفسها مباشرة، بل تضع تجزئة (هاش) الـ note فقط داخل عقدة ورقة في شجرة Merkle. عند صرف note، على المستخدم تقديم إثبات معرفة صفرية يُسمّى tx_proof. هذا الإثبات يقوم بأمرين معًا: أولًا، "إبطال" الـ note التي سيتم إنفاقها (يولد مُعرّفًا فريدًا يُسمّى nullifier لمنع إنفاق نفس الأموال مرتين)، وثانيًا، إثبات أن إجمالي قيمة الـ note الجديدة المُنشأة يطابق إجمالي قيمة الـ note المُبطلة، دون طباعة أموال من لا شيء. ما يراه العالم الخارجي هو فقط: "إبطال note قديمة واحدة" و"إنشاء note جديدة واحدة"؛ أما المبالغ والأطراف المشاركة فلا تكون مرئية خارجيًا.
ما يجعلني أشعر بأن التصميم ذكي فعلًا هو تقسيم المفاتيح: تحتاج لصرف note إلى Secret Key، وهذا لا يعرفه إلا مالك الـ note؛ لكن إذا كنت تريد فقط أن يطّلع المدقق أو جهة الرقابة على ما هي notes التي لديك، وما هي المبالغ المُشفرة داخلها، دون الحاجة إلى تسليم صلاحية إنفاق الأموال، يمكنك مشاركة View Key بشكل مستقل. أي أن "القدرة على الرؤية" و"القدرة على الإنفاق" مفاتيح منفصلة تمامًا. هذا التفكيك بذاته يوفر أساسًا تنفيذيًا على مستوى التشفير لما يعنيه مصطلح "الإفصاح الانتقائي"، وليس مجرد صياغة تسويقية.
إضافةً إلى ذلك، توجد في عقد Transfer تفصيلة يمكن تجاهلها بسهولة: فهي تقوم بدمج (combine) عدة notes صغيرة في خطوة واحدة، لمنع تضخم عدد عقد أوراق شجرة Merkle بلا حدود بما يَسحب أداء الشبكة إلى الأسفل. إن تصميم "دفتر الأستاذ الأساسي يقوم بإدارة النفايات بنفسه" يدل على أن الفريق كان يتوقع منذ البداية تكاليف التشغيل طويلة الأمد للتخزين والتحقق (الإثباتات) من الناحية الهندسية، بدل انتظار أن تكبر الشجرة لدرجة تعطل التشغيل ثم محاولة الإنقاذ.
بالنسبة للمطوّرين، تعني هذه الآلية أنه إذا كنت تريد بناء تطبيق على Phoenix، فستكون عملية توزيع View Key وإدارتها مشكلة تصميم منتج لا يمكن تجنبها—فهي تحدد من يمكنه رؤية حيازة المستخدم في ظل أي شروط. إذا لم تُصمّم هذه الخطوة جيدًا، فإن كلمة "الخصوصية" تصبح مجرد مفتاح على واجهة محفظة ولا تحمل أي قيود عملية.
في Phoenix، لا تُسمّى كل "الأصول" في كل عملية UTXO؛ بل تُسمّى note. لا يقوم الشبكة بتخزين الـ note نفسها مباشرة، بل تضع تجزئة (هاش) الـ note فقط داخل عقدة ورقة في شجرة Merkle. عند صرف note، على المستخدم تقديم إثبات معرفة صفرية يُسمّى tx_proof. هذا الإثبات يقوم بأمرين معًا: أولًا، "إبطال" الـ note التي سيتم إنفاقها (يولد مُعرّفًا فريدًا يُسمّى nullifier لمنع إنفاق نفس الأموال مرتين)، وثانيًا، إثبات أن إجمالي قيمة الـ note الجديدة المُنشأة يطابق إجمالي قيمة الـ note المُبطلة، دون طباعة أموال من لا شيء. ما يراه العالم الخارجي هو فقط: "إبطال note قديمة واحدة" و"إنشاء note جديدة واحدة"؛ أما المبالغ والأطراف المشاركة فلا تكون مرئية خارجيًا.
ما يجعلني أشعر بأن التصميم ذكي فعلًا هو تقسيم المفاتيح: تحتاج لصرف note إلى Secret Key، وهذا لا يعرفه إلا مالك الـ note؛ لكن إذا كنت تريد فقط أن يطّلع المدقق أو جهة الرقابة على ما هي notes التي لديك، وما هي المبالغ المُشفرة داخلها، دون الحاجة إلى تسليم صلاحية إنفاق الأموال، يمكنك مشاركة View Key بشكل مستقل. أي أن "القدرة على الرؤية" و"القدرة على الإنفاق" مفاتيح منفصلة تمامًا. هذا التفكيك بذاته يوفر أساسًا تنفيذيًا على مستوى التشفير لما يعنيه مصطلح "الإفصاح الانتقائي"، وليس مجرد صياغة تسويقية.
إضافةً إلى ذلك، توجد في عقد Transfer تفصيلة يمكن تجاهلها بسهولة: فهي تقوم بدمج (combine) عدة notes صغيرة في خطوة واحدة، لمنع تضخم عدد عقد أوراق شجرة Merkle بلا حدود بما يَسحب أداء الشبكة إلى الأسفل. إن تصميم "دفتر الأستاذ الأساسي يقوم بإدارة النفايات بنفسه" يدل على أن الفريق كان يتوقع منذ البداية تكاليف التشغيل طويلة الأمد للتخزين والتحقق (الإثباتات) من الناحية الهندسية، بدل انتظار أن تكبر الشجرة لدرجة تعطل التشغيل ثم محاولة الإنقاذ.
بالنسبة للمطوّرين، تعني هذه الآلية أنه إذا كنت تريد بناء تطبيق على Phoenix، فستكون عملية توزيع View Key وإدارتها مشكلة تصميم منتج لا يمكن تجنبها—فهي تحدد من يمكنه رؤية حيازة المستخدم في ظل أي شروط. إذا لم تُصمّم هذه الخطوة جيدًا، فإن كلمة "الخصوصية" تصبح مجرد مفتاح على واجهة محفظة ولا تحمل أي قيود عملية.