تعليق صفحة الدفع لمدة خمس ثوانٍ، ثم ارتبكت يدي فبِعتّها مرة أخرى. في الدفع العادي يمكنك تتبّع معاملتين في السجلات، لكن في المعاملات الخصوصية التي تُخفي المبلغ والأطراف المشاركة، كيف يعرف الشبك ما الذي يمنعك من إنفاق نفس المبلغ مرتين؟
اتّبعت هذا السؤال، وقمت بإعادة تفكيك Phoenix الخاصة بالعنوان @Dusk . لا يسجّل الأموال كرصيدٍ مكشوف، بل يقسّمها إلى notes مشفّرة، ويكتب التزام الـ note داخل شجرة Merkle. عند الإنفاق، يتولّى إثبات ZK (الدليل ذو المعرفة الصفرية) إثبات أن الـ note موجود فعلًا وأن المستخدم يتحكم به وأن المدخلات والمخرجات متوازنة، دون كشف المبلغ المحدد أو الـ notes المقابلة.
الذي يلتقط مشكلة “double-spend” هو الـ nullifier؛ ويمكن اعتباره علامة إبطالٍ فريدة تتركها الـ note بعد استخدامها. لا يستطيع العالم الخارجي استنتاج الـ note الأصلية منه، لكن الشبكة تستطيع التحقق مما إذا كانت هذه العلامة قد ظهرت من قبل. إذا تم بناء الـ note نفسها على أنها معاملتان، فستحدث تعارضات على نفس الـ nullifier، ولا يمكن أن تكون المعاملتان صحيحتين في الوقت نفسه.
تذكر وثائق Dusk أيضًا: في معاملات Phoenix، عند حدوث تعارض في الـ nullifier داخل mempool، لن يتم استبدال المعاملة القديمة إلا بمعاملة جديدة يكون سعر الغاز فيها أعلى بشكل صارم. إعادة إرسال رسوم أعلى قد تعني أنك تستبدل الدفع، لا أنك تُنشئ معاملة جديدة. لكن بمجرد أن تدخل المعاملة إلى كتلة “مقبولة” ويتم تنفيذها، حتى لو أرجع العقد خطأ، سيتم استهلاك الـ note وGas المرتبطين بها؛ وبعد ذلك يجب انتظار أن تُدرج الكتلة ضمن الحالة المؤكدة (finalized) لكي يُعد الأمر حاسمًا فعلًا.
لذلك، الحل التشفيري يعالج أن الأصول لا يمكن نسخها، بينما ما يزال المحفظة بحاجة إلى شرح حالة المعاملات: قيد الانتظار، مُستبدلة، فشل التنفيذ، ثم التأكيد النهائي. إذا عرض المحفظة كلمة “فشل” فقط، فقد يواصل المستخدم المحاولة مرارًا.
$DUSK هو الغاز والأصول المُرهَنة، لكن لا يمكنه أن يكون بمثابة ضمان لتجربة المنتج. أريد حقًا معرفة ما إذا كانت المحفظة يمكنها عرض علاقة الاستبدال، وأسباب استهلاك الـ note، وحالة النهائيّة. يمكن للخصوصية إخفاء التفاصيل، لكنها لا يمكنها إخفاء ما إذا كانت المعاملة قد حدثت.
#dusk $DUSK
اتّبعت هذا السؤال، وقمت بإعادة تفكيك Phoenix الخاصة بالعنوان @Dusk . لا يسجّل الأموال كرصيدٍ مكشوف، بل يقسّمها إلى notes مشفّرة، ويكتب التزام الـ note داخل شجرة Merkle. عند الإنفاق، يتولّى إثبات ZK (الدليل ذو المعرفة الصفرية) إثبات أن الـ note موجود فعلًا وأن المستخدم يتحكم به وأن المدخلات والمخرجات متوازنة، دون كشف المبلغ المحدد أو الـ notes المقابلة.
الذي يلتقط مشكلة “double-spend” هو الـ nullifier؛ ويمكن اعتباره علامة إبطالٍ فريدة تتركها الـ note بعد استخدامها. لا يستطيع العالم الخارجي استنتاج الـ note الأصلية منه، لكن الشبكة تستطيع التحقق مما إذا كانت هذه العلامة قد ظهرت من قبل. إذا تم بناء الـ note نفسها على أنها معاملتان، فستحدث تعارضات على نفس الـ nullifier، ولا يمكن أن تكون المعاملتان صحيحتين في الوقت نفسه.
تذكر وثائق Dusk أيضًا: في معاملات Phoenix، عند حدوث تعارض في الـ nullifier داخل mempool، لن يتم استبدال المعاملة القديمة إلا بمعاملة جديدة يكون سعر الغاز فيها أعلى بشكل صارم. إعادة إرسال رسوم أعلى قد تعني أنك تستبدل الدفع، لا أنك تُنشئ معاملة جديدة. لكن بمجرد أن تدخل المعاملة إلى كتلة “مقبولة” ويتم تنفيذها، حتى لو أرجع العقد خطأ، سيتم استهلاك الـ note وGas المرتبطين بها؛ وبعد ذلك يجب انتظار أن تُدرج الكتلة ضمن الحالة المؤكدة (finalized) لكي يُعد الأمر حاسمًا فعلًا.
لذلك، الحل التشفيري يعالج أن الأصول لا يمكن نسخها، بينما ما يزال المحفظة بحاجة إلى شرح حالة المعاملات: قيد الانتظار، مُستبدلة، فشل التنفيذ، ثم التأكيد النهائي. إذا عرض المحفظة كلمة “فشل” فقط، فقد يواصل المستخدم المحاولة مرارًا.
$DUSK هو الغاز والأصول المُرهَنة، لكن لا يمكنه أن يكون بمثابة ضمان لتجربة المنتج. أريد حقًا معرفة ما إذا كانت المحفظة يمكنها عرض علاقة الاستبدال، وأسباب استهلاك الـ note، وحالة النهائيّة. يمكن للخصوصية إخفاء التفاصيل، لكنها لا يمكنها إخفاء ما إذا كانت المعاملة قد حدثت.
#dusk $DUSK
