ثغرة Dusk في PLONK: طبقة خصوصية بقيمة 600 ألف دولار كادت تُخترق عبر تزوير إثبات
بعد أن قرأت تقرير الأمان الذي كشفته OtterSec بتاريخ 30 أبريل 2026، تجمدت تقريبًا لمدة خمس دقائق. لم تقم مُثبتات dusk-plonk على الإطلاق بالتحقق من التزامات المضلعات الأربعة التي يقدّمها المُثبت. ببساطة، يستطيع المهاجم تزوير إثبات زائف للمعرفة الصفرية دون الحاجة إلى أي أصول حقيقية لِصكّ رموز DUSK ونقل العائدات غير المشروعة. بروتوكول خصوصية صُمّم لأسواق مالية مُنظّمة، لكن جوهره التشفيري يحتوي على ثغرة تسمح للمهاجم بالخلق الوهمي للرموز. بنية تحتية تدّعي أن المؤسسات يمكنها الوثوق بها عند النشر على السلسلة، لكن توجد فيها عيوب جوهرية على مستوى طبقة الخصوصية.
سردية الامتثال في ورقة الـ whitepaper جميلة، لكن الكود يكاد يفتح بابًا خلفيًا للّصك غير المحدود. يمكنك القول إن الثغرة تمت معالجتها. لكن ظهور هذا النوع من الثغرات في مرحلة التحقق داخل طبقة الخصوصية بحد ذاته هو إهانة مباشرة لمبدأ «الخصوصية أولًا». مشروع يعيش على ZK، وقد ظهرت فيه مشكلة في تنفيذ ZK. أول سؤال راودني بعد قراءة التقرير هو—إذا كانت سلسلة خصوصية تعيش على ZK، فما الذي قد لا يسوء أيضًا في تنفيذها؟ لقد تراجعت القيمة السوقية لـDusk من أعلى مستوياتها بشكل كبير؛ و600 ألف دولار وفقًا لسعر العملة آنذاك، إذا استغل المهاجم هذه الثغرة لصكّ كميات كبيرة من الرموز، فقد يتم سحق السعر مباشرة. @Dusk
وجدت تقرير تدقيقًا لـDusk وقمت بتصفحه. الجهة المُدقِّقة هي Dust Labs، ونطاق التدقيق يغطي فقط بعض الوحدات. فهل منطق التحقق الخاص بـdusk-plonk ضمن نطاق التدقيق؟ لم أجد توضيحًا صريحًا. إذا تم إغفال كود طبقة الخصوصية الأساسية في التدقيق، أو إذا لم يكن التدقيق أصلًا يغطي كل ما يلزم، فستحتاج قيمة تقرير التدقيق إلى إعادة تقييم. التدقيق لا يُجرى مرة واحدة وينتهي الأمر.
أنا لا أقول إن Dusk غير موثوق، لكن مشروعًا يكتب «الخصوصية» في اسمه، ويعاني من ثغرة جوهرية من هذا النوع في طبقة التحقق الأساسية لـZK، من الصعب عليّ أن أقنع نفسي بالاستمرار في الاحتفاظ به. لنرَ الأمر بعد أن يتم التحقق من جوهر التشفير عبر جولات إضافية. سأضعه مؤقتًا في قائمة الملاحظة، وأرى ما إذا كانت ستظهر إفصاحات عن ثغرات جديدة لاحقًا. إذا تكرّر ظهور المشكلة في نفس الوحدة مرة أخرى، فسيكون ذلك ليس مجرد مشكلة تقنية، بل مشكلة في العملية أيضًا.
#dusk $DUSK
بعد أن قرأت تقرير الأمان الذي كشفته OtterSec بتاريخ 30 أبريل 2026، تجمدت تقريبًا لمدة خمس دقائق. لم تقم مُثبتات dusk-plonk على الإطلاق بالتحقق من التزامات المضلعات الأربعة التي يقدّمها المُثبت. ببساطة، يستطيع المهاجم تزوير إثبات زائف للمعرفة الصفرية دون الحاجة إلى أي أصول حقيقية لِصكّ رموز DUSK ونقل العائدات غير المشروعة. بروتوكول خصوصية صُمّم لأسواق مالية مُنظّمة، لكن جوهره التشفيري يحتوي على ثغرة تسمح للمهاجم بالخلق الوهمي للرموز. بنية تحتية تدّعي أن المؤسسات يمكنها الوثوق بها عند النشر على السلسلة، لكن توجد فيها عيوب جوهرية على مستوى طبقة الخصوصية.
سردية الامتثال في ورقة الـ whitepaper جميلة، لكن الكود يكاد يفتح بابًا خلفيًا للّصك غير المحدود. يمكنك القول إن الثغرة تمت معالجتها. لكن ظهور هذا النوع من الثغرات في مرحلة التحقق داخل طبقة الخصوصية بحد ذاته هو إهانة مباشرة لمبدأ «الخصوصية أولًا». مشروع يعيش على ZK، وقد ظهرت فيه مشكلة في تنفيذ ZK. أول سؤال راودني بعد قراءة التقرير هو—إذا كانت سلسلة خصوصية تعيش على ZK، فما الذي قد لا يسوء أيضًا في تنفيذها؟ لقد تراجعت القيمة السوقية لـDusk من أعلى مستوياتها بشكل كبير؛ و600 ألف دولار وفقًا لسعر العملة آنذاك، إذا استغل المهاجم هذه الثغرة لصكّ كميات كبيرة من الرموز، فقد يتم سحق السعر مباشرة. @Dusk
وجدت تقرير تدقيقًا لـDusk وقمت بتصفحه. الجهة المُدقِّقة هي Dust Labs، ونطاق التدقيق يغطي فقط بعض الوحدات. فهل منطق التحقق الخاص بـdusk-plonk ضمن نطاق التدقيق؟ لم أجد توضيحًا صريحًا. إذا تم إغفال كود طبقة الخصوصية الأساسية في التدقيق، أو إذا لم يكن التدقيق أصلًا يغطي كل ما يلزم، فستحتاج قيمة تقرير التدقيق إلى إعادة تقييم. التدقيق لا يُجرى مرة واحدة وينتهي الأمر.
أنا لا أقول إن Dusk غير موثوق، لكن مشروعًا يكتب «الخصوصية» في اسمه، ويعاني من ثغرة جوهرية من هذا النوع في طبقة التحقق الأساسية لـZK، من الصعب عليّ أن أقنع نفسي بالاستمرار في الاحتفاظ به. لنرَ الأمر بعد أن يتم التحقق من جوهر التشفير عبر جولات إضافية. سأضعه مؤقتًا في قائمة الملاحظة، وأرى ما إذا كانت ستظهر إفصاحات عن ثغرات جديدة لاحقًا. إذا تكرّر ظهور المشكلة في نفس الوحدة مرة أخرى، فسيكون ذلك ليس مجرد مشكلة تقنية، بل مشكلة في العملية أيضًا.
#dusk $DUSK
