أثناء استكشاف @boundless_xyz البيئة ، اكتشفت حالة استخدام مثيرة للاهتمام في تطبيقات @RiscZero R0VM: ZK Proof of Exploit - zkPoEx. من بين جميع الأخطاء ، أهمها تلك الموجودة في المنتجات الحية. في العملات المشفرة ، نظرا لأن نقاط الضعف الحرجة تؤدي على الفور إلى استغلال الأموال ، فإن القيمة النقدية للأخطاء الحية مرتفعة للغاية. عادة ، عند العثور على مثل هذه الأخطاء ، تعمل منصات مكافأة الأخطاء مثل @immunefi أو @HackenProof كوسطاء للتحقق من صحة وشدة الخطأ ومعالجة التفاوض على المكافآت. يحتوي هذا الهيكل على مشكلة واحدة: يجب الكشف عن تفاصيل الخطأ قبل أن يتلقى القبعة البيضاء المكافأة. من منظور المشروع ، بعد تلقي تقرير الخطأ ومراجعته ، يمكنهم تصحيحه ثم الادعاء بأنه "خارج النطاق" أو تقليل شدته. في الحالات القصوى للغاية ، يمكن للوسطاء رؤية الثغرة الأمنية واستغلالها أولا. يسمح zkPoEx ، من خلال R0VM الخاص ب RiscZero ، بإثبات وجود ثغرة أمنية باستخدام دليل ZK دون الكشف عن تفاصيل الخطأ. نظرا لأنه يمكن أن يثبت وجود خطأ يفي بشروط معينة ، يمكن لمكتشف الأخطاء توقع المزيد من الاستجابات التعاونية من المشاريع ، مثل طلب الدفع الجزئي مقدما. للشرح بمزيد من التفصيل، يستخدم المبلغ عقد بيانات الاتصال/الاستغلال كمدخلات خاصة وحالة وقت الهجوم كمدخلات عامة لتغيير قيم الحالة للعقد المستهدف داخل R0VM. بعد التنفيذ، يمكن لإيصال الإرسال والإثبات الذي تم إنشاؤه بواسطة R0VM Prover التحقق مما إذا كان الهجوم قد استوفى شروطا محددة، مثل تغييرات الرصيد. أنا شخصيا أعتقد أن هذه الطريقة مفيدة جدا للإبلاغ عن الثغرات الأمنية الحية ، لكنني لم أر أي حالات تم فيها الإبلاغ عن أخطاء باستخدام هذا النهج حتى الآن. يبدو أن ذلك لأن المشاريع تحتاج إلى توفير الشروط مسبقا ... إذا كان من الصعب بالفعل تنفيذ مثل هذا النظام في الممارسة العملية ، فأنا أود أن أعرف ما هي التحديات.