عندما بدأت للتو استخدام Dusk، كانت لدي في قلبي حيرة كبيرة. وبما أن هناك مشاريع أخرى أيضًا سلاسل خصوصية، فمن السهل على أي شخص تشغيل عقدة والانضمام للمشاركة في إنتاج الكتل، بينما تعتمد Dusk فقط على عقد مرخّصة. في ذلك الوقت، شعرت بشكل لا إرادي أنها تتخلى عن اللامركزية من أجل التقدم بشكل أسرع، فضعف انطباعي مباشرة.

لكن بعد أن تهدّيت وأعدت ترتيب فهمي لمجمل بنية الطبقة الأساسية، أدركت أن تفسيرّي السابق كان منحرفًا. بصراحة، هذا ليس تنازلًا صنعه فريق التطوير لتوفير الوقت، بل هو ترتيب بنيوي لا مفر منه بالنسبة للخصوصية المُمكّنة بالمعرفة الصفرية (ZK).

@Dusk لقد قسّم ببراعة بين تنفيذ العقود وإجماع الكتل إلى مرحلتين مستقلّتين. داخل بيئة Piecrust VM المعزولة يتم تشغيل العقد لإنتاج إثباتات ZK، ولا يتم تسريب أي معلومات حساسة طوال العملية مثل مبالغ المعاملات وعناوين المستخدمين. عقد التحقق التابعة للجنة SBA لا ترى محتوى المعاملة الأصلي، بل تتحقق فقط مما إذا كان الإثبات نفسه موثوقًا، ثم تحسم الحالة النهائية للكتلة.

بعبارة أخرى، عقد التحقق مثل طالب يراجع من دون كتاب (إجابات مفتوحة)، ولا يحصل على «سؤال الامتحان» الخاص بالمرشحين. وبمجرد فتح الباب بلا قيود، قد تتدفق أعداد كبيرة من العقد ذات المصادر غير الواضحة، ما قد يخلق بسهولة ثغرات من نوع تعطل التحقق أو تشغيل خبيث بلا هدف، وبذلك يصبح من الصعب حماية خصوصية المستخدمين.

بالطبع، لهذه الخطة أيضًا بعض نقاط القصور التي لا يمكن تجاوزها. مسار الترجمة الجديد لـ WASM‑ZK سيرفع تكلفة توليد الإثباتات؛ كما أن نموذج التصفية عبر الترخيص لا بد أن يثير احتمال تركّز العقد بشكل مفرط. $DUSK

الآن، ما أراقبه تحديدًا هو ما إذا كان بعد قيام عدد كبير من كيانات RWA بأصولها بربطها بالسلسلة، يمكن التحكم في تكلفة التحقق، وتنسيق العلاقة بين الخصوصية والأمان واللامركزية على نحو مناسب.

كيف يقيّم الجميع إجماع Dusk باستخدام عقد مرخّصة؟

#dusk $DUSK @Dusk