#dusk $DUSK @Dusk كنت أراجع اليوم موضع اختبار DUSK الصغير الخاص بي، ووجدت نفسي أقع في افتراضٍ أساسي إلى حد ما: كنت أعتقد أن شجرات ميركل والبراهين ذات المعرفة الصفرية تقومان تقريبًا بنفس المهمة.

لكن النظر بعمق في @Dusk غيّر ذلك بالنسبة لي.

Dusk-Merkle وPLONK ليستا قابلتين للتبادل. فهما تحلان مشكلات مختلفة، وتلك التفرقة مهمة لفهم مصدر الخصوصية فعليًا.

Dusk-Merkle عبارة عن شجرة ميركل رقيقة (sparse) مخصّصة، وهي محايدة دالّة التجزئة (hash-function agnostic). يمكن استخدامها في أجزاء مختلفة من الشبكة، بما في ذلك Stake وTransfer وCitadel.

الطريقة البسيطة التي أفكر بها الآن:

Merkle = الالتزام بالـ state (الحالة).
PLONK = إثبات عملية حسابية.

يمكن لشجرة ميركل ضغط حالةٍ منظّمة إلى جذر. ثم يمكن لفتح ميركل (Merkle opening) أن يثبت أن عنصرًا بعينه ينتمي إلى البنية التي تم الالتزام بها، دون أن يحتاج المُتحقق إلى معالجة الشجرة كاملة.

أما PLONK فيذهب إلى مكانٍ آخر. فهو يسمح للمُثبت بإظهار أن عبارةً أو عملية حسابية تُطابق دائرة (circuit) معيّنة دون كشف المعلومات الخاصة المستخدمة لإنتاج ذلك البرهان.

هذه الفواصل جعلت بنية $DUSK أسهل لفهمها بالنسبة لي.

الشجرة ترتّب الحالة وتلتزم بها.
الدائرة تحدد ما يجب أن يكون صحيحًا.
البرهان يُظهر أن القواعد قد تم الالتزام بها.
يمكن للعقد عندها تحديد ما تكون عليه عملية انتقال الحالة التالية.

لكن الجزء الذي أجده أكثر إثارة للاهتمام هو التالي.

المرونة ليست تلقائيًا أمانًا.

تصميم ميركل محايد لدوال التجزئة ما يزال يعتمد على اختيار دالة التجزئة المناسبة وتنفيذ عمليات الفتح بشكل صحيح. وبالمثل، دوائر PLONK القابلة لإعادة الاستخدام لها مفاضلة شبيهة: فهي تقلل العمل المكرر، لكن يمكن أن يتم إعادة استخدام افتراضٍ خاطئ عبر تطبيقات متعددة.

لذلك أنا لست فقط أراقب ما إذا كان DUSK يستخدم ZK.

أنا أراقب ما إذا كان كل عنصر تشفيري يؤدي بالضبط المهمة التي يفترض به القيام بها.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS

ما الأهم لخصوصية Dusk؟