كنت أراجع نموذج المعاملات الشفاف لدى Dusk، وتجاوزت في البداية شيئًا بدا بدهيًا تقريبًا: الـ nonce.
Moonlight هو نموذج معاملات مبني على الحسابات لدى Dusk. يمتلك كل حساب مفتاحًا عامًا ورصيدًا وnonce، ويعمل الـ nonce كعداد للمعاملات التي يتم إرسالها من ذلك الحساب.
ذلك العداد الصغير يقوم بمهمة أكبر مما يبدو في البداية.
يربط الورقة البيضاء صراحةً الـ nonce بحماية إعادة التشغيل (replay protection). لا تُمنح المعاملة الإذن فقط لمجرد أن التوقيع صالح؛ بل يجب أيضًا أن يكون تسلسل معاملات الحساب منطقيًا.
إنها واحدة من قطع البنية التحتية للبلوكشين التي لا يلاحظها المستخدمون تقريبًا عندما تعمل بشكل صحيح.
توقّع معاملة، تعالجها الشبكة، يتغير رصيدك وتنتقل إلى ما بعدها.
لكن بدون آليات تمنع قبول معاملة قديمة صالحة مرة أخرى، يمكن أن تتحول نفس عملية التفويض المحتملة إلى مشكلة أمنية مختلفة تمامًا.
ما أراه مثيرًا للاهتمام حول Dusk هو أن Moonlight و Phoenix يحققان متطلبات المعاملات الأساسية نفسها عبر نماذج مختلفة تمامًا.
يعرض Moonlight حالة الحساب والأرصدة وبيانات المعاملات الوصفية علنًا. أما Phoenix فينقل التحقق من الرصيد وحماية الإنفاق المزدوج إلى إثباتات ZK وnullifiers. ومع ذلك، لا يزال كلاهما يتعين عليهما إثبات الملكية، ومنع القابلية للتلاعب (malleability) ووقف الإنفاق المزدوج.
لذا فالقرار الحقيقي في التصميم ليس مجرد “علني مقابل سري”.
بل هو: إلى أي مدى يمكن للشبكة التحقق مباشرة من انتقال الحالة، مقابل مقدار ما يجب إثباته بشكل تشفيري.
وهذا يجعل الـ nonce المتواضع أكثر إثارة للاهتمام مما يبدو.
المعاملة المرئية هي مجرد السطح. تحتها توجد مجموعة من القواعد التي تضمن عدم إمكانية إعادة تشغيل نفس عملية التفويض ببساطة.
كم عدد “ميزات” البلوكشين التي تكون افتراضات أمنية غير مرئية للمستخدمين، ولا يلاحظونها إلا عند فشلها؟
@Dusk $DUSK #dusk
Moonlight هو نموذج معاملات مبني على الحسابات لدى Dusk. يمتلك كل حساب مفتاحًا عامًا ورصيدًا وnonce، ويعمل الـ nonce كعداد للمعاملات التي يتم إرسالها من ذلك الحساب.
ذلك العداد الصغير يقوم بمهمة أكبر مما يبدو في البداية.
يربط الورقة البيضاء صراحةً الـ nonce بحماية إعادة التشغيل (replay protection). لا تُمنح المعاملة الإذن فقط لمجرد أن التوقيع صالح؛ بل يجب أيضًا أن يكون تسلسل معاملات الحساب منطقيًا.
إنها واحدة من قطع البنية التحتية للبلوكشين التي لا يلاحظها المستخدمون تقريبًا عندما تعمل بشكل صحيح.
توقّع معاملة، تعالجها الشبكة، يتغير رصيدك وتنتقل إلى ما بعدها.
لكن بدون آليات تمنع قبول معاملة قديمة صالحة مرة أخرى، يمكن أن تتحول نفس عملية التفويض المحتملة إلى مشكلة أمنية مختلفة تمامًا.
ما أراه مثيرًا للاهتمام حول Dusk هو أن Moonlight و Phoenix يحققان متطلبات المعاملات الأساسية نفسها عبر نماذج مختلفة تمامًا.
يعرض Moonlight حالة الحساب والأرصدة وبيانات المعاملات الوصفية علنًا. أما Phoenix فينقل التحقق من الرصيد وحماية الإنفاق المزدوج إلى إثباتات ZK وnullifiers. ومع ذلك، لا يزال كلاهما يتعين عليهما إثبات الملكية، ومنع القابلية للتلاعب (malleability) ووقف الإنفاق المزدوج.
لذا فالقرار الحقيقي في التصميم ليس مجرد “علني مقابل سري”.
بل هو: إلى أي مدى يمكن للشبكة التحقق مباشرة من انتقال الحالة، مقابل مقدار ما يجب إثباته بشكل تشفيري.
وهذا يجعل الـ nonce المتواضع أكثر إثارة للاهتمام مما يبدو.
المعاملة المرئية هي مجرد السطح. تحتها توجد مجموعة من القواعد التي تضمن عدم إمكانية إعادة تشغيل نفس عملية التفويض ببساطة.
كم عدد “ميزات” البلوكشين التي تكون افتراضات أمنية غير مرئية للمستخدمين، ولا يلاحظونها إلا عند فشلها؟
@Dusk $DUSK #dusk