@Dusk بحثتُ عن ما الذي تَعِدُ به فعلاً عبارة "PLONK

proof verified" عند مستوى العقدة

، إذ إن أغلب الشروح تتعامل مع التحقق بوصفه بوابة مرور/رفض واحدة دون ما يزيد عن ذلك.

يؤكد مسار ما قبل التحقق لدى Dusk أن كل معاملة من معاملات Phoenix تمر عبر

دالة مخصصة للتحقق من البرهان قبل قبولها في mempool.
هذه هي نقطة التحقق التي يعتمد عليها نموذج الخصوصية بالكامل

— لا برهان، لا قبول. $DUSK

وهذه هي النقطة التي يستحق الجلوس معها.

أشارت مراجعة أمنية لطرف ثالث إلى أن في هذه النقطة كان هناك فجوة:

بعض التقييمات داخل التحقق من PLONK

لم تكن تُفحَص بالكامل بالطريقة التي افترضها التصميم.
وقد تم إجراء الإصلاح على شكل التزام (commit) محدد في وقت سابق من هذا العام.

إنها تذكير بأن "تم التحقق باستخدام برهان ZK" ليس

ضماناً ثابتاً — بل هو قوي بقدر كود

يقوم بالتأكد،
وبإمكان ذلك الكود أن يحتوي على ثغرات عمياء يمكن أن تكشفها عمليات التدقيق.

تتبعتُ ما يعنيه ذلك عملياً:

لم تكن الفجوة تعني أن برهانات مزيفة كانت

تمر عبر الإنتاج بلا رادع، إذ كانت حزمة Dusk قد

خضعت بالفعل لعدة مراجعات سابقة لنظام

إثباتات ومكتبة العقدة.

لكن هذا يعني أن ادعاء "يتم فحص البرهان"

يستند إلى تدقيق مستمر، وليس إلى ضمان

تشفيري لمرة واحدة لا يحتاج إلى إعادة نظر. #dusk
ما لم أتحقق منه من المواد الخاصة بـ Dusk هو

ما إذا كانت عمليات التدقيق المستقلة لمسار التحقق تُجرى على وتيرة ثابتة مستقبلاً,

أم أنها تحدث بشكل انتهازي كلما قررت شركة أمنية أن تنظر.
@Dusk #dusk $DUSK