#dusk $DUSK اليوم كنت أقرأ في وثائق نموذج معاملات Phoenix رقم @Dusk ، وعلقت في مفهوم أساسي في سلاسل الخصوصية لكنه يُتجاوز بسهولة: $DUSK طبقة البروتوكول نفسها لا يوجد فيها شيء اسمه "حساب".
على بلوكتشين مثل الإيثيريوم الشفّاف، كل عنوان هو حساب، وتكون الأرصدة وسجلّ المعاملات مرئيين بالكامل على مستوى الشبكة. لكن Phoenix يسير على خط UTXO—أي أن طبقة البروتوكول لا تخزن حسابات، بل تخزن مجموعة من الأشياء تُسمّى "note". يحتوي كل note على مبلغ وشروط إنفاق لعملية واحدة. والمعاملة هي عملية استهلاك notes قديمة وإنتاج notes جديدة. يتم إدخال تجزئة (hash) الـ note الجديد في شجرة Merkle، وتخزن أوراق الشجرة البصمات (fingerprints) لكل note على مستوى الشبكة.
تصميم منع الإنفاق المزدوج هنا يصبح مثيرًا للاهتمام. كل معاملة تُرفق مجموعة من قيم حتمية تُسمّى "nullifier"؛ كل nullifier يتوافق مع note تم استهلاكه، ويقوم بتمييزه على أنه غير صالح. لكن طريقة توليد nullifier تمر بمعالجة تشفيرية؛ فيرى المراقب الخارجي أن nullifier معيّن ظهر، فيفهم أن "هناك note تم إنفاقه"، لكنه لا يستطيع ربط ذلك nullifier تحديدًا بأي note بعينها. تؤكد الشبكة صحة الإلغاء (核销)، لكن لا تعرف من قام بالإلغاء.
أشبه ذلك: ليس كتحقق البنك من الحسابات—تفتح صفحة معيّنة فتراها تكشف عن كل المعاملات لشخص ما. بل أقرب إلى تمزيق كل إيصال ثم رميه في آلة التقطيع، وبعد ذلك بإخبار النظام بشكل مُشفّر: "تم الإلغاء لهذه الإيصال". النظام يؤكد أن الإلغاء صحيح، لكن الشخص الذي يمزّق الأيصالات لا يستطيع إعادة بناء الإيصال الأصلي، ولا يعرف لمن كان هذا الإيصال يعود.
لكن هذه البنية ليست بلا تكلفة أيضًا. مع نمو عدد notes، تزيد شجرة Merkle وتعقيد صيانتها؛ إذ يحتاج كل عقدة كاملة إلى الحفاظ على هيكل الشجرة كاملًا. كما أن توليد nullifier يعتمد على افتراضات تشفيرية في الطبقة السفلية؛ فإذا اختيارات المعلمات سارت في اتجاه خاطئ، قد تصبح حماية الخصوصية شكلية. الوثائق الرسمية تنشر تفاصيل البروتوكول، لكن في بيئة الإنتاج، يجب بعد إطلاق الشبكة الرئيسية الاستمرار في المقارنة والتأكد من معدل تصادم nullifier وسرعة تضخم الشجرة.
عندما أنظر إلى طبقة الخصوصية الخاصة بـ #dusk ، لن أكتفي بملاحظة عبارة "استخدمت UTXO". ما يجب تتبعه فعلًا هو منحنى نمو عدد notes، وحجم مجموعة nullifier، وحِمل التخزين على عُقد التحقق. $DUSK تُدرج الخصوصية في قاع البروتوكول، لكن تكلفة صيانة الدفتر في الأسفل—في النهاية—ستنعكس على أداء الشبكة كلها.
#dusk @Dusk
على بلوكتشين مثل الإيثيريوم الشفّاف، كل عنوان هو حساب، وتكون الأرصدة وسجلّ المعاملات مرئيين بالكامل على مستوى الشبكة. لكن Phoenix يسير على خط UTXO—أي أن طبقة البروتوكول لا تخزن حسابات، بل تخزن مجموعة من الأشياء تُسمّى "note". يحتوي كل note على مبلغ وشروط إنفاق لعملية واحدة. والمعاملة هي عملية استهلاك notes قديمة وإنتاج notes جديدة. يتم إدخال تجزئة (hash) الـ note الجديد في شجرة Merkle، وتخزن أوراق الشجرة البصمات (fingerprints) لكل note على مستوى الشبكة.
تصميم منع الإنفاق المزدوج هنا يصبح مثيرًا للاهتمام. كل معاملة تُرفق مجموعة من قيم حتمية تُسمّى "nullifier"؛ كل nullifier يتوافق مع note تم استهلاكه، ويقوم بتمييزه على أنه غير صالح. لكن طريقة توليد nullifier تمر بمعالجة تشفيرية؛ فيرى المراقب الخارجي أن nullifier معيّن ظهر، فيفهم أن "هناك note تم إنفاقه"، لكنه لا يستطيع ربط ذلك nullifier تحديدًا بأي note بعينها. تؤكد الشبكة صحة الإلغاء (核销)، لكن لا تعرف من قام بالإلغاء.
أشبه ذلك: ليس كتحقق البنك من الحسابات—تفتح صفحة معيّنة فتراها تكشف عن كل المعاملات لشخص ما. بل أقرب إلى تمزيق كل إيصال ثم رميه في آلة التقطيع، وبعد ذلك بإخبار النظام بشكل مُشفّر: "تم الإلغاء لهذه الإيصال". النظام يؤكد أن الإلغاء صحيح، لكن الشخص الذي يمزّق الأيصالات لا يستطيع إعادة بناء الإيصال الأصلي، ولا يعرف لمن كان هذا الإيصال يعود.
لكن هذه البنية ليست بلا تكلفة أيضًا. مع نمو عدد notes، تزيد شجرة Merkle وتعقيد صيانتها؛ إذ يحتاج كل عقدة كاملة إلى الحفاظ على هيكل الشجرة كاملًا. كما أن توليد nullifier يعتمد على افتراضات تشفيرية في الطبقة السفلية؛ فإذا اختيارات المعلمات سارت في اتجاه خاطئ، قد تصبح حماية الخصوصية شكلية. الوثائق الرسمية تنشر تفاصيل البروتوكول، لكن في بيئة الإنتاج، يجب بعد إطلاق الشبكة الرئيسية الاستمرار في المقارنة والتأكد من معدل تصادم nullifier وسرعة تضخم الشجرة.
عندما أنظر إلى طبقة الخصوصية الخاصة بـ #dusk ، لن أكتفي بملاحظة عبارة "استخدمت UTXO". ما يجب تتبعه فعلًا هو منحنى نمو عدد notes، وحجم مجموعة nullifier، وحِمل التخزين على عُقد التحقق. $DUSK تُدرج الخصوصية في قاع البروتوكول، لكن تكلفة صيانة الدفتر في الأسفل—في النهاية—ستنعكس على أداء الشبكة كلها.
#dusk @Dusk
你觉得Phoenix的隐私设计比混币器强在哪
100%
隐私链的账本膨胀是不是无解
0%
Dusk和Zcash的隐私模型差别在哪？
0%
1 الأصوات • تمّ إغلاق التصويت