التحقق الرسمي مقابل عمليات التدقيق: لماذا لم يعد "لقد تحققنا من الكود" كافيًا؟

كنت أنام بشكل سليم بعد عمليات التدقيق. لم أعد أفعل ذلك بعد الآن. في المرة الأولى التي شاهدت فيها بروتوكول ما بعد التدقيق يخسر 30 مليون دولار بسبب تفاعل حكومي غاب عنه المدققون، قلت لنفسي إنها حالة طارئة. وفي المرة الثانية، ألقيت اللوم على النطاق. في المرة الثالثة - في وقت ما بعد الوفاة الخامسة التي قرأتها في ذلك الأسبوع - أدركت أن المشكلة لا تكمن في المدققين. لقد كانت المنهجية. عمليات التدقيق هي بشر يقرأون التعليمات البرمجية ويكتبون الاختبارات. البشر يفتقدون الأشياء. الاختبارات تفوت المسارات. وفي العقد الذكي الذي يتعامل مع رأس المال الحقيقي، فإن عبارة "ربما حصلنا على كل شيء" ليست نموذجًا أمنيًا. إنها أمنية. جدول المحتويات أصبح هذا النمط قابلاً للتنبؤ به بشكل قاتم. يعمل البروتوكول على زيادة رأس المال، وتكليف شركة محترمة بإجراء تدقيق، ويتلقى تقريرًا، ويصلح المشكلات التي تم الإبلاغ عنها، وينشر، ويعلن عن "تدقيق" لمجتمعه. وبعد أشهر، وفي بعض الأحيان أسابيع، اختفت الأموال. خسرت شركة Team Finance 14.5 مليون دولار في أكتوبر 2022. وقد قامت شركتان منفصلتان للتدقيق بمراجعة قاعدة التعليمات البرمجية. وقد أشار أحدهم إلى وظيفة الهجرة الضعيفة. تم استغلال العقد على أي حال. في 18 أبريل 2026، تم استنزاف جسر LayerZero الخاص بـ Kelp DAO لـ 116,500 rsETH - ما يقرب من 292 مليون دولار وحوالي 18% من إجمالي العرض المتداول للرمز المميز. لقد أصبح هذا أكبر استغلال للتمويل اللامركزي في عام 2026. الاستنتاج بعد الوفاة: لم يتم انتهاك أي عقد ذكي. لم يتم اختراق أي تشفير بدائي. تم تنفيذ العقود تمامًا كما هو مكتوب. كان هذا الفشل موجودًا في البنية التحتية للتحقق خارج السلسلة - وهي تكوين DVN واحد يسمح للمهاجم بتزوير رسالة عبر السلسلة. لم يتمكن تقرير التدقيق من اكتشاف ذلك لأنه لم يكن هناك أي خطأ في رمز العقد. وفي عام 2025، وصل إجمالي الخسائر عبر Web3 إلى 3.375 مليار دولار أمريكي عبر 313 حادثًا أمنيًا كبيرًا. عندما تصبح عملية التدقيق بمثابة مربع اختيار - وهو شيء يفعله المشروع للإشارة إلى الاجتهاد بدلا من عملية تقلل المخاطر بشكل ملموس - فإن الصناعة تواجه مشكلة هيكلية. وهو كذلك. اسمحوا لي أن أكون دقيقا بشأن ما توفره عملية تدقيق العقود الذكية، لأن الصناعة تميل إلى التستر على هذا الأمر. تتضمن عملية التدقيق قيام فريق من الباحثين الأمنيين بقراءة التعليمات البرمجية الخاصة بك، وتشغيل محللين ثابتين، وكتابة حالات اختبار مخصصة، وتوثيق ما يجدونه. تكتشف أفضل الشركات ثغرات إعادة الدخول، وتجاوزات الأعداد الصحيحة، ومشكلات التحكم في الوصول، والأخطاء المنطقية، وحالات الحافة الاقتصادية الخطيرة. تقاريرهم مفصلة وقيمة حقا. لكن عملية التدقيق مقيدة بالاهتمام البشري ومجموعة السيناريوهات التي يأخذها المدققون في الاعتبار. لا توجد عملية تدقيق تستكشف بشكل شامل كل مسار تنفيذ ممكن من خلال العقد. مساحة الحالة الخاصة بالعقد الذكي غير التافه - كل مجموعة ممكنة من المدخلات، وحالات التخزين، وسياقات المتصل، وتسلسلات التنفيذ - واسعة جدًا بحيث لا يمكن لأي إنسان أو غامض أن يغطيها بشكل شامل. يلتقط Fuzzing ما يقرب من 80% من المشكلات من خلال إنشاء مدخلات عشوائية. أما نسبة الـ 20% المتبقية فتختبئ في حالات الحافة الرياضية التي لا تصل إليها المدخلات العشوائية أبدًا. قد لا يقوم المدقق الذي يختبر سيناريو الإيداع الأول أبدًا بإنشاء الحالة الدقيقة التي يكون فيها TotalSupply 1 وtotalAssets من النوع (uint256).max، مما يؤدي إلى إنشاء هجوم تضخم. يجيب التدقيق: "هل وجدنا أخطاء؟" إنها لا تجيب، ولا يمكنها من الناحية الهيكلية، أن تجيب: "لا توجد أخطاء". هذا ليس انتقادا لمراجعي الحسابات. وهو قيود رياضية للطريقة. يعد التحقق الرسمي فئة مختلفة تمامًا من الضمانات. فبدلاً من جعل البشر يقرأون التعليمات البرمجية ويبحثون عن المشكلات، يقوم التحقق الرسمي بترجمة العقود الذكية إلى مواصفات رياضية ثم يستخدم مُثبتًا آليًا للبحث بشكل شامل عن أي مسار تنفيذ ينتهك تلك المواصفات. المثل لا يتعب. لا تفوت الحالات المتطورة لأنه نفاد الوقت. لا يفشل في التفكير في السيناريو لأنه يبدو غير مرجح. فهو يستكشف بشكل منهجي مساحة الحالة بأكملها التي تحددها المواصفات. إذا وجد المُثبِّت انتهاكًا — انتقال الحالة الذي تقول المواصفات أنه يجب أن يكون مستحيلًا ولكن الكود يسمح به — يفشل العقد في التحقق. يقوم الفريق بإصلاحه والتحقق مرة أخرى. إذا لم يجد المُبرِّر أي مخالفات، فقد قدم برهانًا رياضيًا. ليس احتمالا. ليس مستوى ثقة عاليا. دليل على أنه ضمن الخصائص المحددة، لا يمكن أن يتصرف الكود بطريقة غير محددة. العبارة الأساسية: ضمن الخصائص المحددة. يثبت التحقق الرسمي ما تحدده. إذا قمت بتحديد الأشياء الخاطئة، أو فشلت في تحديد خاصية مهمة، فإن الدليل لا يغطيها. وهذا هو السبب في أن كتابة المواصفات الدقيقة - الثوابت، وقواعد انتقال الحالة، وخصائص التحكم في الوصول - لا تقل أهمية عن تشغيل المُثبِّت. إن أقوى حجة للتحقق الرسمي ليست نظرية. إنها الأخطاء الملموسة التي لا يزال رمز الشحن - الذي راجعه العديد من الخبراء البشريين - يحتوي عليها. احتوت DAI الخاصة بـ MakerDAO، وهي واحدة من قواعد التعليمات البرمجية الأكثر تمحيصًا في DeFi، على انتهاك لمتغيرها الأساسي منذ إطلاقها الأول في نوفمبر 2019 حتى مايو 2022. وكان هذا خطأ رياضيًا في الحساب الأساسي للبروتوكول